HBase 사용의 이론과 실제

좋은 오후에요 제 이름은 Danil Lipovoy입니다. Sbertech의 우리 팀은 HBase를 운영 데이터용 스토리지로 사용하기 시작했습니다. 공부하는 과정에서 체계화하고 설명하고 싶은 경험이 쌓였습니다 (많은 분들께 도움이 되길 바랍니다). 아래의 모든 실험은 HBase 버전 1.2.0-cdh5.14.2 및 2.0.0-cdh6.0.0-beta1을 사용하여 수행되었습니다.

1. 일반 아키텍처
2. HBASE에 데이터 쓰기
3. HBASE에서 데이터 읽기
4. 데이터 캐싱
5. 일괄 데이터 처리 MultiGet/MultiPut
6. 테이블을 영역으로 분할하는 전략(분할)
7. 내결함성, 압축 및 데이터 지역성
8. 설정 및 성능
9. 스트레스 테스트
10. 조사 결과

1. 일반 아키텍처

백업 마스터는 ZooKeeper 노드에 있는 활성 마스터의 하트비트를 듣고, 사라지는 경우 마스터의 기능을 대신합니다.

2. HBASE에 데이터 쓰기

먼저, 가장 간단한 경우인 put(rowkey)를 사용하여 테이블에 키-값 객체를 쓰는 경우를 살펴보겠습니다. 클라이언트는 먼저 hbase:meta 테이블을 저장하는 루트 영역 서버(RRS)가 어디에 있는지 찾아야 합니다. 그는 ZooKeeper로부터 이 정보를 받습니다. 그런 다음 RRS에 액세스하고 hbase:meta 테이블을 읽습니다. 여기서 RS(RegionServer)가 관심 테이블에 지정된 rowkey에 대한 데이터를 저장하는 일을 담당하는 정보를 추출합니다. 나중에 사용할 수 있도록 메타 테이블은 클라이언트에 의해 캐시되므로 후속 호출은 RS로 직접 더 빠르게 진행됩니다.

다음으로, 요청을 받은 RS는 먼저 이를 WriteAheadLog(WAL)에 기록합니다. 이는 충돌 발생 시 복구에 필요합니다. 그런 다음 데이터를 MemStore에 저장합니다. 이는 특정 영역에 대해 정렬된 키 세트를 포함하는 메모리의 버퍼입니다. 테이블은 여러 영역(파티션)으로 나눌 수 있으며, 각 영역에는 분리된 키 집합이 포함되어 있습니다. 이를 통해 서로 다른 서버에 지역을 배치하여 더 높은 성능을 얻을 수 있습니다. 그러나 이 진술이 명백함에도 불구하고 이것이 모든 경우에 작동하는 것은 아니라는 점을 나중에 알게 될 것입니다.

MemStore에 항목을 배치한 후 항목이 성공적으로 저장되었다는 응답이 클라이언트에 반환됩니다. 그러나 실제로는 버퍼에만 저장되며, 일정 시간이 지나거나 새로운 데이터가 채워져야만 디스크에 도달하게 됩니다.

'삭제' 작업을 수행할 때 데이터는 물리적으로 삭제되지 않습니다. 단순히 삭제된 것으로 표시되며, 주요 압축 함수를 호출하는 순간 파기 자체가 발생합니다. 이에 대한 자세한 내용은 7문단에 설명되어 있습니다.

HFile 형식의 파일은 HDFS에 축적되며 때때로 아무것도 삭제하지 않고 작은 파일을 큰 파일로 병합하는 작은 압축 프로세스가 시작됩니다. 시간이 지남에 따라 이는 데이터를 읽을 때만 나타나는 문제로 변합니다(이에 대해서는 나중에 다시 설명하겠습니다).

위에서 설명한 로드 프로세스 외에도 훨씬 더 효과적인 절차가 있는데, 이는 아마도 이 데이터베이스의 가장 강력한 측면인 BulkLoad입니다. 그것은 우리가 독립적으로 HFiles를 형성하고 이를 디스크에 저장한다는 사실에 있습니다. 이를 통해 우리는 완벽하게 확장하고 매우 적절한 속도를 달성할 수 있습니다. 실제로 여기서의 제한은 HBase가 아니라 하드웨어의 기능입니다. 다음은 16개의 RegionServer와 16개의 NodeManager YARN(CPU Xeon E5-2680 v4 @ 2.40GHz * 64 스레드), HBase 버전 1.2.0-cdh5.14.2로 구성된 클러스터의 부팅 결과입니다.

여기서는 테이블의 파티션(지역) 수와 Spark 실행 프로그램의 수를 늘리면 다운로드 속도가 빨라지는 것을 확인할 수 있습니다. 또한 속도는 녹음 볼륨에 따라 달라집니다. 큰 블록은 MB/초를 증가시키고 작은 블록은 단위 시간당 삽입된 레코드 수를 증가시키며 다른 모든 조건은 동일합니다.

동시에 두 개의 테이블에 로드를 시작하여 속도를 두 배로 높일 수도 있습니다. 아래에서는 한 번에 두 테이블에 10KB 블록을 쓰는 것이 각각 약 600MB/초(총 1275MB/초)의 속도로 발생하는 것을 볼 수 있습니다. 이는 하나의 테이블에 쓰는 속도인 623MB/초와 일치합니다. 위 11번)

그러나 50KB의 레코드를 사용한 두 번째 실행에서는 다운로드 속도가 약간 증가하고 있으며 이는 제한 값에 접근하고 있음을 나타냅니다. 동시에, 실제로 HBASE 자체에는 로드가 생성되지 않는다는 점을 명심해야 합니다. 필요한 것은 먼저 hbase:meta에서 데이터를 제공하고 HFiles를 라이닝한 후 BlockCache 데이터를 재설정하고 비어 있지 않은 경우 디스크에 대한 MemStore 버퍼입니다.

3. HBASE에서 데이터 읽기

클라이언트가 이미 hbase:meta의 모든 정보를 가지고 있다고 가정하면(포인트 2 참조) 요청은 필요한 키가 저장된 RS로 직접 이동합니다. 먼저 MemCache에서 검색이 수행됩니다. 데이터가 있는지 여부에 관계없이 BlockCache 버퍼와 필요한 경우 HFiles에서도 검색이 수행됩니다. 파일에서 데이터가 발견되면 BlockCache에 저장되며 다음 요청 시 더 빠르게 반환됩니다. Bloom 필터를 사용하면 HFile에서 검색하는 것이 상대적으로 빠릅니다. 소량의 데이터를 읽은 후 이 파일에 필요한 키가 포함되어 있는지 즉시 확인하고 그렇지 않은 경우 다음 파일로 이동합니다.

이 세 가지 소스로부터 데이터를 수신하면 RS는 응답을 생성합니다. 특히, 클라이언트가 버전 관리를 요청한 경우 발견된 여러 버전의 객체를 한 번에 전송할 수 있습니다.

4. 데이터 캐싱

MemStore 및 BlockCache 버퍼는 할당된 온 힙 RS 메모리의 최대 80%를 차지합니다(나머지는 RS 서비스 작업용으로 예약됨). 일반적인 사용 모드가 프로세스가 동일한 데이터를 쓰고 즉시 읽는 것이라면 BlockCache를 줄이고 MemStore를 늘리는 것이 합리적입니다. 쓰기 데이터가 읽기를 위해 캐시에 들어가지 않으면 BlockCache의 사용 빈도가 줄어듭니다. BlockCache 버퍼는 LruBlockCache(항상 힙에 있음)와 BucketCache(일반적으로 힙에 있지 않거나 SSD에 있음)의 두 부분으로 구성됩니다. BucketCache는 읽기 요청이 많고 LruBlockCache에 맞지 않아 Garbage Collector가 활발하게 작동하는 경우에 사용해야 합니다. 동시에 읽기 캐시를 사용하여 성능이 크게 향상될 것이라고 기대해서는 안 되지만 이에 대해서는 8문단에서 다시 설명하겠습니다.

전체 RS에 하나의 BlockCache가 있고 각 테이블마다 하나의 MemStore가 있습니다(각 Column Family에 하나씩).

방법 설명 이론적으로 쓰기 시 데이터는 캐시에 들어가지 않으며 실제로 테이블의 경우 CACHE_DATA_ON_WRITE 매개변수와 RS의 "Cache DATA on Write"는 false로 설정됩니다. 그러나 실제로 MemStore에 데이터를 쓴 다음 디스크에 플러시(따라서 삭제)한 다음 결과 파일을 삭제하면 get 요청을 실행하여 데이터를 성공적으로 수신하게 됩니다. 또한 BlockCache를 완전히 비활성화하고 테이블을 새 데이터로 채운 다음 MemStore를 디스크로 재설정하고 삭제하고 다른 세션에서 요청하더라도 여전히 어딘가에서 검색됩니다. 그래서 HBase는 데이터뿐만 아니라 신비한 미스터리도 저장합니다.

hbase(main):001:0> create 'ns:magic', 'cf'
Created table ns:magic
Took 1.1533 seconds
hbase(main):002:0> put 'ns:magic', 'key1', 'cf:c', 'try_to_delete_me'
Took 0.2610 seconds
hbase(main):003:0> flush 'ns:magic'
Took 0.6161 seconds
hdfs dfs -mv /data/hbase/data/ns/magic/* /tmp/trash
hbase(main):002:0> get 'ns:magic', 'key1'
 cf:c      timestamp=1534440690218, value=try_to_delete_me

"읽기 시 데이터 캐시" 매개변수가 false로 설정됩니다. 아이디어가 있으시면 댓글로 토론해 주세요.

5. 일괄 데이터 처리 MultiGet/MultiPut

단일 요청(Get/Put/Delete)을 처리하는 것은 상당히 비용이 많이 드는 작업이므로 가능하면 이를 List 또는 List로 결합해야 성능을 크게 향상시킬 수 있습니다. 이는 쓰기 작업의 경우 특히 그렇습니다. 그러나 읽을 때는 다음과 같은 함정이 있습니다. 아래 그래프는 MemStore에서 50개의 레코드를 읽는 데 걸리는 시간을 보여줍니다. 읽기는 하나의 스레드에서 수행되었으며 가로 축에는 요청의 키 수가 표시됩니다. 여기서는 한 요청에서 키를 000개로 늘리면 실행 시간이 단축되는 것을 볼 수 있습니다. 속도가 증가합니다. 그러나 MSLAB 모드가 기본적으로 활성화되면 이 임계값 이후 성능이 급격하게 떨어지기 시작하고 레코드의 데이터 양이 많아질수록 작동 시간이 길어집니다.

테스트는 가상 머신, 8개 코어, 버전 HBase 2.0.0-cdh6.0.0-beta1에서 수행되었습니다.

MSLAB 모드는 신세대 데이터와 구세대 데이터의 혼합으로 인해 발생하는 힙 조각화를 줄이기 위해 설계되었습니다. 해결 방법으로 MSLAB을 활성화하면 데이터가 상대적으로 작은 셀(청크)에 배치되어 청크로 처리됩니다. 결과적으로, 요청한 데이터 패킷의 양이 할당된 크기를 초과하면 성능이 급격히 저하됩니다. 반면, 이 모드를 끄는 것도 데이터 처리가 집중되는 동안 GC로 인해 중지될 수 있으므로 권장되지 않습니다. 좋은 해결책은 읽기와 동시에 넣기를 통해 활성 쓰기의 경우 셀 볼륨을 늘리는 것입니다. 기록 후 MemStore를 디스크로 재설정하는 플러시 명령을 실행하거나 BulkLoad를 사용하여 로드하는 경우 문제가 발생하지 않는다는 점은 주목할 가치가 있습니다. 아래 표는 더 큰(동일한 양) 데이터에 대한 MemStore의 쿼리로 인해 속도가 느려지는 것을 보여줍니다. 그러나 청크 크기를 늘리면 처리 시간이 정상으로 돌아갑니다.

청크 크기를 늘리는 것 외에도 지역별로 데이터를 분할하는 것이 도움이 됩니다. 테이블 분할. 이로 인해 각 지역으로 들어오는 요청이 줄어들고 셀에 맞으면 응답이 양호하게 유지됩니다.

6. 테이블을 영역으로 분할하는 전략(분할)

HBase는 키-값 저장소이고 파티셔닝은 키별로 이루어지기 때문에 데이터를 모든 지역에 균등하게 나누는 것이 매우 중요합니다. 예를 들어, 이러한 테이블을 세 부분으로 분할하면 데이터가 세 영역으로 분할됩니다.

예를 들어 나중에 로드된 데이터가 긴 값처럼 보이고 대부분이 동일한 숫자로 시작하는 경우 이로 인해 급격한 속도 저하가 발생합니다. 예를 들어 다음과 같습니다.

1000001
1000002
...
1100003

키는 바이트 배열로 저장되므로 모두 동일하게 시작하고 이 키 범위를 저장하는 동일한 영역 #1에 속합니다. 여러 가지 분할 전략이 있습니다.

HexStringSplit – 키를 "00000000" => "FFFFFFFF" 범위의 XNUMX진수로 인코딩된 문자열로 바꾸고 왼쪽을 XNUMX으로 채웁니다.

UniformSplit – 키를 "00" => "FF" 범위의 XNUMX진수 인코딩과 오른쪽 패딩이 XNUMX인 바이트 배열로 변환합니다.

또한 분할할 키 범위나 집합을 지정하고 자동 분할을 구성할 수 있습니다. 그러나 가장 간단하고 효과적인 접근 방식 중 하나는 균일 분할 및 해시 연결 사용입니다. 예를 들어 CRC32(rowkey) 함수와 rowkey 자체를 통해 키를 실행하는 가장 중요한 바이트 쌍입니다.

해시 + 행 키

그러면 모든 데이터가 지역 전체에 고르게 분산됩니다. 읽을 때 처음 XNUMX바이트는 삭제되고 원래 키는 그대로 유지됩니다. RS는 또한 해당 지역의 데이터와 키의 양을 제어하고, 제한이 초과되면 자동으로 이를 여러 부분으로 나눕니다.

7. 내결함성 및 데이터 지역성

각 키 세트를 담당하는 지역은 단 하나이므로 RS 충돌 또는 폐기와 관련된 문제에 대한 해결책은 필요한 모든 데이터를 HDFS에 저장하는 것입니다. RS가 떨어지면 마스터는 ZooKeeper 노드에 하트비트가 없음을 통해 이를 감지합니다. 그런 다음 제공되는 영역을 다른 RS에 할당하고 HFiles가 분산 파일 시스템에 저장되므로 새 소유자가 이를 읽고 계속해서 데이터를 제공합니다. 그러나 일부 데이터는 MemStore에 있고 HFiles에 들어갈 시간이 없었기 때문에 HDFS에도 저장되어 있는 WAL을 사용하여 작업 기록을 복원합니다. 변경 사항이 적용된 후 RS는 요청에 응답할 수 있지만 이동으로 인해 일부 데이터와 이를 서비스하는 프로세스가 다른 노드에 있게 됩니다. 지역성이 줄어들고 있어요.

문제에 대한 해결책은 대규모 압축입니다. 이 절차는 파일을 담당하는 노드(해당 지역이 있는 위치)로 파일을 이동하며, 그 결과 이 ​​절차 중에 네트워크와 디스크의 로드가 급격히 증가합니다. 그러나 앞으로는 데이터에 대한 접근이 눈에 띄게 가속화될 것입니다. 또한 major_compaction은 모든 HFile을 영역 내 하나의 파일로 병합하고 테이블 설정에 따라 데이터를 정리합니다. 예를 들어, 유지해야 하는 객체의 버전 수나 객체가 물리적으로 삭제되기 전까지의 수명을 지정할 수 있습니다.

이 절차는 HBase의 운영에 매우 긍정적인 영향을 미칠 수 있습니다. 아래 그림은 활성 데이터 기록으로 인해 성능이 어떻게 저하되는지 보여줍니다. 여기서는 40개의 스레드가 하나의 테이블에 어떻게 쓰고 40개의 스레드가 동시에 데이터를 읽는지 확인할 수 있습니다. 쓰기 스레드는 다른 스레드에서 읽는 점점 더 많은 HFiles를 생성합니다. 결과적으로 점점 더 많은 데이터를 메모리에서 제거해야 하고 결국 GC가 작동하기 시작하여 사실상 모든 작업이 마비됩니다. 대규모 압축 작업을 시작하여 발생한 잔해물을 제거하고 생산성을 회복했습니다.

테스트는 3개의 DataNode와 4개의 RS(CPU Xeon E5-2680 v4 @ 2.40GHz * 64 스레드)에서 수행되었습니다. HBase 버전 1.2.0-cdh5.14.2

데이터가 활발히 기록되고 읽혀지는 "라이브" 테이블에서 대규모 압축이 시작되었다는 점은 주목할 가치가 있습니다. 이로 인해 데이터를 읽을 때 잘못된 응답이 발생할 수 있다는 설명이 온라인에 있었습니다. 확인하기 위해 새 데이터를 생성하고 이를 테이블에 쓰는 프로세스가 시작되었습니다. 그런 다음 결과 값이 적힌 값과 일치하는지 즉시 읽고 확인했습니다. 이 과정이 진행되는 동안 약 200회 정도의 대규모 압축이 이루어졌으며 단 한 건의 실패도 기록되지 않았습니다. 아마도 문제는 부하가 높은 경우에만 드물게 나타날 수 있으므로 계획대로 쓰기 및 읽기 프로세스를 중지하고 이러한 GC 감소를 방지하기 위해 정리를 수행하는 것이 더 안전합니다.

또한 대규모 압축은 MemStore의 상태에 영향을 주지 않습니다. 이를 디스크로 플러시하고 압축하려면 플러시(connection.getAdmin().flush(TableName.valueOf(tblName)))를 사용해야 합니다.

8. 설정 및 성능

이미 언급했듯이 HBase는 BulkLoad를 실행할 때 아무것도 할 필요가 없는 부분에서 가장 큰 성공을 보여줍니다. 그러나 이는 대부분의 시스템과 사람에게 적용됩니다. 그러나 이 도구는 대규모 블록에 데이터를 대량으로 저장하는 데 더 적합한 반면, 프로세스에 여러 경쟁 읽기 및 쓰기 요청이 필요한 경우 위에 설명된 Get 및 Put 명령이 사용됩니다. 최적의 매개변수를 결정하기 위해 테이블 ​​매개변수와 설정의 다양한 조합을 사용하여 출시가 수행되었습니다.

• 10개의 스레드가 연속으로 3번 동시에 실행되었습니다(이것을 스레드 블록이라고 부르겠습니다).
• 블록 내 모든 스레드의 작동 시간을 평균하여 블록 작동의 최종 결과였습니다.
• 모든 스레드는 동일한 테이블에서 작업했습니다.
• 스레드 블록이 시작될 때마다 주요 압축이 수행되었습니다.
• 각 블록은 다음 작업 중 하나만 수행했습니다.

-놓다
-얻다
—얻기+넣기

• 각 블록은 해당 작업을 50번 반복했습니다.
• 레코드의 블록 크기는 100바이트, 1000바이트 또는 10000바이트(임의)입니다.
• 요청된 키의 개수(키 10개 또는 XNUMX개)가 다른 블록이 시작되었습니다.
• 블록은 다른 테이블 설정에서 실행되었습니다. 변경된 매개변수:

— BlockCache = 켜짐 또는 꺼짐
— 블록 크기 = 65KB 또는 16KB
— 파티션 = 1, 5 또는 30
— MSLAB = 활성화 또는 비활성화

따라서 블록은 다음과 같습니다.

ㅏ. MSLAB 모드가 켜져/꺼졌습니다.
비. BlockCache = true/none, BlockSize = 65/16Kb, Partition = 1/5/30 매개변수가 설정된 테이블이 생성되었습니다.
씨. 압축은 GZ로 설정되었습니다.
디. 10개의 스레드가 1/10/100바이트의 레코드로 이 테이블에 1000/10000 put/get/get+put 작업을 수행하면서 동시에 실행되어 연속 50개의 쿼리(임의 키)를 수행했습니다.
이자형. d 지점은 세 번 반복되었습니다.
에프. 모든 스레드의 작동 시간을 평균화했습니다.

가능한 모든 조합이 테스트되었습니다. 레코드 크기가 증가하면 속도가 떨어지거나 캐싱을 비활성화하면 속도가 느려질 것으로 예측할 수 있습니다. 그러나 목표는 각 매개변수의 영향 정도와 유의성을 이해하는 것이었으므로 수집된 데이터를 선형 회귀 함수의 입력으로 입력하여 t-통계를 사용하여 유의성을 평가할 수 있습니다. 다음은 Put 작업을 수행한 블록의 결과입니다. 전체 조합 세트 2*2*3*2*3 = 144개 옵션 + 72 tk. 일부는 두 번 수행되었습니다. 따라서 총 216개의 실행이 있습니다.

테스트는 3개의 DataNode와 4개의 RS(CPU Xeon E5-2680 v4 @ 2.40GHz * 64 스레드)로 구성된 미니 클러스터에서 수행되었습니다. HBase 버전 1.2.0-cdh5.14.2.

BlockCache가 활성화되고 BlockSize = 3.7, 16바이트 레코드, 팩당 100개 조각이 있는 파티션이 하나인 테이블에서 MSLAB 모드를 끈 상태에서 10초의 최고 삽입 속도를 얻었습니다.
BlockCache가 활성화되고 BlockSize = 82.8, 16바이트의 레코드, 각각 10000개의 파티션이 있는 테이블에서 MSLAB 모드가 활성화된 경우 1초의 가장 낮은 삽입 속도를 얻었습니다.

이제 모델을 살펴보겠습니다. 우리는 R2를 기반으로 한 모델의 좋은 품질을 볼 수 있지만 여기서는 외삽이 금기라는 것이 절대적으로 분명합니다. 매개변수가 변경될 때 시스템의 실제 동작은 선형적이지 않습니다. 이 모델은 예측이 아니라 주어진 매개변수 내에서 어떤 일이 발생했는지 이해하는 데 필요합니다. 예를 들어, 여기에서는 BlockSize 및 BlockCache 매개변수가 Put 작업에 중요하지 않다는 학생의 기준을 볼 수 있습니다(일반적으로 예측 가능함).

그러나 파티션 수를 늘리면 성능이 저하된다는 사실은 이해할 수 있지만 다소 예상치 못한 일입니다(BulkLoad를 사용하여 파티션 수를 늘리면 긍정적인 영향을 이미 확인했습니다). 첫째, 처리를 위해서는 30개 지역이 아닌 XNUMX개 지역에 대한 요청을 생성해야 하는데, 데이터 양이 이 정도로 이득을 얻을 정도는 아니다. 둘째, 총 동작 시간은 가장 느린 RS에 의해 결정되는데, DataNode의 수가 RS의 수보다 적기 때문에 일부 지역에서는 집약성이 XNUMX이 됩니다. 그럼 상위 XNUMX개를 살펴보겠습니다.

이제 Get 블록 실행 결과를 평가해 보겠습니다.

파티션 수가 의미를 잃었는데, 이는 아마도 데이터가 잘 캐시되고 읽기 캐시가 가장 중요한(통계적) 매개변수라는 사실로 설명될 수 있습니다. 당연히 요청의 메시지 수를 늘리는 것도 성능에 매우 유용합니다. 최고 점수:

마지막으로 먼저 get과 put을 수행한 블록의 모델을 살펴보겠습니다.

여기서는 모든 매개변수가 중요합니다. 그리고 리더들의 결과는 다음과 같습니다.

9. 부하 테스트

글쎄, 마침내 우리는 어느 정도 괜찮은 로드를 출시할 것이지만 비교할 것이 있으면 항상 더 흥미로울 것입니다. Cassandra의 주요 개발자인 DataStax의 웹사이트에는 연구 결과 HBase 버전 0.98.6-1을 포함한 여러 NoSQL 저장소의 NT입니다. 로딩은 스레드 40개, 데이터 크기 100바이트, SSD 디스크로 진행됐다. 읽기-수정-쓰기 작업을 테스트한 결과는 다음과 같습니다.

내가 아는 한, 읽기는 100개의 레코드 블록으로 수행되었으며 16개의 HBase 노드에 대해 DataStax 테스트에서 초당 10개의 작업 성능을 보여주었습니다.

우리 클러스터에도 16개의 노드가 있다는 것은 다행이지만 각 노드에 64개의 코어(스레드)가 있는 것은 그리 "운이 좋지" 않습니다. 반면 DataStax 테스트에는 4개만 있습니다. 반면에 그들은 SSD 드라이브를 가지고 있지만 우리는 HDD를 가지고 있습니다. 또는 로드 중 새 버전의 HBase 및 CPU 사용률은 실질적으로 크게 증가하지 않았습니다(시각적으로 5~10%). 하지만 이 구성을 사용해 시작해 보겠습니다. 기본 테이블 설정, 읽기는 0에서 50천만 사이의 키 범위에서 무작위로 수행됩니다(즉, 기본적으로 매번 새로워짐). 테이블에는 50개의 파티션으로 나누어진 64천만 개의 레코드가 포함되어 있습니다. 키는 crc32를 사용하여 해시됩니다. 테이블 설정은 기본값이며 MSLAB은 활성화되어 있습니다. 40개의 스레드를 시작하면 각 스레드는 100개의 임의 키 집합을 읽고 생성된 100바이트를 즉시 이 키에 다시 씁니다.

스탠드: DataNode 16개 및 RS 16개(CPU Xeon E5-2680 v4 @ 2.40GHz * 64 스레드). HBase 버전 1.2.0-cdh5.14.2.

평균 결과는 초당 40개 작업에 가까우며 이는 DataStax 테스트보다 훨씬 좋습니다. 그러나 실험 목적으로 조건을 약간 변경할 수 있습니다. 모든 작업이 하나의 테이블과 고유 키에서만 수행될 가능성은 거의 없습니다. 기본 로드를 생성하는 특정 "핫" 키 세트가 있다고 가정해 보겠습니다. 따라서 10개의 서로 다른 테이블에서 더 큰 레코드(100KB)를 4개씩 배치하여 로드를 생성하고 요청된 키의 범위를 50으로 제한해 보겠습니다. 아래 그래프는 40개의 스레드 실행을 보여줍니다. 각 스레드는 읽기를 수행합니다. 100개의 키 세트를 생성하고 이 키에 즉시 임의의 10KB를 다시 씁니다.

스탠드: DataNode 16개 및 RS 16개(CPU Xeon E5-2680 v4 @ 2.40GHz * 64 스레드). HBase 버전 1.2.0-cdh5.14.2.

로드하는 동안 위와 같이 여러 번 대규모 압축이 시작되었으며, 이 절차를 수행하지 않으면 성능이 점차 저하되지만 실행 중에 추가 로드도 발생합니다. 하락은 다양한 이유로 발생합니다. 때로는 스레드 작업이 완료되고 다시 시작되는 동안 일시 중지되었으며 때로는 타사 응용 프로그램이 클러스터에 로드를 생성하기도 했습니다.

읽고 즉시 쓰는 것은 HBase의 가장 어려운 작업 시나리오 중 하나입니다. 예를 들어 100바이트의 작은 Put 요청만 만들어 이를 10~50개 조각의 팩으로 결합하면 초당 수십만 개의 작업을 수행할 수 있으며 상황은 읽기 전용 요청과 유사합니다. 특히 50개 블록의 요청으로 인해 DataStax에서 얻은 결과보다 결과가 훨씬 더 우수하다는 점은 주목할 가치가 있습니다.

스탠드: DataNode 16개 및 RS 16개(CPU Xeon E5-2680 v4 @ 2.40GHz * 64 스레드). HBase 버전 1.2.0-cdh5.14.2.

10. 결론

이 시스템은 매우 유연하게 구성되어 있지만 많은 매개변수의 영향은 아직 알려지지 않았습니다. 그 중 일부는 테스트되었지만 결과 테스트 세트에는 포함되지 않았습니다. 예를 들어, 예비 실험에서는 무작위로 생성된 데이터에 대해 이해할 수 있는 이웃 셀의 값을 사용하여 정보를 인코딩하는 DATA_BLOCK_ENCODING과 같은 매개 변수의 중요성이 미미한 것으로 나타났습니다. 많은 수의 중복 개체를 사용하는 경우 이득이 상당할 수 있습니다. 일반적으로 HBase는 상당히 진지하고 세심하게 계획된 데이터베이스라는 인상을 주는데, 이는 대규모 데이터 블록을 사용하여 작업을 수행할 때 매우 생산적일 수 있습니다. 특히 읽기와 쓰기 과정을 시간에 맞춰 분리하는 것이 가능하다면 더욱 그렇습니다.

귀하의 의견에 충분히 공개되지 않은 내용이 있으면 더 자세히 말씀해 드리겠습니다. 귀하의 경험을 공유하거나 동의하지 않는 사항이 있으면 토론해 보시기 바랍니다.

출처 : habr.com