NoSQL

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

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

• 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(수십 ~ 수백 GB/day)

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

Mobile phonecall request

(수억/day)

Social Network Data(수억/day)

HELP!!!

More Money!!!

Big Server

Is it Possible???

Thinking Data Characteristic

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

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

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

Consistency

Availability

Durability

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

Data Size

What is NoSQL?

Next Generation Databases mostly addressing some of the points

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

• 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

NoSQL 출현 배경

CAP(Brewers Conjecture)

분산환경에서 적절한

응답시간 이내에

세가지 속성을 만족시키는

저장소는 구성하기 어렵다.

Consistency

Availability Partition Tolerance

RDBMSBigtableCloudataHBase

DynamoCassandra

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

ClientA ClientB

Master Slave #1 Slave #2

replicationreplication

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

Select DataWhere Key = ‘k1’

PatitionedClientA ClientB

Master Slave #1 Slave #2

replication

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

Select DataWhere Key = ‘k1’

AvailabilityPartition Tolerance

CAP(MySQL-Read)

MySQL- master/slave

Not my words, BUT

It‟s from USA

선택의 문제

Deep Dive into NoSQL

Deep Dive into 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

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

Who using 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

NoSQL 대표 아키텍처

• 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

Google Bigtable

• Cloudata– Korea, Gruter

– Java, 여러 종류의 파일 시스템 지원

– 자체 commit log 시스템

• HBase– Apache

– Java, Hadoop 기반

• Hypertable– Zvents, Baidu

– C++, Hadoop, KFS

Bigtable clone project

• 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 특징

Cloudata(Hbase) Architecture

분산파일시스템(Hadoop or other)

TabletServer #1 TabletServer #2 TabletServer #n

CloudataMaster

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

사용자 애플리케이션

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

논리적 Table

물리적 저장소

Cloudata System Components

DataNode #1(DFS)

TaskTracker #1(Map&Reduce)

TabletServer #1(Cloudata)

DataNode #2(DFS)

TaskTracker #2(Map&Reduce)

TabletServer #2(Cloudata)

DataNode #n(DFS)

TaskTracker #n(Map&Reduce)

TabletServer #n(Cloudata)

Local disk(SATA)

rpc

CTableScanner/Uploader

rpc socket

ZooKeeper(Lock Service)

Local disk(SATA)

Local disk(SATA)

…

CloudataMaster

: physical server(cloudata)

: daemon process(cloudata)

: daemon process(other platform)

eventfailover/ event

Client

failover/ event

: control

: data

CommitlogServer #1

CommitlogServer #2

CommitlogServer #n

Cloudata Data Model

row #n

row #m+1

row #m

row #k+1

row #k

row #1

Rowkey Column#1

TabletA-1

cK1 v1, t1rk-1v2, t2

ck2 v3, t2

v4, t3

v5, t4

Ckn vn, tn

- Sorted by rowKey- Sorted by column

Column#n

TabletA-2

TabletA-n

Row#1

Col1-1

CF1

Col1-2

Col1-3

Col1-N

Col2-1

Col2-2

Col2-K

CF2

ColN-1

ColN-2

ColN-M

CFn

Row.Key

…… …

ColumnColumn Key

Value(t1)

Value(t2)

Value(tn)

…

분산된 서버에 배포

• 1:N 관계– 1 user: 1+friends– 질의: 특정 사용자의 모든 친구

Data Model 예제(1:N)

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

T_FRIEND

user_id

friend_id

type

T_USER_FRIEND

row info friend

<user_id> namesexage

<user_id>=type

RDBMS Cloudata

select * from T_USER, T_FRIENDwhere T_FRIEND.user_id = ?

and T_USER.id = T_FRIEND.friend_id

T_USER

id(pk)

name

sex

age

List friendKeys = get(rowkey==?)for each friendKeys {

get(rowkey==eachKey)}

• N:M relation– 1 student - many courses– 1 course - many students

Data Model 예제(N:M)

RDBMS Cloudata

T_Student

id(pk)

name

sex

age

T_S_C

s_id

c_id

type

T_Course

id(pk)

title

teacher_id

T_Student

row info course

s_id namesexage

c_id:<type>

T_Course

row info course

c_id title

teacher_id

s_id:<type>

• 1:N relation– 로그 레코드: time, ip, domain, url…– 저장된 로그는 5분, 시간, 일, 주 단위로 분석

Data Model 예제(log data)

RDBMS Cloudata

T_ACCESS_LOG

row http user

<time><INC_COUNTER> ipdomainurlreferer

login_id

T_ACCESS_LOG

time

ip

domain

url

referer

login_id

• 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 분산 및 Lookup

Data operation

TabletServer

MemoryTableCommitLogServer

MapFile#2(HDFS)

put(key, value)CommitLog

MapFile#1(HDFS)

MapFile #n(HDFS)

Minor Compaction

MergedMapFile(HDFS)

Major Compaction

Searcherget(key)

분리된MapFile#1

(HDFS)

분리된MapFile#2

(HDFS)

Split

• Master 장애– Data operation은 정상 처리– Table Schema Management, Tablet Split 기능만 장애– Multi-Master로 장애 대처

• TabletServer 장애– Master에 의해 Tablet re-assign– 수십 초 ~ 수분 이내 복구

• ZooKeeper 장애– 3/5개 node로 클러스터 구성, 절대 장애 발생하지 않음

• Hadoop NameNode 장애– 별도의 이중화 방안 필요

• Hadoop 전체 장애– Cloudata 클러스터도 장애

Failover

Cloudata MapReduce

Tablet A-3

Tablet A-N

…

Tablet A-2

TabletA-1

TableA

META Table

Map Task

TaskTracker

Map Task

Map Task

Map Task

TaskTracker

Map Task

Map Task

Map Task

TaskTracker

Map Task

Map Task

TaskTracker

ReduceTask

TaskTracker

ReduceTask

TableB

Tablet B-2

Tablet B-1

Partitioned by key

DBMSor HDFS

Table

tInputF

orm

at

Hadoop

• Google Bigtable clone– Data Model, Architecture, Features

• Open source– http://hbase.apache.org

HBase

DataNode #1

(DFS)

TaskTracker #1

(Map&Reduce)

RegionServer#1

DataNode #2

(DFS)

TaskTracker #2

(Map&Reduce)

RegionServer#2

DataNode #n

(DFS)

TaskTracker #n

(Map&Reduce)

RegionServer#n

Local disk

(SATA)

HTable HBaseAdminZooKeeper

(Lock Service)

Local disk

(SATA)

Local disk

(SATA)

…

HMaster

Client

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

• AppEngine Datastore– Multi-tenancy

• Data can be clustered together only if it is in the same Bigtableinstance

• All logical tables for a tenant must be packed into the same Bigtableinstance

• Mapping – One column family per

logical table

Bigtable Usecase

ColumnFamily

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

• 소셜 네트워크 분석 서비스

Cloudata Usecase

File Storage(HDFS)

MapReduce

Data Storage(Cloudata)

WebServer(apache)

AppServer(thrift)

DistributedSearch Server(lucene, thrift)

Crawler

LogCollector(scribe)

AnalysisApp.

DistributedIndexer

API WebServer

( jetty)

HTTP Application Analysis Storage

Cache(memcached)

DistributedSearch Server(lucene, thrift)

DistributedSearch Server(lucene, thrift)

WebServer(apache)WebServer(apache)

API WebServer

( jetty)

API WebServer

( jetty) AppServer(thrift)

AppServer(thrift)

• www.searcus.com– Twitter Data 저장

• 17대, 20억 이상 rows, 4TB, 200 ~ 250GB/server

Cloudata Usecase

Cloudata Usecase

Rowkey USERINFO FOLLWER FOLLOWING

000000021827129

created_at: 1247056652000description: 테스트favourites_count: 3followers_count: 91712friends_count: 89010Id: 54882396listed_count: 11801Location: 서울Name: 김형준

000000006030342000000007253242000000014743863000000014914904000000015045031000000015260344000000015360238

000000015260344000000015889416000000016126916000000018747960000000018784326000000019325363

000000021827130

…

000000021827131

…

Rowkey TWITTER

000000021827129-00001 in_reply_to_status_id:-1in_reply_to_user_id: -1serial_no: 1063883048source: Twitter for Androidtext: 오픈소스 활동이나 엔지니어링은 꾸준함이 중요하다. 4-5년 이상 꾸준하게 할 수 있는환경을 스스로 만들어 나가는 것이 관건

000000021827129-00002 in_reply_to_status_id: 78046819107610624in_reply_to_user_id: 40249032serial_no: 1063882962source: webText: @youngwookim cassandra 버린다는 거는 어디 나오나요???

000000021827129-00003 …

• nFractals: www.nfractals.com– Cloud 기반 CDN 아키텍팅 및 컨설팅– Cloud 기반 컨텐츠 다운로드 서비스 구축 및 운영– Hadoop, Hbase, MongoDB, Hive 등 활용

• NoSQL 활용– User access log 저장

• Hadoop 저장, Hive 분석, Hbase 저장

– Log 분석 결과를 관리자가 웹에서 즉시 조회• 과금 데이터 및 트래픽 현황 조회• URL 랭킹, 지역별 접근 분포 등

Hbase Usecase(nFractals)

Hbase Usecase(nFractals)

HadoopApp Server

App Sever

Hbase

Hive(Map/Reduce)

20,000 logs/sec- 고객별(수백)- 도메인별- 분석항목- 5분 주기(aggregation)- 50대

Hbase REST

Google Chart DataSource

App Sever

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

Facebook Message Service

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

Hbase usecase(Adobe)

• 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

Dynamo

• 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

• 모든 서버는 동일한 기능 수행(P2P)• 각 서버는 특정 범위의 키 영역을 서비스

– 사용자 지정 token 또는 부하 상황에 따른 token 지정– Server2: A → D, Server3: D → K, … Server1: V → A

• 데이터 분산– Random Partitioner: Hash(Key)를 이용, 랜덤하게 분산– OrderPreservingPartitioner: Key 이용, 순서있게 분산

• 데이터 복제– Ring 구성에서 Successor에 복제

Cassandra Architecture

RPC Daemon(Thrift, Avro)

StorageService

JMX

Server1(token=A)

Server2(token=D)

Server3(token=K)

Server4(token=O)

Server5(token=V)

• 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

Consistency Level

Keyspace: DatabaseColumnFamily: TableColumn-name: column-keySuperColumn: column groupIndex: Rowkey, Column-name, Super column name

Cassandra Data Model

ColumnFamily: MailIndexTerm

rowkey:jindolk

“apple”

m1:10 m2:5 mn:21...

“ipad”...

rowkey:jaso

“termA”

m1:10 m2:5 mn:21...

“termB”...

SuperColumn

Column: name=mail번호, value=weight

• Write 연산– 클러스터 내 임의의 노드로 request

– Partitioner가 해당 데이터를 서비스하는 노드 선택

– 디스크에 commit log 저장

– 각 노드에서는 메모리에 데이터 저장

– Minor compaction, Major compaction

• Read 연산– 클러스터 내 임의의 노드로 request

– Partitioner가 해당 데이터를 서비스하는 노드 선택

– R(복제본)개의 결과 데이터를 기다림

Data operation

• Failover– 특정 노드 장애 시 복제본에 의해 서비스

• R/W 파라미터 값에 따라 가용성 수준 결정

– Master 서버가 없기 때문에 특정 노드 장애 시에도 지속적인 서비스가능

• Node 추가/제거– 노드 제거

• 기존 Ring에 신규 노드 추가– 추가 시 복제본 서버로 부터 데이터 복제 후 서비스 투입

• Ring 구성 변경– 다른 노드가 제거 대상 노드의 데이터를 모두 복제한 후 제거

– 노드 추가• 부하가 높은 Key 범위를 자동으로 할당• 해당 Key 범위의 데이터를 모두 복제한 후 서비스 투입

Failover, Node 추가/제거

• Problem– Cassandra Server Membership

• Failure Detection, Live Node Detection

– Connection Pool– Abstraction

• Thrift/AVRO, Version

• Hector– 3rd Cassandra client library, MIT License

Cassandra Client

Application Server

Cassandra Thrift Client

ORMapper

AutoDiscover

Connection Pool

API Wrapper

User Application

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

Cassandra 성능

• 국내 모 금융권

Cassandra Usecase

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

bigger-problem/

Cassandra Usecase

Diggs

Friends

1

n

특정 아이템에 대해 digg한 친구 목록

SELECT digdate, userid FROM DiggsWHERE userid IN (SELECT friendid FROM Friends WHERE userid = „me‟)AND itemid = 13084479 ORDER BY `digdate` DESC, `id` DESC LIMIT 4;

Column Family: FriendsItem

Rowkey: userIdSuper Column: itemId

Column: friendU1, Item1, U11U2,U3, Item1, U11

U11의 friends가 U1, U3U12의 friends가 U3U11 digg Item1, U11 digg Item2, U12 diggs Item1

U1, Item1, U11Item2, U11

U2,U3, Item1, U11

Item2, U11

U1, Item1, U11Item2, U11

U2,U3, Item1, [U11, U12]

Item2, U11

• 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

MongoDB Sharding

mongod(configsvr)

mongod(shard1)

mongod(shard1)

mongod(shard2)

mongod(shard2)

mongos

mongod(configsvr)

mongos

mongod(shard3)

mongos

mongod(shard3)

mongos

로드밸런서클라이언트

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

서버5 서버6

mongod(configsvr)

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

MongoDB 성능

• www.timeattack.co.kr

– 제일기획, 그루터

– 모바일, 위치기반 이벤트, 쿠폰 서비스

– Replica-Set 구성

• Avatar node

– Geo search

MongoDB Usecase

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

MongoDB Usecase

NoSQL 비교

항목 Cloudata/HBase Cassandra MongoDB

Consistency Strong Eventual Strong

Availability X O X

Partition-Tolerance O O O

Partition policyKey ordered

(META)Hashing

Key orderedKey ordered(configsvr)

Replication O O O

Data Model Column Family Column Family Document

IndexRow key

Column keyRow key

Colmun keyAll Fields

Language Java Java C

Persistence Hadoop Local File Local File

Client Protocol Java, Thrift, REST Thrift, AvroAPI

(C, Java, php, …)

License Apache Apache AGPL

Company Gruter Facebook, Datastax 10gen

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

Cloumon

• 데이터 저장을 위한 많은 솔루션이 존재– 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.