빅 데이터 애플리케이션을위한 NoSQL 데이터베이스의 효과적인 크기 조정

빅 데이터 애플리케이션을위한 NoSQL 데이터베이스의 효과적인 크기 조정

 Rajini 라잔 | 11/01/2017

http://www.thedatateam.in/perspective/post/index.html?postId=34

구조화되지 않은 데이터의 확산으로 인해 대규모의 다양한 데이터 세트를 수집 및 처리하는 것이 조직의 실제 과제였습니다. 조직은 종종 조직 프로세스, 시스템 및 고객으로부터 비정형 데이터를 관리 할 때 NoSQL 데이터베이스를 설정하고 크기를 조정해야하는 어려움을 겪습니다. 크기 조정은 조직에서 직면 한 광범위한 데이터 문제에 대한 핵심 과제입니다. 데이터 엔지니어 및 IT 관리자는 데이터에 대한 올바른 하드웨어 계획에 어떻게 도달 할 수 있습니까? 거대한 데이터 세트 및 현대적인 고객 홍보에 대한 데이터베이스의 크기, 성능 및 확장성에 영향을 미치는 요인 및 고려 사항은 무엇입니까? 이것들은 우리가이 게시물에서 다루기를 희망하는 몇 가지 질문입니다. 특히 HBase를 살펴 보겠습니다.

HBase 개요

HBase는 엄청난 양의 데이터를 색인 생성하고 관리하는 탁월한 도구입니다. 랜덤 액세스, 일관된 읽기 / 쓰기, 가변 스키마 등의 특성 외에도 HBase는 수평 적으로 확장 할 수있는 능력으로 널리 인정 받고 있습니다. 데이터가 기업에서 증식 할 수있는 속도는 때때로 예측할 수 없습니다. HBase의 자동 샤딩은 기존 데이터에 영향을 미치지 않고 새로운 데이터 노드 즉 수평 스케일링을 추가함으로써 데이터 밸런싱을 효율적으로 가능하게합니다. 그러나 조직에서는 HBase의 이점을 활용할 수 있습니다. 단, 조직의 애플리케이션 및 사용 사례의 요구 사항에 따라 적절하게 데이터베이스 크기를 조정해야합니다. 따라서 HBase 클러스터의 규모를 결정하는 데 꼭 필요한 지침은 없습니다. 즉, HBase 사이징에 영향을 미치는 많은 핵심 요소가 있다.

데이터 저장소에 필요한 메모리

데이터의 크기는 HBase 구성을 결정하는 데 매우 중요합니다. 그러나 디스크의 물리적 데이터 크기는 데이터의 논리적 크기와 다르지만 종속적입니다. 디스크의 실제 데이터 크기는 다음과 같습니다.

• - HBase 오버 헤드 증가
• - 압축 및 데이터 블록 인코딩에 의해 감소
• - 지역 서버의 크기 증가
• - HDFS 복제로 증가 - 일반적으로 3 배 (3 배) 복제 스키마. 맞춤 설정 가능

참고 : 이 글을 쓰는 시점에서 실제 HBase 버전은 1.1.2입니다. 아래 사례 연구를 통해 HBase 크기 조정과 관련된 요소를 설명합니다. 우리는 다음 가정들로 시작합시다 :

1. 데이터 양 : 하루에 예상되는 데이터는 5 백만 행으로 가정되며 각 레코드 크기는 1000 바이트입니다
2. 데이터 보관 : 아니오 : 데이터를 데이터베이스에 보존 해야하는 일수. 가정 : 10 년
3. 전년 대비 증가량 : 매년 지나갈 때마다 데이터 양이 증가 할 것으로 예상됩니다. 가정 : 10 %
4. 압축 비율 : 사용 가능한 데이터에 대한 예상 압축. 가정 : 10 %

   

년	연간 행 수 (백만)	크기 (GB)	오버 헤드를 포함한 크기 (GB)	압축 (GB)	누적 (GB)	필요한 노드수
Y1	1800	1676.38	4190.95	419.10	419.10	3
Y2	1980	1844.02	4610.05	461.00	880.10	3
Y3	2178	2028.42	5071.05	507.11	1387.20	3
Y4	2395.8	2231.26	5578.16	557.82	1945.02	3
Y5	2635.38	2454.39	6135.97	613.60	2558.62	3
Y6	2898.918	2699.83	6749.57	674.96	3233.57	3
Y7	3188.8098	2969.81	7424.53	742.45	3976.03	3
Y8	3507.69078	3266.79	8166.98	816.70	4792.73	3
Y9	3858.459858	3593.47	8983.68	898.37	5691.09	3
Y10	4244.305844	3952.82	9882.04	988.20	6679.30	4

[표 1.1] HBase의 규모 (전년 대비)  

데이터 양

이 예제에서 HBase에 저장된 데이터의 양은 위의 표 1.1의 두 번째 열에 설명되어 있습니다. 분명히, 하루에 수집 된 데이터와 저장된 총 데이터 크기 간에는 직접적인 관계가 있습니다. 우리는 원시 데이터 크기, 오버 헤드 고려 사항에 도달하고 데이터 압축 측면을 고려하여 연간 추가되는 데이터를 생성합니다. 전년 대비 데이터 크기 수치를 보았을 때 누적 데이터 축적량이 데이터 저장소에 표시됩니다. 명확성을 위해 한 가지 예가 아래에 나와 있습니다. 행 당 1000 바이트의 초기 가정을 고려하여 => 1,800,000,000 x 1000 GB로 변환, 1,800,000,000 x 1000/3072 ≈ 1676.38
(약) 10 % YoY 증가,  Y2 1,800,000,000 + (1,800,000,000 * 0.1) = 1,980 만

데이터 볼륨에 대한 오버 헤드의 영향

이 절에서는 표 1의 오버 헤드를 포함한 크기 3 (GB)의 계산을 설명합니다. 메모리 측면에서 오버 헤드 는 데이터 자체와 별도로 추가 메모리 요구 사항을 나타냅니다. 행 키, 열 패밀리, 열 한정자, 타임 스탬프 및 데이터 유형으로 구성된 HBase 키는 데이터 저장을위한 색인 키입니다. 오버 헤드가있는 크기 = 연간 행렬 x 오버 헤드 비율 오버 헤드 비율 자체는 많은 키를 사용하여 정의됩니다.  

짧은 행 길이

행 키 바이트 []

가족 길이 바이트

열 패밀리 바이트

열 한정자 byte []

긴 타임 스탬프

키 유형 바이트

이제 KeyValue 형식에 필요한 고정 부분 = 키 길이 + 값 길이 + 행 길이 + CF 길이 + 타임 스탬프 + 키 값  KeyValue에 필요한 가변 부분 format = Row + Column 패밀리 + Column Qualifier + Value 필요한 총 바이트 수 = 고정 부분 + 가변 부분의HFile 은 정렬 된 키와 값 쌍으로 레코드를 디스크에 저장합니다. HFiles에는 HBase가 데이터를 검색 할 수있는 다층 인덱스가 포함되어 있습니다. 오버 헤드 비율의 계산은 오버 헤드와 HFiles 주변의 이러한 중요한 측면을 고려해야합니다. 

 

 

#columns (C)	10	평균 크기 (ACS)	100
열당 바이트 수 (BpC)	24	#column families	1
행키 크기 (Rk)	10
Hfile 색인 (Hi)	20 %
오버 헤드 비율	150 %

표 1.2 오버 헤드 가정 오버 헤드 비율 = (C x (ACS + BpC) + Rk) ÷ (C x ACS) x (1 + Hi) 위의 예에서 오버 헤드 및 오버 헤드 비율은 오버 헤드 = (10 x (100 + 24) BPC / C의 = 오버 × 100 = 104.167 ≈ 105 % (천장 반올림) 평균 열 크기 +10) ÷ (10 × 100) × (+ 0.2 1) = 1,200분의 1,250 = 1.04167 비율 주 : 데이터 차종 권 1 레코드 당 1000 바이트의 가정. 1000/10 ≈ 100

데이터 볼륨에 대한 압축 효과

압축은 데이터 볼륨을 줄이는 데 도움이됩니다. 채택 된 압축 방식에 따라 사용중인 알고리즘이 다를 수 있으며 압축 성능이 데이터 크기에 영향을 미칩니다. 압축 비율을 알면 데이터의 크기 (오버 헤드 고려)를 다음과 같이 계산할 수 있습니다. 크기 (GB)와 압축률 = 오버 헤드 * 압축률 열 5 = 열 4 * 0.1 => 4190.95 x 0.1 ≈ 419.10 (첫 번째 기록) 압축비: (압축되지 않은 데이터 크기 - 압축 된 데이터 크기) / 압축되지 않은 데이터 크기 백분율 압축을 사용하면 HBase 쿼리 성능에 긍정적 인 영향을주지 않지만 데이터로드시 약간의 오버 헤드가 추가됩니다. Gzip 코덱은 Snappy보다 압축률이 좋습니다. 데이터 압축 및 HBase 쿼리 성능은 직접적으로 비례합니다. 압축이 클수록 HBase를 쿼리하는 데 걸리는 시간이 길어집니다. 다음 테스트 세트에서 압축 전의 원래 압축되지 않은 파일은 100GB입니다.

	압축되지 않은	gzip (.gz)	으스스한 (. 스 내피)
압축비	N / A	32 %	5 %
HBase 테이블에 데이터를로드하는 데 걸린 시간 (밀리 초)	565	1029	585

표 1.3 압축 된 HBase 작업량 이제 이전 가정 인 10 %를 기반으로 압축 후 데이터 크기에 대한 예상치에 도달 할 수 있습니다. 표 1.1에서 문제의 예제에 대해 압축 후 데이터베이스 크기가 제공됩니다. 저장되는 데이터의 유형과 크기 및 성능에 대한 고려 사항에 따라 압축 비율이 다른 여러 압축 알고리즘을 사용할 수 있습니다. 압축에 대한 자세한 내용은 여기

하드웨어 요구 사항 : 핵심 요소

이제 데이터 양과 압축 측면을 이해 했으므로 하드웨어 요구 사항을 예측할 수 있습니다. 필요한 머신 = 최대 ([압축 된 데이터의 크기 ÷ 머신 당 사용 가능한 데이터], 최소 머신 수 : 하드웨어 요구 사항을 계산하기 전에, 아래의 두 가지 중요한 고려 사항 인 영역 서버 및 JVM 메모리 관리 고려 사항을 살펴 보겠습니다.

지역 서버 및 JVM 힙 고려 사항

우리는 이전 섹션에서 압축 된 데이터의 크기를 계산했습니다. 머신 당 사용 가능한 데이터는 지역 서버에 의존한다는 점에 유의해야합니다. 지역 서버는 모든 지역에 대해 모든 읽기 및 쓰기 요청을 담당합니다. 또한 구성된 영역 크기 임계 값을 초과하는 영역을 분할합니다. HBase는 "메모리 저장소"와 "블록 캐시"의 두 가지 캐시 구조를 유지 관리합니다.

1. 메모리 저장소는 수신 된 데이터 편집 내용을 누적하여 메모리에 버퍼링합니다.
2. 블록 캐시는 읽은 후에 메모리에 상주하는 데이터 블록을 유지합니다.

블록 캐시가 캐시 데이터를 저장하기 위해 HBase의 기본 Java 가상 머신 힙을 사용한다는 점도 중요합니다. 이것은 JVM의 가비지 콜렉션 (GC) 프로세스에 나쁜 영향을 미치는 요소가 캐시 성능 성능 및 확장 성, 데이터베이스 쿼리 성능에 영향을 미친다는 것을 의미합니다. 당연히 이는 많은 응용 프로그램에서 JVM 힙 크기를 사용할 수있는 많은 응용 프로그램의 요구 사항에 맞지 않습니다. 이러한 성능 문제를 완화하기 위해 HBase에는 Off-Heap 메모리를 사용 하는 BucketCache 라는 또 다른 메모리 내 데이터 구조가 포함되어 있습니다. 이것은 아래 표에서 Ohc (Off Heap Cache)로 표시됩니다.  

지역 서버 (RS) 모범 사례
RS 당 메모리 (M)	30.50GB
권장 지역 크기 (RecRS)	5.00GB
블록 캐시 (Bc)	12.20GB
Memstore (Ms)	12.20GB
Memstore 플러시 크기 (Mfs)	128.00MB
RS 당 #regions	95.31
RS (DpRS) 당 처리되는 데이터	476.56GB
오프 힙 캐시 (Ohc)	95.31GB

표 1.4 지역 서버 모범 사례 위의 표 1.2에서 RS 메모리 (M)의 40 %가 memstore 및 블록 캐시에 할당된다고 가정합니다. 이는 종종 기본 권장 값입니다. 이제, Memstore = RSxMemstore 분수 당 메모리 블록 캐쉬 = RSxblackcache 분수 당 메모리 : Memstore & Blockcache = 30.50 x 0.4 = 12.20GB

지역 서버 당 지역

지역 서버 당 지역 수를 제한하는 것이 가장 좋지만, 엄지 법칙을 사용하여 각 지역 서버에 얼마나 많은 수를 가져야하는지 결정할 수 있습니다. RS 당 영역 수 = (Ms ÷ Mfs) × 1000 RS 당 처리되는 데이터 = RS 당 영역 수 x RecRS JVM 힙에 대한 의존을 완화하는 오프 힙 캐시는 다음과 같습니다. 지역 서버 당 처리되는 데이터의 경우 20 %로 가정합니다. 따라서 지금까지 수행 한 계산 결과는 1 region 서버 → 476.56 GB의 데이터입니다.

기계 사양 및 크기

마지막으로 서버의 각 노드의 시스템 사양을 고려하지 않고 HBase 클러스터의 크기를 완전히 조정하는 것은 불가능합니다. HBase의 약속은 상용 하드웨어를 사용하여 기업이 수평으로 확장 할 수있게하는 것입니다. 즉, 범용 하드웨어는 핵심 사양 및 클러스터 설정 방법에 따라 다양한 결과를 산출 할 수 있습니다. 아래에서 볼 수있는 것은 전용 HBase 클러스터를 위해 설정된 클러스터를 묘사 한 것입니다. 당연히 실제 시나리오에서는 이러한 리소스를 공유하여 사용할 수 있습니다. 이로 인해 최종 구성을 결정할 때 HBase와 관계없는 요소를 고려해야합니다.  

#Disks	6 ~ 10
RAID 구성	RAID-0
각 디스크의 크기 (GB)	600 ~ 1024
CPU 코어	24
메모리 (GB)	512
최소 기계	삼

표 1.5 HBase 전용 가상 클러스터의 시스템 사양 HBase가 사용 가능한 메모리는 512GB입니다. HBase에 대해 시스템을 완전히 사용할 수 있다고 가정하기 때문입니다. 시스템 당 지역 서버 수 = 사용 가능한 HBase 메모리 ÷ (오프 힙 캐시 + RS 당 메모리) 따라서 첫 번째 예 : #region machine per machine = 512 / (95.31 + 30.50) ≈ 4 사용 가능 데이터 = 지역 서버 기계 당 * 지역 서버 당 처리되는 데이터 사용 가능한 데이터 = 4 x 476.56 = 1906.24 GB

기계 수 견적

마지막으로 HBase 클러스터의 여러 요소와 요구 사항을 해결 했으므로 필요한 시스템 수를 줄일 수 있습니다. 필요한 머신 수 = 최대 ([압축 된 데이터의 크기 / 머신 당 사용 가능한 데이터], 머신의 최소 개수) 압축 된 데이터 크기와 머신 당 사용 가능한 데이터를 기반으로 최대 머신 수를 다음과 같이 추정 할 수 있습니다. 압축 데이터의 크기 ÷ 컴퓨터 당 사용 가능한 데이터 = 419.10 ÷ 1906.24 ≈ 0.21 최대 (0.21,3) = 3 위의 가정을 기준으로 크기 차트는 10 번째응용 프로그램의 데이터 갈증을 촉진하기 위해 추가 노드를 추가하여 클러스터를 수평 확장해야합니다. 독자는 HBase와 같은 NoSQL 데이터베이스의 크기 조정이 주로 기계 구성, 데이터 볼륨 및 도구 별 오버 헤드에 달려 있음을 이해해야합니다. 게시물에서 가정을 변경하면 새로운 크기 조정 요구 사항이 제공됩니다. 더 잘 이해하기 위해 미리 계산 된 워크 북을 여기 에 첨부 합니다 - 크기 조정 시트 (HBase) .

끝 맺는 말

이 글에서는 HBase로 NoSQL 데이터베이스 사이징에 대한 자세한 사례 연구를 보았습니다. 또한 우리는 이러한 데이터베이스의 크기 조정에 영향을 미치는 많은 요소에 대해서도 논의했습니다. 업계의 대용량 데이터 사용 사례가 확산되면서 데이터 엔지니어는 효율적으로 수행 할 수있는 확장 가능한 데이터베이스를 개발해야합니다. 해마다 데이터 요구 사항과 변경 방법을 고려했을뿐만 아니라 Java 가상 머신의 영향과 HBase 성능에 영향을 미치는 기타 메모리 고려 사항에 대해서도 논의했습니다.  

참고 문헌 :

1. http://blog.cloudera.com/blog/2012/06/hbase-io-hfile-input-output/
2. https://www.mapr.com/blog/in-depth-look-hbase-architecture
3. https://www.ibm.com/developerworks/community/wikis/