No sql 20110619_jco_김형준
Upcoming SlideShare
Loading in...5
×
 

No sql 20110619_jco_김형준

on

  • 1,466 views

하둡을 알기전에 알아두면 좋은 Nosql.

하둡을 알기전에 알아두면 좋은 Nosql.
db에서 스키마free 제약조건을 약하한 그런개념

Statistics

Views

Total Views
1,466
Views on SlideShare
1,466
Embed Views
0

Actions

Likes
0
Downloads
37
Comments
0

0 Embeds 0

No embeds

Accessibility

Categories

Upload Details

Uploaded via as Adobe PDF

Usage Rights

© All Rights Reserved

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Processing…
Post Comment
Edit your comment

No sql 20110619_jco_김형준 No sql 20110619_jco_김형준 Presentation Transcript

  • 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 ServerSocial Network Data (수억/day)
  • Is it Possible???
  • 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 #nMapFile#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
  • 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 UsecaseRowkey USERINFO FOLLWER FOLLOWING00000002 created_at: 1247056652000 000000006030342 0000000152603441827129 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: 106388304800000002 … source: Twitter for Android1827130 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• Cassandras 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. – Facebooks 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&A13:55 ~ 14:05 에이콘 부스
  • 이 저작물은 크리에이티브 커먼스 코리아 저작자표시-비영리- 동일조건변경허락 2.0 대한민국 라이센스에 따라 이용하실 수 있습니다.This work is Licensed under Creative Commons Korea Attribution 2.0 License.