2020.03.30

마이SQL을 쓰긴 애매할 때…'틈새' 데이터베이스 9가지

Serdar Yegulalp | InfoWorld
데이터베이스가 필요하다면 보통은 마이SQL(MySQL), 마리아DB(MariaDB), 포스트그레SQL(PostgreSQL), SQL라이트(SQLite), 몽고DB(MongoDB)와 같은 것 중 하나를 선택하면 된다. 그러나 이와 같은 '팔방미인형' 데이터베이스로 부족할 때가 있다. 어느 쪽을 선택하기도 애매한, 중간에 위치한 용도로 사용하기 위해 더 특화된 데이터베이스가 필요한 경우다. 메모리 분석부터 키-값 저장소와 시계열 시스템까지 다양한 분야에서 쓰이는 9가지 색다른 데이터베이스를 알아보자.
 
ⓒ Getty Images Bank
 

덕DB

'SQL OLAP 시스템'이라고 하면 보통 거대한 데이터 크런칭 시스템이나 끝없이 뻗어 있는 데이터 웨어하우스 클러스터가 연상된다. 분석 데이터베이스에 대한 덕DB(DuckDB)의 성격은 마이SQL과 포스트그레SQL에 대한 SQL라이트와 같다. 본격적인 OLAP 솔루션과 같은 수준의 규모로는 실행할 수 없지만 애초에 설계 목적은 로컬 데이터 집합에 대한 빠른 메모리 내 분석 처리를 제공하는 데 있다.

비록 규모는 더 작지만 덕DB 기능의 상당수는 대형 OLAP 제품의 기능에 대응한다. 데이터는 행이 아닌 열에 저장되고 쿼리 처리는 CPU 캐싱을 최대한 활용하기 위해 벡터화된다. 태블로(Tableau)와 같은 보고 솔루션에 대한 기본 연결은 지원하지 않지만 이러한 솔루션은 어렵지 않게 수동으로 실행할 수 있다. C++에 대한 바인딩 외에, 덕DB는 분석용으로 가장 일반적인 프로그래밍 환경인 파이썬과 R에 기본적으로 연결된다.
 

엣지DB

'엣지'는 그래프 데이터베이스에서 긴밀하게 연결된 데이터 집합의 두 개체 또는 노드 간의 연결이나 관계(예를 들어 고객과 주문, 또는 주문과 제품)를 지칭하는 용어다. 엣지DB(EdgeDB)는 포스트그레SQL 코어와 여기서 제공하는 모든 속성(예를 들어 ACID 트랜잭션과 고도의 안정성)을 사용해 강한 필드 유형, SQL과 비슷한 쿼리 언어가 있는 이른바 객체-관계 데이터베이스를 구축한다.

따라서 엣지DB는 NoSQL과 같은 사용 편의성과 직접성, 그래프 데이터베이스의 관계형 모델링 기능, SQL의 확실성과 일관성을 지원한다. 엣지DB는 공식적으로 문서 데이터베이스가 아니지만 문서 데이터베이스처럼 데이터를 저장하는 데 사용할 수 있다. 또한 네오4j(Neo4j)와 같은 네이티브 그래프 데이터베이스처럼 그래프QL(GraphQL) 쿼리 언어를 사용해 엣지DB에서 손쉽게 데이터를 불러올 수 있다.
 

파운데이션DB

애플이 선봉에 선 오픈소스 프로젝트인 파운데이션DB(FoundationDB)는 데이터를 내부에 키-값 쌍으로 저장하되(기본적으로 NoSQL 모델) 관계형 테이블, 그래프, 문서를 비롯한 다른 많은 데이터 구조로 체계화할 수 있는 '멀티 모델' 데이터베이스다. ACID 트랜잭션은 데이터 무결성을 보장하며 수평 확장과 복제를 기본적으로 지원한다. 다만 파운데이션DB의 설계에는 몇 가지 제한이 있다. 키, 값, 트랜잭션에는 모두 엄격한 크기 제한이 있으며 트랜잭션의 경우 시간제한도 적용된다.
 

하퍼DB

하퍼DB(HarperDB)의 목표는 구조적 데이터와 비구조적 데이터를 처리하는 단일 데이터베이스를 제공하는 것이다. 파운데이션DB와 같은 멀티 모델 데이터베이스와 데이터 웨어하우스 또는 OLAP 솔루션 사이에 있다고 보면 된다. 저장한 데이터는 중복 제거를 거쳐 SQL, NoSQL, 엑셀 등 사용자가 원하는 인터페이스를 통해 쿼리에서 사용할 수 있다. 태블로, 파워 BI와 같은 BI 솔루션은 데이터를 추출하거나 처리할 필요 없이 하퍼DB와 직접 통합이 가능하다. 기업용 에디션과 커뮤니티 에디션 2가지로 제공된다.
 

키DB

레디스(Redis)는 인기 있고 강력한 메모리 내 키-값 저장소이지만 떨어지는 스레드 성능과 사용 편의성 측면에서 비판을 받아왔다. 키DB(KeyDB)는 레디스와 프로토콜이 호환되므로 레디스의 대체재로 사용할 수 있다. 동시에 레디스에 비해 더 개선된 기능도 제공한다. 대표적으로 네트워크 I/O 작업과 쿼리 파싱을 위한 멀티스레딩이 있다. 레디스의 예정된 다음 에디션인 레디스 6에도 스레드 I/O가 포함되지만 키DB는 지금 바로 사용할 수 있다.
 

M3DB

우버(Uber)의 내부 엔지니어링 팀이 만든 M3DB는 우버의 메트릭스 플랫폼에 사용되는 분산 시계열 데이터베이스다(기본적으로 프로메테우스(Prometheus)용 데이터 저장소로 사용됨). 아파치 카산드라와 페이스북의 고릴라 프로젝트의 아이디어를 차용해, 임의 시간 정밀도, 비순차 삽입, 구성 가능한 복제 및 읽기 일관성 수준 등을 지원한다. 그러나 개발진에 따르면 전체 시계열 데이터베이스 사용 사례에는 적합하지 않을 수 있다. 예를 들어 M3DB는 주어진 시간대(기본 2시간) 외에는 비순차 데이터를 삽입할 수 없으며 다른 데이터보다는 주로 64비트 부동소수점을 저장하고 불러오는 데 최적화됐다.
 

레디SQL

이름에서 알 수 있듯이 레디스 메모리 내 키-값 저장소와 SQL 쿼리 기능을 혼합한 것이 바로 레디SQL(RediSQL)이다. 구체적으로 SQL라이트 데이터베이스를 내장한 레디스 모듈이다. 데이터는 레디스에서 투명하게 저장되며 레디스가 지속성과 메모리 내 처리를 담당한다. 각 데이터베이스는 레디스 키와 연결되므로 하나의 레디스 인스턴스에 여러 SQL 데이터베이스를 둘 수 있다. 이러한 데이터베이스에 대한 쿼리는 표준 SQL로, 표준 레디스 API를 통해 전달된다. 또한 레디스에서 구문(기본적으로 저장 프로시저)을 만들어 사전 컴파일해서 쿼리 실행 속도를 높일 수 있다. 상용 에디션과 오픈소스 에디션, 2가지로 제공된다.
 

RQ라이트

SQL라이트(SQLite)는 엄청나게 빠르고 안정적인 내장 가능한 오픈소스 데이터베이스라는 점에서 좋은 평가를 받고 있다. SQL라이트는 단일 사용자 애플리케이션에서 데이터베이스가 필요할 때 선택할 수 있는 훌륭한 방편이지만 SQL라이트 인스턴스는 단일 노드로 제한된다.

RQ라이트(RQLite)는 SQL라이트를 기반으로 해서 분산 데이터베이스 시스템을 구축한다. 여러 노드를 손쉽게 설정할 수 있으며, 데이터는 이러한 노드에 걸쳐 래프트(Raft) 합의 알고리즘을 사용해 자동으로 복제된다. RQ라이트는 노드와 검색(discovery) 서비스 간에 암호화를 제공해 자동 노드를 쉽게 추가할 수 있다. 그러나 RQ라이트에는 몇 가지 단점이 있다. 쓰기 속도가 SQL라이트에 비해 느리고 결정론적 SQL 함수, 즉 모든 노드에서 같은 결과를 보장하는 함수만 안전성을 보장한다.
 

움브라DB

요즘 대부분의 하이엔드 데이터베이스에는 테이블 핀(SQL 서버)과 같은 일종의 메모리 내 기능이 있다. 움브라DB(UmbraDB)는 포스트그레SQL 대용으로 사용할 수 있는 분석 데이터베이스로, 가능한 경우 항상 메모리 내 처리를 사용하도록 설계됐다. 사용할 수 없는 경우에는 독창적인 가변 크기 페이지 메커니즘을 사용해 스토리지의 데이터를 페이지화한다. 장기 실행 쿼리는 LLVM용으로 최적화된다. editor@itworld.co.kr


2020.03.30

마이SQL을 쓰긴 애매할 때…'틈새' 데이터베이스 9가지

Serdar Yegulalp | InfoWorld
데이터베이스가 필요하다면 보통은 마이SQL(MySQL), 마리아DB(MariaDB), 포스트그레SQL(PostgreSQL), SQL라이트(SQLite), 몽고DB(MongoDB)와 같은 것 중 하나를 선택하면 된다. 그러나 이와 같은 '팔방미인형' 데이터베이스로 부족할 때가 있다. 어느 쪽을 선택하기도 애매한, 중간에 위치한 용도로 사용하기 위해 더 특화된 데이터베이스가 필요한 경우다. 메모리 분석부터 키-값 저장소와 시계열 시스템까지 다양한 분야에서 쓰이는 9가지 색다른 데이터베이스를 알아보자.
 
ⓒ Getty Images Bank
 

덕DB

'SQL OLAP 시스템'이라고 하면 보통 거대한 데이터 크런칭 시스템이나 끝없이 뻗어 있는 데이터 웨어하우스 클러스터가 연상된다. 분석 데이터베이스에 대한 덕DB(DuckDB)의 성격은 마이SQL과 포스트그레SQL에 대한 SQL라이트와 같다. 본격적인 OLAP 솔루션과 같은 수준의 규모로는 실행할 수 없지만 애초에 설계 목적은 로컬 데이터 집합에 대한 빠른 메모리 내 분석 처리를 제공하는 데 있다.

비록 규모는 더 작지만 덕DB 기능의 상당수는 대형 OLAP 제품의 기능에 대응한다. 데이터는 행이 아닌 열에 저장되고 쿼리 처리는 CPU 캐싱을 최대한 활용하기 위해 벡터화된다. 태블로(Tableau)와 같은 보고 솔루션에 대한 기본 연결은 지원하지 않지만 이러한 솔루션은 어렵지 않게 수동으로 실행할 수 있다. C++에 대한 바인딩 외에, 덕DB는 분석용으로 가장 일반적인 프로그래밍 환경인 파이썬과 R에 기본적으로 연결된다.
 

엣지DB

'엣지'는 그래프 데이터베이스에서 긴밀하게 연결된 데이터 집합의 두 개체 또는 노드 간의 연결이나 관계(예를 들어 고객과 주문, 또는 주문과 제품)를 지칭하는 용어다. 엣지DB(EdgeDB)는 포스트그레SQL 코어와 여기서 제공하는 모든 속성(예를 들어 ACID 트랜잭션과 고도의 안정성)을 사용해 강한 필드 유형, SQL과 비슷한 쿼리 언어가 있는 이른바 객체-관계 데이터베이스를 구축한다.

따라서 엣지DB는 NoSQL과 같은 사용 편의성과 직접성, 그래프 데이터베이스의 관계형 모델링 기능, SQL의 확실성과 일관성을 지원한다. 엣지DB는 공식적으로 문서 데이터베이스가 아니지만 문서 데이터베이스처럼 데이터를 저장하는 데 사용할 수 있다. 또한 네오4j(Neo4j)와 같은 네이티브 그래프 데이터베이스처럼 그래프QL(GraphQL) 쿼리 언어를 사용해 엣지DB에서 손쉽게 데이터를 불러올 수 있다.
 

파운데이션DB

애플이 선봉에 선 오픈소스 프로젝트인 파운데이션DB(FoundationDB)는 데이터를 내부에 키-값 쌍으로 저장하되(기본적으로 NoSQL 모델) 관계형 테이블, 그래프, 문서를 비롯한 다른 많은 데이터 구조로 체계화할 수 있는 '멀티 모델' 데이터베이스다. ACID 트랜잭션은 데이터 무결성을 보장하며 수평 확장과 복제를 기본적으로 지원한다. 다만 파운데이션DB의 설계에는 몇 가지 제한이 있다. 키, 값, 트랜잭션에는 모두 엄격한 크기 제한이 있으며 트랜잭션의 경우 시간제한도 적용된다.
 

하퍼DB

하퍼DB(HarperDB)의 목표는 구조적 데이터와 비구조적 데이터를 처리하는 단일 데이터베이스를 제공하는 것이다. 파운데이션DB와 같은 멀티 모델 데이터베이스와 데이터 웨어하우스 또는 OLAP 솔루션 사이에 있다고 보면 된다. 저장한 데이터는 중복 제거를 거쳐 SQL, NoSQL, 엑셀 등 사용자가 원하는 인터페이스를 통해 쿼리에서 사용할 수 있다. 태블로, 파워 BI와 같은 BI 솔루션은 데이터를 추출하거나 처리할 필요 없이 하퍼DB와 직접 통합이 가능하다. 기업용 에디션과 커뮤니티 에디션 2가지로 제공된다.
 

키DB

레디스(Redis)는 인기 있고 강력한 메모리 내 키-값 저장소이지만 떨어지는 스레드 성능과 사용 편의성 측면에서 비판을 받아왔다. 키DB(KeyDB)는 레디스와 프로토콜이 호환되므로 레디스의 대체재로 사용할 수 있다. 동시에 레디스에 비해 더 개선된 기능도 제공한다. 대표적으로 네트워크 I/O 작업과 쿼리 파싱을 위한 멀티스레딩이 있다. 레디스의 예정된 다음 에디션인 레디스 6에도 스레드 I/O가 포함되지만 키DB는 지금 바로 사용할 수 있다.
 

M3DB

우버(Uber)의 내부 엔지니어링 팀이 만든 M3DB는 우버의 메트릭스 플랫폼에 사용되는 분산 시계열 데이터베이스다(기본적으로 프로메테우스(Prometheus)용 데이터 저장소로 사용됨). 아파치 카산드라와 페이스북의 고릴라 프로젝트의 아이디어를 차용해, 임의 시간 정밀도, 비순차 삽입, 구성 가능한 복제 및 읽기 일관성 수준 등을 지원한다. 그러나 개발진에 따르면 전체 시계열 데이터베이스 사용 사례에는 적합하지 않을 수 있다. 예를 들어 M3DB는 주어진 시간대(기본 2시간) 외에는 비순차 데이터를 삽입할 수 없으며 다른 데이터보다는 주로 64비트 부동소수점을 저장하고 불러오는 데 최적화됐다.
 

레디SQL

이름에서 알 수 있듯이 레디스 메모리 내 키-값 저장소와 SQL 쿼리 기능을 혼합한 것이 바로 레디SQL(RediSQL)이다. 구체적으로 SQL라이트 데이터베이스를 내장한 레디스 모듈이다. 데이터는 레디스에서 투명하게 저장되며 레디스가 지속성과 메모리 내 처리를 담당한다. 각 데이터베이스는 레디스 키와 연결되므로 하나의 레디스 인스턴스에 여러 SQL 데이터베이스를 둘 수 있다. 이러한 데이터베이스에 대한 쿼리는 표준 SQL로, 표준 레디스 API를 통해 전달된다. 또한 레디스에서 구문(기본적으로 저장 프로시저)을 만들어 사전 컴파일해서 쿼리 실행 속도를 높일 수 있다. 상용 에디션과 오픈소스 에디션, 2가지로 제공된다.
 

RQ라이트

SQL라이트(SQLite)는 엄청나게 빠르고 안정적인 내장 가능한 오픈소스 데이터베이스라는 점에서 좋은 평가를 받고 있다. SQL라이트는 단일 사용자 애플리케이션에서 데이터베이스가 필요할 때 선택할 수 있는 훌륭한 방편이지만 SQL라이트 인스턴스는 단일 노드로 제한된다.

RQ라이트(RQLite)는 SQL라이트를 기반으로 해서 분산 데이터베이스 시스템을 구축한다. 여러 노드를 손쉽게 설정할 수 있으며, 데이터는 이러한 노드에 걸쳐 래프트(Raft) 합의 알고리즘을 사용해 자동으로 복제된다. RQ라이트는 노드와 검색(discovery) 서비스 간에 암호화를 제공해 자동 노드를 쉽게 추가할 수 있다. 그러나 RQ라이트에는 몇 가지 단점이 있다. 쓰기 속도가 SQL라이트에 비해 느리고 결정론적 SQL 함수, 즉 모든 노드에서 같은 결과를 보장하는 함수만 안전성을 보장한다.
 

움브라DB

요즘 대부분의 하이엔드 데이터베이스에는 테이블 핀(SQL 서버)과 같은 일종의 메모리 내 기능이 있다. 움브라DB(UmbraDB)는 포스트그레SQL 대용으로 사용할 수 있는 분석 데이터베이스로, 가능한 경우 항상 메모리 내 처리를 사용하도록 설계됐다. 사용할 수 없는 경우에는 독창적인 가변 크기 페이지 메커니즘을 사용해 스토리지의 데이터를 페이지화한다. 장기 실행 쿼리는 LLVM용으로 최적화된다. editor@itworld.co.kr


X