The nosql echossytem

1,017 views

Published on

th

0 Comments
0 Likes
Statistics
Notes
  • Be the first to comment

  • Be the first to like this

No Downloads
Views
Total views
1,017
On SlideShare
0
From Embeds
0
Number of Embeds
8
Actions
Shares
0
Downloads
35
Comments
0
Likes
0
Embeds 0
No embeds

No notes for slide

The nosql echossytem

  1. 1. The Architecture of OpenSource Applications: The NoSQL Ecosystem 아꿈사 박종석
  2. 2. What’s in a name?● No SQL – 기존의 RDBMS 가 아니다 . (sql 은 RDBMS 의 인 터페이스 )● Not only SQL – 기존의 RDBMS 의 대안이다 .
  3. 3. SQL and the Relational Model● SQL – 정보를 어떻게 가져오는지 보다 , 어떤 정보를 원하 는지를 기술하는 언어 – 유저는 실제로 데이터가 어떻게 저장되어있는지에 대해서는 신경쓰지 않는다 . ● 대신 어떤 데이터에 index 를 걸지 , 어떤 알고리즘으로 데이터를 프로세싱할지와 같은 추상화된 정보가 요구 ● 보통 query optimizer 가 좋은 성능을 발휘하지만 유저가 더 많은 정보를 제공해주면 좀 더 효율적이 된다 . (hint)
  4. 4. SQL and the Relational Model● RDBMS – 관계형 모델에 근거 ● 같은 entity 는 같은 속성을 가지고 하나의 table 로 저장 됨 – 데이터 이용은 데이터 구조 (schema) 에 영향을 끼 치지 않는다 ● 기존 모델 ( 계층형 , 네트워크 ) 에서는 데이터의 구조가 매우 중요했고 , 프로그래밍도 이것을 고려해야 했다 . ( 데이터를 이용하면서 구조가 변경되고 , 이것을 항상 숙지하고 있어야 원하는 데이터에 접근이 가능함 ) – 데이터와 프로그램이 분리가 가능하게됨 – 매우 구조화된 entity 와 그들간의 relationsships
  5. 5. RDBMS 의 문제점● Sql 의 풍부한 표현력은 각 쿼리의 성능이나 , work load 를 예측하기 어렵게 만든다 – But, 간단한 query 만 지원하는 경우엔 어플리케이 션 로직이 복잡해짐● Strict 한 data 구조를 사용한다 – Object orient 데이터 구조나 dynamic data 구조 (list, queue, set) 에 적합하지 않다● Data 가 많아지게 되면 여러 컴퓨터 노드로 분 산을 시켜야 한다 – 여러 컴퓨터 노드 사이의 join 은 매우 어렵고 비 효 율적이기 때문에 결국 denormalization 을 해야 한
  6. 6. RDBMS 는 대부분 좋다 !● 지금까지 많은 연구와 적용을 통해서 검증된 방 식● 만약 data 를 저장하고자 한다면 RDBMS 를 우선 고려● 하지만 특정 분야에서는 NoSQL 을 고려할 수 있다 . – 대용량의 데이터 – RDBMS 로 설계하기에 너무 복잡한 데이터 구조가 필요한 경우
  7. 7. NoSQL Inspirations● Google’s BigTable – Multi-column, range-based partitioning scheme, strict consistency● Amazon’s Dynamo – Key-oriented distributed datastore(simpe key- value data model), eventually consistency● NoSQL system 디자인에 큰 영향을 끼쳤다 – Hbase ● BigTable – Voldemort ● Dynamo
  8. 8. Characteristics and Considerations● Data and query model – Rows, objects, data structures or documents data? – 여러 record 에 동시에 접근하는 query?● Durability – Data 변경이 즉시 stable storage 로 저장 ? – 하나의 머신이 예상치 못하게 crash 되었을때 또는 데이터 센터가 불에탔을때 데이터가 유지 ?● Scalability – Data 가 오직 특정 머신에만 저장 ?
  9. 9. Characteristics and Considerations● Data and query model – Rows, objects, data structures or documents data? – 여러 record 에 동시에 접근하는 query?● Durability – Data 변경이 즉시 stable storage 로 저장 ? – 하나의 머신이 예상치 못하게 crash 되었을때 또는 데이터 센터가 불에탔을때 데이터가 유지 ?● Scalability – Data 가 오직 특정 머신에만 저장 ?
  10. 10. Characteristics and Considerations● Consistency – 여러 노드에 데이터가 분산 (partitioned or replicated) 되어 있을때 , data 변경을 어떻게 처리 할 것인가 ?● Transactional semantics – ACID 를 어느정도 까지 지원할 것인가 ? – 비즈니스와 성능 요구의 tradeoff● Single-server performance – Data 를 안전하게 disk 에 저장하려고 한다면 어떤 on-disk data structure 로 저장해야할까 ? – Read-heavy? Write-heavy?
  11. 11. NoSQL Data and Query Models
  12. 12. Key-based NoSQL Data Models● 아무리 데이터가 복잡해도 , NoSQL 에서는 결 국 key 를 통해서 데이터를 찾게된다 – 이후 value 에 대한 연산 방법은 각 NoSQL 이 다 름● 데이터 표현하는 법 – Employee:30 ● 직원 id 가 30 인 레코드 – employee_departments:20 ● 20 번 부서 레코드 – 관계형모델의 예 (Join 사용 ) (todo:) – Key-value 모델의 예 (employee_departments 가
  13. 13. Key-based NoSQL Data Models Key-Value Store● Voldemort(based in Dynamo), BDB● Value 가 어떤 정보인지에 대해서 NoSQL store 는 모른다 . ( 단지 payload) – Value 에 대한 연산을 제공하지 않음 – Application 에서 데이터 수정관련 모든 작업을 해야 함● Set, get, delete 외에 value 에 대한 어떤 연산 도 할 수 없다
  14. 14. Key-based NoSQL Data Models Key-Data Structure Stores● Redis● 각 value 에 type 을 지정 – Integer, string, list, set, sorted set● Set, get, delete 외에 Type-specific command 제공 – Integer ● Increment, decrement – Lists ● Push, pop● 편리한 기능과 성능이 조화를 이룬다
  15. 15. Key-based NoSQL Data Models Key-Document Stores● CouchDB, MongoDB, Riak● Document 는 많은 구조화된 정보를 가지고 있 는 데이터● JSON 또는 비슷한 형태로 저장● 자유로운 구조 ( 형태 ) 의 Document 를 만들 수 있지만 ... – 어플리케이션 로직이 복잡해진다
  16. 16. Key-based NoSQL Data Models Key-Document Stores
  17. 17. Key-based NoSQL Data Models BigTable Column Family Stores● Hbase, Cassandra (BigTable)● CF(Column Family) = 테이블과 비슷 – 논리적인 관련이 있는 column 을 묶어서 관리● Timestamp – 각 column 은 마지막 변경된 시간인 timestamp 를 가지고 있다 .● Sparse column placement – 공간 절약 및 성능 향상
  18. 18. Graph Storage● Node, edge, property 로 구성● HyperGraphDB, Neo4J
  19. 19. Complex Queries● Key-value 의 단순쿼리가 아닌 sql 수준의 복 잡한 쿼리를 제공● MongoDB● 참고 – SQL to MongoDB Mapping Chart – http://docs.mongodb.org/manual/reference/sql-comparis
  20. 20. Transactions ACID● Atomic( 원자성 ) – 연산은 성공 또는 실패 둘 중 하나 . 중간은 없다● Consistent( 일관성 ) – 비일관적인 데이터 상태를 트랜잭션이 보면 안된다● Isolated( 고립성 ) – 두개의 트랜잭션이 동시에 수행되어도 서로 연관을 주면 안된다 . 트랜잭션이 순서대로 수행된것 처럼 되어야 한다● Durable( 지속성 ) – 트랜잭션의 변경사항은 반영되어 남아있는다
  21. 21. Transactions ACID 단점● ACID 는 성능 저하 요인이 된다 – long and slow 트랜잭션 하나는 전체 성능을 떨어 뜨린다● NoSQL 은 Performance 를 엄밀한 ACID 보다 중요하게 여긴다 – 하지만 key level 연산은 반드시 ACID 를 지킨다 ● To avoid serious key-value pairs corruption
  22. 22. Data Durability● 이상적인 경우 – 데이터 변경이 바로 안전한 디스크에 저장되고 , 지 리적으로 떨어진 디스크에도 곧바로 저장된다● 문제는 성능 ! – NoSQL 은 다른 방법 적용 – 성능과 Durability 수준에 대한 trade-off
  23. 23. Single-server Durability● Server restart or power loss 에서 데이터 변경 을 보장 – 메모리에만 저장하지 말고 디스크에도 저장해야함● Fsync – 매번 디스크에 접근하는 비용이 비싸기 때문에 , 실 제로는 write 를 해도 디스크에 쓰지 않고 fsync 를 할때에 디스크에 저장
  24. 24. Single-server Durability Control fsync frequency● Memcached – 오직 메모리에서만 처리 – Single-server failure 시 데이터 사라짐 – 하지만 매우 빠름● Redis – fsync frequency 조절 가능 ● Every update ● every N seconds ( 최악의 경우 ? 최근 N 초간 데이터 날라감 ) ● entirely turn off fsync ( 언젠가는 disk 에 반영됨 )
  25. 25. Single-server Durability Increase Sequential Writes by Logging● B+Tree – Data 인덱싱에 사용 – B+Tree 의 update 는 여러 페이지에 산재되어 나타 남 (Random access) ● 디스크는 쓰는량보다 접근 횟수에 크리티컬● Log – 연산을 디스크에 바로하지 않고 , 로그로 저장한다 – 예를 들면 , 100 개 페이지에 대한 연산을 1 번의 write 로 끝냄 ( 성능 대략 100 배 향상 ) – 서버 failure 시에 로그를 통해 상태 복구 (redo)
  26. 26. Single-server Durability Increase Throughput by Grouping Writes● Group commit – 한번의 fsync 로 여러 트랜잭션을 동시에 commit – 한 페이지에 동시에 여러 트랜잭션이 접근한 경우 에 가능 – 처음에 끝났어야 하는 트랜잭션은 , 나중에 온 트랜 잭션이 끝날때까지 기다려야 함 . – Latency 는 증가하지만 전체 throughput 은 상승 – 성능과 Durability 두개를 모두 만족 (Hbase) ● Fsync 가 끝나야지 commit
  27. 27. Multi-server Durability Master-slave● Redis● Master 가 log 형태로 slave 로 데이터 전달● Master 가 고장나면 slave 의 데이터를 사용가능● Data loss 일어날 가능성 있다 (slave 복사 완료까지 기다리지 않음 )● Master 는 write, Slave 는 read 로 부하를 분산하기도 한다
  28. 28. Multi-server Durability Replica set● MongoDB – Master 가 고장나면 slave 중 하나가 master 가 되고 , master 가 복구되면 slave 가 되는데 , 이 과정이 자동으로 이루어 진다 – Master 는 update 가능 , slave 는 read 만 ● 하지만 , 모든 노드에 update 가능한 옵션 설정 가능 – Replica 들이 최신이 데이터가 아니어도 그냥 진행 가능 옵션도 설정 가능● Hbase – Master 에 대한 연산이 완전히 Slave 로 반영될때까지 연산 완료 안함 ● 느리지만 안정적
  29. 29. Multi-server Durability configurable form of replication● Riak, Cassandra, Voldemort● N = 데이터가 copy 되는 개수● Update 에 대한 데이터가 다른 머신에 반영되 는 갯수 W 조절가능● Example – N =3, W=2 ● 하나의 데이터는 3 개의 copy 를 가지고 있다 . ● 그 데이터에 update 가 일어나면 , 최소한 2 개의 copy 가 모두 반영될때까지 완료하지 않는다● 전체 데이터 센터가 고장날때를 대비해서
  30. 30. Scaling for Performance● Scale up – 머신의 성능을 높임 – 프로그램 복잡도 전혀 올라가지 않는 장점 – 효과대비 비용이 비싸고 , 성능 향상에도 한계가 있 다● Scale out – 머신을 계속해서 붙여나갈 수 있게함 – 프로그램이 복잡해짐 ● 대부분의 NoSQL 을 쓰면 쉽게 해결됨 (key-value 특성 상 다른 데이터에 의존성이 적기 때문 ) – 성능 향상에 한계가 없다 .
  31. 31. Do Not Shard Until You Have To● 복잡하기때문● 샤딩 없이 가능한 방법 – Read Replicas ● 앞서 설명한 master-slave – Caching ● 여러개의 Memcached host 를 사용 ● Scaling 을 지원하는 persistent solution 의 복잡함이 없 다 ● Read heavy workload 로 memcached 를 쓴다 ● Write 오버헤드는 master server 로 몰린다
  32. 32. Sharding Through Coordinators ● CouchDB – 각 CouchDB Instance 간에는 서로는 인식하지 않음 – Proxy 의 ConfigDB(Lounge and BigCouch) 가 client 의 요 청을 받아서 각 CouchDB 로 중계 – 장점 ? 심플 , 관심사 분리ConfigDB 만이 topology 인식3 replica, 2 partition
  33. 33. Sharding Through Coordinators● Gizzard http://gywn.net/category/nosql/
  34. 34. Consistent Hash Ringshttp://charsyam.wordpress.com/2011/11/25/memcached-%EC%97%90%EC%84%9C%EC%9● H = hash function (key to integer)● L = 1000● A,B,C,D,E = 서버노드 – H(A) mod L = 7, H(B) mod L = 234, H(C) mod L = 447, H(D) mode L = 660, H(E) mod L = 875● 어떤 키가 어떤 머신에 속해야 하는지 알 수 있다 . – H(‘employee30’) mod L = 899 ==> E – H(‘employee31’) mod L = 234 ==> B
  35. 35. Consistent Hash Rings Replicating Data● Replication factor 가 3 이라면 ?● Range[7,234] 는 A 뿐만아니라 , B,C 에도 저장 됨
  36. 36. Consistent Hash Rings Achieving Better Distribution● Node 의 key range 가 불균형이다 . – key range 를 hash function 에 의존 – A = 227, E = 132 – A 가 고장나면 B 가 440 를 관리하게됨● Virtual node 개념 – A 는 A_1, A_2, A_3, A_4 의 합 – 노드가 많아질수록 균등해짐
  37. 37. Range Partitioning The BigTable Way● Master Server● 3-level hierachy = 2^61 byte (128MB tablets)● Handling Failures – Master Server 는 sing failure point – Machine failures 를 인식하기 위해 chubby, zookeeper 가 필요하다 ● Managing server membership and liveness
  38. 38. Range PartitioningRange Partitioning-based NoSQL Projects● Hbase – BigTable’s hierarchical approch to range-partiting● MongoDB – Configuration nodes = 라우팅 테이블 가짐 ● 이들간의 연산은 two-phase commit● Cassandra – Order-preserving partitioner ● 해싱하지 않은 key 값으로 서버 결정 ● 순서가 비슷한 key 들은 하나의 머신에 들어감 ● Fast range scan 이 가능●
  39. 39. Which Partitioning Scheme to Use● Range partitioning – Range scans 이 종종 필요한 경우 – Key 순서대로 data 를 읽을 필요가 있는 경우 – 랜덤 노드 접근을 안할때 – 라우팅하고 configuration 노드 관리에 비용이 든 다 – Single points of failure – 서버가 다운되었을때 , 로드가 이웃노드들에 전가 되지 않고 퍼뜨릴 수 있다 . ( 이것은 hash partitioning 에서도 virtual 노드를 쓰면 된다 .)● Hash Partitioning
  40. 40. consistency● 데이터를 여러 노드에 분산하는 것은 로드 밸런 싱과 durability 에 좋지만 , consistency 에는 나 쁘다● Tow major approaches to data consistency – Strong consistency ● All replicas remain in sync – Eventual consistency ● 언젠가는 모든 replicas 에게 sync 되지만 시간이 걸릴 수 있다
  41. 41. Consistency CAP
  42. 42. Consistency CAP● Consistency – 모든 데이터베이스 클라이언트는 같은 쿼리에 대해 같은 값을 읽어야 한다 . (ACID 의 C 와 다름 )● Availability – 모든 데이터베이스 클라이언트는 항상 데이터 읽기와 쓰기가 가능해야 한다● Partition Tolerance – 데이터베이스는 다중 머신으로 분리되어도 동작해야 한다 . 즉 , 네트워크 일부 가 장애상황이어도 기능을 계속 수행할 수 있어야 한다 .
  43. 43. Consistency CAP● 분산 시스템은 셋 중 두가지만 강력하게 지원할 수 있다● CA – 2 단계 커밋 – 네트웍 파티션시 시스템 블럭 – 결국 단일 데이터 센터● CP – 샤드 – 노드 장애 발생시 일부 데이터 사용 못함● AP
  44. 44. Strong Consistency● R+W>N – N = machine – W = update 가 반영될 replica 수 – R = Read 요청을 위해 읽은 replica 수● W=N – 하나의 replica fail 에도 write 가 hang 이 될 수 있 다● 보통 R + W = N + 1● W=N, R=1 인 선택을 많이 한다 – Sync 가 맞지 않은 상황을 피하려고 ...
  45. 45. Eventual Consistency● R + W <= N – Dynamo-based systems (Voldemort, Cassandra, Riak) – N = machine – W = update 가 반영될 replica 수 – R = Read 요청을 위해 읽은 replica 수
  46. 46. Eventual Consistency Versioning and Conflicts● Key k 을 A,B,C 가 가지고 있다● Clock vector(N_A, N_B, N_C)● A 가 k 에 없데이트하면 N_A 값을 올린다 . 나머지 값은 전달받는다● Conflict 에 탐지 ? – A 가 vector clock 를 받았을때 , N_A 가 자기가 가진 값보다 작은데 , N_B 또는 N_C 가 자기가 가진것보다 크면 conflict 를 탐지 – B4 이벤트이후 모두 conflict!● Conflict 처리 ?
  47. 47. Eventual Consistency Conflict Resolution● Dynamo, voldemort – Application 이 알아서 해라 ● Svn 에서 merge, 수동 conflict 처리 같이● Cassandra – 모든 Key 에 timestamp – 쉽게 merge 할 수 있는 경우에 못하는게 아쉽● Riak – Voldemort, cassandra 방법 모두 지원● Couch – 하이브리드
  48. 48. Eventual Consistency read repair● Coordinator 가 read 할때 conflict 감지● Conflict resolution protocols 를 보내서 해결
  49. 49. Hinted Handoff● Node 가 temporarily unavailable 할때 다른 노 드가 변경사항을 대신 받아서 저장해 두었다가 새로운 replica 가 나타면 변경사항을 적용● Sloppy quorum – W 만큼의 write 까지 hinted handoff 적용● Anti-Entropy – 오랫동안 replica 가 정상이 되지 않거나 , hinted handoff 를 가지고 있던 서버도 다운되는 경우 다른 replica 로 데이터를 sync 해야 한다● Gossip –

×