BigData
빅 데이터 애플리케이션을위한 NoSQL 데이터베이스의 효과적인 크기 조정
IT오이시이
2018. 7. 24. 01:18
728x90
빅 데이터 애플리케이션을위한 NoSQL 데이터베이스의 효과적인 크기 조정
Rajini 라잔 | 11/01/2017
http://www.thedatateam.in/perspective/post/index.html?postId=34
구조화되지 않은 데이터의 확산으로 인해 대규모의 다양한 데이터 세트를 수집 및 처리하는 것이 조직의 실제 과제였습니다. 조직은 종종 조직 프로세스, 시스템 및 고객으로부터 비정형 데이터를 관리 할 때 NoSQL 데이터베이스를 설정하고 크기를 조정해야하는 어려움을 겪습니다. 크기 조정은 조직에서 직면 한 광범위한 데이터 문제에 대한 핵심 과제입니다. 데이터 엔지니어 및 IT 관리자는 데이터에 대한 올바른 하드웨어 계획에 어떻게 도달 할 수 있습니까? 거대한 데이터 세트 및 현대적인 고객 홍보에 대한 데이터베이스의 크기, 성능 및 확장성에 영향을 미치는 요인 및 고려 사항은 무엇입니까? 이것들은 우리가이 게시물에서 다루기를 희망하는 몇 가지 질문입니다. 특히 HBase를 살펴 보겠습니다.
[표 1.1] HBase의 규모 (전년 대비)
(약) 10 % YoY 증가, Y2 1,800,000,000 + (1,800,000,000 * 0.1) = 1,980 만
HBase 개요
HBase는 엄청난 양의 데이터를 색인 생성하고 관리하는 탁월한 도구입니다. 랜덤 액세스, 일관된 읽기 / 쓰기, 가변 스키마 등의 특성 외에도 HBase는 수평 적으로 확장 할 수있는 능력으로 널리 인정 받고 있습니다. 데이터가 기업에서 증식 할 수있는 속도는 때때로 예측할 수 없습니다. HBase의 자동 샤딩은 기존 데이터에 영향을 미치지 않고 새로운 데이터 노드 즉 수평 스케일링을 추가함으로써 데이터 밸런싱을 효율적으로 가능하게합니다. 그러나 조직에서는 HBase의 이점을 활용할 수 있습니다. 단, 조직의 애플리케이션 및 사용 사례의 요구 사항에 따라 적절하게 데이터베이스 크기를 조정해야합니다. 따라서 HBase 클러스터의 규모를 결정하는 데 꼭 필요한 지침은 없습니다. 즉, HBase 사이징에 영향을 미치는 많은 핵심 요소가 있다.
데이터 저장소에 필요한 메모리
데이터의 크기는 HBase 구성을 결정하는 데 매우 중요합니다. 그러나 디스크의 물리적 데이터 크기는 데이터의 논리적 크기와 다르지만 종속적입니다. 디스크의 실제 데이터 크기는 다음과 같습니다.- - HBase 오버 헤드 증가
- - 압축 및 데이터 블록 인코딩에 의해 감소
- - 지역 서버의 크기 증가
- - HDFS 복제로 증가 - 일반적으로 3 배 (3 배) 복제 스키마. 맞춤 설정 가능
- 데이터 양 : 하루에 예상되는 데이터는 5 백만 행으로 가정되며 각 레코드 크기는 1000 바이트입니다
- 데이터 보관 : 아니오 : 데이터를 데이터베이스에 보존 해야하는 일수. 가정 : 10 년
- 전년 대비 증가량 : 매년 지나갈 때마다 데이터 양이 증가 할 것으로 예상됩니다. 가정 : 10 %
- 압축 비율 : 사용 가능한 데이터에 대한 예상 압축. 가정 : 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 |
데이터 양
이 예제에서 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 % |
데이터 볼륨에 대한 압축 효과
압축은 데이터 볼륨을 줄이는 데 도움이됩니다. 채택 된 압축 방식에 따라 사용중인 알고리즘이 다를 수 있으며 압축 성능이 데이터 크기에 영향을 미칩니다. 압축 비율을 알면 데이터의 크기 (오버 헤드 고려)를 다음과 같이 계산할 수 있습니다. 크기 (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 |
하드웨어 요구 사항 : 핵심 요소
이제 데이터 양과 압축 측면을 이해 했으므로 하드웨어 요구 사항을 예측할 수 있습니다. 필요한 머신 = 최대 ([압축 된 데이터의 크기 ÷ 머신 당 사용 가능한 데이터], 최소 머신 수 : 하드웨어 요구 사항을 계산하기 전에, 아래의 두 가지 중요한 고려 사항 인 영역 서버 및 JVM 메모리 관리 고려 사항을 살펴 보겠습니다.지역 서버 및 JVM 힙 고려 사항
우리는 이전 섹션에서 압축 된 데이터의 크기를 계산했습니다. 머신 당 사용 가능한 데이터는 지역 서버에 의존한다는 점에 유의해야합니다. 지역 서버는 모든 지역에 대해 모든 읽기 및 쓰기 요청을 담당합니다. 또한 구성된 영역 크기 임계 값을 초과하는 영역을 분할합니다. HBase는 "메모리 저장소"와 "블록 캐시"의 두 가지 캐시 구조를 유지 관리합니다.- 메모리 저장소는 수신 된 데이터 편집 내용을 누적하여 메모리에 버퍼링합니다.
- 블록 캐시는 읽은 후에 메모리에 상주하는 데이터 블록을 유지합니다.
| 지역 서버 (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
표 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
지역 서버 당 지역
지역 서버 당 지역 수를 제한하는 것이 가장 좋지만, 엄지 법칙을 사용하여 각 지역 서버에 얼마나 많은 수를 가져야하는지 결정할 수 있습니다. 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 |
| 최소 기계 | 삼 |
기계 수 견적
마지막으로 HBase 클러스터의 여러 요소와 요구 사항을 해결 했으므로 필요한 시스템 수를 줄일 수 있습니다. 필요한 머신 수 = 최대 ([압축 된 데이터의 크기 / 머신 당 사용 가능한 데이터], 머신의 최소 개수) 압축 된 데이터 크기와 머신 당 사용 가능한 데이터를 기반으로 최대 머신 수를 다음과 같이 추정 할 수 있습니다. 압축 데이터의 크기 ÷ 컴퓨터 당 사용 가능한 데이터 = 419.10 ÷ 1906.24 ≈ 0.21 최대 (0.21,3) = 3 위의 가정을 기준으로 크기 차트는 10 번째응용 프로그램의 데이터 갈증을 촉진하기 위해 추가 노드를 추가하여 클러스터를 수평 확장해야합니다. 독자는 HBase와 같은 NoSQL 데이터베이스의 크기 조정이 주로 기계 구성, 데이터 볼륨 및 도구 별 오버 헤드에 달려 있음을 이해해야합니다. 게시물에서 가정을 변경하면 새로운 크기 조정 요구 사항이 제공됩니다. 더 잘 이해하기 위해 미리 계산 된 워크 북을 여기 에 첨부 합니다 - 크기 조정 시트 (HBase) .끝 맺는 말
이 글에서는 HBase로 NoSQL 데이터베이스 사이징에 대한 자세한 사례 연구를 보았습니다. 또한 우리는 이러한 데이터베이스의 크기 조정에 영향을 미치는 많은 요소에 대해서도 논의했습니다. 업계의 대용량 데이터 사용 사례가 확산되면서 데이터 엔지니어는 효율적으로 수행 할 수있는 확장 가능한 데이터베이스를 개발해야합니다. 해마다 데이터 요구 사항과 변경 방법을 고려했을뿐만 아니라 Java 가상 머신의 영향과 HBase 성능에 영향을 미치는 기타 메모리 고려 사항에 대해서도 논의했습니다.참고 문헌 :
728x90
반응형