데이터 베이스 MySQL 튜토리얼 HBase MVCC and built-in Atomic Operations

HBase MVCC and built-in Atomic Operations

Jun 07, 2016 pm 04:28 PM
and atomic hbase mvcc

By Lars Hofhansl (This is a follow to my ACID in HBase post from March this year) HBase has a few special atomic operations: checkAndPut, checkAndDelete - these simply check a value of a column as a precondition and then apply the Put or D

By Lars Hofhansl

(This is a follow to my ACID in HBase post from March this year)
HBase has a few special atomic operations:
  • checkAndPut, checkAndDelete - these simply check a value of a column as a precondition and then apply the Put or Delete if the check succeeded.
  • Increment, Append - these allow an atomic add to a column value interpreted as an integer, or append to the end of a column, resp.
checkAndPut and checkAndDelete are idempotent in the sense that they can safely be applied multiple time (but note that their outcome might differ when other changes are applied between the retries).

Increment and Append are not idempotent. They are the only non-repeatable operations in HBase. Increment and Append are also the only operations for which the snapshot isolation provided by HBase's MVCC model is not sufficient... More on that later.

In turns out that checkAndPut and checkAndDelete are not as atomic as expected (the issue was raised by Gregory and despite me not believing it first he is right - see HBASE-7051).

A look at the code makes this quite obvious:
Some of the Put optimizations (HBASE-4528) allow releasing the rowlock before the changes are sync'ed to the WAL. This also requires the lock to be released before the MVCC changes are committed so that changes are not visible to other transaction before they are guaranteed to be durable.
Another operation (such as checkAndXXX) that acquires the rowlock to make atomic changes may in fact not see current picture of things despite holding the rowlock as there could be still outstanding MVCC changes that only become visible after the row lock was release and re-acquired. So it might operate on stale data. Holding the rowlock is no longer good enough after HBASE-4528.

Increment and Append have the same issue.

The fix for this part is relatively simple: We need a "MVCC barrier" of sorts. Instead of completing a single MVCC transaction at the end of the update phase (which will wait for all prior transactions to finish), we just wait a little earlier instead for prior transactions to finish before we start the check or get phase of the atomic operation. This only reduces concurrency slightly, since before the end of the operation we have to await all prior transactions anyway. HBASE-7051 does exactly that for the checkAndXXX operations.

In addition - as mentioned above - Increment and Append have another issue, they need to be serializable transactions. Snapshot isolation is not good enough.
For example: If you start with 0 and issue an increment of 1 and another increment of 2 the outcome must always be 3. If both could start with the same start value (a snapshot) the outcome could 1 or 2 depending on which one finishes first.

Increment and Append currently skirt the issue with an ugly "hack": When they write their changes into the memstore they set the memstoreTS of all new KeyValues to 0! The effect is that they are made visible to other transactions immediately, violating HBase's MVCC. Again see ACID in HBase for an explanation of the memstoreTS.
This guarantees the correct outcome of concurrent Increment and Append operations, but the visibility to concurrent scanners is not what you expect. An Incremented and Appended value even for partial rows can be become visible to any scanner at any time even though the scanner should see an earlier snapshot of the data.
Increment and Append are also designed for very high throughput so they actually manipulate HBase's memstore to remove older versions of the columns just modified. Thus you lose the version history of the changes in exchange for avoiding a memstore exploding with version of the many Increments or Appends. This is called "upsert" in HBase. Upsert is nice in that it prevents the memstore being filled will a lot of old value if nobody cares for them. The downside is that is a special operation on the memstore, and hard to get right w.r.t. MVCC. It also does not work with mslab (see this Cloudera blog post for explanation of mslab).

If you don't care about visibility this is a simple problem, since you can just look through the memstore and remove old values. If you care about MVCC, though, you have to prove first that is safe to remove a KV.

I tried to fix this almost exactly a year ago (HBASE-4583), but after some discussions with my fellow committers we collectively gave up on that.

A few days ago I reopened HBASE-4583 and started with a radical patch that gets rid of all upsert-type logic (which set the memstoreTS to 0) and just awaits prior transactions before commencing the Increment/Append. Then I rely on my changes from HBASE-4241 to only flush the versions of columns needed when it is time to flush the memstore to disk. Turns out this is still quite a bit slower (10-15%), since it needs to flush the memstore frequently even thought it leads to mostly empty files. Still that was nice try, as it gets rid of a lot of special code and turns Increment and Append into normal HBase citizens.

A 2nd less radical version makes upsert MVCC aware.

That is actually not as easy as it looks. In order to remove a version of a column (a KeyValue) from the memstore you have to prove that is not and will not be seen by any concurrent or future scanner. That means we have to find the earliest readpoint of any scanner and ensure that there is at least one version of the KV older than that smallest readpoint; then we can safely remove any older versions of that KV from the memstore - because any scanner is guaranteed to see a newer version of the KV.
The "less radical" patch in  does exactly that.

In the end the patch I ended up committed with HBASE-4583 does both:
If the column family that has the column to be incremented or appended to has VERSIONS set to 1, we perform an MVCC aware upsert added by the patch. If VERSIONS is > 1, we use the usual logic to add a KeyValue to the memstore. So now this behaves as expected in all cases. If multiple versions are requested they are retained and time range queries will work even with Increment and Append; and it also keeps the performance characteristics (mostly) when VERSIONS is set to 1.

본 웹사이트의 성명
본 글의 내용은 네티즌들의 자발적인 기여로 작성되었으며, 저작권은 원저작자에게 있습니다. 본 사이트는 이에 상응하는 법적 책임을 지지 않습니다. 표절이나 침해가 의심되는 콘텐츠를 발견한 경우 admin@php.cn으로 문의하세요.

핫 AI 도구

Undresser.AI Undress

Undresser.AI Undress

사실적인 누드 사진을 만들기 위한 AI 기반 앱

AI Clothes Remover

AI Clothes Remover

사진에서 옷을 제거하는 온라인 AI 도구입니다.

Undress AI Tool

Undress AI Tool

무료로 이미지를 벗다

Clothoff.io

Clothoff.io

AI 옷 제거제

Video Face Swap

Video Face Swap

완전히 무료인 AI 얼굴 교환 도구를 사용하여 모든 비디오의 얼굴을 쉽게 바꾸세요!

뜨거운 도구

메모장++7.3.1

메모장++7.3.1

사용하기 쉬운 무료 코드 편집기

SublimeText3 중국어 버전

SublimeText3 중국어 버전

중국어 버전, 사용하기 매우 쉽습니다.

스튜디오 13.0.1 보내기

스튜디오 13.0.1 보내기

강력한 PHP 통합 개발 환경

드림위버 CS6

드림위버 CS6

시각적 웹 개발 도구

SublimeText3 Mac 버전

SublimeText3 Mac 버전

신 수준의 코드 편집 소프트웨어(SublimeText3)

빅 데이터 저장 및 쿼리를 위해 Beego에서 Hadoop 및 HBase 사용 빅 데이터 저장 및 쿼리를 위해 Beego에서 Hadoop 및 HBase 사용 Jun 22, 2023 am 10:21 AM

빅데이터 시대가 도래하면서 데이터의 처리와 저장이 더욱 중요해지고 있으며, 대용량 데이터를 어떻게 효율적으로 관리하고 분석할 것인가가 기업의 과제가 되었습니다. Apache Foundation의 두 가지 프로젝트인 Hadoop과 HBase는 빅데이터 저장 및 분석을 위한 솔루션을 제공합니다. 이 기사에서는 빅데이터 저장 및 쿼리를 위해 Beego에서 Hadoop 및 HBase를 사용하는 방법을 소개합니다. 1. Hadoop 및 HBase 소개 Hadoop은 오픈 소스 분산 스토리지 및 컴퓨팅 시스템입니다.

MySQL MVCC 원리 및 구현에 대한 심층 분석 MySQL MVCC 원리 및 구현에 대한 심층 분석 Sep 09, 2023 pm 08:07 PM

MySQLMVCC의 원리와 구현에 대한 심층 분석 MySQL은 현재 가장 널리 사용되는 관계형 데이터베이스 관리 시스템 중 하나이며 효율적인 동시 처리를 지원하는 다중 버전 동시성 제어(MultiversionConcurrencyControl, MVCC) 메커니즘을 제공합니다. MVCC는 높은 동시성과 격리성을 제공할 수 있는 데이터베이스에서 동시 트랜잭션을 처리하는 방법입니다. 이 기사에서는 MySQLMVCC의 원리와 구현에 대한 심층 분석을 제공하고 코드 예제를 통해 이를 설명합니다. 1. 엠

MySQL MVCC 원칙 및 모범 사례에 대한 심층적인 해석 MySQL MVCC 원칙 및 모범 사례에 대한 심층적인 해석 Sep 09, 2023 am 11:40 AM

MySQLMVCC 원칙 및 모범 사례에 대한 심층 해석 1. 개요 MySQL은 동시 액세스 문제를 처리하기 위해 MVCC(다중 버전 동시성 제어) 메커니즘을 지원하는 가장 널리 사용되는 관계형 데이터베이스 관리 시스템 중 하나입니다. 이 문서에서는 MySQLMVCC의 원리에 대한 심층적인 설명을 제공하고 몇 가지 모범 사례를 제공합니다. 2. MVCC 원칙 버전 번호 MVCC는 추가로 추가됩니다.

MySQL MVCC의 원리를 이해하고 데이터베이스 트랜잭션 처리를 최적화합니다. MySQL MVCC의 원리를 이해하고 데이터베이스 트랜잭션 처리를 최적화합니다. Sep 09, 2023 am 09:42 AM

MySQLMVCC의 원리를 이해하고 데이터베이스 트랜잭션 처리를 최적화합니다. 최근 몇 년 동안 데이터 볼륨이 지속적으로 증가하고 애플리케이션 요구 사항이 개선됨에 따라 데이터베이스 트랜잭션 처리의 성능 최적화는 데이터베이스 개발과 운영 및 유지 관리에 매우 중요한 링크가 되었습니다. 가장 일반적으로 사용되는 오픈소스 관계형 데이터베이스 중 하나인 MySQL의 MVCC(Multi-VersionConcurrencyControl) 원칙은 트랜잭션 처리에서 중요한 역할을 합니다. 이 기사에서는 MySQLMVCC의 원리를 소개하고

MySQL MVCC의 원리를 익히고 데이터 읽기 효율성을 향상시키세요. MySQL MVCC의 원리를 익히고 데이터 읽기 효율성을 향상시키세요. Sep 10, 2023 pm 04:34 PM

MySQLMVCC의 원리를 익히고 데이터 읽기 효율성을 향상시키세요. 소개: MySQL은 일반적으로 사용되는 관계형 데이터베이스 관리 시스템이고 MVCC(Multi-VersionConcurrencyControl)는 MySQL에서 일반적으로 사용되는 동시성 제어 메커니즘입니다. MVCC 원리를 익히면 MySQL의 내부 작동 원리를 더 잘 이해하고 데이터 읽기 효율성을 향상시키는 데 도움이 될 수 있습니다. 이 기사에서는 MVCC의 원리와 이 원리를 사용하여 데이터 읽기 효율성을 향상시키는 방법을 소개합니다.

Java에서 원자성 기능을 사용하는 방법은 무엇입니까? Java에서 원자성 기능을 사용하는 방법은 무엇입니까? May 09, 2023 pm 04:40 PM

스레드 안전성: 여러 스레드가 클래스에 액세스할 때 클래스는 런타임 환경에서 사용하는 스케줄링 방법이나 해당 프로세스가 실행을 대체하는 방식에 관계없이 작동하며 호출 코드에서 추가 동기화 또는 조정이 필요하지 않습니다. 클래스는 스레드로부터 안전하다고 합니다. 스레드 안전성은 주로 다음 세 가지 측면에 반영됩니다. 원자성: 상호 배타적인 액세스가 제공되며 동시에 하나의 스레드만 작동할 수 있습니다. 가시성: 한 스레드의 주 메모리 수정 사항을 다른 스레드에서 관찰할 수 있습니다. 적시성 : 스레드가 다른 스레드의 명령 실행 순서를 관찰합니다. 명령 재정렬로 인해 관찰 결과는 일반적으로 JUC의 Atomic 패키지에 대한 자세한 설명입니다. .

Mysql MVCC 다중 버전 동시성 제어 지식 포인트는 무엇입니까? Mysql MVCC 다중 버전 동시성 제어 지식 포인트는 무엇입니까? May 27, 2023 pm 11:31 PM

1. MVCCMVCC, 정식 명칭은 Multi-VersionConcurrencyControl이며, 이는 다중 버전 동시성 제어입니다. MVCC는 일반적으로 데이터베이스 관리 시스템에서 데이터베이스에 대한 동시 액세스를 달성하고 프로그래밍 언어로 트랜잭션 메모리를 구현하는 데 사용됩니다. MySQLInnoDB에서 MVCC 구현은 주로 데이터베이스 동시성 성능을 향상시키고 읽기 및 쓰기 충돌을 처리하는 더 나은 방법을 사용하여 > 읽기 및 쓰기 충돌이 있더라도 잠금 및 비차단 동시 읽기를 달성할 수 없습니다. 2. 현재 읽기는 selectlockinsharemode(공유 잠금), selectforupdate, insert, de와 같습니다.

MySQL 다중 버전 동시성 제어 MVCC 인스턴스 분석 MySQL 다중 버전 동시성 제어 MVCC 인스턴스 분석 Jun 03, 2023 am 11:51 AM

1. 다중 버전 동시성 제어, MVCCMVCC(MultiversionConcurrencyControl)란 무엇입니까? 이름에서 알 수 있듯이 MVCC는 데이터 행의 다중 버전 관리를 통해 데이터베이스 동시성 제어를 구현합니다. 이 기술은 InnoDB의 트랜잭션 격리 수준에서 일관된 읽기 작업을 보장합니다. 즉, 다른 트랜잭션에 의해 업데이트되고 있는 일부 행을 쿼리하여 업데이트되기 전의 값을 확인할 수 있기 때문에 쿼리 수행 시 다른 트랜잭션이 잠금을 해제할 때까지 기다릴 필요가 없다. . MVCC에 대한 공식적인 표준은 없습니다. MVCC의 구현은 DBMS마다 다를 수 있으며 보편적으로 사용되지 않습니다(관련 DBMS 설명서를 참조할 수 있음).

See all articles