최근 대용량으로 끊임없이 전송되는 로그성 데이터를 저장할 수 있는 저장소로 어떤 NoSQL 솔루션을 사용하면 좋을지에 대해 검증중입니다. 현재까지 테스트한 솔루션은 cloudata(www.cloudata.org), hbase 입니다. hbase 테스트 결과는 http://www.jaso.co.kr/411 에 있습니다. cloudata는 hbase와 동일합니다.
오늘은 mongo db의 sharding 구성에 대해 테스트를 했습니다. 테스트는 처음에는 여러 서버로 샤딩을 구성해서 진행하다가 테스트가 정상적으로 진행이 되지 않아 두대의 서버만 구성해서 테스트를 수행했습니다.
- 데이터 서버(mongod): 2대, replica-set 구성은 하지 않음 - config 서버: 3대(데이터 서버에 1대 더 추가) - mongos: 데이터 서버 사용 - 테스트 클라이언트: 1대, 싱글쓰레드
테스트를 수행하면 첨부한 파일과 같이 대략 500 ~ 1000 TPS가 나타납니다. 하나의 클라이언트로만 테스트 했기 때문에 이 TPS가 mongo db의 최대 성능은 아닙니다. 하나의 mongo db는 대략 수백 ~ 만 정도의 TPS에 들쑥날쑥하고 평균적으로는 1000 ~ 2000 정도 나오는 것 같습니다. 첨부한 파일에서 보는 것 처럼 TPS가 0인 구간이 계속 유지되는 것을 볼 수 있습니다. 그리고 그때 서버의 로그를 보면 다음과 같은 메세지가 지속적으로 나타납니다.
"[conn11] waiting till out of critical section"
이것은 청크를 샤딩된 다른 서버로 보내거나 샤딩 정보를 수정할때 락이 발생하고 이것 때문에 트랜젝션을 못받아 주는 것으로 생각됩니다. 꾸준히 일정 수준이상의 insert 트래픽이 지속적으로 전송되는 서비스에 사용하기 위해서는 별도의 튜닝 작업이 필요할 것으로 생각됩니다. tps의 시간대별 변화를 나타내면 다음 그림과 같습니다.
tps가 0인 구간이 지속되는 부분이 있습니다. 이 구간에서는 클라이언트의 요청을 거의 처리 못하고 있는 구간이라고 볼 수 있습니다.
오랜만에 hbase 성능테스트를 하였습니다. 버전은 stable 버전으로 릴리즈된 0.20.6을 사용하였습니다. 이전에도 테스트를 수행했는데 이번에 테스트한 것과 같이 대량으로 데이터를 저장하는 테스트가 아닌 속도 위주의 테스트만 진행했었습니다. 이번에 테스트한 내용은 다음과 같습니다. 1. Hadoop/HBase - Hadoop 0.20.2 - HBase: 0.20.6 - 서버: NameNode 1, DataNode 6, 각 서버에 TaskTracker, HBase Region Server 실행 - Region Server Max Heap: 4GB
2. 테스트 프로그램 - Map only로 32개의 map task가 각 서버에 6개씩 실행 - 한 MapTask에서 1000byte 1 row를 1GB 씩 저장 - 전체 1000개의 Task 수행(약 1TB 저장 테스트)
3. 테스트 결과 - 전체 작업 52% 진행 후 task kill됨 - 작업 kill 당시 Region 갯수: 4098, 서버당 약 680개 - kill 원인은 한건 put하는데 10분 이상 걸려 mapreduce 작업 타임아웃에 걸림 - 실행 시간 각 MapTask가 32개씩 병렬로 수행되는 구조이기 때문에 32개 * (1024 * 1024 * 1024)/1000 만큼의 갯수가 매번 32개 Task가 종료될때마다 저장됨 따라서 Hbase의 TPS(Transaction per Second) 는 다음과 같이 계산 가능 TPS = (32개 * (1024 * 1024 * 1024)/1000) / 32개 map task 실행시간
실행 시간은 hbase에 레코드가 많이 쌓일수록 많이 소요되어 있으며 다음과 같다.
hbase에 데이터가 없는 경우에는 약 7000 TPS 정도 나오지만 테이터 어느 정도 저장된 상태에서는 3000 ~ 4000 정도로 절반 이하로 떨어진다. 이 상태에서 계속해서 데이터가 입력되면 더 이상 데이터를 받아 줄 수 없는 상태가 된다.
4. 시사점 - 본 테스트의 결과는 6대의 hbase 클러스터로 어느 정도의 throughput을 낼 수 있는지 측정을 하는 것이 었다. 결론적으로는 약 5000 ~ 7000 정도의 TPS의 성능이 나오지만 이런 트래픽이 지속적으로 유입되는 경우에는 저장할 수 없다. - 이런 증상은 cloudata(www.cloudata.org)도 거의 유사한데 원인은 관리하는 Region(Tablet)이 많아지면 그 만큼 메모리 관리와 디스크 저장에 오버헤드가 크기 때문이다. hadoop을 파일시스템으로 사용하는 경우 한번의 write가 세개의 서버에 I/O가 발생하기 때문에 오버헤드가 훨씬 더 크다고 할 수 있다. - 솔루션 내부적으로 어떻게 잘 스케쥴링 하느냐가 관건인데 아직까지는 최적화가 많이 필요할 것으로 생각된다. - 현재의 대안은 hadoop 클러스터와 hbase 클러스터의 크기를 조절하는 방법도 생각해 볼 수 있다. 예를 들어 hadoop을 30대에 설치 했다면 hbase는 1/3 정도인 10대의 서버에만 설치하는 것이다. 이렇게 함으로써 클러스터 전체의 I/O 부하를 줄이면 최소한 데이터가 입력되지 않는 상황은 발생하지 않을 것으로 예측된다. -> 실제 장비 부족으로 테스트를 수행하지는 않음
빈도수가 높다라기 보다는 클러스터가 견딜 수 있는 TPS를 측정할때 이런 증상이 나타나게 되면 감당 가능한 TPS가 넘어었다는 의미겠죠 즉 임계치를 넘었으니까 테스트 할때 request를 더 작게 해서 해봐야 겠죠...
클러스터의 TPS를 알아야 요구사항대비 시스템의 용량이 맞는지 확인해 볼 수 있습니다. 따라서 이런 증상이 자체가 나오면 안되겠죠. ㅋㅋㅋ
안녕하세요~ HBase 를 관련해서 공부를 하는 학생입니다.
근데 제가 구현한 상태에서 측정한 TPS와는 차이가 좀 나서 좀 조언을 구하려고 합니다.
저는 6개 대신 5개의 서버로 구성하였습니다.
그리고 원격에서 대략 다음과 같은 코드를 이용하여 데이터를 삽입하였습니다.
HTable table = new HTable("TEST";
for(i = 0; i < 100000; i++) {
Put put = new Put(Bytes.toByte(i));
put.add(.....);
put.add(.....);
table.put(put);
}
대충 이 비슷한 코든데 데이터 자체의 크기도 그리 크지 않습니다.
위와 같은 로직에서 약 350 TPS 가 나오는데요(Autoflush true 일 때)...
어딘가 성능차이가 크게 발생할 만한 부분이 있을까요?
구체적인 서버 환경과 테스트 프로그램 등을 종합적으로 봐야 알 것 같습니다.
현재 추측해볼 수 있는 것은 성능 테스트에 참여한 클라이언트를 1대 또는 작은 대수로 돌리게 되면 Region Server의 최대 성능을 사용하기 어렵습니다. 그리고 테이블 생성 시 디폴트로 생성하면 Region이 하나만 생성되어 분산의 효과를 보기 어렵습니다.
VoltDB라고 분산된 환경에서 SQL을 지원하는 NoSQL 솔루션에 대한 기사가 나와서 몇가지 살펴 보았습니다.
메인 페이지에 소개된 내용만으로는 상당히 쓸만한 솔루션 같았는데 자세히 보니 메모리 기반으로 동작한다고 하네요...
NoSQL 솔루션 분석할 때 주의할 점이 바로 이런 부분에 있습니다. VoltDB 성능 비교도 Cassandra 등과 하고 있는데 이건 잘못된 비교 방식이죠. Cassandra는 파일 시스템에 데이터를 저장하기 때문에 상식적으로도 성능 비교 자체가 의미가 없죠...
NoSQL 솔루션을 검토하기 위해서는 대략 다음과 같은 사항에 대해 검토해봐야 합니다.
1. 확장성: 얼마나 많이, 얼마나 쉽게, 노드의 추가/제거시 시스템 부하는 어떻게 되는지, 제거는 쉽게할 수 있는지 등
2. 데이터모델: 관계형, key/value, Document, Bigtable style 등
3. 성능: 단순 성능이 아니라 데이터가 많이 저장되어 있는 상태에서의 성능
4. 데이터 저장 가능 용량: 메모리 기반인지 디스크 기반인지
5. 관리의 편의성: 일반적으로 DHT 등과 같은 기술을 사용하면 관리가 어렵고 중앙집중 메타 데이터 방식을 사용할 경우 관리가 좀 쉬운 경향이 있습니다.
6. 지원하는 클라이언트 API: 이것도 안되는 경우가 많이 있습니다.
7. 인덱스 지원 여부: 응용 애플리케이션의 요구에 따라 달라질 수 있지만 인덱스를 지원하는지 여부에 대해서는 검토가 필요합니다.
8. 라이센스 9. 안정성
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과
같은 저장소를 사용해야 한다.
tps.txt
;
GAIA_Neptune_Platformday2009.pdf
