th

1. The Architecture of OpenSource
Applications:
The NoSQL Ecosystem
아꿈사 박종석

2. What’s in a name?
●
No SQL
– 기존의 RDBMS 가 아니다 . (sql 은 RDBMS 의 인
터페이스 )
●
Not only SQL
– 기존의 RDBMS 의 대안이다 .

3. SQL and the Relational Model
●
SQL
– 정보를 어떻게 가져오는지 보다 , 어떤 정보를 원하
는지를 기술하는 언어
– 유저는 실제로 데이터가 어떻게 저장되어있는지에
대해서는 신경쓰지 않는다 .
●
대신 어떤 데이터에 index 를 걸지 , 어떤 알고리즘으로
데이터를 프로세싱할지와 같은 추상화된 정보가 요구
●
보통 query optimizer 가 좋은 성능을 발휘하지만 유저가
더 많은 정보를 제공해주면 좀 더 효율적이 된다 . (hint)

4. SQL and the Relational Model
●
RDBMS
– 관계형 모델에 근거
●
같은 entity 는 같은 속성을 가지고 하나의 table 로 저장
됨
– 데이터 이용은 데이터 구조 (schema) 에 영향을 끼
치지 않는다
●
기존 모델 ( 계층형 , 네트워크 ) 에서는 데이터의 구조가
매우 중요했고 , 프로그래밍도 이것을 고려해야 했다 .
( 데이터를 이용하면서 구조가 변경되고 , 이것을 항상
숙지하고 있어야 원하는 데이터에 접근이 가능함 )
– 데이터와 프로그램이 분리가 가능하게됨
– 매우 구조화된 entity 와 그들간의 relationsships

5. RDBMS 의 문제점
●
Sql 의 풍부한 표현력은 각 쿼리의 성능이나 ,
work load 를 예측하기 어렵게 만든다
– But, 간단한 query 만 지원하는 경우엔 어플리케이
션 로직이 복잡해짐
●
Strict 한 data 구조를 사용한다
– Object orient 데이터 구조나 dynamic data 구조
(list, queue, set) 에 적합하지 않다
●
Data 가 많아지게 되면 여러 컴퓨터 노드로 분
산을 시켜야 한다
– 여러 컴퓨터 노드 사이의 join 은 매우 어렵고 비 효
율적이기 때문에 결국 denormalization 을 해야 한

6. RDBMS 는 대부분 좋다 !
●
지금까지 많은 연구와 적용을 통해서 검증된 방
식
●
만약 data 를 저장하고자 한다면 RDBMS 를
우선 고려
●
하지만 특정 분야에서는 NoSQL 을 고려할 수
있다 .
– 대용량의 데이터
– RDBMS 로 설계하기에 너무 복잡한 데이터 구조가
필요한 경우

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. Characteristics and Considerations
●
Data and query model
– Rows, objects, data structures or documents
data?
– 여러 record 에 동시에 접근하는 query?
●
Durability
– Data 변경이 즉시 stable storage 로 저장 ?
– 하나의 머신이 예상치 못하게 crash 되었을때 또는
데이터 센터가 불에탔을때 데이터가 유지 ?
●
Scalability
– Data 가 오직 특정 머신에만 저장 ?

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. 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. NoSQL Data and Query Models

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. Key-based NoSQL Data Models
Key-Value Store
●
Voldemort(based in Dynamo), BDB
●
Value 가 어떤 정보인지에 대해서 NoSQL
store 는 모른다 . ( 단지 payload)
– Value 에 대한 연산을 제공하지 않음
– Application 에서 데이터 수정관련 모든 작업을 해야
함
●
Set, get, delete 외에 value 에 대한 어떤 연산
도 할 수 없다

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. Key-based NoSQL Data Models
Key-Document Stores
●
CouchDB, MongoDB, Riak
●
Document 는 많은 구조화된 정보를 가지고 있
는 데이터
●
JSON 또는 비슷한 형태로 저장
●
자유로운 구조 ( 형태 ) 의 Document 를 만들
수 있지만 ...
– 어플리케이션 로직이 복잡해진다

16. Key-based NoSQL Data Models
Key-Document Stores

17. Key-based NoSQL Data Models
BigTable Column Family Stores
●
Hbase, Cassandra (BigTable)
●
CF(Column Family) = 테이블과 비슷
– 논리적인 관련이 있는 column 을 묶어서 관리
●
Timestamp – 각 column 은 마지막 변경된 시간인
timestamp 를 가지고 있다 .
●
Sparse column placement
– 공간 절약 및 성능 향상

18. Graph Storage
●
Node, edge, property 로 구성
●
HyperGraphDB, Neo4J

19. Complex Queries
●
Key-value 의 단순쿼리가 아닌 sql 수준의 복
잡한 쿼리를 제공
●
MongoDB
●
참고
– SQL to MongoDB Mapping Chart
– http://docs.mongodb.org/manual/reference/sql-comparis

20. Transactions ACID
●
Atomic( 원자성 )
– 연산은 성공 또는 실패 둘 중 하나 . 중간은 없다
●
Consistent( 일관성 )
– 비일관적인 데이터 상태를 트랜잭션이 보면 안된다
●
Isolated( 고립성 )
– 두개의 트랜잭션이 동시에 수행되어도 서로 연관을
주면 안된다 . 트랜잭션이 순서대로 수행된것 처럼
되어야 한다
●
Durable( 지속성 )
– 트랜잭션의 변경사항은 반영되어 남아있는다

21. Transactions ACID 단점
●
ACID 는 성능 저하 요인이 된다
– long and slow 트랜잭션 하나는 전체 성능을 떨어
뜨린다
●
NoSQL 은 Performance 를 엄밀한 ACID 보다
중요하게 여긴다
– 하지만 key level 연산은 반드시 ACID 를 지킨다
●
To avoid serious key-value pairs corruption

22. Data Durability
●
이상적인 경우
– 데이터 변경이 바로 안전한 디스크에 저장되고 , 지
리적으로 떨어진 디스크에도 곧바로 저장된다
●
문제는 성능 !
– NoSQL 은 다른 방법 적용
– 성능과 Durability 수준에 대한 trade-off

23. Single-server Durability
●
Server restart or power loss 에서 데이터 변경
을 보장
– 메모리에만 저장하지 말고 디스크에도 저장해야함
●
Fsync
– 매번 디스크에 접근하는 비용이 비싸기 때문에 , 실
제로는 write 를 해도 디스크에 쓰지 않고 fsync 를
할때에 디스크에 저장

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. Single-server Durability
Increase Sequential Writes by Logging
●
B+Tree
– Data 인덱싱에 사용
– B+Tree 의 update 는 여러 페이지에 산재되어 나타
남 (Random access)
●
디스크는 쓰는량보다 접근 횟수에 크리티컬
●
Log
– 연산을 디스크에 바로하지 않고 , 로그로 저장한다
– 예를 들면 , 100 개 페이지에 대한 연산을 1 번의
write 로 끝냄 ( 성능 대략 100 배 향상 )
– 서버 failure 시에 로그를 통해 상태 복구 (redo)

26. Single-server Durability
Increase Throughput by Grouping Writes
●
Group commit
– 한번의 fsync 로 여러 트랜잭션을 동시에 commit
– 한 페이지에 동시에 여러 트랜잭션이 접근한 경우
에 가능
– 처음에 끝났어야 하는 트랜잭션은 , 나중에 온 트랜
잭션이 끝날때까지 기다려야 함 .
– Latency 는 증가하지만 전체 throughput 은 상승
– 성능과 Durability 두개를 모두 만족 (Hbase)
●
Fsync 가 끝나야지 commit

27. Multi-server Durability
Master-slave
●
Redis
●
Master 가 log 형태로 slave 로 데이터 전달
●
Master 가 고장나면 slave 의 데이터를 사용가능
●
Data loss 일어날 가능성 있다 (slave 복사 완료까지 기다리지
않음 )
●
Master 는 write, Slave 는 read 로 부하를 분산하기도 한다

28. Multi-server Durability
Replica set
●
MongoDB
– Master 가 고장나면 slave 중 하나가 master 가 되고 , master 가 복구되면
slave 가 되는데 , 이 과정이 자동으로 이루어 진다
– Master 는 update 가능 , slave 는 read 만
●
하지만 , 모든 노드에 update 가능한 옵션 설정 가능
– Replica 들이 최신이 데이터가 아니어도 그냥 진행 가능 옵션도 설정 가능
●
Hbase
– Master 에 대한 연산이 완전히 Slave 로 반영될때까지 연산 완료 안함
●
느리지만 안정적

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. Scaling for Performance
●
Scale up
– 머신의 성능을 높임
– 프로그램 복잡도 전혀 올라가지 않는 장점
– 효과대비 비용이 비싸고 , 성능 향상에도 한계가 있
다
●
Scale out
– 머신을 계속해서 붙여나갈 수 있게함
– 프로그램이 복잡해짐
●
대부분의 NoSQL 을 쓰면 쉽게 해결됨 (key-value 특성
상 다른 데이터에 의존성이 적기 때문 )
– 성능 향상에 한계가 없다 .

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. Sharding Through Coordinators
●
CouchDB
– 각 CouchDB Instance 간에는 서로는 인식하지 않음
– Proxy 의 ConfigDB(Lounge and BigCouch) 가 client 의 요
청을 받아서 각 CouchDB 로 중계
– 장점 ? 심플 , 관심사 분리
ConfigDB 만이 topology 인식
3 replica, 2 partition

33. Sharding Through Coordinators
●
Gizzard
http://gywn.net/category/nosql/

34. Consistent Hash Rings
http://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. Consistent Hash Rings
Replicating Data
●
Replication factor 가 3 이라면 ?
●
Range[7,234] 는 A 뿐만아니라 , B,C 에도 저장
됨

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. 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. Range Partitioning
Range 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. Which Partitioning Scheme to Use
●
Range partitioning
– Range scans 이 종종 필요한 경우
– Key 순서대로 data 를 읽을 필요가 있는 경우
– 랜덤 노드 접근을 안할때
– 라우팅하고 configuration 노드 관리에 비용이 든
다
– Single points of failure
– 서버가 다운되었을때 , 로드가 이웃노드들에 전가
되지 않고 퍼뜨릴 수 있다 . ( 이것은 hash
partitioning 에서도 virtual 노드를 쓰면 된다 .)
●
Hash Partitioning

40. consistency
●
데이터를 여러 노드에 분산하는 것은 로드 밸런
싱과 durability 에 좋지만 , consistency 에는 나
쁘다
●
Tow major approaches to data consistency
– Strong consistency
●
All replicas remain in sync
– Eventual consistency
●
언젠가는 모든 replicas 에게 sync 되지만 시간이 걸릴
수 있다

41. Consistency
CAP

42. Consistency
CAP
●
Consistency
– 모든 데이터베이스 클라이언트는 같은 쿼리에 대해 같은 값을 읽어야 한다 .
(ACID 의 C 와 다름 )
●
Availability
– 모든 데이터베이스 클라이언트는 항상 데이터 읽기와 쓰기가 가능해야 한다
●
Partition Tolerance
– 데이터베이스는 다중 머신으로 분리되어도 동작해야 한다 . 즉 , 네트워크 일부
가 장애상황이어도 기능을 계속 수행할 수 있어야 한다 .

43. Consistency
CAP
●
분산 시스템은 셋 중 두가지만 강력하게 지원할
수 있다
●
CA
– 2 단계 커밋
– 네트웍 파티션시 시스템 블럭
– 결국 단일 데이터 센터
●
CP
– 샤드
– 노드 장애 발생시 일부 데이터 사용 못함
●
AP

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. Eventual Consistency
●
R + W <= N
– Dynamo-based systems (Voldemort, Cassandra,
Riak)
– N = machine
– W = update 가 반영될 replica 수
– R = Read 요청을 위해 읽은 replica 수

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. Eventual Consistency
Conflict Resolution
●
Dynamo, voldemort
– Application 이 알아서 해라
●
Svn 에서 merge, 수동 conflict 처리 같이
●
Cassandra
– 모든 Key 에 timestamp
– 쉽게 merge 할 수 있는 경우에 못하는게 아쉽
●
Riak
– Voldemort, cassandra 방법 모두 지원
●
Couch
– 하이브리드

48. Eventual Consistency
read repair
●
Coordinator 가 read 할때 conflict 감지
●
Conflict resolution protocols 를 보내서 해결

49. Hinted Handoff
●
Node 가 temporarily unavailable 할때 다른 노
드가 변경사항을 대신 받아서 저장해 두었다가
새로운 replica 가 나타면 변경사항을 적용
●
Sloppy quorum
– W 만큼의 write 까지 hinted handoff 적용
●
Anti-Entropy
– 오랫동안 replica 가 정상이 되지 않거나 , hinted
handoff 를 가지고 있던 서버도 다운되는 경우 다른
replica 로 데이터를 sync 해야 한다
●
Gossip
–