1 / 21

Survey on NoSQL

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 정의.

kelsie-oneil
Télécharger la présentation

Survey on NoSQL

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. Survey on NoSQL • 조성범 • 2012-01-26

  2. 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적용시 고려사항

  3. NoSQL 정의 • NoSQL = not only SQL • NoSQL은 비관계형(Non Relational) 데이터 저장소 • Query Language로 SQL을 사용하지 않음 • 고정된 스키마를 사용 안 함(Schema Free) • 기존 RDBMS의 Join과 같은 복잡한 operation은 지원안함 • 초대용량의 데이터 저장소 • 성능 및 확장성을 위해 기존 RDBMS의 ACID 트랜잭션 및 제약사항을 일정부분 포기 • 분산 데이터 저장소 기반 • Scale horizontally(수평 확장에 강함) • High Availability(고가용성)

  4. 등장배경 • 웹 서비스의 구조 변화 • SNS나 Amazon등의 Web 2.0 • 대용량, 실시간 웹서비스의 등장 • 데이터가 고정된 형태를 가지고 있지 않고 계속 변화 • 사용자의 데이터 요구가 일관적이지 않고 다양 • 데이터 규모의 확대 • 데이터의 규모가 커지면서 기존 RDBMS에서 Big Data 처리에 한계 • RDBMS의 수평적 확장성 한계 • 데이터 규모 확대에 따른 High scalability와 High availability가 중요해짐 • 비정형적이고 구조화되지 않은 대용량의 데이터 처리에 한계를 가진 RDBMS의 대안 필요.

  5. 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이 이슈화되기 시작함.

  6. NoSQL의 특징 • Schema Free • Big Data 지원 • 다수의 저가 x86 서버로 구성 가능 • 데이터 파티션 및 복제 • Data Read/Write 속도가 빠름 • 분산환경의 병렬처리 지원 • 높은 확장성 • 점진적으로 노드를 추가하여 수평 확장이 가능 • 엄격한 트랜잭션 및 데이터 Consistency 지원 부족 • Eventually consistency/BASE (Not ACID) • 오픈소스 중심으로 발전 • 아직 성장중인 미완성의 기술, 안정성 보장 및 문제 발생 시 기술지원이 곤란 • 자체적인 기술력을 확보하여야 구축, 유지보수가 가능 • 범용적인 용도가 아닌 제한된 용도로 사용 • SNS 등 일부 특화 서비스에 적합하도록 개발

  7. 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

  8. Brewer’s CAP Theorem • CAP 이론은 분산 컴퓨팅 시스템이 다음 3가지 요구사항을 동시에 충족한다는 것은 불가능하다는 이론 • Consistency • 모든 노드(클라이언트)가 동시에 동일한 데이터를 바라본다 • 데이터 정합성 • Availability • 노드 실패가 운영을 영속하는데 영향을 미치지 않는다 • 전체 node 중 부분적으로 instance가 crash되도 시스템은 정상적인 운영이 가능하다 • Partition tolerance : • 물리적 네트워크 분산 환경에서 시스템이 동작 가능하다 • RDBMS는 CA를 충족하도록 디자인됨. • NoSQL은 CAP 중에서 C 또는 A를 일부 포기함으로써 분산 확장에 특화

  9. 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

  10. NoSQL제품 분류(CAP/Data Model)

  11. 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

  12. 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

  13. 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

  14. 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

  15. 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 • 복잡한 스택 구조의 필요 없이 어떤 크기의 데이터도 저장 가능

  16. NoSQL비교

  17. 적용사례(1) • Google • Google Bigtable적용 • 모든 URL 기반의 문서 정보 수집 • 수집한 정보를 Map/Reduce로 색인 • 색인 데이터도 Bigtable에 저장 • Amazon • Amazon’s Dynamo 적용 • Amazon의 e-commerce 사이트의 절대적인 Availability를 보장하기 위해서 Amazon Dynamo를 디자인/개발/적용/운영함 • 장바구니 기능에 적용됨 • Digg • Cassandra • 특정 아이템에 대해 digg한 친구 목록

  18. 적용사례(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

  19. 적용사례(3) • Daum • Daum클라우드 • 2004년 11월 부터Daum자체 개발 분산 파일 시스템 • Daum Café • ‘최근 방문 카페’ 기능에 Cassandra 적용 • MyAgora • MongoDB적용 • NHN • NHN 인증 플랫폼 • MySQL클러스터링으로 세션 정보 저장 – MySQL을 메모리 DB로 사용 • in-house 메모리 DB로 사용자 정보 저장 – Oracle 로그 기반으로 메모리 리플리케이션

  20. NoSQL적용시 고려사항 • RDBMS를 대체한다는 접근은 옳지 않음 • 데이터의 속성과 요구사항에 따라(CAP, ACID/BASE) RDBMS와 NoSQL 선택 • 한 시스템에 여러 솔루션 적용도 고려 • 소규모/복잡한 관계 데이터 : RDBMS • 대규모 실시간 처리 데이터 : NoSQL • 대규모 저장용 데이터 : Hadoop등 • 적절한 솔루션 선택 • 반드시 운영 중 발생할 수 있는 이슈에 대해 검증 후 도입 필요 • 대부분의 NoSQL솔루션은 베타 상태(섣부른 선택은 독이 될 수 있음) • 솔루션의 프로그램 코드 수준으로 검증 필요 • NoSQL솔루션에 대한 안정성 확보 • 솔루션 자체의 안정성은 검증이 필요 • 현재의 RDBMS 수준의 안정성은 지원하지 않음 • 요구사항에 부합되는 NoSQL선정 필요 • 처음부터 중요 시스템에 적용하기 보다는 시범 적용 필요 • 선정된 솔루션 검증, 기술력 내재화

  21. 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

More Related