공부할 가치가 된다는 생각에 리스트업해보는 차원에 포스팅 하는 것이므로, 큰 기대는 말자.
1. 클라우드 환경에서의 RDBMS 의 문제점?
관계형 디비의 가장 큰 문제점이 무엇이라고 생각하는가?
조금 경험이 있는 사람들이라면 일단 가장 큰 부분으로 확장성을 들어야 하지 않을까 싶다.
( 클라우드라는 개념이 먼저 선행되었으니까...ㅎㅎ )
뭐 어찌됐건, RDBMS 의 가장 고심점은 확장성인데, 기존의 MySQL 을 비교해보자면,
Master - Slave 형식의 1:n 데이타 복제 를 통한 I/O 분산 정도 밖에 생각나는게 없을거고,
그렇다고 NDB 엔진을 이용한다는 것도 어마어마한 데이타를 메모리에 올려놓기위한,
배보다 큰 배꼽질은 더욱 더 골치 아플것이다. Memcached 역시도 한계가 있다.
오라클 역시 RAC 등을 사용한다면 그 엄청난 비용은 어찌감당할것인가?
가장 중요한 이 관계형 디비의 확장성 문제는, 트위터나 포스퀘어등 엄청난 트랜잭션을
유발하는 SNS 에서 특히 부각되기 시작했다. (맞어?...먼산~)
2. 그럼 대안은? NoSQL
NoSQL 이란 기존의 스키마등 구조적인 부분을 매우 중시해 오던 RDBMS 에 반대로
스키마리스 (Schemaless) 형 데이타 구조 및 문서지향적 데이타 구조이다.
비 관계형 데이타 구조로써, 뭐..SQL 이 아니다 라는 의미의 No 가 아니라,
Not-Only SQL 이라는 것이다. 즉 꼭 하나씩 매칭되는 데이타 구조를 갖고 있지 않아도 되는
의미를 뜻한다고 볼 수 있다.
뭐 약간 오바지만, 사실 관계형 디비는 각 레코드들마다 필요 없는 열(Null 값이 있는) 들이
존재 할 수 밖에 없는 구조였고, 열 유형이 반드시 필요하다는 구조적 강제성때문에,
유연하고 널리 적용 될 수 있는 데이타 구조라고 보기엔 어려웠다.
NoSQL 에서는 스키마를 사용하지 않는 다는 점에 있어서 데이타 모델링 측면에서 특별히
제약받을 것이 없다는 장점을 갖고있다.
머..NoSQL 에 대한 데이타모델링적 부분은 다른 것에서 검색해 보면 될꺼임..
3. Schemaless 형 데이타베이스는 그럼 뭐뭐가 있느냐?
3-1. 하둡(Hadoop) HBase
그 유명한 하둡납셨다...
원래 이녀석은 구글놈의 BigTable 의 클론프로젝트이며 오픈프로젝트이다.
( 구글의 비공개에 열받았다나?..쿨럭 )
이녀석은 HFS ( Hadoop File System )을 기반으로 하여 모든 업데이트 정보를 데이터의 젤 끝에
위치시켜 접근시간을 단축시켰으며, 주기적인 데이타 재정렬과 다른 노드로의 분리저장을 통해
Master-Master 형태의 리플리케이션을 제공한다. 게다가 B-Tree 알고리즘을 통한 범위검색도
지원하며 Row 단위에서의 트랜잭션마져 지원하는 NoSQL 계의 최강자라고 한다.
(개인적으론 하둡 안좋아함...)
게다가 가장 많은 커뮤니티와 연구가 이루어 지고 있다고 한다.
3-2. Facebook 의 Cassandra
이게 페이스북에서 만들어 오픈한건 최근에서야 알았다...
난 아파치재단에서 관리되길레 그할배들껀줄 알았는데...
이녀석은 컬럼그룹 형태의 데이타 베이스로 HBase 나 빅테이블과 비슷한 형식으로 구현되고
있다고 하며, 가장 독특하게도 즉시 각 노드들로의 데이타 복제를 하지 않고, 일정시간 후
데이타를 종합하는 방법으로 데이타 일관성을 제공하는 유일한 NoSQL DBMS 라고 한다.
이는 Single-Point Failure 를 줄여주며 일관적 데이타에 대한 보증이 되므로 장점이라고 한다.
3-3. MongoDB ( http://www.mongodb.org/display/DOCS/Introduction )
Mongo 라고 부르며 DB 라고 정의짓는다 라고 홈페이지에 씌여져있다. (멋지다)
10gen (이름 이상하지만 발음만 주의하면 된다. 쿨럭) 에서 개발한 오픈프로젝트로 C++로
구성되어 있으며 GPL 라이센스에, JSON 으로 구현되어 JDBC 따위 드라이버를 따로 필요없이
그냥 쉽게쉽게 스크립트 형식으로 사용 할 수 있는 장점이 있고,
기존 관계형 디비와 동일한 참조키등 기존 개념을 포함하도록 구현되어 있어, 접근하기에도
용이하다는 장점이 있단다. 게다가 단순하게 문서에 데이타를 저장한다는 개념에 충실하여,
노드간 데이터 분리 및 확장이 투명하게 이루어 진다고 한다. (+.,+)
현재 3월 16일자로 1.8 버젼이 릴리즈되어있다.
사이트의 소개부분에 보면 있는 그림의 Shard 라는 개념 맘에 든다. 게임서버같아 쿨럭
3-4. Drizzle ( http://drizzle.org/ )
사실 이녀석은 MySQL 의 프론트 DBMS들중 하나로, 클라우드 환경에 적합하도록 목표된
녀석으로써 완벽하게 NoSQL 은 아니지만, NoSQL 의 개념을 상당부분 도입하여 잘 섞어논,
RDBMS 이다. MySQL 과 동일한 API 를 제공하며, MySQL 의 엔진들을 지원하므로
MySQL 에 익숙한 사람들에게 매우 유용한 프로젝트가 되기도 할 것이다.
현재 3.13일자로 GA 버젼이 릴리즈되었다.
관심있는 DBMS 중 하나이기때문에 게다가 클라우드에 맞춰졌기때문에 리스트업한다.
4. 그럼 NoSQL 이 더 좋은거냐?
더 좋고 안좋고는 없다. 소잡는 칼, 닭잡는 칼 따로 있고, 쟁기로 호미질 하거나, 호미로 쟁기질
또는 고무신으로 물을 퍼먹을 수 없는것이다. 더 극악의 조악한 예를 들자면...... 그만두자..:P
다만 지금같은 쓰나미급 리퀘스트들을 처리하기 위해서는 기존 RDBMS 로는 한계가 있으며,
확장성에 대한 비용 및 용이성에 대한 제한이 있기에, 그것을 해결하기 위한 대안으로
제시되고 있는 방법론중 하나인 것이다.
NoSQL 의 기능상 획기적이며 유연한 점들은 매우 훌륭한 장점이지만, 금융권등 결제 관련된
트랜잭션의 보장이 필요한 - ACID ( Atomicity, Consistency, Isolation, Durability ) - 서비스에대한
보장을 충분히 해주지 못하는 부분이 아직까지는 있고, 검증되지 않은 부분들이 있기에
( IT 소프트웨어 의 검증은 참 오랜시간이 걸리는것 같다. 거의 음식수준이랄까... )
선택할 수 있는 방법으로 제시되는 것이지 어느것이 우월하다라는걸 얘기하고자 하는게 아니다.
5. 결론
클라우드 및 대규모 쓰나미급 데이타 요청들이 대세인 요즘 IT 서비스 흐름을 보건데,
기존 관계형 디비만을 고집하는 것은 미래적인 1:1 고객 대화형 서비스로 발전하기엔
부족함이 많고, 결국 이득보단 손해를 더 많이 보게 될 수 있을것이라고 생각한다.
불안정한 부분은 안정되기 마련이므로, 역사가 짧아 무시하고 지나가기보단,
이런 단점들을 극복한 새로운 주자에 대해 반성하고 도입하려 노력해야 하지 않을까 싶다.
포스팅하며 참조한 글들중 마음에 와닷는 글이 있었다.
단순히 적용하기가 어려워서, 적용하는 곳이 없어서, 적용하는데 유지보수 문제가 걸려서, 적용하는 것을 고객이 원하지 않아서 등 다양한 불가함을 이야기 하지만, 해외의 굵직한 리딩업체들이 NoSQL 제품 활용을 통해 얻는 기술적/비용적 이득은 결코 작지 않다.
뭐 여러가지 얘기했는데 내가 가장 주목하고 있는 녀석들은
MongoDB 와 Drizzle 이다.
써야하고 정리해야 할것들이 너무나도 많다..
시간이 남을때 빨리빨리 해야하는데, 오히려 압박감이 되기도 한다.
항상 여유롭고 평화를 간직 할 수 있길 기도한다.
참조 :
http://www.ibm.com/developerworks/kr/library/j-javadev2-12/index.html
