MongoDB and Tokyo Tyrant are useful now. CouchDB has promise, but is too slow currently. Non-relational databases have shown their worth at larger sites when used cleverly. Non-relational databases will continue to improve performance, stability & features. Relational databases are still a great choice: fast, powerful and proven. With caching, denormalization, rework (e.g. Drizzle) & better replication, they will continue to be competitive.
1. 기능 추가 [#3332] Bigtable에서의 Memory Cache 기능 [#3121] Metrics에 ganglia 지원 [#3055] Tablet balacer 기능
2. 기능 개선 [#3411] MultiVersion query에서도 사용자 정의 Filter 사용 가능해야함 [#3197] hadoop 미 실행시 tabletserver startup이 안되어야 함 [#3144] 포맷시 ChangeLog image 파일은 dfs에서 삭제되지 않음 [#3071] TabletInfo에 start row key 추가 [#2960] NTable의 tablet lookup cache hit 비율 높히기 [#2943] changelog verifier가 실패한 경우 처리 [#2939] Web 관리자 화면에서 Tablet의 change log replica 서버 목록 보는 기능 [#2862] Tablet Split 처리시 put lock 시간 최소화 [#2802] CellFilter내에 start CellKey, end Cell Key 지정 기능 [#2702] NBlobInputStream open시 permission에러인 경우도 txTimeout까지 대기 [#2671] changelog server가 tablet server보다 많은 경우 changelog server의 할당 정책
3. Bug fix [#3382] 웹UI에서 ChangelogServer가 Live와 Dead 둘 다 나타납니다. [#3196] Cell 클래스내 버그 [#2938] NeptuneMaster만 restart 되었을 때 TabletServer의 Tablet 갯수가 0으로 표시 [#2762] DirectUploader에서 Cell의 null value 지정 [#2535] IO operation is timed out 180 sec due to timed out waiting for rpc response [#2473] IO operation is timed out 180 sec
* 1.4에서 ROOT, META 테이블에 저장되는 데이터가 변경되었습니다.
1.3 사용자는 1.4 로 업그레이드시 반드시 업그레이드 절차에 따라 업그레이드 해야 합니다.
Hadoop, HBase, Neptune 등에서 공통적으로 사용되고 있는 클래스가 Configuration 클래스입니다. Hadoop은 Configuration, HBase는 HBaseConfiguration, Neptune은 NConfiguration 입니다. 이들 각각의 클래스는 클래스 패스 상에 있는 xml 파일을 읽어 환경 변수를 메모리로 로딩하는 기능을 수행하는 클래스입니다. Hadoop을 이용하는 프로그램은 주로 배치 작업인 경우가 많기 때문에 Configuration 객체를 생성하기 위해 파일을 로딩하는데 성능상의 문제가 큰 이슈가 되지 않습니다. 하지만 Neptune이 HBase와 같이 실시간 트랜젝션 처리를 수행하는 시스템의 경우 이런 작업이 성능에 큰 영향을 줄 수 있습니다. Configuration 정보를 얻기 위해 xml파일을 오픈하여 parsing 하는데만 수십 ms 이상이 소요되기 때문에 수 ms의 트렌젝션 시간을 지원해야 하는 시스템의 경우 잘못 사용하게 되면 성능에 문제가 발생합니다. 따라서 Neptune, HBase 등을 사용할 경우 Configuration 객체는 특별한 경우가 하니라면 한번만 생성하여 재 사용하는 것이 좋습니다. 여기서 특별한 경우한 트렌젝션의 종류에 따라 Configuration의 값이 틀려져야 하는 경우를 의미합니다. 그럴 경우에도 미리 생성해 놓고 공유하는 것이 좋습니다.
이런 새로운 시도는 저장해야 할 데이터가 계속해서 증가하고 twitter와
같이 대량의 트렌젝션을 실시간 처리해야 하는 서비스가 많아 지면서 기존의 관계형 데이터베이스와는 다른 새로운 개념의 데이터 저장소에 대한 요구사항이
늘어났기 때문이다.
국내에서는 이제
겨우 Hadoop에 대한 기술적 검토만 수행되거나 적용되고 있는 상황이다. 따라서 관계형 데이터베이스(MySQL)와 분산파일시스템(Hadoop FS), 분산데이터저장소(Neptune) 등에 대한 정확한
차이점과 사용 용도에 대해 혼란이 많다. 이번 글에서는 이들 사이의 차이점과 각 사용 사례별로 적합한
저장소를 살펴보고자 한다.
No-SQL이나 Anti-RDBMS에서 주장하는 RDBMS의 문제점 또는 제약 조건으로 제시하는 데이터의 속성은 주로 확장성과 안정성이다.
확장성
RDBMS는 하나의 DBMS 인스턴스 내에서 저장할 수 있는 데이터의
크기는 제한적이다. 오라클과 같은 상용 DBMS의 경우에는
하나의 인스턴스에 수십억 이상의 레코드와 수백 GB 이상의 데이터를 저장할 수는 있지만 이보다 더 큰
데이터의 경우 여러 노드에 분산 배치하거나 Oracle-RAC 등과 같은 분산 기반의 솔루션을 도입해야
한다. MySQL과 같은 오픈소스 DBMS의 경우 하나의
인스턴스에서 많은 수의 레코드를 서비스하기 위해서는 적절하게 튜닝해야 하며 DBMS가 설치된 장비의
디스크 용량 내에서만 서비스 가능하다.
따라서 지금까지는
하나의 장비에서 수용 가능한 디스크 크기(보통 수백 GB) 이상의
데이터 저장에 대한 요구가 있는 경우 여러 대의 RDBMS에 분산시키고 분산된 DBMS의 데이터 파티션에 대한 정보를 관리하는 모듈을 각자 개발하여 사용하였다.
[그림] RBDMS를 이용한 클러스터 구성
이렇게 파티션
될 경우 분리된 파티션 간에는 RDBMS의 최고 강점인 엔티티 간의 관계연산 즉 JOIN 연산을 사용할 수 없다. 이런 문제를 해결해주는 솔루션이 Distributed RDBMS이지만 비용이 비싼 단점이 있다. 어쨌든
최근의 No-SQL에 대한 시도는 “RDBMS에서 JOIN을 사용할 수 없다면 굳이 RDBMS를 사용할 필요가 있는가?” 라는 의문에서 시작했다고 할 수 있다.
이런 구성에서는
데이터의 파티셔닝, 파티셔닝에 따른 query 수행 전략
등의 코드를 모두 개발자가 만들어야 한다. DBMS의 역할 중에 하나는 구조화된 데이터의 접근에 대해
추상화된 계층을 제공하여 개발자가 쉽게 접근 가능하도록 하는 것인데, 위와 같은 구조에서는 이런 역할을
수행하는 계층을 개발자가 구현해야 하는 부담이 있다.
[그림] 데이터관리시스템의 기능-추상화된 데이터관리 계층
또한 이런 정적인
구성에 가장 큰 문제점은 최초 구성된 클러스터 보다 더 많은 데이터 저장 공간이 필요하게 될 경우 새로운 DBMS
인스턴스를 추가하는 것 이외에 전체 클러스터에 대해 파티셔닝 작업을 다시 해야 하며 이런 작업은 보통 시스템을 멈춘 상태에서 작업을
하거나 데이터 유실이 발생할 수 있는 아주 위험한 작업이 된다.
따라서 데이터의
크기가 하나의 서버에서 처리할 수 있는 용량(보통 수백 GB)보다
더 큰 경우 분산 환경을 고려해야 한다. 가장 간단한 방법은 앞에서도 잠깐 언급한 분산 RDBMS를 사용하는 것이다. 분산
RDBMS는 기존의 RDBMS 기능(JOIN 등)을 그대로 가지면서 대용량 데이터를 저장할 수 있는 솔루션이다. 분산 RDBMS의 가장 큰 문제는 비용이다. twitter에서 발생하는
데이터나 웹에서 발생하는 데이터 등을 위해 이렇게 고 비용 저장소가 필요하지는 않다. 물론 텔레콤 회사의
요금 계산의 기초가 되는 콜 정보 등과 같이 중요하면서 대용량을 요구하는 데이터의 경우 고가의 분산 RDBMS에
저장할 수 있을 것이다.
다음으로 생각할
수 있는 스토리지는 Hadoop 등과 같은 오픈소스 기반의 분산 데이터 저장소이다. Hadoop은 데이터를 저장하는 파일시스템(hdfs, Hadoop
distributed file system)과 데이터를 분석하는 MapReduce 두 가지
핵심적인 기능을 제공한다. Hadoop에서 가장 오해를 많이 하는 부분이 데이터 저장 부분이다. Hadoop에서 제공하는 데이터 저장소는 단순히 파일 시스템 기능만 제공하기 때문에 파일 내부에 저장된 데이터
중 일부를 검색하거나, 키를 이용하여 데이터를 수정하는 등과 같은 실시간 연산에서는 사용하기 어렵다. Hadoop 파일 시스템이 실시간 처리가 가능하다는 오해를 갖게 된 가장 큰 원인은 Hive라고 하는 Hadoop의 서브 프로젝트 때문이다. Hive는 SQL과 비슷한 문법을 이용하여 Hadoop 내에 테이블을 생성하고 생성된 테이블에 데이터를 저장하거나 조회하는 기능을 제공한다. 하지만 Hive에서 수행되는 모든
SQL(Query)은 MapReduce 작업으로 수행되며
Hadoop은 MapReduce 작업을 실행하는데 최소 수초 이상의 준비 작업을 거친다. 따라서 Hive는 실시간 처리를 위한 SQL이 아니라 배치 처리(MapReduce) 작업을 SQL 문법을 이용해서 쉽게 해주는 도구에 불과하다.
또 다른 데이터
저장소로는 최근 많이 이슈화 되고 있는 Key-value 스토리지가 있다. Key-Value 스토리지는 대용량 데이터에 대해 심플한 데이터 모델과 실시간 처리를 주요 기능으로 제공한다. 따라서 엔티티의 관계 연산(JOIN)은 지원하지 않으며 분산(또는 standalone)된 환경에서 운영된다. Key-Value 스토리지는 구글의 Bigtable 개념을 도입한
스토리지와 아마존의 Dynamo의 개념을 도입한 스토리지로 구분할 수 있다.
아마존의 Dynamo 개념을 도입한 스토리지는 DHT(Distributed Hash
Table)라고 하는 해쉬 기반의 키 파티셔닝 전략을 이용하여 데이터를 분산된 노드에서 저장한다 한다. Bigtable 개념을 도입한 스토리지는 특정 Key를 서비스하고
있는 노드에 대한 정보를 별도의 META 정보로 관리하며 이들 Key에
대해서 인덱스 정보까지 가지고 있어 Dynamo 계열 저장소 보다는 다양한 데이터 연산을 제공한다.
Key-Value 저장소는 기본적으로 대용량 처리를 목적으로 설계되었기 때문에 데이터의 확장성은 대체적으로 잘
지원하고 있다. 앞에서 언급한 RDBMS를 분산 배치시켜
개발자가 만든 프로그램에 의해 관리되던 부분을 Key-Value 저장소가 대체함으로써 개발자에게 다시
추상화된 데이터 저장소 계층을 제공하는 데이터관리시스템의 본연의 기능을 수행하고 있다.
안정성
RDBMS는 다양한 방법을 이용하여 저장된 데이터의 안정성은 확보한다. 데이터
파일을 저장하는 스토리지 자체에서 안정성을 제공할 수도 있으며(이런 스토리지는 일반적으로 가격이 비싸다), 주기적으로 백업을 받거나, RDBMS 솔루션 자체에서 제공하는 replication 기능을 이용할 수도 있다. 이런 모든 작업이
관리자를 필요로 하게 된다. 특정 DB 서버에 장애가 발생할
경우 백업 받은 데이터를 이용하여 복구하거나 replication 된 서버가 다시 active한 master로 인식하게 하는 등의 작업이 필요하다. RDBMS의 기본 전제는 DBMS가 수행된 서버에 장애가 발생하지
않는다는 가정하에 만들어진 솔루션이기 때문에 안정적인 스토리지, 백업 등과 같은 DBMS와 관련 없는 솔루션이나 기법들이 추가되어야 한다. 이렇게
추가되는 항목들은 비용을 발생시키거나 더 많은 관리를 필요로 하게 된다. 또한 대용량 데이터 저장을
위해 다수의 데이터베이스 서버를 운영하는 경우라면 이런 관리가 아주 복잡하게 엉켜버릴 수도 있다. 수
백대의 MySQL 서버를 Master-Slave 관계로 구성하고
그 중 5% 서버에 장애가 항상 발생할 수 있다고 상상해보라.
Hadoop이나 대부분의 Key-Value 스토리지는 특정 서버의 장애를
일반적인 상황으로 간주하여 설계되어 있기 때문에 솔루션 자체 내에 안정성을 보장하고 있다. 데이터의
복제, 서버 장애 발생시 self-healing 기능 등이
이미 구현되어 있기 때문에 특정 서버에 장애가 발생하여도 정상적인 데이터 서비스가 가능하며, 장애가
발생한 서버를 빼고 새로운 서버를 넣고 몇 개의 단순한 명령만 수행하면 새로운 노드가 추가된다.
적합한 스토리지의 선택
아직까지 많은
프로젝트에서 요구사항은 대용량임에도 불구하고 NAS, Local Disk, RDBMS 만을 이용하여
시스템을 설계한다. 당장 시스템을 만들어 오픈 할 수는 있지만 1 ~
2년 내에 쌓여가는 데이터를 보면서 증설 계획이나 시스템 업그레이드 계획을 수립하게 된다. 이제
개발자 NAS, Local Disk, RDBMS뿐만 아니라 추가로 분산파일시스템, 분산데이터저장소를 이용할 수 있다. 시스템의 아키텍처 단계에서 요구사항
분석 후 시스템을 구성하는 데이터의 특성을 분석하고 각 특성에 맞는 적절한 스토리지를 선택함으로써 개발
-> 관리 -> 시스템 중지 -> 확장 -> 관리가 반복되는 악순환을 제거할 수 있다.
적합한 스토리지를
선택하기 위해서는 먼저 데이터가 요구하는 속성부터 정의해야 한다. 일반적으로 다음과 같은 속성을 정의할
수 있다.
-데이터 용량
스토리지에
저장될 데이터가 수백 GB 이상 이거나 한대의 장비에 저장할 수 있는지 여부
-실시간 데이터 처리
데이터의
처리(select, insert)가 실시간 처리를 요구하는지 여부
-데이터 복잡성
다양한 데이터가 존재하고 데이터 간의 관계가 복잡한지 여부
-안정성
아주
중요한 데이터라서 고 가용성을 요구하는지 여부
-분석 작업과 연계
저장된
데이터를 이용하여 분석 작업이 수행되는지 여부
-비용
이런 데이터 특성에 대해 각 스토리지는 다음과 같이 지원한다.
위의 스토리지
특성과 요구사항에서 도출된 데이터 특성을 비교하여 적합한 스토리지를 선택한다. 최근 시스템은 다양한
특성을 가진 데이터를 관리해야 한다. 따라서 시스템에서 사용되는 스토리지 솔루션도 과거와 같이 NAS, RDBMS 두 종류로만 구성되는 것이 아니라 위에서 언급한 다양한 스토리지 구성을 고려해야 한다.
예를 들어 실시간
데이터 처리가 필요하고, 대용량이면서 비용이 싼 스토리지가 필요하면
Neptune이나 Dynomite 등을 고려할 수 있다.
다음은 RDBMS, Hadoop, Neptune으로 구성된 시스템 사례이다.
[그림] 애플리케이션의 구성 사례
위의 시스템 구성은 다음과 같은 요구사항을 만족하는 시스템 구성이다.
-시스템으로 요청되는 데이터는 대부분 실시간으로 처리되어야 하며 데이터는 계속 누적되어야
한다(Neptune).
-누적된 데이터는 실시간으로 조회되어야 한다(Neptune).
-데이터 중 일부는 파일 형태의 데이터도 있다(Hadoop).
-저장된 데이터는 주기적으로 배치 작업을 통해 분석 되어야 하며(Hadoop MapReduce) 분석된 결과 중 일부는 데이터 크기는 작지만 복잡한 query 등에서 활용 가능해야 한다(RDBMS).
-분석 결과 중 일부는 대용량 데이터이며 실시간으로 화면에서 조회 가능해야 한다(Neptune).
-데이터 분석은 요구사항이 수시로 변경될 수 있으며 요구사항 변경에 따라 기존 저장된 데이터를
이용하여 빠르게 분석 가능해야 한다(Hadoop MapReduce).
결론
최근 Hadoop, Neptune 등과 같은 다양한 스토리지가 나오고 있으며 일부 개발자는 이를 자신의 시스템에 적용해보고자
기술적 욕심을 가지고 있다. 하지만 스토리지의 선택은 신중해야 하며 데이터의 특성에 적합만 스토리지를
선택해야 한다. 그렇지 않으면 개발 시 많은 공수가 필요하거나 시스템 오픈 후 1 ~ 2년 후에 문제가 발생할 수 있다.
Neptune이나 HBase와 같은 Bigtable
기반의 데이터 저장소를 사용하고 싶다는 문의가 많은데 요구사항을 자세히 분석해보면 Hadoop + RDBMS로
충분히 해결 가능한 구성인 경우가 많다. Neptune과 같은 저장소가 사용되는 기본 전제조건은 실시간
처리 여부와 데이터 용량이다. 실시간 처리가 필요하고 데이터가 작으면
RDBMS 사용하는 것이 최상의 선택이다. 개발자도 익숙하고 다양한 데이터 연산을 제공하기
때문이다. 실시간 처리가 필요하고 데이터 용량이 많은 경우라면
Neptune이나 분산 RDBMS를 고려할 수 있다. 저비용이며
상대적으로 덜 중요한 데이터이면 Neptune을 사용할 수 있다. 대용량이면서
실시간 처리가 필요 없는 경우라면 Hadoop 만으로도 충분하다. 저장된
데이터를 배치로 분석하였는데 분석된 결과가 다시 실시간으로 서비스 되어야 하고 대용량인 경우라면 Neptune과
같은 저장소를 사용해야 한다.
1. neptune memory 자료구조 개선
- 과제개요: Neptune의 TabletServer에서의 MemoryTable의 메모리 자료 구조 개선을 통해 메모리 사용량을 줄이는 것을 목적으로 한다.
- 현황:
+ 현재 neptune 메모리 자료 구조는 jdk에서 기본적으로 제공하는 HashMap, TreeMap, TreeSet을 사용하고 있으며 최종적으로 메모리에
저장되는 객체는 ColumnValue이며 String, byte[] 등을 멤버변수로 가지고 있다.
+ 자바에서는 실제 필요한 메모리 보다 이를 관리하기 위한 메모리로 인해 메모리 낭비가 있어
현재의 구현보다 좀 더 효율적인 메모리 자료구조가 필요하다.
+ Neptune에서 입력된 데이터는 Memory에 먼저 저장되고 Memory가 정해진 크기 이상이 되면 Disk로 저장하는 방식으로 취하고 있기 때문에
Memory 사용량을 줄이면 Disk로 저장되는 횟수를 줄일 수 있어 성능 향상이 된다.
- 선정기준:
+ 1 column, 100 row, 1000 cells each row, 1000 byte cell value 기준으로 메모리 사용율 및 put/get 성능
+ Neptune 테스트 케이스 통과(com.nhncorp.neptune.client.TestNTable) - 필수
2 Neptune을 다른 분산파일시스템에 적용
- 과제개요: Neptune은 파일 저장소로 분산파일시스템을 이용하고 있는데 기본 구현은 Hadoop 파일 시스템을 이용하고 있다.
이번 과제는 Neptune을 Hadoop 파일시스템이 아닌 다른 분산파일시스템을 적용하고 그 성능을 테스트하는 과제이다.
- 현황:
Neptune의 현재 구현은 파일 시스템을 추상화시켜 com.nhncorp.neptune.fs.NeptuneFileSystem이라고 하는 추상클래스를 정의하고 있으며
데이터의 저장 및 조회를 위해 NeptuneFileSystem 추상 클래스를 이용하고 있다.
따라서 Neptune에 다른 분산파일시스템을 적용하기 위해서는 Neptune의 요구사항에 맞는 분산 스토리지를 선정하여 해당 파일시스템을
이용할 수 있도록 NeptuneFileSystem에 정의된 추상메소드를 구현하면 된다.
- 선정기준
+ random write, random read 성능: PerfomranceTest 코드 이용
+ Neptune 테스트 케이스 통과(com.nhncorp.neptune.client.TestNTable) - 필수
3. neptune META recover
- 과제개요: Neptune의 META 데이터가 유실되었을 때 데이터 파일을 이용하여 META 데이터를 복구하는 도구 개발
- 현황:
현재 일부 개발 되어 있지만 ChangeLog 파일 적용 및 성능 등의 문제로 사용하기 어려움
따라서 MapReduce를 이용하여 META 정보를 복구하는 프로그램이 필요함
- 선정기준
+ 기능 구현 여부
+ 자체 테스트 프로그램
+ 복구 속도
4. 자유과제
- 위 세가지 과제 이외에 추가로 Neptune 엔진이나 Neptune을 사용하는 서비스, 사용 도구 등 모든 주제 제출 가능
경품은 크지 않지만 이를 이런 행사를 통해 관심있는 분야의 사람들끼리 모여서 같이 만들어 가는 자리가 되었으면 합니다. 참여하신 분들에게는 제 사비라도 털어서 보답하겠습니다 .ㅋㅋㅋ
Neptune에서 put 연산은 일단 메모리에 저장된 다음 메모리가 일정 크기 이상 커지게 되면 파일시스템(분산파일시스템, hadoop 등)으로 저장하는 구조를 가지고 있습니다. 당연한 결과이지만 다음과 같은 상황을 발견하였습니다.
메모리의 내용을 파일시스템으로 저장하는 bandwidth가 put 요청에 의해 메모리에 저장되는 bandwidth보다 작으면 메모리 부족 현상이 발생한다.
당연하겠죠... 문제는 파일시스템으로 저장하는 bandwidth가 얼마인지 알아야지만 put에 대한 bandwidth를 조절할 수 있다는 겁니다. 단순히 파일시스템의 I/O를 측정하면 될 것 같지만 좀 더 복잡한 문제가 있습니다. Neptune의 경우 하나의 파일 I/O가 많이 발생하는 부분은 다음 4가지 상황입니다. 1. 메모리 -> 파일시스템(Minor Compaction) 2. 여러개의 파일을 하나로 Merge(Major Compaction) 3. 큰 파일을 두개로 분리(Split) 4. put 요청된 commit 로그 저장
여기서 메모리 문제만 보면 Minor Compaction에 가중치를 두어 수행하게 할 수 있겠지만 이럴 경우 Split이나 Major Compaction이 더디게 수행되고 이렇게 되면 get 성능 저하, Split 시간이 더 많이 소요되는 등 또 다른 문제점이 발생할 수 있습니다. 그리고 put bandwidth의 경우 사용자가 저장하는 데이터의 크기에 따라 다양하게 나타날 수 있습니다. 하나의 Cell Value내에 100 byte 저장할 때와 100K 저장할 때 TabletServer요청되는 데이터양은 크게 차이가 납니다. 이런 모든 것을 고려하여 TabletServer 파라미터들을 설정하여야 하는데 관련 파라미터는 다음과 같습니다.
1. tabletServer.maxMinorCompactionThread 하나의 TabletServer에서 동시에 수행할 수 있는 Minor Compaction 갯수 많으면 메모리를 더 빨리 확보할 수 있지만 파일시스템의 부하로 인해 일정 수준이상 늘릴 경우 더 느려질수 있음
2. tabletServer.maxMajorCompactionThread 하나의 TabletServer에서 동시에 수행할 수 있는 Major Compaction 갯수 neptunemaster.iolock.ratio 값과 연동되어 동작함.
3. tabletServer.maxSplitThread 하나의 TabletServer에서 동시에 수행할 수 있는 Split 갯수 neptunemaster.iolock.ratio 값과 연동되어 동작함.
4. tabletServer.put.heavyMemoryAcceptRate TabletServer의 heap 메모리가 일정 수준이하로 떨어질 경우 put 요청을 skip 시키고 클라이언트(NTable)이 재시도를 한다. 모든 요청을 skip 시키는 것이 아니라 이 값에 따라 일정한 비율로 skip 시킨다.
5. tabletServer.put.splitingAcceptRate Tablet이 split 중인 경우에는 minor compaction 작업이 수행되지 않기 때문에 너무 많은 put 요청이 오게되면 메모리 부족 현상이 발생할 수 있다. Tablet split인 경우 put 요청을 skip 시키고 클라이언트(NTable)이 재시도를 한다. 이때 NTable에서 sleep 하는 시간(ms).
값이 크면 TabletServer에 부하는 줄어들지만 put의 성능이 저하된다.
6. tabletServer.heavyMemoryPutSleep tabletServer.put.heavyMemoryAcceptRate에 의해 skip 된 put 요청은 NTable에서 일정 시간 sleep 후 다시 재시도한다. 이 값은 NTable에서 sleep 하는 시간(ms)을 나타낸다. 값이 크면 TabletServer에 부하는 줄어들지만 put의 성능이 저하된다.
7. tabletServer.tabletSplitPutSleep tabletServer.put.splitingAcceptRate에 의해 skip 된 put 요청은 NTable에서 일정
시간 sleep 후 다시 재시도한다. 이 값은 NTable에서 sleep 하는 시간(ms)을 나타낸다. 값이 크면
TabletServer에 부하는 줄어들지만 put의 성능이 저하된다.
8. neptunemaster.iolock.ratio 전체 클러스터의 split/major compaction의 부하 수준을 결정한다. TabletServer가 하나 추가될 때 마다 클러스터 전체에서 동시에 수행할 수 있는 Split, Major Compaction Thread는 이 수치의 배수만큼 증가한다. 예를 들어 ratio가 2로 설정되어 있고 전체 TabletServer의 대수가 10대인 경우 동시에 수행할 수 있는 Thread는 20이 된다. 이렇게 제한을 두는 이유는 maxSplitThread 등의 값이 5로 설정되어 있고 TabletServer가 10대이면 50개의 Thread가 파일시스템으로 I/O 요청을 하게 되는데 이렇게 되면 파일시스템 측에 병목이 발생하여 commit 로그 저장, Minor compaction 수행에도 영향을 미치게 된다. 따라서 적절한 수준으로 파일시스템의 부하를 조정하기 위해 ratio를 설정 가능하도록 하였다. 이 값이 작으면 파일시스템 I/O 부하는 줄어들지만 하나의 Tablet의 크기가 커져 Split하는데 시간이 더 많이 소요될 수 있으며 Tablet의 데이터 파일의 갯수가 많아져 get 성능이 나빠지면 merge 수행하는데에도 시간이 더 많이 소요된다.
9. split.majorcompaction.ratio neptunemaster.iolock.ratio에 의해 설정된 값 중 Split과 Major Compaction의 비율. 예를 들어 neptunemaster.iolock.ratio의 값에 의해 동시에 수행할 수 있는 갯수가 10인 경우 split.majorcompaction.ratio 값이 0.7 이면 7개는 Split이 3개는Major Compaction을 수행한다. 이 수치는 Split과 Major Compaction이 동시에 스케쥴링 되었을 때만 반영되고 Split만 스케쥴링되었을 경우 10개를 모두 Split에 할당한다.
GAIA_Neptune_Platformday2009.pdf
