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 테이블을 읽습니다. 여기서 관심 있는 테이블의 주어진 행 키에 대한 데이터를 저장하는 RegionServer(RS)에 대한 정보를 추출합니다. 나중에 사용하기 위해 메타 테이블은 클라이언트에 의해 캐시되므로 후속 요청이 더 빠르게 RS에 직접 전송됩니다.

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

레코드가 MemStore에 배치되면 레코드가 성공적으로 저장되었다는 응답이 클라이언트에게 반환됩니다. 실제로는 버퍼에만 저장되고 일정 시간이 지나거나 새로운 데이터로 채워질 때만 디스크에 기록됩니다.

"삭제" 작업을 수행해도 물리적인 데이터 삭제는 발생하지 않습니다. 이러한 항목은 단순히 삭제된 것으로 표시될 뿐이며, 삭제 자체는 7항에서 더 자세히 설명하는 주요 컴팩트 함수를 호출하는 순간에 발생합니다.

HFile 파일은 HDFS에 저장되며, 가끔 작은 압축 프로세스가 실행되어 아무것도 삭제하지 않고 작은 파일을 큰 파일에 붙이는 간단한 작업이 수행됩니다. 시간이 지남에 따라 이는 데이터를 읽을 때만 나타나는 문제가 됩니다(나중에 이에 대해 살펴보겠습니다).

위에 설명된 로딩 프로세스 외에도 훨씬 더 효율적인 절차가 있는데, 이것이 바로 이 데이터베이스의 가장 큰 장점인 BulkLoad입니다. 이는 우리가 독립적으로 HFiles를 형성하고 디스크에 저장한다는 사실로 구성되는데, 이를 통해 완벽한 확장성과 매우 적절한 속도를 달성할 수 있습니다. 실제로, 여기서의 한계는 HBase가 아니라 하드웨어의 성능입니다. 아래는 16개의 RegionServer와 16개의 NodeManagers 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에 저장되고 다음 요청 시 더 빠르게 반환됩니다. HFile에서의 검색은 Bloom 필터를 사용하기 때문에 비교적 빠릅니다. 즉, 적은 양의 데이터를 읽은 후 해당 파일에 필요한 키가 있는지 즉시 판별하고, 없으면 다음 파일로 넘어갑니다.

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

4. 데이터 캐싱

MemStore와 BlockCache 버퍼는 할당된 온힙 RS 메모리의 최대 80%를 차지합니다(나머지는 RS 서비스 작업을 위해 예약됩니다). 일반적인 사용 모드가 프로세스가 동일한 데이터를 쓰고 즉시 읽는 것이라면 BlockCache를 줄이고 MemStore를 늘리는 것이 합리적입니다. 왜냐하면 읽기용으로 캐시에 데이터를 쓸 때 데이터가 캐시에 도달하지 않으므로 BlockCache가 덜 자주 사용되기 때문입니다. BlockCache 버퍼는 LruBlockCache(항상 힙에 위치)와 BucketCache(일반적으로 힙 외부 또는 SSD에 위치)의 두 부분으로 구성됩니다. 많은 읽기 요청이 있고 LruBlockCache에 맞지 않아 가비지 컬렉터가 활발하게 작동하는 경우 BucketCache를 사용해야 합니다. 동시에 읽기 캐시를 사용하여 성능이 급격하게 향상될 것이라고 기대해서는 안 되지만 8번 항목에서 이에 대해 다시 설명하겠습니다.

RS 전체에 대해 하나의 BlockCache가 있고, 각 테이블에는 자체 MemStore(각 열 패밀리당 하나씩)가 있습니다.

방법 설명 이론상, 캐시에 데이터를 쓸 때 데이터가 캐시에 도달하지 않으며 실제로 테이블의 CACHE_DATA_ON_WRITE 및 RS의 "쓰기 시 캐시 데이터"와 같은 매개변수는 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개의 레코드를 읽는 데 걸리는 시간을 보여줍니다. 읽기는 하나의 스레드에서 수행되었으며, 가로축은 쿼리의 키 개수를 보여줍니다. 여기서는 한 요청에서 키 수를 천 개로 늘리면 실행 시간이 짧아지고 속도가 빨라지는 것을 볼 수 있습니다. 그러나 기본적으로 MSLAB 모드가 활성화되어 있는 경우 이 임계값을 지나면 성능이 급격히 떨어지기 시작하고, 레코드의 데이터 양이 많을수록 런타임이 더 길어집니다.

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

MSLAB 모드는 새 세대와 이전 세대의 데이터가 섞임으로 인해 발생하는 힙 조각화를 줄이도록 설계되었습니다. 이 문제에 대한 해결책으로, MSLAB을 활성화하면 데이터가 비교적 작은 셀(청크)에 분산되어 부분적으로 처리됩니다. 결과적으로 요청된 데이터 패킷의 양이 할당된 크기를 초과하게 되면 성능이 급격히 저하됩니다. 반면, 이 모드를 비활성화하는 것도 바람직하지 않습니다. 데이터를 집중적으로 처리하는 기간 동안 GC로 인해 중단이 발생하기 때문입니다. 좋은 해결책은 읽기와 동시에 쓰기를 활성화할 경우 셀 볼륨을 늘리는 것입니다. 기록 후 MemStore를 디스크로 플러시하는 flush 명령을 실행하거나 BulkLoad를 사용하여 로드하는 경우에는 문제가 발생하지 않는다는 점에 유의하세요. 아래 표는 MemStore에서 더 큰(그리고 동일한 양의) 데이터를 쿼리할 경우 속도 저하가 발생한다는 것을 보여줍니다. 그러나 청크 크기를 늘리면 처리 시간이 정상으로 돌아갑니다.

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

6. 테이블을 지역별로 분할하는 전략(스필링)

HBase는 키-값 저장소이며 키별로 파티셔닝이 이루어지므로 모든 지역에 데이터를 균등하게 분배하는 것이 매우 중요합니다. 예를 들어, 이러한 표를 세 부분으로 분할하면 데이터가 세 개 영역으로 나뉩니다.

이는 나중에 로드된 데이터가 예를 들어 대부분 같은 숫자로 시작하는 긴 값인 경우 급격한 속도 저하로 이어질 수 있습니다. 예:

1000001
1000002
...
1100003

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

HexStringSplit – 키를 "00000000" => "FFFFFFFF" 범위의 XNUMX진수 인코딩과 왼쪽을 XNUMX으로 패딩하여 문자열로 변환합니다.

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

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

해시 + 행키

그러면 모든 데이터가 모든 지역에 균등하게 분산됩니다. 읽을 때, 처음 두 바이트는 단순히 삭제되고 원래 키는 그대로 유지됩니다. RS는 또한 해당 지역의 데이터와 키의 양을 제어하고, 한도를 초과할 경우 자동으로 여러 부분으로 분할합니다.

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

각 키 세트는 하나의 지역에만 책임을 지기 때문에 RS 충돌이나 서비스 중단과 관련된 문제를 해결하려면 모든 필요한 데이터를 HDFS에 저장해야 합니다. RS에 장애가 발생하면 마스터는 ZooKeeper 노드에 하트비트가 없음을 통해 이를 감지합니다. 그런 다음 제공될 지역을 다른 RS에 할당하고, HFiles가 분산 파일 시스템에 저장되므로 새로운 소유자가 이를 읽고 데이터 제공을 계속합니다. 하지만 일부 데이터는 MemStore에 있어서 HFiles에 도달할 시간이 없었을 수 있으므로 HDFS에 저장된 WAL을 사용하여 작업 기록을 복원합니다. 변경 사항이 적용된 후 RS는 요청에 응답할 수 있지만, 이러한 이동으로 인해 일부 데이터와 이를 처리하는 프로세스가 다른 노드에 위치하게 되어 지역성이 감소합니다.

이 문제에 대한 해결책은 주요 압축입니다. 이 절차는 파일을 담당 노드(해당 지역이 있는 곳)로 이동하는데, 이로 인해 이 절차를 수행하는 동안 네트워크와 디스크의 부하가 급격히 증가합니다. 하지만 미래에는 데이터에 대한 접근이 눈에 띄게 빨라질 것입니다. 또한, major_compaction은 지역 내의 모든 HFile을 하나의 파일로 병합하고, 테이블 설정에 따라 데이터를 정리합니다. 예를 들어, 개체의 버전 수를 지정하여 보관해야 하거나 개체가 실제로 삭제되는 기간을 지정할 수 있습니다.

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

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

주요 압축이 데이터가 활발하게 쓰여지고 읽히는 "라이브" 테이블에서 시작되었다는 점이 주목할 만합니다. 온라인에서는 이로 인해 데이터를 읽을 때 잘못된 응답이 발생할 수 있다는 주장이 있었습니다. 이를 테스트하기 위해 새로운 데이터를 생성하여 테이블에 쓰는 프로세스가 시작되었습니다. 그런 다음 받은 값이 쓰여진 내용과 일치하는지 바로 읽고 확인했습니다. 이 공정이 운영되는 동안 대규모 다짐이 약 200회 이루어졌으며 단 한 번의 실패도 기록되지 않았습니다. 아마도 이 문제는 드물게 발생하고 부하가 높을 때만 발생할 수 있으므로, 이러한 GC 감소를 방지하기 위해 쓰기 및 읽기 프로세스를 정기적으로 중지하고 정리를 수행하는 것이 더 안전할 것입니다.

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

8. 설정 및 성능

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

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

- 놓다
-얻다
— Get+Put

• 각 블록은 50번의 반복 작업을 수행했습니다.
• 블록의 레코드 크기는 100바이트, 1000바이트 또는 10000바이트(무작위)입니다.
• 블록은 요청된 키의 개수(키 10개 또는 XNUMX개)에 따라 다르게 실행되었습니다.
• 블록은 다양한 테이블 설정으로 실행되었습니다. 매개변수가 변경되었습니다:

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

그래서 블록은 이렇게 생겼습니다:

에이. MSLAB 모드가 켜졌다/꺼졌다.
비. 다음 매개변수가 설정된 테이블이 생성되었습니다: BlockCache = true/none, BlockSize = 65/16Kb, Partitions = 1/5/30.
기음. GZ 압축이 설정되었습니다.
디. 10개의 스레드가 동시에 실행되어 1/10 put/get/get+put 작업을 이 테이블에 수행하였고, 100/1000/10000바이트의 레코드가 있었으며, 50개의 요청을 연속으로 실행했습니다(무작위 키).
이자형. d 지점은 3번 반복되었습니다.
에프. 모든 스레드의 실행 시간은 평균화되었습니다.

가능한 모든 조합이 테스트되었습니다. 레코드 크기가 커질수록 속도가 떨어지고, 캐싱을 비활성화하면 속도 저하가 발생하는 것은 예측 가능합니다. 그러나 목표는 각 매개변수의 영향의 정도와 중요성을 이해하는 것이었기 때문에 수집된 데이터는 선형 회귀 함수의 입력으로 제공되었으며, 이를 통해 t-통계량을 사용하여 신뢰도를 평가하는 것이 가능해졌습니다. 아래는 Put 연산을 수행하는 블록의 결과입니다. 조합의 전체 집합은 2*2*3*2*3 = 144개 옵션 + 72개입니다. 일부는 두 번 수행되었기 때문입니다. 따라서 총 216개의 발사가 있습니다.

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

MSLAB 모드가 비활성화되고, 파티션이 하나이고, BlockCache가 활성화되고, BlockSize = 3.7이고, 레코드 수가 16바이트이고, 배치당 레코드가 100개인 테이블에서 가장 빠른 삽입 속도인 10초를 얻었습니다.
82.8초의 가장 낮은 삽입 속도는 MSLAB 모드가 활성화된 경우, BlockCache가 활성화된 하나의 파티션이 있는 테이블에서 BlockSize = 16, 10000바이트 레코드(각각 1개)를 사용할 때 얻어졌습니다.

이제 모델을 살펴보겠습니다. R2에 따르면 모델의 품질이 양호하지만 여기서 외삽법이 금기시된다는 점은 매우 분명합니다. 매개변수를 변경할 때 시스템의 실제 동작은 선형적이지 않습니다. 이 모델은 예측을 위해 필요한 것이 아니라, 주어진 매개변수 내에서 무슨 일이 일어났는지 이해하기 위해 필요합니다. 예를 들어, 여기서 우리는 학생 기준에서 BlockSize 및 BlockCache 매개변수가 Put 작업(일반적으로 매우 예측 가능함)에 중요하지 않다는 것을 알 수 있습니다.

하지만 파티션 수를 늘렸을 때 성능이 저하된다는 사실은 다소 예상치 못한 일입니다(BulkLoad에서 파티션 수를 늘리면 긍정적인 효과가 나타나는 것을 이미 확인했습니다). 하지만 이해할 만한 일입니다. 첫째, 처리를 위해서는 하나가 아닌 30개 지역에 요청을 보내야 하는데, 데이터 양이 그렇게 많지 않아 이로 인한 이점이 없습니다. 둘째, 총 실행 시간은 가장 느린 RS에 의해 결정되며, DataNode의 수가 RS의 수보다 적기 때문에 일부 지역은 지역성이 전혀 없습니다. 그럼, 상위 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바이트를 이러한 키에 즉시 다시 씁니다.

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

평균 결과는 초당 40만 건에 가까워 DataStax 테스트보다 상당히 더 나은 수준입니다. 그러나 실험 목적으로는 조건을 약간 변경할 수 있습니다. 모든 작업이 단 하나의 테이블로만 수행되거나, 고유 키로만 수행되는 것은 거의 불가능합니다. 주요 부하를 생성하는 "핫" 키 세트가 있다고 가정해 보겠습니다. 따라서 10개씩 100개의 서로 다른 테이블에 있는 더 큰 레코드(4KB)를 로드하고 요청되는 키 범위를 50개로 제한해 보겠습니다. 아래 그래프는 40개의 스레드가 실행되는 것을 보여줍니다. 각 스레드는 100개의 키 세트를 읽고 해당 키에 대해 무작위로 10KB를 즉시 씁니다.

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

부하가 걸리는 동안, 위에서 볼 수 있듯이 주요 압축이 여러 번 실행되었습니다. 이 절차가 없으면 성능이 점차 저하되지만, 실행 중에 추가적인 부하가 발생합니다. 하락은 다양한 이유로 인해 발생합니다. 가끔 스레드가 종료되어 재시작하는 동안 일시 정지가 발생하기도 하고, 가끔은 타사 애플리케이션이 클러스터에 부하를 발생시키기도 했습니다.

즉시 읽고 쓰는 것은 HBase에 가장 까다로운 워크플로 중 하나입니다. 예를 들어 각각 100바이트 정도의 작은 put 요청만 만들고 이를 10~50개 단위로 묶으면 초당 수십만 건의 작업을 처리할 수 있으며, 읽기 전용 요청의 경우도 상황은 비슷합니다. DataStax에서 얻은 결과보다 훨씬 더 나은 결과가 나왔다는 점이 주목할 만합니다. 이는 주로 50만 개의 블록에서 쿼리를 실행한 덕분입니다.

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

10. 결론

이 시스템은 구성하기가 매우 유연하지만, 많은 수의 매개변수의 영향은 아직 알려지지 않았습니다. 일부는 테스트를 거쳤지만 최종 테스트 세트에는 포함되지 않았습니다. 예를 들어, 예비 실험에서는 무작위로 생성된 데이터의 경우 이해할 수 있는 것처럼, 이웃 셀의 값을 사용하여 정보를 인코딩하는 DATA_BLOCK_ENCODING과 같은 매개변수의 경우 그다지 의미가 없는 것으로 나타났습니다. 반복되는 객체를 많이 사용하면 상당한 이점을 얻을 수 있습니다. 전반적으로, HBase는 상당히 진지하고 잘 고안된 데이터베이스라는 인상을 주며, 대량의 데이터 블록을 처리할 때 매우 생산적일 수 있습니다. 특히 시간적으로 읽기와 쓰기 과정을 분리할 수 있는 기회가 있다면 더욱 그렇습니다.

만약 여러분이 충분히 다루지 못한 내용이 있다고 생각하신다면, 더 자세히 말씀드리겠습니다. 여러분의 경험을 공유해주세요. 혹은 동의하지 않는 부분이 있다면 토론해주세요.

출처 : habr.com