Posting

Machbase의 최신 소식을 지금 만나보세요

In memory cluster DBMS에 대해서

개요

마크베이스 CTO 심광훈

마크베이스는 다양한 형태의 테이블을 지원하는데, 메모리 상주형 테이블로는 Lookup table과 volatile table이 있습니다. Volatile table은 스키마의 경우 디스크에 저장되고,  데이터는 메모리에 저장하기 때문에 서버 종료시에는 모드 데이터가 삭제됩니다. 반면,   Lookup table은  스키마와 데이터가 모두 디스크에 보과되고, 성능을 위해  모든 데이터가 메모리에 다시 적재되는 특성이 있습니다.  따라서, 서버 종료시에도 데이터가 모두 보존이 됩니다.

마크베이스 클러스터 버전에서 이 두가지의 테이블을 지원하지만, 몇몇 제약사항이 있습니다. 즉,  마크베이스는 Lookup 테이블은  2대의 broker 노드 간에 복제를 통하여 공유되며,  volatile table은 복제하거나 공유되지 않습니다. 

이렇게  In memory 형태의 테이블을 여러 노드에서 공유하고, 동일한 복제본을 유지하는 것과, 노드 추가시에 성능이 증가하도록 하며, 다중 노드의 In memory 데이터들이 일관성을 유지하는 것에 어떤 어려움이 있는지 이 문서에서 살펴 보겠습니다.

In memory & scale-out

In memory 데이터베이스는 모든 데이터가 메모리에 존재하고, 데이터에 대한 삽입, 갱신, 삭제는 메모리에 존재하는 데이터를 가공함으로써 디스크에 기반한 DBMS보다 빠른 성능을 얻을 수 있습니다.

단점으로는 데이터 입력 및 갱신시에 로그를 남겨야 하기 때문에(In memory dbms라도 로그를 기록해서 ACID transaction을 지원합니다.) 메모리 캐쉬가 충분한 RDBMS보다 갱신 및 삽입. 삭제 연산이 생각보다 빠르지 않고,  시스템 메모리의 크기 이하의 데이터만을 저장할 수 있으며, HA를 위한 복제는 가능하지만, 노드 추가를 통한 Scale-out에는 한계가 있다는 점입니다.

다음의 문제점을 살펴보도록 합니다.

  • HA를 위한 복제(Replication) 
  • Sharding 등 분산 저장

HA를 위한 복제

In memory DBMS가 고가용성을 유지하는 방법은 복제(Replication)가 대표적입니다. 두대 이상의 노드에서 데이터를 복제하여 동일한 데이터를 유지한다면 노드 하나에 장애가 발생하더라도 데이터는 유지가 가능합니다. 대부분의 In-memory DBMS는 복제 기능으로 고가용성을 지원합니다.

그러나 복제를 이용한 고가용성은 다음의 문제가 있습니다.

  • 복제를 이용한 클러스터는 확장성이 없다.
  • 단일 노드에 비해서 검색성능은 향상될 수 있으나 입력/삭제/갱신 성능은 저하된다.

각 문제점에 대해서 좀 더 자세히 살펴봅시다.

복제시 확장성 없음

모든 데이터가 메모리에 존재하는 In memory DBMS에서 아무리 많은 노드를 클러스터에 투입하더라도 모두 동일한 데이터를 복제합니다. 단일 노드의 메모리 이상의 데이터를 저장할 수 없습니다. In memory DBMS의 가장 큰 문제점인 메모리 사용량에 의한 DB 사이즈 제약조건을 해결할 수 없습니다.

성능 저하

각 복제 노드가 master노드의 데이터를 일관성 있게 복제하기 위해서 master 노드는 복제 노드에 데이터가 전송된 것을 확인해야 합니다. 만약 데이터의 전송 및 반영을 확인하지 않고 갱신, 입력, 삭제를 진행하면 데이터의 불일치가 발생합니다. 이때, 복제 노드에서 읽기 연산을 수행하면 데이터베이스의 일관성이 훼손되게 됩니다.

일반적으로 복제를 진행하는 원본 노드(master node)는 대량으로 입력되는 데이터 갱신 요청(insert/update/delete)을 로그를 통한 복제등의 기법을 이용하여 복제 대상 노드에 전달합니다. 이때 복제를 위해서 사용되는 cpu와 네트워크 대역폭 사용량에 의하여 master node의 성능이 느려지게 됩니다.

<복제시 데이터 입력 시퀀스 다이어그램>

이와 같은 문제를 살펴보면, In memory dbms를 위해서 복제를 이용하면 HA만 가능하고 용량 / 성능의 확장은 불가하다는 것을 알 수 있습니다.

Sharding등 분산 저장

Scale-out을 해결하기 위해서 각 분산 노드는 일부분의 데이터만을 저장하고, 데이터 검색시 분산 노드들이 각기 유지하고 있는 데이터를 이용하여 검색을 수행하는 방법이 있습니다. 이 방법은 단일 노드의 메모리 한계를 벗어나 대량의 데이터를 In-memory로 유지하는 유일한 방법으로 In memory의 고성능과 확장 가능성을 갖고 있는 좋은 방법 처럼 보입니다. 

이 모델의 장 단점을 한번 확인해 봅시다.

  • Scale out 이 가능하다. 노드를 추가하면 단일 노드의 In memory한계를 확실히 벗어날 수 있다.
  • 단일 노드보다 검색 성능이 떨어질 수 있다.
  • 갱신 / 삭제 / 삽입시 단일 노드보다 성능이 감소한다.

Scale out이 가능한 것은 각 분산 노드가 데이터를 각각 저장하고 있고, 노드가 많아지면 전체 노드의 메모리 크기 만큼 저장 공간이 증가하므로 용량 증가가 이루어진다는 점에서 아무런 문제가 없습니다.

하지만 단일 노드에 비해 성능이 증가하지는 못합니다. 이유를 살펴보겠습니다.

검색 성능

In memory DBMS에서 모든 데이터는 메모리에 존재하므로, 색인을 통한 검색이든, full-scan을 통해서 순차 접근을 하든 간에, 데이터를 접근하는데 있어서 cpu의 레지스터나 캐쉬 다음으로 빠른 속도를 얻을 수 있습니다. 그러나 분산 저장을 이용한 클러스터에서 다른 노드에 저장되어 있는 데이터를 접근하려면 반드시 네트워크를 통해서 그 데이터를 전송받아서 처리할 수 밖에 없습니다. 두 노드는 데이터 요청/결과 전달을 위해 네트워크 전송이 필요하며 이는 반드시 메모리 접근에 비해 상당히 큰 지연시간을 발생시킵니다.

순차적 데이터 접근시에는 대역폭이 문제가 됩니다. 네트워크 대역폭이 지속적으로 증가하였지만, 메모리의 순차접근 대역폭은 네트워크 대역폭보다 항상 더 큽니다.

따라서, 단일 서버에서 질의를 수행하는 것 보다 단순 검색시에는 성능이 저하될 수 있습니다. 물론 Hadoop의 Map-reduce기법과 MPP기법등으로 대량 데이터의 집합 연산이나 병렬 스캔 연산이 있어서 대량 통계 데이터 검색 등은 상황이 다릅니다만, “PK를 이용하여 데이터 한건을 찾는다. ” 와 유사한 시나리오에서는 성능이 느려질 수 밖에 없습니다. Foreign key constraint나 join 등의 연산, PK혹은 Unique 제약조건의 검사등에서 이와같은 연산은 자주 실행되는 연산이므로 검색성능은 특정한 경우에 대해서는 단일 노드에 비해 느려질 가능성이 있습니다.

갱신/삽입/삭제

In memory DBMS에서 갱신, 삽입, 삭제시에 레코드에 대한 로킹, 갱신. 삽입, 삭제에 대한 로그 등은 디스크에 기록합니다. 다만, 갱신이나 삽입시에 실제 데이터 파일에 접근하지 않고 상대적으로 빠른 로그만 디스크에 기록하므로 디스크 기반 DBMS보다 빠르게 동작합니다.

이때 다중 노드 클러스터가 도입되면 상황은 복잡해 집니다. 특정 노드에 있는 데이터를 업데이트하는 시나리오에서, 그 데이터에 대한 배타적 잠금을 수행하고, 데이터를 업데이트하고, 잠금을 해제하는 연산이 필요합니다. 단일 노드에서는 이는 비교적 쉽게 수행되었으나, 잠금, 갱신, 잠금 해제를 네트워크를 통해서 수행하는 환경에서는 검색과 유사하게 갱신성능이 네트워크를 통해 전달되기 때문에 상당히 느려집니다.

삽입 및 삭제시에도 해당 데이터를 읽고 있는 다른 트랜잭션이 있는 경우, 이를 일관성 있는 연산으로 수행하기가 어렵습니다.

NoSQL 기반 In memory cluster

SQL의 정확하고 구현하기 힘든 기능들을 제외하고, 단순한 사용방법으로 Scale out 문제를 해결하고자 나온 것이 NoSql입니다. In memory DBMS이외에도 SQL을 지원하지 않지만 데이터 처리에 사용할 수 있으며, 검색성능이 매우 빠른 제품으로 memcached등의 제품이 있습니다. 이 memcached는 scale out이 가능하지 않아서 scale out 가능한 제품들이 개발되었는데 최근 가장 넓게 쓰이는 제품은 redis인 것 같습니다.

Redis등의 제품은 KV store(Key value store)라고 합니다. key값을 주면 해당 키값을 갖는 data를 주는 형태입니다. 복잡한 질의조건, join등이 없으나 모든 데이터가 메모리에 적재되어 있고, 이때 key를 사용한 검색은 SQL의 복잡한 과정을 건너뛸 수 있어서 매우 빠릅니다. 물론, 복잡질의, 통계 질의, 복잡한 조건을 이용한 검색등을 이용하려면 사용자가 직접 코딩을 해야 해서 편의성은 낮지만, 기능을 축소해서 scale out을 얻었습니다.

결론

마크베이스에서는 단순 참조용으로 제공하고 있는 lookup table등의 in memory table을 이와같은 기술적인 한계를 참고하여 클러스터 환경에서도 모든 노드에서 접근할 수 있으며 빠른 검색 성능을 얻을 수 있는 복제 가능한 메모리 테이블을 개발하고 있습니다. 성능과 확장성, 고가용성을 동시에 만족시키기 어려운 in memory cluster를 어떻게 구현할 것인지를 마크베이스에서는 연구하고 있습니다.

이후 개발할 machbase cluster에서는 이러한 문제를 모두 해결할 참조 테이블 기능을 지원할 예정입니다.

연관 포스트

Deep Anomaly Detection in Time Series (2) : 이상 감지 모델

개요 안녕하세요, 마크베이스의 Cloud개발본부 연구원 양창은입니다. 지난 게시글 Deep Anomaly Detection in Time Series (1) : Time Series Data에서는 시계열 데이터와 이상치(Anomaly)의 종류에 대해 알아보았습니다. 그리고

IIoT를 위한 Data Lake – machlake

Data Lake 란, 대규모의 다양한 원시 데이터 세트를 기본 형식으로 저장하는 데이터 리포지터리 유형입니다. 원시 데이터는 특정 목적을 위해 처리되지 않은 데이터를 뜻합니다. 산업 IoT