The Architecture of OpenSource Applications:

The NoSQL Ecosystem

아꿈사 박종석

What’s in a name?

● No SQL– 기존의 RDBMS 가 아니다 . (sql 은 RDBMS 의

인터페이스 )● Not only SQL

– 기존의 RDBMS 의 대안이다 .

SQL and the Relational Model

● SQL– 정보를 어떻게 가져오는지 보다 , 어떤 정보를

원하는지를 기술하는 언어– 유저는 실제로 데이터가 어떻게 저장되어있는지에

대해서는 신경쓰지 않는다 .● 대신 어떤 데이터에 index 를 걸지 , 어떤 알고리즘으로

데이터를 프로세싱할지와 같은 추상화된 정보가 요구● 보통 query optimizer 가 좋은 성능을 발휘하지만 유저가

더 많은 정보를 제공해주면 좀 더 효율적이 된다 . (hint)

SQL and the Relational Model

● RDBMS– 관계형 모델에 근거

● 같은 entity 는 같은 속성을 가지고 하나의 table 로 저장됨– 데이터 이용은 데이터 구조 (schema) 에 영향을 끼치지 않는다

● 기존 모델 ( 계층형 , 네트워크 ) 에서는 데이터의 구조가 매우 중요했고 , 프로그래밍도 이것을 고려해야 했다 . ( 데이터를 이용하면서 구조가 변경되고 , 이것을 항상 숙지하고 있어야 원하는 데이터에 접근이 가능함 )

– 데이터와 프로그램이 분리가 가능하게됨– 매우 구조화된 entity 와 그들간의 relationsships 을 정의한다

RDBMS 의 문제점● Sql 의 풍부한 표현력은 각 쿼리의 성능이나 , work load 를

예측하기 어렵게 만든다– But, 간단한 query 만 지원하는 경우엔 어플리케이션 로직이 복잡해짐

● Strict 한 data 구조를 사용한다– Object orient 데이터 구조나 dynamic data 구조 (list, queue, set)

에 적합하지 않다● Data 가 많아지게 되면 여러 컴퓨터 노드로 분산을 시켜야 한다

– 여러 컴퓨터 노드 사이의 join 은 매우 어렵고 비 효율적이기 때문에 결국 denormalization 을 해야 한다

– Demormalization 은 하나의 컴퓨터에는 그것과 관련된 모든 데어터가 들어 있어야 한다는 것인데 , 이것은 결국 key-value 모델이지 relational model 이라고 하기 어렵다

RDBMS 는 대부분 좋다 !

● 지금까지 많은 연구와 적용을 통해서 검증된 방식

● 만약 data 를 저장하고자 한다면 RDBMS 를 우선 고려

● 하지만 특정 분야에서는 NoSQL 을 고려할 수 있다 .– 대용량의 데이터– RDBMS 로 설계하기에 너무 복잡한 데이터 구조가

필요한 경우

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

– Cassandra● BigTalbe(data model)● Dynamo(partitioning and consistency schemes)

Characteristics and Considerations

● Data and query model– Rows, objects, data structures or documents data?– 여러 record에 동시에 접근하는 query?

● Durability– Data 변경이 즉시 stable storage로 저장?– 하나의 머신이 예상치 못하게 crash되었을때 또는 데이터 센터가 불에탔을때 데이터가

유지?● Scalability

– Data가 오직 특정 머신에만 저장?– 많은 read & write가 요구?

● Partitioning– Scalability, availability, durability 이슈로 데이터가 여러 서버로 분산될 필요가 있는

가?– 어떤서버에 어떤 데이터가 저장될지 어떻게 알까?

Characteristics and Considerations

● Data and query model– Rows, objects, data structures or documents data?– 여러 record에 동시에 접근하는 query?

● Durability– Data 변경이 즉시 stable storage로 저장?– 하나의 머신이 예상치 못하게 crash되었을때 또는 데이터 센터가 불에탔을때 데이터가

유지?● Scalability

– Data가 오직 특정 머신에만 저장?– 많은 read & write가 요구?

● Partitioning– Scalability, availability, durability 이슈로 데이터가 여러 서버로 분산될 필요가 있는

가?– 어떤서버에 어떤 데이터가 저장될지 어떻게 알까?

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?

● Analytical workloads– Build dataset-seized reports– aggregating statistics across multiple users

NoSQL Data and Query Models

Key-based NoSQL Data Models

● 아무리 데이터가 복잡해도 , NoSQL에서는 결국 key를 통해서 데이터를 찾게된다– 이후 value에 대한 연산 방법은 각 NoSQL이 다름

● 데이터 표현하는 법– Employee:30

● 직원 id가 30인 레코드– employee_departments:20

● 20번 부서 레코드– 관계형모델의 예 (Join사용 ) (todo:)– Key-value모델의 예 (employee_departments 가 employee를 모두 가짐 )

(todo:)● Join이 없고 , key를 통해 data를 접근하므로 비교적 성능이 적고 예측가능

( 단순한 쿼리패턴 )– 어플리케이션이 복잡해짐 ( 트레이드오프 )

Key-based NoSQL Data ModelsKey-Value Store

● Voldemort(based in Dynamo), BDB● Value 가 어떤 정보인지에 대해서 NoSQL

store 는 모른다 . ( 단지 payload)– Value 에 대한 연산을 제공하지 않음– Application 에서 데이터 수정관련 모든 작업을

해야함● Set, get, delete 외에 value 에 대한 어떤

연산도 할 수 없다

Key-based NoSQL Data ModelsKey-Data Structure Stores

● Redis● 각 value 에 type 을 지정

– Integer, string, list, set, sorted set● Set, get, delete 외에 Type-specific command 제공

– Integer● Increment, decrement

– Lists● Push, pop

● 편리한 기능과 성능이 조화를 이룬다– Type-specific command <== 기능성 up– Multi-key operations(aggregation or joins) 이 없다 <== 성능 다운

방지

Key-based NoSQL Data ModelsKey-Document Stores

● CouchDB, MongoDB, Riak● Document 는 많은 구조화된 정보를 가지고

있는 데이터● JSON 또는 비슷한 형태로 저장● 자유로운 구조 ( 형태 ) 의 Document 를 만들

수 있지만 ...– 어플리케이션 로직이 복잡해진다

Key-based NoSQL Data ModelsKey-Document Stores

Key-based NoSQL Data ModelsBigTable Column Family Stores● Hbase, Cassandra (BigTable)● CF(Column Family) = 테이블과 비슷

– 논리적인 관련이 있는 column 을 묶어서 관리● Timestamp – 각 column 은 마지막 변경된 시간인

timestamp 를 가지고 있다 .● Sparse column placement

– 공간 절약 및 성능 향상

Graph Storage

● Node, edge, property 로 구성● HyperGraphDB, Neo4J

Complex Queries

● Key-value 의 단순쿼리가 아닌 sql 수준의 복잡한 쿼리를 제공

● MongoDB● 참고

– SQL to MongoDB Mapping Chart– http://docs.mongodb.org/manual/reference/s

ql-comparison/

Transactions ACID

● Atomic( 원자성 )– 연산은 성공 또는 실패 둘 중 하나 . 중간은 없다

● Consistent( 일관성 )– 비일관적인 데이터 상태를 트랜잭션이 보면 안된다

● Isolated( 고립성 )– 두개의 트랜잭션이 동시에 수행되어도 서로 연관을 주면 안된다 . 트랜잭션이

순서대로 수행된것 처럼 되어야 한다● Durable( 지속성 )

– 트랜잭션의 변경사항은 반영되어 남아있는다

Transactions ACID 단점

● ACID 는 성능 저하 요인이 된다 – long and slow 트랜잭션 하나는 전체 성능을

떨어뜨린다● NoSQL 은 Performance 를 엄밀한 ACID

보다 중요하게 여긴다– 하지만 key level 연산은 반드시 ACID 를 지킨다

● To avoid serious key-value pairs corruption

Data Durability

● 이상적인 경우– 데이터 변경이 바로 안전한 디스크에 저장되고 ,

지리적으로 떨어진 디스크에도 곧바로 저장된다

● 문제는 성능 !– NoSQL 은 다른 방법 적용– 성능과 Durability 수준에 대한 trade-off

Single-server Durability

● Server restart or power loss 에서 데이터 변경을 보장– 메모리에만 저장하지 말고 디스크에도 저장해야함

● Fsync– 매번 디스크에 접근하는 비용이 비싸기 때문에 ,

실제로는 write 를 해도 디스크에 쓰지 않고 fsync 를 할때에 디스크에 저장

Single-server DurabilityControl fsync frequency

● Memcached– 오직 메모리에서만 처리– Single-server failure 시 데이터 사라짐– 하지만 매우 빠름

● Redis– fsync frequency 조절 가능

● Every update● every N seconds (최악의 경우 ? 최근 N 초간 데이터 날라감 ) ● entirely turn off fsync ( 언젠가는 disk 에 반영됨 )

● B+Tree– Data 인덱싱에 사용– B+Tree 의 update 는 여러 페이지에 산재되어 나타남

(Random access)● 디스크는 쓰는량보다 접근 횟수에 크리티컬

● Log– 연산을 디스크에 바로하지 않고 , 로그로 저장한다– 예를 들면 , 100 개 페이지에 대한 연산을 1번의 write 로 끝냄 ( 성능 대략 100배 향상 )

– 서버 failure 시에 로그를 통해 상태 복구 (redo)

Single-server DurabilityIncrease Sequential Writes by Logging

● Group commit– 한번의 fsync 로 여러 트랜잭션을 동시에 commit– 한 페이지에 동시에 여러 트랜잭션이 접근한 경우에

가능– 처음에 끝났어야 하는 트랜잭션은 , 나중에 온

트랜잭션이 끝날때까지 기다려야 함 .– Latency 는 증가하지만 전체 throughput 은 상승– 성능과 Durability 두개를 모두 만족 (Hbase)

● Fsync 가 끝나야지 commit

Single-server DurabilityIncrease Throughput by Grouping

Writes

Multi-server DurabilityMaster-slave

● Redis

● Master 가 log 형태로 slave 로 데이터 전달● Master 가 고장나면 slave 의 데이터를 사용가능● Data loss 일어날 가능성 있다 (slave 복사 완료까지

기다리지 않음 )

● Master 는 write, Slave 는 read 로 부하를 분산하기도 한다

● MongoDB

– Master 가 고장나면 slave 중 하나가 master 가 되고 , master 가 복구되면 slave 가 되는데 , 이 과정이 자동으로 이루어 진다

– Master 는 update 가능 , slave 는 read 만● 하지만 , 모든 노드에 update 가능한 옵션 설정 가능

– Replica 들이 최신이 데이터가 아니어도 그냥 진행 가능 옵션도 설정 가능● Hbase

– Master 에 대한 연산이 완전히 Slave 로 반영될때까지 연산 완료 안함● 느리지만 안정적

Multi-server DurabilityReplica set

● Riak, Cassandra, Voldemort● N = 데이터가 copy 되는 개수● Update 에 대한 데이터가 다른 머신에 반영되는 갯수 W 조절가능● Example

– N =3, W=2● 하나의 데이터는 3개의 copy 를 가지고 있다 .● 그 데이터에 update 가 일어나면 , 최소한 2개의 copy 가 모두 반영될때까지 완료하지 않는다

● 전체 데이터 센터가 고장날때를 대비해서– Rack-aware configurations 지정가능– 다른 데이터 센터로 데이터 복사본을 유지

Multi-server Durabilityconfigurable form of replication

Scaling for Performance● Scale up

– 머신의 성능을 높임– 프로그램 복잡도 전혀 올라가지 않는 장점– 효과대비 비용이 비싸고 , 성능 향상에도 한계가 있다

● Scale out– 머신을 계속해서 붙여나갈 수 있게함– 프로그램이 복잡해짐

● 대부분의 NoSQL을 쓰면 쉽게 해결됨 (key-value 특성상 다른 데이터에 의존성이 적기 때문 )– 성능 향상에 한계가 없다 .– 목표 = Linear scalability

● 머신을 2배 더 추가하면 성능이 2배 더 향상● sharding

– 어떻게 데이터를 머신들에게 퍼트려서 read, write 부하를 나눌 것인가?

Do Not Shard Until You Have To

● 복잡하기때문● 샤딩 없이 가능한 방법

– Read Replicas● 앞서 설명한 master-slave

– Caching● 여러개의 Memcached host 를 사용● Scaling 을 지원하는 persistent solution 의 복잡함이 없다● Read heavy workload 로 memcached 를 쓴다● Write 오버헤드는 master server 로 몰린다

Sharding Through Coordinators

● CouchDB

– 각 CouchDB Instance 간에는 서로는 인식하지 않음– Proxy 의 ConfigDB(Lounge and BigCouch) 가 client

의 요청을 받아서 각 CouchDB 로 중계– 장점 ? 심플 , 관심사 분리

3 replica, 2 partition

ConfigDB 만이 topology 인식

Sharding Through Coordinators

● Gizzard

http://gywn.net/category/nosql/

Consistent Hash Rings

http://charsyam.wordpress.com/2011/11/25/memcached-%EC%97%90%EC%84%9C%EC%9D%98-consistent-hashing/

● 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

Consistent Hash RingsReplicating Data

● Replication factor 가 3이라면 ?● Range[7,234] 는 A 뿐만아니라 , B,C 에도

저장됨

Consistent Hash RingsAchieving 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 의 합– 노드가 많아질수록 균등해짐

Range PartitioningThe 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

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 이 가능

● Twitter’s Gizzard

Which Partitioning Scheme to Use

● Range partitioning – Range scans 이 종종 필요한 경우– Key 순서대로 data 를 읽을 필요가 있는 경우– 랜덤 노드 접근을 안할때– 라우팅하고 configuration 노드 관리에 비용이 든다– Single points of failure– 서버가 다운되었을때 , 로드가 이웃노드들에 전가되지 않고 퍼뜨릴 수 있다 .

( 이것은 hash partitioning 에서도 virtual 노드를 쓰면 된다 .)● Hash Partitioning

– 데이터를 균등하게 퍼트린다 .– 라우팅이 심플– Hash function 을 클라이언트에서 수행

consistency

● 데이터를 여러 노드에 분산하는 것은 로드 밸런싱과 durability 에 좋지만 , consistency에는 나쁘다

● Tow major approaches to data consistency– Strong consistency

● All replicas remain in sync– Eventual consistency

● 언젠가는 모든 replicas 에게 sync 되지만 시간이 걸릴 수 있다

ConsistencyCAP

ConsistencyCAP

● Consistency

– 모든 데이터베이스 클라이언트는 같은 쿼리에 대해 같은 값을 읽어야 한다 . (ACID 의 C 와 다름 )

● Availability

– 모든 데이터베이스 클라이언트는 항상 데이터 읽기와 쓰기가 가능해야 한다● Partition Tolerance

– 데이터베이스는 다중 머신으로 분리되어도 동작해야 한다 . 즉 , 네트워크 일부가 장애상황이어도 기능을 계속 수행할 수 있어야 한다 .

ConsistencyCAP

● 분산 시스템은 셋 중 두가지만 강력하게 지원할 수 있다● CA

– 2단계 커밋– 네트웍 파티션시 시스템 블럭– 결국 단일 데이터 센터

● CP– 샤드– 노드 장애 발생시 일부 데이터 사용 못함

● AP– 시스템이 정확하지 않은 데이터 반환

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 가 맞지 않은 상황을 피하려고 ...

Eventual Consistency

● R + W <= N– Dynamo-based systems (Voldemort,

Cassandra, Riak)– N = machine– W = update 가 반영될 replica 수– R = Read 요청을 위해 읽은 replica 수

Eventual ConsistencyVersioning 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 처리 ?

Eventual ConsistencyConflict Resolution

● Dynamo, voldemort– Application 이 알아서 해라

● Svn 에서 merge, 수동 conflict 처리 같이● Cassandra

– 모든 Key 에 timestamp– 쉽게 merge 할 수 있는 경우에 못하는게 아쉽

● Riak– Voldemort, cassandra 방법 모두 지원

● Couch– 하이브리드– 둘다 가능

Eventual Consistencyread repair

● Coordinator 가 read 할때 conflict감지● Conflict resolution protocols 를 보내서

해결

Hinted Handoff

● Node 가 temporarily unavailable 할때 다른 노드가 변경사항을 대신 받아서 저장해 두었다가 새로운 replica 가 나타면 변경사항을 적용

● Sloppy quorum– W 만큼의 write 까지 hinted handoff 적용

● Anti-Entropy– 오랫동안 replica 가 정상이 되지 않거나 , hinted handoff 를

가지고 있던 서버도 다운되는 경우 다른 replica 로 데이터를 sync해야 한다

● Gossip– 주기적으로 랜덤하게 선택된 노드의 상태를 전달받는다