Transcript Survey on NoSQL 조성범 2012-01-26

Survey on NoSQL
0

조성범

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적용시 고려사항
1
NoSQL 정의
• NoSQL = not only SQL
• NoSQL은 비관계형(Non Relational) 데이터 저장소
–
–
–
–
–
Query Language로 SQL을 사용하지 않음
고정된 스키마를 사용 안 함(Schema Free)
기존 RDBMS의 Join과 같은 복잡한 operation은 지원안함
초대용량의 데이터 저장소
성능 및 확장성을 위해 기존 RDBMS의 ACID 트랜잭션 및 제약사항을 일정부
분 포기
– 분산 데이터 저장소 기반
Scale horizontally(수평 확장에 강함)
⇒ High Availability(고가용성)
⇒
2
등장배경
• 웹 서비스의 구조 변화
–
–
–
–
SNS나 Amazon등의 Web 2.0
대용량, 실시간 웹서비스의 등장
데이터가 고정된 형태를 가지고 있지 않고 계속 변화
사용자의 데이터 요구가 일관적이지 않고 다양
• 데이터 규모의 확대
– 데이터의 규모가 커지면서 기존 RDBMS에서 Big Data 처리에 한계
– RDBMS의 수평적 확장성 한계
– 데이터 규모 확대에 따른 High scalability와 High availability가 중요해짐
• 비정형적이고 구조화되지 않은 대용량의 데이터 처리에 한
계를 가진 RDBMS의 대안 필요.
3
NoSQL History
•
1998
–
•
2000 ~ 2005
–
–
–
•
NoSQL이라는 용어는 1998년에 오픈소스 lightweight RDBMS 프로젝트와 함께 시작
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
–
4
2009년부터 NoSQL이 이슈화되기 시작함.
NoSQL의 특징
• Schema Free
• Big Data 지원
– 다수의 저가 x86 서버로 구성 가능
– 데이터 파티션 및 복제
• Data Read/Write 속도가 빠름
• 분산환경의 병렬처리 지원
• 높은 확장성
– 점진적으로 노드를 추가하여 수평 확장이 가능
• 엄격한 트랜잭션 및 데이터 Consistency 지원 부족
– Eventually consistency/BASE (Not ACID)
• 오픈소스 중심으로 발전
– 아직 성장중인 미완성의 기술, 안정성 보장 및 문제 발생 시 기술지원이 곤란
– 자체적인 기술력을 확보하여야 구축, 유지보수가 가능
• 범용적인 용도가 아닌 제한된 용도로 사용
– SNS 등 일부 특화 서비스에 적합하도록 개발
5
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
6
Brewer’s CAP Theorem
• CAP 이론은 분산 컴퓨팅 시스템이 다음 3가지 요구사항을
동시에 충족한다는 것은 불가능하다는 이론
– Consistency
모든 노드(클라이언트)가 동시에 동일한 데이터를 바라본다
⇒ 데이터 정합성
⇒
– Availability
노드 실패가 운영을 영속하는데 영향을 미치지 않는다
⇒ 전체 node 중 부분적으로 instance가 crash되도 시스템은 정상적인 운영이 가능하
다
⇒
– Partition tolerance :
⇒
물리적 네트워크 분산 환경에서 시스템이 동작 가능하다
• RDBMS는 CA를 충족하도록 디자인됨.
• NoSQL은 CAP 중에서 C 또는 A를 일부 포기함으로써 분산
확장에 특화
7
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
8
NoSQL 제품 분류(CAP/Data Model)
9
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
10
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
11
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
12
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
13
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
–
복잡한 스택 구조의 필요 없이 어떤 크기의 데이터도 저장 가능
14
NoSQL 비교
15
적용사례(1)
• Google
–
–
–
–
Google Bigtable 적용
모든 URL 기반의 문서 정보 수집
수집한 정보를 Map/Reduce로 색인
색인 데이터도 Bigtable에 저장
• Amazon
– Amazon’s Dynamo 적용
– Amazon의 e-commerce 사이트의 절대적인 Availability를 보장하기 위해서
Amazon Dynamo를 디자인/개발/적용/운영함
– 장바구니 기능에 적용됨
• Digg
– Cassandra
– 특정 아이템에 대해 digg한 친구 목록
16
적용사례(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
17
적용사례(3)
• Daum
– Daum 클라우드
⇒
2004년 11월 부터 Daum 자체 개발 분산 파일 시스템
– Daum Café
⇒
‘최근 방문 카페’ 기능에 Cassandra 적용
– MyAgora
⇒
MongoDB 적용
• NHN
– NHN 인증 플랫폼
MySQL 클러스터링으로 세션 정보 저장 – MySQL을 메모리 DB로 사용
⇒ in-house 메모리 DB로 사용자 정보 저장 – Oracle 로그 기반으로 메모리 리플리케
이션
⇒
18
NoSQL적용시 고려사항
• RDBMS를 대체한다는 접근은 옳지 않음
–
–
데이터의 속성과 요구사항에 따라(CAP, ACID/BASE) RDBMS와 NoSQL 선택
한 시스템에 여러 솔루션 적용도 고려
⇒
⇒
⇒
소규모/복잡한 관계 데이터 : RDBMS
대규모 실시간 처리 데이터 : NoSQL
대규모 저장용 데이터 : Hadoop 등
• 적절한 솔루션 선택
–
–
–
반드시 운영 중 발생할 수 있는 이슈에 대해 검증 후 도입 필요
대부분의 NoSQL 솔루션은 베타 상태(섣부른 선택은 독이 될 수 있음)
솔루션의 프로그램 코드 수준으로 검증 필요
• NoSQL 솔루션에 대한 안정성 확보
–
–
–
솔루션 자체의 안정성은 검증이 필요
현재의 RDBMS 수준의 안정성은 지원하지 않음
요구사항에 부합되는 NoSQL 선정 필요
• 처음부터 중요 시스템에 적용하기 보다는 시범 적용 필요
–
선정된 솔루션 검증, 기술력 내재화
19
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
20