NoSQL

NoSQL

김형준(gruter)
babokim@gmail.com
Revision: 2011.06.19

2011 JCO 11th Conference | Session ${track_#}-${session_#} | Javacommunity.Org

김형준
• babokim@gmail.com(gtalk)
• 그루터, www.gruter.com
• www.jaso.co.kr
• www.cloudata.org
• www.cloumon.org
• www.twitter.com/babokim
• www.facebook.com/babokim
• 페이스북 그룹: 클라우드 컴퓨팅 구현 기술

Thinking BigData

http log HELP!!!
(수십 ~ 수백 GB/day)

Web Page Crawler
(수천억 ~ 수조 URL)
(수십만 페이지/day)

Mobile phone More Money!!!
call request
(수억/day)
Big Server
Social Network Data
(수억/day)

Thinking Data Characteristic
Consistency
모든 사용자가 반드시 동일한 데이터를 봐야 하는가?
페이스북은???

Availability
언제든지 데이터를 저장/조회 할 수 있어야 하는가?
Twitter overload whale

Durability
모든 데이터가 100% 안정적으로 저장되어야 하는가?
1억 개 중에 1 ~ 2개 유실되면?

Data Size
데이터 양이 증가해도 계속 저장할 수 있는가?

What is NoSQL?
Next Generation Databases mostly addressing some of the points
beingnon-relational, distributed, open-source and
horizontal scalable.
The original intention has been modern web-scale databases.

NoSQL ≠ Anti RDBMS, NoSQL = Not Only SQL

popularized in early 2009.

NoSQL 출현 배경
• Data Tsunami
– 40 billions Web page, 55 trillions Web link
– 281 exa-bytes, 45 GB/person
• 데이터 저장소의 확장성에 대한 요구 증가
– Scale up 방식이 아닌 Scale out 방식 요구
• 대용량 데이터 처리에 불필요한 기능
– UPDATEs and DELETEs and JOIN
– ACID Transactions
– Fixed Schema
• 대용량 처리에 필요한 기능은 지원하지 않음
– hierarchical data, graphs
• ACID vs. BASE
– Atomic, Consistency, Isolation, Durability
– Basically Available, Soft-state, Eventually consistent

CAP(Brewers Conjecture)

Consistency
Bigtable
RDBMS Cloudata
HBase
분산환경에서 적절한
응답시간 이내에
세가지 속성을 만족시키는
저장소는 구성하기 어렵다.
Availability Partition
Tolerance

Dynamo
Cassandra

http://lpd.epfl.ch/sgilbert/pubs/BrewersConjecture-SigAct.pdf

CAP(MySQL-Read)
Update Data = ‘A’
Where Key = ‘k1’
Select Data
Where Key = ‘k1’ MySQL
ClientA ClientB
- master/slave

Master Slave #1 Slave #2

replication
replication

Update Data = ‘A’ Select Data
Where Key = ‘k1’ Where Key = ‘k1’

Availability ClientA ClientB
Partition Tolerance Patitioned

Master Slave #1 Slave #2

replication

Not my words, It‟s from USA
BUT

Deep Dive into NoSQL

Deep Dive into NoSQL

NoSQL 특징

• 단순한 데이터 모델
– Key/value, Document 기반, Simple Column 모
델
• Schema Free
• Big Data 지원
– 다수의 저가 x86 서버로 구성
– 데이터 파티션 및 복제
• Eventually consistent / BASE (not ACID)
• Simple API
• 범용적인 용도가 아닌 제한된 용도로 사용

NoSQL 솔루션
• http://nosql-database.org/
• Wide Column Store / Column Families
– Hbase, Cassandra, Hypertable, Cloudata,
Amazon SimpleDB, SciDB, Stratosphere
• Document Store
– MongoDB, CouchDB, Terrastore, ThruDB,
OrientDB, RavenDB, Citrusleaf, SisoDB
• Key Value / Tuple Store
– MEMBASE, Riak, Redis, Chordless, GenieDB,
Scalaris, Tokyo Cabinet / Tyrant, Scalien,
Berkeley DB, MemcacheDB, Hibari,
HamsterDB, Pincaster, RaptorDB
• Object Databases
– Db4o, Versant, Objectivity, Starcounter,
Perst, ZODB, NEO, PicoLisp, Sterling,
종류도 다양하고
Morantex
솔루션도 많다.

Who using NoSQL?
• Twitter
– Cassandra, HBase, Hadoop, Scribe, FlockDB, Redis
• Facebook
– Cassandra, HBase, Hadoop, Scribe, Hive
• Netflix
– Amazon SimpleDB, Cassandra
• Digg
– Cassandra
• SimpleGeo
– Cassandra
• StumbleUpon
– HBase, OpenTSDB 많은 업체에서 사용하는
• Yahoo!
– Hadoop, HBase, PNUTS
일반화된 기술이다.
• Rackspace 하나 이상을 사용한다.
– Cassandra

NoSQL 분석 시 고려사항
• Data Model
– Key/Value, Document, Wide Columnar
• CAP
– Consistency, Availability
• Data Indexing
– Row only, Field indexing
• API model
– Basic API: get, put, delete
– Advance API: execute, mapreduce
• Data partitioning
– DHT, META
• Data replication
– 지원/미지원, Consistency
• Membership Changes
– 쉽다/어렵다
• Master Model
– Master/Slave, Active/Standby

NoSQL 대표 아키텍처
• Bigtable
– How can we build a distributed db on top of
Distributed File System?
– Shared Disk or Data
– http://labs.google.com/papers/bigtable.html
– 2006
• Dynamo
– How can we build a distributed hash table
appropriate for the data center?
– DHT (Distributed Hashing Table)
– http://portal.acm.org/citation.cfm?id=1294281
– 2006

Google 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

Bigtable clone project

• Cloudata
– Korea, Gruter
– Java, 여러 종류의 파일 시스템 지원
– 자체 commit log 시스템
• HBase
– Apache
– Java, Hadoop 기반
• Hypertable
– Zvents, Baidu
– C++, Hadoop, KFS

Cloudata

• Distributed Data Storage
– semi-structured data store(not file system)
– 데이터 저장을 위해 분산 파일 시스템 사용
– 실시간/배치 처리 모두 지원
• Google Bigtable clone
– Data Model, Architecture, Features
• Open source
– http://www.cloudata.org
• Goal
– 500 nodes
– 200 GB/node, Peta bytes

Cloudata 특징
• 테이블 관리
– Create, drop, modify table schema
• 실시간 데이터 처리
– Single row operation(no join, group by, order by)
– Multi row operation: like, between
• 배치 프로세싱 지원
– Scanner, Direct Uploader, MapReduce Adapter
• 확장성
– Automatic table split & re-assignment
• 신뢰성
– 데이터 파일은 분산 파일 시스템(Hadoop)에 저장
– 커밋 로그를 위해 자체 Commit Log용 클러스터 구성
• Failover
– 서버 장애시 수십초 ~ 수분 이내 다른 서버로 재할당
• Utility
– Web Console, Shell(simple query), Data Verifier

Cloudata(Hbase) Architecture

사용자 애플리케이션

분산/병렬컴퓨팅 플랫폼(MapReduce)

Cloudata Cloudata
Master (대용량분산 데이터 저장소)

TabletServer #1 TabletServer #2 TabletServer #n

논리적 Table

물리적 저장소 분산파일시스템(Hadoop or other)

Cloudata System Components

Client
failover
/ event ZooKeeper event Scanner/
CloudataMaster CTable
(Lock Service) Uploader

rpc failover rpc socket
/ event

TabletServer #1 TabletServer #2 TabletServer #n
(Cloudata) (Cloudata) (Cloudata)
Commitlog Commitlog Commitlog
Server #1 Server #2 Server #n

DataNode #1 TaskTracker #1 DataNode #2 TaskTracker #2 … DataNode #n TaskTracker #n
(DFS) (Map&Reduce) (DFS) (Map&Reduce) (DFS) (Map&Reduce)

Local disk Local disk Local disk
(SATA) (SATA) (SATA)

: physical server(cloudata)
: daemon process(cloudata)
: daemon process(other platform)
: control
: data

Cloudata Data Model
분산된 서버에 배포
Rowkey Column#1 Column#n
rk-1 cK1 v1, t1
TabletA-1 row #1 v2, t2
ck2 v3, t2
v4, t3
v5, t4
row #k
Ckn vn, tn
TabletA-2 row #k+1
- Sorted by rowKey
- Sorted by column

row #m
Row#1 Row.Key Column
TabletA-n row #m+1
CF1 CF2 CFn Column Key
Col1-1 Col2-1 ColN-1
Col1-2 Col2-2 ColN-2 Value(t1)

row #n
Col1-3 … … Value(t2)
… Col2-K ColN-M …
Col1-N Value(tn)

Data Model 예제(1:N)
• 1:N 관계
– 1 user: 1+friends
– 질의: 특정 사용자의 모든 친구

RDBMS Cloudata
T_USER T_FRIEND T_USER_FRIEND

id(pk) user_id row info friend

name friend_id <user_id> name <user_id>=type
sex
sex type age
age

select * from T_USER, T_FRIEND List friendKeys = get(rowkey==?)
where T_FRIEND.user_id = ? for each friendKeys {
and T_USER.id = get(rowkey==eachKey)
T_FRIEND.friend_id }

Hbase Schema Design Case Studies
(http://www.slideshare.net/hmisty/20090713-hbase-schema-design-case-studies)

Data Model 예제(N:M)
• N:M relation
– 1 student - many courses
– 1 course - many students

RDBMS Cloudata
T_Student

T_Student T_S_C T_Course row info course

id(pk) s_id id(pk) s_id name c_id:<type
sex >
name c_id title age
sex type teacher_id
T_Course
age
row info course

c_id title s_id:<type>
teacher_id

Data Model 예제(log data)

• 1:N relation
– 로그 레코드: time, ip, domain, url…
– 저장된 로그는 5분, 시간, 일, 주 단위로 분석
RDBMS Cloudata
T_ACCESS_LOG
T_ACCESS_LOG
time
row http user
ip
<time><INC_COUNTER> ip login_id
domain domain
url
url
referer
referer

login_id

Data 분산 및 Lookup

• Tablet
– 1 Table = n Tablet, 데이터 분산 단위
– 100 ~ 200MB/Tablet, 수천 Tablet/Server
• Lookup path
– ROOT Table: Meta의 위치 저장
– META Table: User Tablet의 위치 저장
– User Table: 데이터 파일 정보 저장
– Data File: rowkey에 대한 인덱스 저장

Data operation

TabletServer
Minor
CommitLogServer Compaction
put(key, value) MemoryTable
CommitLog

get(key) Searcher

분리된 분리된 Merged MapFile#1 MapFile#2 MapFile #n
MapFile#1 MapFile#2 MapFile (HDFS) (HDFS) (HDFS)
(HDFS) (HDFS) (HDFS)

Split Major Compaction

Failover
• Master 장애
– Data operation은 정상 처리
– Table Schema Management, Tablet Split 기능만 장애
– Multi-Master로 장애 대처
• TabletServer 장애
– Master에 의해 Tablet re-assign
– 수십 초 ~ 수분 이내 복구
• ZooKeeper 장애
– 3/5개 node로 클러스터 구성, 절대 장애 발생하지 않음
• Hadoop NameNode 장애
– 별도의 이중화 방안 필요
• Hadoop 전체 장애
– Cloudata 클러스터도 장애

Cloudata MapReduce
Hadoop
TaskTracker
TableA Map
Map
TaskMap
Task

TabletInputFormat
Task Partitioned TaskTracker
TabletA-1 by key

TaskTracker Reduce TableB
Tablet A-2 Task
Map
Map Tablet B-1
TaskMap
Task
Tablet A-3 Task TaskTracker
Tablet B-2
… TaskTracker Reduce
Task
Map
Map
Tablet A-N TaskMap
Task
Task
DBMS
or HDFS

META Table

HBase
• Google Bigtable clone
– Data Model, Architecture, Features
• Open source
– http://hbase.apache.org
Client
ZooKeeper
HMaster (Lock Service) HTable HBaseAdmin

RegionServer#1 RegionServer#2 RegionServer#n

DataNode #1
(DFS)
TaskTracker #1
(Map&Reduce)
DataNode #2
(DFS)
TaskTracker #2
(Map&Reduce)
… DataNode #n
(DFS)
TaskTracker #n
(Map&Reduce)

Local disk Local disk Local disk
(SATA) (SATA) (SATA)

Performance

Experiment Cloudata HBase HBase(Cache)

Random read 495 578 1,623

Random write 1,223 2,864 8,300

Sequential read 498 600 2,109

Sequential write 1,327 2,635 6,553

Scan 40,329 22,795 30,840
Number of 1000-byte values read/written per second

Bigtable Usecase
ColumnFamily
• AppEngine Datastore
– Multi-tenancy
• Data can be clustered
together only if it is in
the same Bigtable
instance
• All logical tables for a
tenant must be packed
into the same Bigtable
instance
• Mapping
– One column family per
logical table

Cloudata Usecase
• Gruter: www.gruter.com
– 클라우드 컴퓨팅 아키텍팅 및 컨설팅
– 소셜 네트워크 분석 및 서비스
– www.searcus.com
• 소셜 네트워크 분석 서비스

HTTP Application Analysis Storage

Distributed Distributed
WebServer Distributed
Distributed Indexer
WebServer
WebServer Search Server
(apache) Search Server
Search Server
(apache)
(apache) (lucene, thrift) Analysis File Storage
(lucene, thrift)
(lucene, thrift) App. (HDFS)

Cache MapReduce
API (memcached)
API
API Data Storage
WebServer LogCollector
WebServer
WebServer (Cloudata)
( jetty) (scribe)
( jetty) AppServer
AppServer
( jetty) AppServer
(thrift)
(thrift)
(thrift) Crawler

Cloudata Usecase

• www.searcus.com
– Twitter Data 저장
• 17대, 20억 이상 rows, 4TB, 200 ~ 250GB/server

Cloudata Usecase
Rowkey USERINFO FOLLWER FOLLOWING

00000002 created_at: 1247056652000 000000006030342 000000015260344
1827129 description: 테스트 000000007253242 000000015889416
favourites_count: 3 000000014743863 000000016126916
followers_count: 91712 000000014914904 000000018747960
friends_count: 89010 000000015045031 000000018784326
Id: 54882396 000000015260344
Rowkey 000000019325363
TWITTER
listed_count: 11801 000000015360238
Location: 서울 000000021827129-00001 in_reply_to_status_id:-1
Name: 김형준 in_reply_to_user_id: -1
serial_no: 1063883048
00000002 … source: Twitter for Android
1827130 text: 오픈소스 활동이나 엔지니어링은 꾸준함
00000002 … 이 중요하다. 4-5년 이상 꾸준하게 할 수 있는
1827131 환경을 스스로 만들어 나가는 것이 관건
000000021827129-00002 in_reply_to_status_id: 78046819107610624
in_reply_to_user_id: 40249032
serial_no: 1063882962
source: web
Text: @youngwookim cassandra 버린다는 거
는 어디 나오나요???
000000021827129-00003 …

Hbase Usecase(nFractals)

• nFractals: www.nfractals.com
– Cloud 기반 CDN 아키텍팅 및 컨설팅
– Cloud 기반 컨텐츠 다운로드 서비스 구축 및 운영
– Hadoop, Hbase, MongoDB, Hive 등 활용
• NoSQL 활용
– User access log 저장
• Hadoop 저장, Hive 분석, Hbase 저장
– Log 분석 결과를 관리자가 웹에서 즉시 조회
• 과금 데이터 및 트래픽 현황 조회
• URL 랭킹, 지역별 접근 분포 등

Hbase Usecase(nFractals)

App Server Hive
Hadoop
(Map/Reduce)

App Sever

20,000 logs/sec
App Sever Hbase - 고객별(수백)
- 도메인별
- 분석항목
Hbase REST
- 5분 주기(aggregation)
- 50대
Google Chart
DataSource

Facebook Message Service
• New Message Service
– combines chat, SMS, email, and Messages into a real-time conversation
– Data pattern
• A short set of temporal data that tends to be volatile
• An ever-growing set of data that rarely gets accessed
– chat service supports over 300 million users who send over 120 billion
messages per month
• Cassandra's eventual consistency model to be a difficult pattern to
reconcile for our new Messages infrastructure.
• HBase meets our requirements
– Has a simpler consistency model than Cassandra.
– Very good scalability and performance for their data patterns.
– Most feature rich for their requirements: auto load balancing and failover,
compression support, multiple shards per server, etc.
– HDFS, the filesystem used by HBase, supports replication, end-to-end
checksums, and automatic rebalancing.
– Facebook's operational teams have a lot of experience using HDFS because
Facebook is a big user of Hadoop and Hadoop uses HDFS as its distributed
file system.

Hbase usecase(Adobe)
• http://hstack.org/why-were-using-hbase-part-1
• When we started pushing 40 million records, HBase
squeaked and cracked. After 20M inserts it failed so bad it
wouldn’t respond or restart, it mangled the data
completely and we had to start over.
– HBase community turned out to be great, they jumped and
helped us, and upgrading to a new HBase version fixed our
problems
• On December 2008, Our HBase cluster would write data but
couldn’t answer correctly to reads.
– I was able to make another backup and restore it on a MySQL
cluster
• We decided to switch focus in the beginning of 2009. We
were going to provide a generic, real-time, structured data
storage and processing system that could handle any data
volume.

Dynamo
• Amazon’s High available key/value store
– Shopping Cart
• Availability
– 동일 데이터를 여러 노드에 복사
• Consistency
– Eventual consistency
– 현재 가용한 쇼핑 카트의 정보를 보여주고, 추가/삭제 연산이 가능하도록 하는 것이 Dynamo
의 목적
• Persistence
– Berkley DB Transactional store, MySQL, In-memory buffer
• N,R,W 파라미터
– Consistency, Performance, Availability, Durability 수준 설정
– N:데이터의 복제본 수
– R, W: 읽기 또는 쓰기 연산에서 성공해야 하는 노드 수
– read-intensive/low updates application: 3, 1, 3
– Amazon Apps의 기본 값: 3, 2, 2
• 관련 오픈소스 프로젝트
– Scalaris, Voldemort, Ringo

Cassandra
• Facebook’s data store
• Apache open source
– http://cassandra.apache.org
• Hybrid
– Bigtable: Data Model, In-Memory/On-Disk Data processing
– Dynamo: Consistent hashing, No Meta data
• Data Model
– Keyspace: Database
– ColumnFamily: Table
– Column-name: column-key
– SuperColumn: column group
• Support Language
– server: java, thrift
– client: java, c/c++, php, python 등

Cassandra Architecture
Server1
(token=A)

Storage RPC Daemon
Server5 Service (Thrift, Avro)
Server2
(token=V) (token=D)
JMX

Server4 Server3
(token=O) (token=K)

• 모든 서버는 동일한 기능 수행(P2P)
• 각 서버는 특정 범위의 키 영역을 서비스
– 사용자 지정 token 또는 부하 상황에 따른 token 지정
– Server2: A → D, Server3: D → K, … Server1: V → A
• 데이터 분산
– Random Partitioner: Hash(Key)를 이용, 랜덤하게 분산
– OrderPreservingPartitioner: Key 이용, 순서있게 분산
• 데이터 복제
– Ring 구성에서 Successor에 복제

Consistency Level

• Basically Eventual Consistency
• Replication, Read/Write Consistency
– Consistency, Performance, Availability,
Durability 수준 설정
– R, W: 읽기 또는 쓰기 연산에서 성공해야 하는 노드 수
• ONE, QURUM, ALL
– read-intensive/low updates application
• Replica=3, Read=One, Write=ALL
– High Availability
• Replica=3, Read=QURUM, Write=QURUM

Cassandra Data Model
Keyspace: Database
ColumnFamily: Table
Column-name: column-key
SuperColumn: column group
Index: Rowkey, Column-name, Super column name
SuperColumn

ColumnFamily: MailIndexTerm

rowkey: “apple” “ipad”
...
jindolk
m1:10 m2:5 ... mn:21

rowkey: “termA” “termB”
...
jaso
m1:10 m2:5 ... mn:21

Column: name=mail번호, value=weight

Data operation

• Write 연산
– 클러스터 내 임의의 노드로 request
– Partitioner가 해당 데이터를 서비스하는 노드 선택
– 디스크에 commit log 저장
– 각 노드에서는 메모리에 데이터 저장
– Minor compaction, Major compaction
• Read 연산
– 클러스터 내 임의의 노드로 request
– Partitioner가 해당 데이터를 서비스하는 노드 선택
– R(복제본)개의 결과 데이터를 기다림

Failover, Node 추가/제거
• Failover
– 특정 노드 장애 시 복제본에 의해 서비스
• R/W 파라미터 값에 따라 가용성 수준 결정
– Master 서버가 없기 때문에 특정 노드 장애 시에도 지속적인 서비스
가능
• Node 추가/제거
– 노드 제거
• 기존 Ring에 신규 노드 추가
– 추가 시 복제본 서버로 부터 데이터 복제 후 서비스 투입
• Ring 구성 변경
– 다른 노드가 제거 대상 노드의 데이터를 모두 복제한 후 제거
– 노드 추가
• 부하가 높은 Key 범위를 자동으로 할당
• 해당 Key 범위의 데이터를 모두 복제한 후 서비스 투입

Cassandra Client
• Problem
– Cassandra Server Membership
• Failure Detection, Live Node Detection
– Connection Pool
– Abstraction
• Thrift/AVRO, Version
• Hector
– 3rd Cassandra client library, MIT License

Application Server
User Application

ORMapper

API Wrapper

Connection Pool

Cassandra Thrift Client

AutoDiscover

Cassandra 성능

• http://www.jaso.co.kr/426

Cassandra Usecase

• 국내 모 금융권

Cassandra Usecase
• http://about.digg.com/blog/looking-future-cassandra
• http://www.thebuzzmedia.com/digg-v4-troubles-are-symptom-of-a-
bigger-problem/

Diggs 특정 아이템에 대해 digg한 친구 목록
n
SELECT digdate, userid FROM Diggs
1 WHERE userid IN (SELECT friendid FROM Friends WHERE userid = „me‟)
Friends AND itemid = 13084479 ORDER BY `digdate` DESC, `id` DESC LIMIT 4;

U11의 friends가 U1, U3
U12의 friends가 U3
U11 digg Item1, U11 digg Item2, U12 diggs Item1
Column Family:
FriendsItem
Rowkey: userId
Super Column: itemId U1, Item1, U11 U1, Item1, U11
U1, Item1, U11 Item2, U11 Item2, U11
Column: friend
U2, U2, U2,
U3, Item1, U11 U3, Item1, U11 U3, Item1, [U11, U12]
Item2, U11 Item2, U11

MongoDB
• Document-oriented storage
– JSON-like data schemas
– Dynamic queries
– Full index support
• Replication and fail-over support
– Master-Slave replication
– Replica pair(Replica-Set)
– Limited Master-Master
• Auto-sharding for cloud-level scalability
• MapReduce for complex aggregation
• Reference
– Foursquare, sourceforge, New York Times, …
• Open Source
– http://www.mongodb.org

MongoDB Sharding

서버1 서버2 서버3 서버4

mongod mongod
(configsvr) (configsvr)

mongod mongod mongod mongod
(shard1) (shard1) (shard2) (shard2)

mongos mongos

클라이언트 로드밸런서

mongos mongos

mongod mongod
(shard3) (shard3)
mongod
(configsvr)

서버5 서버6

MongoDB 성능

• http://www.jaso.co.kr/416

MongoDB Usecase

• www.timeattack.co.kr
– 제일기획, 그루터
– 모바일, 위치기반 이벤트, 쿠폰 서비스
– Replica-Set 구성
• Avatar node
– Geo search

MongoDB Usecase
• DAUM
– MyAgora
– http://www.platformday.com/2011/files/mongoDB.pdf

NoSQL 비교
항목 Cloudata/HBase Cassandra MongoDB
Consistency Strong Eventual Strong
Availability X O X

Partition-Tolerance O O O
Key ordered Hashing Key ordered
Partition policy
(META) Key ordered (configsvr)
Replication O O O
Data Model Column Family Column Family Document
Row key Row key
Index All Fields
Column key Colmun key
Language Java Java C

Persistence Hadoop Local File Local File
API
Client Protocol Java, Thrift, REST Thrift, Avro
(C, Java, php, …)
License Apache Apache AGPL
Company Gruter Facebook, Datastax 10gen

Cloumon
• 클라우드 컴퓨팅 관리/모니터링 도구
– 오픈소스 버전, 엔터프라이즈 버전
– www.cloumon.org
– ZooKeeper, Cassandra, Hadoop, Hbase 등 관리

결론
• 데이터 저장을 위한 많은 솔루션이 존재
– Oracle, MySQL만 있다는 생각은 버려야 함
– 먼저 시스템의 데이터 속성과 요구사항을 파악(CAP, ACID/BASE)
– 한 시스템에 여러 솔루션을 적용
• 소규모/복잡한 관계 데이터: RDBMS
• 대규모 실시간 처리 데이터: NoSQL
• 대규모 저장용 데이터: Hadoop 등
• 적절한 솔루션 선택
– 반드시 운영 중 발생할 수 있는 이슈에 대해 검증 후 도입 필요
– 대부분의 NoSQL 솔루션은 베타 상태(섣부른 선택은 독이 될 수 있음)
– 솔루션의 프로그램 코드 수준으로 검증 필요
NoSQL 솔루션에 대한 안정성 확보
– 솔루션 자체의 안정성은 검증이 필요하며 현재의 DBMS 수준의 안정성은 지원하지 않음
– 반드시 안정적인 데이터 저장 방안 확보 후 적용 필요
– 운영 및 개발 경험을 가진 개발자 확보 어려움
– 요구사항에 부합되는 NoSQL 선정 필요
처음부터 중요 시스템에 적용하기 보다는 시범 적용 필요
– 선정된 솔루션 검증, 기술력 내재화
저장소의 경우 직접 개발할 필요도 있음
– 많은 인터넷 업체에서 개발/사용하고 있는 저장소를 공개
– NoSQL의 경우 다양한 오픈소스가 발표되는 원인이기도 함

감사합니다.

Q&A

13:55 ~ 14:05 에이콘 부스

이 저작물은 크리에이티브 커먼스 코리아 저작자표시-비영리-
동일조건변경허락 2.0 대한민국 라이센스에 따라 이용하실 수 있습니다.
This work is Licensed under Creative Commons Korea Attribution 2.0 License.

NoSQL

Recomendados

Recomendados

Más contenido relacionado

La actualidad más candente

La actualidad más candente (20)

Destacado

Destacado (20)

Similar a NoSQL

Similar a NoSQL (20)

Más de Gruter

Más de Gruter (20)

NoSQL