NoSQL이 등장하게된 계기는, 기존 RDBMS는 구조상 분산처리에 적합하지 않았습니다. 데이터베이스를 분산 저장하는 샤딩이라는 기술이 있지만, 어플리케이션 레벨에서 직접 구성해야 했기 때문에 번거로웠고, 다른 방법인 오라클의 공유 디스크 기술의 경우에는 라이선스 문제가 있었습니다. 또한 하드웨어의 성능을 증가시키는 scale-up 확장방식에 적합하였기 때문에 장비수를 늘리는 scale-out 방식을 사용할 수 없어 비용부담이 컸습니다. 두번째로 SNS등의 발전으로 처리할 데이터가 폭발적으로 증가하고, 데이터의 형식은 예측할 수 없어 스키마가 정해져있는 기존 관계형 데이터베이스를 대체할 방법이 필요했습니다. 세번째로, RDBMS 시장은 주로 오라클과 마이크로소프트, IBM같은 상용 DBMS가 대부분 차지하고 있는 상황이여서, Mysql과같은 오픈소스의 선택지가 넓은 NoSQL을 고려하게 되었습니다.
기존의 RDBMS와 NoSQL에 대해 정리한 표 입니다. 가장 큰 차이는 각각 ACID와 BASE특성을 갖고 있다는 점과 schema 구조의 유연성의 차이, 하드웨어 업그레이드 방식의 수직적 확장에 의존하는 RDBMS와는 달리 NoSQL 수평적 확장이 가능하고, noSQL은 데이터를 저장할 때의 형식에 의존하지 않습니다. 또한 NoSQL은 집합 단위로 데이터가 저장됩니다. 그럼 특징을 하나씩 살펴보겠습니다.
우선 기존 RDBMS부터 알아보자면 각각 트랜잭션이 무조건 다 완료되거나 다 실패한다는 ATOMICITY(원자성), 트랜잭션이 데이터의 일관성(공통되는 특징)에 영향을 끼치면 안된다는 CONSISTENCY(일관성) , 트랜잭션이 순차적으로 동시에 한개씩 실행됨을 보장하는 ISOLATION(독립성), 트랜잭션의 결과가 영구히 남아있어야 한다는 DURABILITY(지속성) 4개의 특성 ACID라고 하고, 이 특성을 기반으로 두고 있습니다.
이와 반대로 NoSQL은 기본적으로 시스템이 언제나 사용할 수 있는 상태로 유지될 수 있도록 지원하는 availability, 아래 eventually consistency를 위해 input 없이도 시스템 상태가 바뀔 수 있다는 soft-state, 입력 당시엔 일관성이 유지된 상태가 아니지만, 특정 상황엔 일관성이 유지된 상태가 된다는 Eventually consistency 총 3개의 특성 BASE라 하고, 기반으로 두고 있습니다.
RDBMS와의 가장 큰 차이점은 noSQL같은 경우 무조건적으로 일관성을 보장하지 않습니다.
지금까지의 RDBMS와 다른 특징 데이터에 일관성이 보장되지 않아도 되고, 데이터 타입이 고정되지 않고 유연하며, 확장성이 좋다라는 특징 덕분에 빅데이터 처리에 유리합니다.
NoSQL은 아직 제품군이 제대로 정의되지 않았고, 제품 각각의 특성이 있기에 CAP 이론을 기반으로 제품을 구분합니다. Consistency는 모든 사용자가 서로 같은 시점의 데이터를 볼 수 있어야 한다는 특성, Availability는 시스템이 항상 작동해야 한다는 특성, 세번쨰 Tolerance to Network Partitions는 각각의 분산처리를 위해 나눠진 노드끼리 메시지 손실이 일어날 수 있다는 특성입니다. 1,2번째 특성의 경우 분산 시스템의 특성이지만, 3번째 P의 경우 네트워크 구성에 관련한 특성이고, 장애가 없는 네트워크란 존재하지 않기 때문에 모든 nosql 제품은 P를 택하게 됩니다. 즉, 네트워크 장애 상황(P)가 일어나면 A와 P중 무엇에 가중치를 두느냐의 차이입니다.
아까의 CAP는 P를 포함(즉, 장애가 있다는 상황)을 전제로 계산하기 때문에, 이를 개선하여 장애가 존재할시(partitio일시) Availability와 Consitency를, 일반 상황에선 consistency 와 latency 중 하나에 우선순위를 두어 제품군을 나누도록 권장하고 있습니다.
NoSQL 제품을 큰 범위로 나누자면 집합지향 모델과 그래프 모델로 이루어져 있습니다. 주로 집합지향 모델이 채택되고, 각각 키-밸류 형식, 도큐먼트 형식, 컬럼패밀리 방식으로 나눠집니다. 그래프 모델은 기존 RDBMS와 비슷한 특성을 가지고, 클러스터링에 적합하지 않으며 특수한 상황에만 사용됩니다.
NoSQL은 주로 aggregate이라는 단위를 씁니다. 오른쪽이 기존 관계형 데이터베이스가 값을 저장하는 방식이라면, 왼쪽에는 의미있는 단위로 값을 묶어 한번에 저장합니다. 이 방식으로 인해 여러 큰 클러스터에 값을 저장하는데 유리하고, 질의가 빨라집니다. 또한 하나의 집합이 하나의 노드에 저장됨을 보장합니다.
Agreegate oriented 모델 방식 중 Key-value oriented 방식은 Key값과 value값이 1대1로 매칭되는 가장 간단한 방식입니다. Put,get,delete 정도의 단순한 쿼리만 지원하고, 키로만 값을 찾아올 수 있습니다. value에는 들어가는 값의 형식을 제한하지 않습니다. 이 방식을 사용한 DB로는 aws dynamodb, redis가 있습니다.
Column family stores 방식은 하나의 키에 여러 컬럼을 묶어놓은 column family를 저장하는 방식으로 여러 개의 데이터를 한번에 저장할 수 있습니다. 이 방식을 사용한 db는 Cassandra, apache hbase가 있습니다.
DOCUMENT DATABASE 방식은 키와 – json, xml 등의 구조화된 데이터 형식으로 저장됩니다. 다른 도큐먼트 query languag를 사용시 도큐먼트 안의 데이터도 질의 가능합니다. 이 방식을 사용한 DB로는 mongoDB, CouchDB가 있습니다.
NoSQL은 RDBMS의 데이터 분석 – 테이블 디자인 – 쿼리 디자인 방식과 다르게 데이터 분석 – 쿼리 디자인 – 테이블디자인의 순서로 모델링합니다.
감사합니다.
NoSQL이 등장하게된 계기는, 기존 RDBMS는 구조상 분산처리에 적합하지 않았습니다. 데이터베이스를 분산 저장하는 샤딩이라는 기술이 있지만, 어플리케이션 레벨에서 직접 구성해야 했기 때문에 번거로웠고, 다른 방법인 오라클의 공유 디스크 기술의 경우에는 라이선스 문제가 있었습니다. 또한 하드웨어의 성능을 증가시키는 scale-up 확장방식에 적합하였기 때문에 장비수를 늘리는 scale-out 방식을 사용할 수 없어 비용부담이 컸습니다. 두번째로 SNS등의 발전으로 처리할 데이터가 폭발적으로 증가하고, 데이터의 형식은 예측할 수 없어 스키마가 정해져있는 기존 관계형 데이터베이스를 대체할 방법이 필요했습니다. 세번째로, RDBMS 시장은 주로 오라클과 마이크로소프트, IBM같은 상용 DBMS가 대부분 차지하고 있는 상황이여서, Mysql과같은 오픈소스의 선택지가 넓은 NoSQL을 고려하게 되었습니다.
기존의 RDBMS와 NoSQL에 대해 정리한 표 입니다. 가장 큰 차이는 각각 ACID와 BASE특성을 갖고 있다는 점과 schema 구조의 유연성의 차이, 하드웨어 업그레이드 방식의 수직적 확장에 의존하는 RDBMS와는 달리 NoSQL 수평적 확장이 가능하고, noSQL은 데이터를 저장할 때의 형식에 의존하지 않습니다. 또한 NoSQL은 집합 단위로 데이터가 저장됩니다. 그럼 특징을 하나씩 살펴보겠습니다.
우선 기존 RDBMS부터 알아보자면 각각 트랜잭션이 무조건 다 완료되거나 다 실패한다는 ATOMICITY(원자성), 트랜잭션이 데이터의 일관성(공통되는 특징)에 영향을 끼치면 안된다는 CONSISTENCY(일관성) , 트랜잭션이 순차적으로 동시에 한개씩 실행됨을 보장하는 ISOLATION(독립성), 트랜잭션의 결과가 영구히 남아있어야 한다는 DURABILITY(지속성) 4개의 특성 ACID라고 하고, 이 특성을 기반으로 두고 있습니다.
이와 반대로 NoSQL은 기본적으로 시스템이 언제나 사용할 수 있는 상태로 유지될 수 있도록 지원하는 availability, 아래 eventually consistency를 위해 input 없이도 시스템 상태가 바뀔 수 있다는 soft-state, 입력 당시엔 일관성이 유지된 상태가 아니지만, 특정 상황엔 일관성이 유지된 상태가 된다는 Eventually consistency 총 3개의 특성 BASE라 하고, 기반으로 두고 있습니다.
RDBMS와의 가장 큰 차이점은 noSQL같은 경우 무조건적으로 일관성을 보장하지 않습니다.
지금까지의 RDBMS와 다른 특징 데이터에 일관성이 보장되지 않아도 되고, 데이터 타입이 고정되지 않고 유연하며, 확장성이 좋다라는 특징 덕분에 빅데이터 처리에 유리합니다.
NoSQL은 아직 제품군이 제대로 정의되지 않았고, 제품 각각의 특성이 있기에 CAP 이론을 기반으로 제품을 구분합니다. Consistency는 모든 사용자가 서로 같은 시점의 데이터를 볼 수 있어야 한다는 특성, Availability는 시스템이 항상 작동해야 한다는 특성, 세번쨰 Tolerance to Network Partitions는 각각의 분산처리를 위해 나눠진 노드끼리 메시지 손실이 일어날 수 있다는 특성입니다. 1,2번째 특성의 경우 분산 시스템의 특성이지만, 3번째 P의 경우 네트워크 구성에 관련한 특성이고, 장애가 없는 네트워크란 존재하지 않기 때문에 모든 nosql 제품은 P를 택하게 됩니다. 즉, 네트워크 장애 상황(P)가 일어나면 A와 P중 무엇에 가중치를 두느냐의 차이입니다.
아까의 CAP는 P를 포함(즉, 장애가 있다는 상황)을 전제로 계산하기 때문에, 이를 개선하여 장애가 존재할시(partitio일시) Availability와 Consitency를, 일반 상황에선 consistency 와 latency 중 하나에 우선순위를 두어 제품군을 나누도록 권장하고 있습니다.
NoSQL 제품을 큰 범위로 나누자면 집합지향 모델과 그래프 모델로 이루어져 있습니다. 주로 집합지향 모델이 채택되고, 각각 키-밸류 형식, 도큐먼트 형식, 컬럼패밀리 방식으로 나눠집니다. 그래프 모델은 기존 RDBMS와 비슷한 특성을 가지고, 클러스터링에 적합하지 않으며 특수한 상황에만 사용됩니다.
NoSQL은 주로 aggregate이라는 단위를 씁니다. 오른쪽이 기존 관계형 데이터베이스가 값을 저장하는 방식이라면, 왼쪽에는 의미있는 단위로 값을 묶어 한번에 저장합니다. 이 방식으로 인해 여러 큰 클러스터에 값을 저장하는데 유리하고, 질의가 빨라집니다. 또한 하나의 집합이 하나의 노드에 저장됨을 보장합니다.
Agreegate oriented 모델 방식 중 Key-value oriented 방식은 Key값과 value값이 1대1로 매칭되는 가장 간단한 방식입니다. Put,get,delete 정도의 단순한 쿼리만 지원하고, 키로만 값을 찾아올 수 있습니다. value에는 들어가는 값의 형식을 제한하지 않습니다. 이 방식을 사용한 DB로는 aws dynamodb, redis가 있습니다.
Column family stores 방식은 하나의 키에 여러 컬럼을 묶어놓은 column family를 저장하는 방식으로 여러 개의 데이터를 한번에 저장할 수 있습니다. 이 방식을 사용한 db는 Cassandra, apache hbase가 있습니다.
DOCUMENT DATABASE 방식은 키와 – json, xml 등의 구조화된 데이터 형식으로 저장됩니다. 다른 도큐먼트 query languag를 사용시 도큐먼트 안의 데이터도 질의 가능합니다. 이 방식을 사용한 DB로는 mongoDB, CouchDB가 있습니다.
NoSQL은 RDBMS의 데이터 분석 – 테이블 디자인 – 쿼리 디자인 방식과 다르게 데이터 분석 – 쿼리 디자인 – 테이블디자인의 순서로 모델링합니다.
감사합니다.
게임 서비스를 위한 AWS상의 고성능 SQL 데이터베이스 구성 (이정훈 솔루션즈 아키텍트, AWS) :: Gaming on AWS 2018Amazon Web Services Korea
게임 서비스를 위한 AWS상의 고성능 SQL 데이터베이스 구성
게임 서비스 아키텍처에서 관계형 데이터베이스는 핵심 컴포넌트이며 또한 전체 서비스의 성능 병목 지점이 되곤 합니다. 이 세션에서는 AWS 상에서 게임 서비스를 구현할 때, 기존 물리환경에서의 DB 성능과 동일하거나 더 높은 성능을 얻을 수 있는 구성을 설명 드리며, MS SQL 구성의 성능 데모를 시연하고자 합니다.
GRUTER가 들려주는 Big Data Platform 구축 전략과 적용 사례: Tajo와 SQL-on-HadoopGruter
- 관련 기술 트렌드 소개
- Tajo의 아키텍쳐와 로드맵
Tajo는 Big Data 분석 처리 엔진 분야에서 핫이슈로 부상하고 있는 SQL-on-Hadoop의 차세대 핵심 기술로 Apache Incubation 프로젝트로 등록되어 있는 오픈소스이며, Gruter가 개발을 주도하고 있는 프로젝트입니다.
Lablupconf session7 People don't know what they want until LABLUP show it to ...Lablup Inc.
Lablup Conf 1st (Session7/Cases)
"People don't know what they want until LABLUP show it to them. : Practical guide to building GPU clusters for AI" - 김정묵
- 발표내용 :
* 교육부터 하이퍼스케일 AI 모델 개발까지, GPU Cluster 구축과 운영을 준비하실 때 미리 고려하실 사항들을 사례와 함께 공유드립니다.
- 영상보러가기 : https://youtu.be/GMYWKF993J8
사례로 알아보는 MariaDB 마이그레이션
현대적인 IT 환경과 애플리케이션을 만들기 위해 우리는 오늘도 고민을 거듭합니다. 최근 들어 오픈소스 DB가 많은 업무에 적용되고 검증이 되면서, 점차 무거운 상용 데이터베이스를 가벼운 오픈소스 DB로 전환하는 움직임이 대기업의 미션 크리티컬 업무까지로 확산하고 있습니다. 이는 클라우드 환경 및 마이크로 서비스 개념 확산과도 일치하는 움직임입니다.
상용 DB를 MariaDB로 이관한 사례를 통해 마이그레이션의 과정과 효과를 살펴 볼 수 있습니다.
MariaDB로 이관하는 것은 어렵다는 생각을 막연히 가지고 계셨다면 본 자료를 통해 이기종 데이터베이스를 MariaDB로 마이그레이션 하는 작업이 어렵지 않게 수행될 수 있다는 점을 실제 사례를 통해 확인하시길 바랍니다.
웨비나 동영상
https://www.youtube.com/watch?v=xRsETZ5cKz8&t=52s
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?
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 를 만들
수 있지만 ...
– 어플리케이션 로직이 복잡해진다
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
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 되지만 시간이 걸릴
수 있다
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
–