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, Cit-

rusleaf, SisoDB 등

• Key-Value– Membase, Riak, Redis, Chordless, GenieDB, Scalaris, Tokyo

Cabinet/Tyrant, Scalien, Berkeley DB, MemcacheDB, Hibari, Hams-terDB, 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-ori-

ented 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