220 likes | 665 Views
Survey on NoSQL. 조성범 2012-01-26. Table of Contents. NoSQL 정의 등장배경 NoSQL History NoSQL 의 특징 RDBMS vs. NoSQL Brewer’s CAP Theorem NoSQL 의 데이터모델 NoSQL 제품 분류 (CAP/Data Model) NoSQL 솔루션 BigTable /Dynamo/ Hbase /Cassandra/ MongoDB NoSQL 비교 적용사례 NoSQL 적용시 고려사항. NoSQL 정의.
E N D
Survey on NoSQL • 조성범 • 2012-01-26
Table of Contents • NoSQL 정의 • 등장배경 • NoSQL History • NoSQL의 특징 • RDBMS vs. NoSQL • Brewer’s CAP Theorem • NoSQL의 데이터모델 • NoSQL제품 분류(CAP/Data Model) • NoSQL솔루션 • BigTable/Dynamo/Hbase/Cassandra/MongoDB • NoSQL비교 • 적용사례 • NoSQL적용시 고려사항
NoSQL 정의 • NoSQL = not only SQL • NoSQL은 비관계형(Non Relational) 데이터 저장소 • Query Language로 SQL을 사용하지 않음 • 고정된 스키마를 사용 안 함(Schema Free) • 기존 RDBMS의 Join과 같은 복잡한 operation은 지원안함 • 초대용량의 데이터 저장소 • 성능 및 확장성을 위해 기존 RDBMS의 ACID 트랜잭션 및 제약사항을 일정부분 포기 • 분산 데이터 저장소 기반 • Scale horizontally(수평 확장에 강함) • High Availability(고가용성)
등장배경 • 웹 서비스의 구조 변화 • SNS나 Amazon등의 Web 2.0 • 대용량, 실시간 웹서비스의 등장 • 데이터가 고정된 형태를 가지고 있지 않고 계속 변화 • 사용자의 데이터 요구가 일관적이지 않고 다양 • 데이터 규모의 확대 • 데이터의 규모가 커지면서 기존 RDBMS에서 Big Data 처리에 한계 • RDBMS의 수평적 확장성 한계 • 데이터 규모 확대에 따른 High scalability와 High availability가 중요해짐 • 비정형적이고 구조화되지 않은 대용량의 데이터 처리에 한계를 가진 RDBMS의 대안 필요.
NoSQL History • 1998 • NoSQL이라는 용어는 1998년에 오픈소스lightweight RDBMS 프로젝트와 함께 시작 • 2000 ~ 2005 • Memory Cache 기반의 Memcached가 2003년에 시작되고 파일기반의 스토리지 버전인 memcachedb 버전이 나옴. • Document database인 CouchDB project가 2005년에 시작됨. 2008년도에 Apache Foundation으로 이전 • 2004년에 Google BigTable project시작, 연구논문이 2006년에 발표됨. • 2006 ~ 2010 • Amazon Dynamo에 대한 연구논문이 2007년도에 발표됨. • Document database인MongoDB project가 2007년도에 시작되어 2009년도에 릴리즈됨. • Facebook이 2008년도에 Cassandra project를 오픈소스화 함. • BigTable clone인 Hbase가 Hadoop project에서 시작됨. • 2009년에 Cassandra project의 committer인 Rackspace의 Eric Evans가 “NoSQL”이란 용어를 다시 소개함. • By Google Trend • 2009년부터 NoSQL이 이슈화되기 시작함.
NoSQL의 특징 • Schema Free • Big Data 지원 • 다수의 저가 x86 서버로 구성 가능 • 데이터 파티션 및 복제 • Data Read/Write 속도가 빠름 • 분산환경의 병렬처리 지원 • 높은 확장성 • 점진적으로 노드를 추가하여 수평 확장이 가능 • 엄격한 트랜잭션 및 데이터 Consistency 지원 부족 • Eventually consistency/BASE (Not ACID) • 오픈소스 중심으로 발전 • 아직 성장중인 미완성의 기술, 안정성 보장 및 문제 발생 시 기술지원이 곤란 • 자체적인 기술력을 확보하여야 구축, 유지보수가 가능 • 범용적인 용도가 아닌 제한된 용도로 사용 • SNS 등 일부 특화 서비스에 적합하도록 개발
RDBMS vs. NoSQL • Strong consistency(ACID) vs. Eventual consistency(BASE) • ACID : Atomicity, Consistency, Isolation, Durability • BASE : Basically Available, Soft state, Eventual consistency • Big dataset vs. HUGE datasets • Scaling is possible(scale up) vs. Scaling is easy(scale out) • Scale up(vertical) : 서버자체의 하드웨어 성능을 높여 확장 • Scale out(horizontal) : 서버의 노드 수를 늘려 성능을 확장 • SQL vs. Map-Reduce • Good availability vs. Very high availability • General Purpose vs. Specific Purpose
Brewer’s CAP Theorem • CAP 이론은 분산 컴퓨팅 시스템이 다음 3가지 요구사항을 동시에 충족한다는 것은 불가능하다는 이론 • Consistency • 모든 노드(클라이언트)가 동시에 동일한 데이터를 바라본다 • 데이터 정합성 • Availability • 노드 실패가 운영을 영속하는데 영향을 미치지 않는다 • 전체 node 중 부분적으로 instance가 crash되도 시스템은 정상적인 운영이 가능하다 • Partition tolerance : • 물리적 네트워크 분산 환경에서 시스템이 동작 가능하다 • RDBMS는 CA를 충족하도록 디자인됨. • NoSQL은 CAP 중에서 C 또는 A를 일부 포기함으로써 분산 확장에 특화
NoSQL의 데이터모델 • Key-Value store • Hash table에 unique key를 저장하고 특정 값을 참조하는 방식 • 대표적인 제품 : Dynamo • Document –Oriented • Key-value와 유사 • 구조화된 데이터를 저장 • stored in JSON or XML format • 대표적인 제품 : MongoDB, CouchDB • Column-Oriented • Often referred as “BigTable clones” • 하나의 키가 여러개의컬럼을 참조하는 방식 • 분산 서버에서 대용량 데이터 처리에 적합한 모델 • 대표적인 제품 : Bigtable, HBase, HyperTable, Cassandra
NoSQL솔루션 • http://nosql-database.org • Column-Oriented • Hbase, Cassandra, Hypertable, Cloudata, Amazon SimpleDB, SciDB, Stratosphere 등 • Documen-Oriented • MongoDB, CouchDB, Terrastore, ThruDB, OrientDB, RavenDB, Citrusleaf, SisoDB등 • Key-Value • Membase, Riak, Redis, Chordless, GenieDB, Scalaris, Tokyo Cabinet/Tyrant, Scalien, Berkeley DB, MemcacheDB, Hibari, HamsterDB, Pincaster, RaptorDB등 • 종류도 많고 매우 다양함 • 대표적인 솔루션 : Hbase, Cassandra, MongoDB
NoSQL대표 아키텍처 • BigTable • Google’s Data Management System • Google App Engine, Analytics, Docs, Earth, etc. • A sparse, distributed, persistent multidimensional sorted map • Indexed by row key, column key, timestamp • In-Memory, On-Disk • 데이터는 Google File System에 저장 • 분산파일시스템의 한계 극복 • Real time transaction, Batch processing 모두 만족 • MapReduce • 관련 오픈소스 프로젝트 : Hbase, Hypertable, Cloudata • Dynamo • Amazon’s High available key/value store • DHT(Distributed Hashing Table) • 관련 오픈소스 프로젝트 : Scalaris, Voldemort, Ringo
HBase • Google’s BigTable clone • An open-source, distributed, versioned, column-oriented store • Linear and modular scalability • Strongly consistent reads/writes • Not an “eventually consistent” • Automatic sharding • Automatic RegionServer failover • Hadoop/HDFS와 통합 • Support MapReduce • API • Java API, Thrift/REST API
Cassandra • Facebook에서만든 오픈소스Data store • 현재는 Apache 오픈소스 프로젝트로 자리를 옮김 • Google의 BigTable과 Amazon의 Dynamo의 특징을 모두 채택 • BigTable의 Column-oriented model, memTable, SSTable방식의 쓰기 방식 채택 • Dynamo의 High Availability, performance 와 consistency 사이의 trade off 조절 기능 도입 • Scalability 매우 강력 • Fault-Tolerant • Single point of failure가 없음 • Consistency-Partition tolerance 사이의 균형 • Read replica count, Write replica count를 설정하는 방식으로 Consistency와 Availability 사이의 균형을 사용자가 선택 가능. • High Performance • Read연산보다 Write연산이 훨씬 더 빠름 • Lockless : concurrency issue로 인한 성능저하는 발생안함 • API • 클라이언트와의 통신은 Thrift API 사용 • Thrift는 Facebook에서 개발한RPC
MongoDB • Document-oriented storage • Dynamic Schema기반의 Json-Style의 문서 조회로 단순한 구성과 강력한 기능 제공 • Json으로 데이터를 저장, Json의 속성에 대한 질의 가능 • Full Index 지원 • 기존 사용하던 어떤 속성이든 인덱스로 설정 가능 • 기존 SQL 방식과 유사 • Replication과 고 가용성 지원 • 확장과 안정성을 위해 LAN과 WAN을 통한 미러링 지원 • Auto Sharding for cloud-level scalability • 설정 기능들을 사용하지 않고 수평적인 확장 지원 • 다양한 조회 기능 • 문서기반 질의 지원, JavaScript Style의 query 사용 • Map/Reduce • 유연한 조합과 데이터 처리 지원 • GridFS • 복잡한 스택 구조의 필요 없이 어떤 크기의 데이터도 저장 가능
적용사례(1) • Google • Google Bigtable적용 • 모든 URL 기반의 문서 정보 수집 • 수집한 정보를 Map/Reduce로 색인 • 색인 데이터도 Bigtable에 저장 • Amazon • Amazon’s Dynamo 적용 • Amazon의 e-commerce 사이트의 절대적인 Availability를 보장하기 위해서 Amazon Dynamo를 디자인/개발/적용/운영함 • 장바구니 기능에 적용됨 • Digg • Cassandra • 특정 아이템에 대해 digg한 친구 목록
적용사례(2) • Twitter • Cassandra, Hbase, Hadoop, Scribe, FlockDB, Redis • Facebook • Cassandra, Hbase, Hadoop, Scribe, Hive • Inbox search(페이스북 사용자 프로필 내부 검색) • Netflix • Amazon SimpleDB, Cassandra • Yahoo! • Hadoop, Hbase, PNUTS • Rackspace • Cassandra • Foursquare • MongoDB
적용사례(3) • Daum • Daum클라우드 • 2004년 11월 부터Daum자체 개발 분산 파일 시스템 • Daum Café • ‘최근 방문 카페’ 기능에 Cassandra 적용 • MyAgora • MongoDB적용 • NHN • NHN 인증 플랫폼 • MySQL클러스터링으로 세션 정보 저장 – MySQL을 메모리 DB로 사용 • in-house 메모리 DB로 사용자 정보 저장 – Oracle 로그 기반으로 메모리 리플리케이션
NoSQL적용시 고려사항 • RDBMS를 대체한다는 접근은 옳지 않음 • 데이터의 속성과 요구사항에 따라(CAP, ACID/BASE) RDBMS와 NoSQL 선택 • 한 시스템에 여러 솔루션 적용도 고려 • 소규모/복잡한 관계 데이터 : RDBMS • 대규모 실시간 처리 데이터 : NoSQL • 대규모 저장용 데이터 : Hadoop등 • 적절한 솔루션 선택 • 반드시 운영 중 발생할 수 있는 이슈에 대해 검증 후 도입 필요 • 대부분의 NoSQL솔루션은 베타 상태(섣부른 선택은 독이 될 수 있음) • 솔루션의 프로그램 코드 수준으로 검증 필요 • NoSQL솔루션에 대한 안정성 확보 • 솔루션 자체의 안정성은 검증이 필요 • 현재의 RDBMS 수준의 안정성은 지원하지 않음 • 요구사항에 부합되는 NoSQL선정 필요 • 처음부터 중요 시스템에 적용하기 보다는 시범 적용 필요 • 선정된 솔루션 검증, 기술력 내재화
References • http://en.wikipedia.org/wiki/NoSQL • http://tedwon.com/display/dev/NoSQL+Database • http://blog.knuthaugen.no/2010/03/a-brief-history-of-nosql.html • http://cafe.naver.com/hermeneus.cafe?iframe_url=/ArticleRead.nhn%3Farticleid=32 • http://fantazic.com/archives/517 • http://blog.outsider.ne.kr/519?category=7 • http://blog.outsider.ne.kr/520 • http://www.torea.kr/?document_srl=4062144 • http://fantazic.com/archives/445 • http://www.slideshare.net/ssuser8e9456/no-sql-20110619jco • http://hbase.apache.org/ • http://cassandra.apache.org/ • http://www.mongodb.org/ • http://www.slideshare.net/ssuser8e9456/no-sql-20110619jco