ClustrixDB

0. INDEX

0. INDEX
1. Concepts
2. Key-Features
3. Query Processing Step
4. Architecture
5. Why we use ClustrixDB?

1. Concepts

ClustrixDB는 Scalable하고, Shared-Nothing의 데이터 분배 구조이며
내결함성을 보유하고 간단한 SQL 인터페이스에 의해 실행 가능한 NewSQL이다.
주로 온라인 트랜잭션(OLTP)에 최적화되어 있으며 MySQL과 호환성도 제공한다.

NewSQL

• NewSQL의 필요성
  • 용량이 크고 다양한 데이터가 늘어나며 기존의 RDBMS와 NoSQL로 처리하는 데 한계가 나타남.
  • 대용량 데이터 처리와 높은 수준의 데이터 정합성을 필요로 하는 분야에서 적합.

• NewSQL의 정의
  • 표준으로 내려온 정의는 없으며 가장 많이 언급된 내용을 살펴보면,

    SQL 지원, ACID 준수, 성능 개선을 가지고 NoSQL의 특징인 확장성과 가용성을 갖춘 DBMS
    

    SQL 기반 상호 작용, 트랜잭션에 대한 ACID 지원, 비공유 구조,
    비잠금 동시성 제어, Node단위의 고성능 DBMS
    

• RDBMS, NoSQL, NewSQL 비교

2. Key-Features

• Scalable
• High Concurrency OLTP( Online Transaction Processing )
• Automatic Data Distribution
• Fault-Tolerant
• Flexible Deployment Options
• MySQL Compatible
• Easy to Migrate from MySQL

Scalable

shared-nothing architecture이라 선형적으로 노드를 늘릴 수 있다.
또한 각 노드가 각각 다른 데이터를 가진다.
읽기/쓰기는 여러 노드로 분산되어 contention을 줄인다.
게다가 데이터와 쿼리의 실행 모두 자동으로 분산한다.

노드의 add는 Flex Up, reduce는 Flex Down으로 칭한다.
두 연산 모두 백그라운드에서 자동 재분배하기 때문에
온라인 상태인지, DB를 사용 가능 한지에 대해 사용자는 신경쓸 필요 없다.

High Concurrency OLTP

ClustrixDB는 large-scale OLTP에 대해 설계되었다. ACID는 물론이고,
앞서 설명한 바와 같이 단순하게 노드를 추가하는 것만으로 read/write에 대해 high throughput을 가진다.
클러스터 환경에서 데이터와 워크로드를 나눔으로써 단일 인스턴스 DB보다 높은 병렬적 효율을 가진다.

Automatic Data Distribution

ClustrixDB의 핵심 컴포넌트 중 하나인 Rebalancer는 백그라운드에서 데이터의 분배에 대해 manage한다.
예상치 않은 failure에 대해 Rebalancer가 자동으로 처리한다.

Fault-Tolerant

내결함성을 염두하고 설계되었으며, 그렇기 때문에 data loss를 막을 수 있다.

Flexible Deployment Options

다양한 플랫폼에서 유연하게 배포 가능하다.

• CentOS 7.4 이상
• 클라우드( AWS, Rackspace, Azure )
• 기타 하드웨어

MySQL Compatible

SQL, DML, DDL, trigger, stored procedure( PSM )에 대해 MySQL 구문을 사용한다.

Easy to Migrate from MySQL

MySQL을 호환하므로 MySQL 툴을 가지고 ClustrixDB로의 Migration도 쉽게 가능하다.

3. Query Processing Step

1. 노드가 선택되고, GTM( Global Transaction Manager )이 노드간의 처리를 위해 corrdination을 수행한다.
   ( A node is chosen and the Global Transaction Manager( GTM ) performs coordination for processing across nodes. )

2. Sierra DB 엔진이 파싱하고, 각 SQL statement를 컴파일 하고 분배 수행의 최적 path를 선택한다.
   ( The Sierra Database Engine parses and compiles each SQL statement and chooses an optimal path for distributed execution. )

3. Executable한 프로그램 fragment들은 클러스터간에 분산되고 다른 노드들에서 실행된다.
   ( Executable program fragments are distributed across the cluster and executed on different nodes. )

4. 프로그램 fragments들에 의한 결과가 GTM 노드로 반환된다.
   ( Results from the program fragments are returned to the GTM node. )

5. GTM 노드는 모으고 쿼리의 결과를 최종 사용자에게 반환한다.
   ( The GTM node assembles and returns query results to the end user. )

Global Transaction Manager

ClustrixDB 에서의 쿼리 처리는 일반적으로 클러스터간 커넥션을 분산하는 Load Balancer를 통해
클러스터의 한 노드가 GTM( Global Transaction Manager )으로 선택될 때 시작한다.

이후 GTM은 쿼리 실행 단계를 지시함으로써 트랜잭션의 모든 측면을 관리하고,
각 단계가 성공적으로 완료되었는지 확인한 뒤 쿼리 결과를 caller에게 반환하기 전 수집, 마무리 한다.

ClustrixDB는 쿼리를 실행가능한 쿼리 fragment들로 컴파일하고 GTM은 실행을 위해 적절한 노드(들)로 분배한다.
중간 결과가 나오면 GTM에 반환한다.
모든 쿼리 fragments들이 성공적으로 실행되면, GTM은 결과를 finalize하고
client 혹은 application 혹은 사용자에게 그 결과를 반환한다.

Rebalancer

ClustrixDB의 데이터가 이전에 클러스터 전체에 분배되지 않았다면, 분배 프로세싱은 불가능하거나 필요하지 않다.
이를 위해 ClustrixDB는 Rebalancer에 의해 관리되는 전매 특허의 데이터 분배 방법을 사용한다.
Rebalancer는 크러스터 내 데이터를 정렬해 read/write가 항상 균형을 유지하도록 한다.
또한 내결함성을 보장하기 위해 클러스터 전체에 여러 데이터 사본(replica)을 유지관리한다.
만약 노드가 예상치 못한 실패로 인해 손상되어도 데이터의 손실은 없다.
Rebalancer가 알아서 replica가 생성 및 유지되도록 자동으로 보장 한다.
또한 데이터베이스가 온라인 상태를 유지하는 동안 데이터가 추가될 새로운 노드로의 데이터를 리밸런싱하고,
제거할 노드에서 데이터를 옮김으로써 클러스터의 사이즈 변경을 수용한다.

Rebalancer는 컨시스턴트 해싱 알고리즘을 사용해 각 테이블 row를 해당 테이블의 주어진 slice로 할당하고,
모든 slice 맵을 모든 노드로 제공한다.
이를 통해 ClustrixDB가 관련된 데이터의 위치를 빠르고 쉽게 확인할 수 있다.
Rebalancer는 진행중인 production processing을 방해하는 일 없이 백그라운드에서 지속적으로 실행된다.

데이터가 sliced되고 클러스터의 수많은 노드에 분산되지만 데이터베이스 테이블은 항상 애플리케이션 상에서
single logical unit으로 나타난다.
Clustrix는 간단한 SQL 인터페이스를 사용하고, 분산 데이터에 액세스하기 위해 특별한 애플리케이션 프로그래밍도 필요하지 않다.

Sierra Database Engine

Sierra는 쿼리 플래닝과 실행을 처리하는 ClustrixDB의 SQL 엔진이다.
Sierra는 분산된 shared-nothing 환경에서 수행할 수 있도록 특별하게 설계되었다.
분산된 데이터에 대한 수행을 최대한 효율적으로 수행할 수 있다.
Sierra DB 엔진은 다음 두 가지 파트를 포함한다.

• Sierra Parallel Planner(병렬 플래너)는 SQL statement의 최적 수행 플랜을 결정한다.
  
• Sierra Distributed Execution Engine(분산 실행 엔진)은 이러한 계획을 기반으로 쿼리 fragment들을 실행하고
  중간 결과를 제공한다.
  

Sierra Parallel Planner

Sierra Parallel Planner는 확률 통계, 데이터 볼륨,
인덱스 및 쿼리 연산의 오버헤드를 사용해 가장 효율적인 쿼리 플랜을 결정하는 cost-based 옵티마이저이다.
이 Sierra Parallel Planner의 주요 차별화된 특징은 클러스터 전체의 데이터 분배를 고려하며
이 플랜을 결정하는 데에 있다.

Sierra Distributed Execution Engine

Sierra Planner가 최적의 쿼리 플랜을 결정하면, 이 플랜은 machine-executable 쿼리 fragment들로 컴파일된다.
이러한 컴파일된 쿼리 fragment들은 클러스터 내의 다른 노드들 간 실행되고, 효율성과 실행 동시성이 상승한다.
각각의 노드 실행이 완료되면 그 결과가 GTM 노드에 반환되고, 부분 결과들을 종합해 최종 결과 셋을 사용자에게 반환한다.

aggregate 수행 또한 분산된다.
계산은 부분 aggregate( SUM, MAX, MIN, AVG 등 )가 먼저 계산된다는 점을 제외하고
다른 쿼리들과 동일하게 fragmented되고 분산된다.
중간 결과는 GTM에 의해 통합되어 최종 결과를 생성한다.

Conclusion

ClustrixDB는 자동 데이터 분산, 정교한 쿼리 플래너 및 분산 실행 모델을 사용해 ACID 호환 RDBMS에서
확장성(Scalability), 동시성(Concurrency)를 제공한다.

이를 달성하기 위해 ClustrixDB는 다른 MPP( Massively Parallel Processing ) DB에서 사용하는 많은 기술들을 사용한다.
분산 트랜잭션을 해결하기 위해 Paxos를 사용하고, MVCC를 사용해 트랜잭션 충돌을 방지한다.

설명한 주요 구성 요소를 통해 ClustrixDB는 분산 실행에 간단한 SQL 인터페이스를 제공하며 동시에
확장성, 효율성, 내결함성을 제공한다.

4. Architecture

Data Distribution

• Representation

• Slice

• Replica

Consistency

ClustrixDB는 다음과 같은 일관성 접근을 취한다.

• 복제의 동기화
  파티셔닝된 모든 노드들은 before/after acknowledge를 제공하며, 쓰기작업은 병렬적으로 수행된다.
• Paxos 프로토콜이 분산 트랜잭션 해결에 사용된다.
• read에 lock이 없는 MVCC 지원

Paxos 프로토콜

신뢰할 수 없는 프로세서들의 네트워크에서 합의 문제를 해결하기 위한 프로토콜 그룹

Concurrency Control

ClustrixDB는 MVCC와 2 Phase Locking으로 데이터를 관리한다.

• Visibility Rules
  • xid : 트랜잭션 스타트 id
  • iid : 호출 시작 id
  • cid : 커밋 id

즉, insert의 cid보다 iid나 xid가 높으면 해당 insert 내용을 볼 수 있다.

Fault Tolerance

• Built-in Fault Tolerance : 모든 데이터는 2개 이상 복제본을 유지하므로 자동으로 복구가 가능하다.
• Deploying Across Zones : 복제본을 다른 zone( AWS Availability Zones, 다른 server rack, 다른 네트워크, 파워소스 등 )
  에 구성해 결함을 방지할 수 있다.
• Using Replication : disaster 복구 사이트를 설정해 치명적인 오류를 복구할 수 있다.
• MAX_FAILURES : 복제할 replica 갯수를 설정할 수 있다.

Rebalancer

Rebalancer는 클러스터의 healthy한 데이터 분배를 유지보수 하는 자동 시스템이다.
주 용도는 "unhealthy"한 데이터 respond에 대한 modify이다.

• Healthy Cluster
  • 적절한 수의 slice를 가진 representation
  • 저장 장치에 잘 분배된 Replica
  • decommissioned 노드에 대해 배치하지 않는 Replica

• 다양한 데이터에 대한 처리
  • 초기 데이터 : 노드에 일률적으로 slice 데이터들을 분배
  • 데이터 증가 : 큰 slice 데이터를 작은 slice로 분할 및 분배
  • Flex Up/Down : 노드 추가/삭제에 따라 slice 데이터 재분배
  • 노드 손상시 : 손상된 노드의 slice 데이터 복제를 통해 손실노드 데이터 재보호
  • 데이터 몰림(Skewed Data) : 각 노드에 균일하게 재배포
  • 자주 사용되는 데이터 : 빈번한 요청이 있는 slice 데이터를 찾아 노드간 재분배

• Flex up 노드 분배 예시

before

after

5. Why we use ClustrixDB?

ClustrixDB는 여러 서버를 결합하여 강력한 단일 데이터베이스 서버로 만든다.
애플리케이션을 수정하면서까지 샤딩이나 복제를 하기 싫을 때 사용할 수 있다.
기본적으로 데이터베이스 확장에 대해서 다음과 같은 작업들이 필요하다.

• 더 큰 서버
• 동기/비동기 복제 클러스터
• 데이터베이스 샤딩

하지만 ClustrixDB는 복제(Replication) 또는 샤딩(Sharding) 없이 확장할 수 있다.

• 읽기/쓰기/저장 확장성
• App 변경 없음
• 자동 HA
• 쉬운 설치

마침.