‘질문 12개로 구성한’ 데이터베이스 선택 가이드

데이터베이스를 선택할 때 고려해야 할 중요한 질문은 다음과 같다.

– 애플리케이션이 성숙했을 때 얼마나 많은 데이터를 저장할 것으로 예상되는가?
– 첨두 부하(peak load)에서 동시에 몇 명의 사용자를 처리할 것으로 예상되는가?
– 애플리케이션에 필요한 가용성, 확장성, 지연 속도, 처리량, 데이터 일관성은 어느 정도인가?
– 데이터베이스 체계(schemas)는 얼마나 자주 바뀔 것인가?
– 사용자 인구의 지리적 분포는 어떠한가?
– 자연스러운 데이터의 ‘형태’는 무엇인가?
– 애플리케이션은 OLTP, OLAP 중 어떤 것을, 또는 모두를 필요로 하는가?
– 현실 속에서 기대하는 쓰기 대비 읽기의 비율은?
– 지리적 쿼리(Query) 또는 전체 텍스트 쿼리가 필요한가?
– 선호하는 프로그래밍 언어는 무엇인가?
– 예산이 있는가? 그렇다면 라이선스 및 지원 계약까지 포함시킬 수 있는가?
– 데이터 저장소에 대한 법적 한계가 있는가?

이 질문들의 의미를 살펴본다. 
 

어느 정도의 데이터를 저장할 것인가?
기가바이트 단위 이하의 수준으로 예상된다면 거의 모든 데이터베이스가 문제되지 않으며, 인-메모리 데이터베이스도 충분히 적용 가능하다. 테라바이트(Terabyte, 수천 기가바이트) 범위의 데이터베이스를 처리할 수 있는 데이터베이스 옵션도 많다.

페타바이트(Petabyte, 수백만 기가바이트) 이상의 수준이라면 사용할 수 있는 데이터베이스가 몇 개 없으며 구내 스토리지를 위한 자본 지출이나 클라우드 스토리지를 위한 운영 지출 등 상당한 데이터베이스 저장 비용에 대비해야 한다. 

이런 규모에서는 ‘라이브’ 데이터에 대한 쿼리는 속도를 위해 인-메모리나 로컬 SSD로 실행하고 전체 데이터 세트는 경제성을 위해 회전식 디스크에 보관하는 식의 단계화된 저장소 구조가 필요할 수 있다.

동시 사용자는 몇 명인가?
동시 사용자로부터 발생하는 부하를 추정하는 작업이 데이터베이스를 설치하기 직전에 서버 규모 설정 연습으로 치부되는 경우가 많다. 안타깝게도 많은 데이터베이스가 확장 문제를 가진다. 테라바이트 또는 페타바이트 단위의 데이터를 쿼리 처리하는 수천 명의 사용자를 처리할 수 없는 것이다.

동시 사용자를 예측하는 작업은 직원들이 사용하는 데이터베이스일 경우 훨씬 쉽다. 공개 데이터베이스의 경우 예상치 못하거나 계절적인 부하를 위해 여러 서버로 확장할 수 있는 옵션이 있어야 할 수 있다. 안타깝게도 대형 테이블의 수동 샤딩(sharding) 없이 수평적으로 확장할 수 있도록 지원하는 데이터베이스는 일부에 그친다. 

‘성격(-ility)’ 요건은 무엇인가?
가용성(availability), 확장성(scalability)과 같은 요건을 의미한다.  ‘성(-ility)’으로 끝나지 않는 레이턴시, 쓰루풋, 데이터 일관성(data consistency) 요건도 여기에 포함된다. 

가용성은 트랜잭션 데이터베이스의 핵심 기준인 경우가 많다. 모든 애플리케이션이 99.999%의 24/7 가용성이 필요한 것은 아니지만 그런 것들도 있다. 일부 클라우드 데이터베이스는 여러 가용성 구역에서 운영하는 한 ‘파이브 나인’(99.999%) 가용성을 제공한다. 구내 데이터베이스는 일반적으로 예약된 유지보수 기간 외에 높은 가용성에 맞추어 구성할 수 있으며, 활성-활성 서버쌍을 구성할 수 있다면 더욱 그렇다.

확장성, 특히 수평적 확장성은 역사적으로 NoSQL 데이터베이스가 SQL 데이터베이스보다 좋았다. 그러나 많은 SQL 데이터베이스가 따라잡고 있다. 동적 확장성은 클라우드에서 훨씬 쉽게 달성할 수 있다. 확장성이 좋은 데이터베이스는 부하 대비 처리량이 충분해질 때까지 확장함으로써 많은 동시 사용자를 처리할 수 있다.

레이턴시는 데이터베이스의 응답 시간과 애플리케이션의 E2E 응답 시간 모두를 의미한다. 모든 사용자 동작이 1초 미만의 응답 시간을 갖는 것이 이상적이며, 이를 위해서는 데이터베이스가 각각의 단순한 트랜잭션에 100밀리초 미만의 속도로 반응해야 하는 경우가 많다. 분석 쿼리는 수 초 또는 수 분이 소요될 수 있다. 애플리케이션은 복잡한 쿼리를 백그라운드로 수행하여 응답 시간을 아낄 수 있다.

OLTP 데이터베이스의 처리량(Throughput)은 일반적으로 초당 트랜잭션으로 측정된다. 처리량이 높은 데이터베이스는 많은 동시 사용자를 지원할 수 있다.

일반적으로 데이터 일관성은 SQL 데이터베이스에 ‘강력하다.’ 모든 읽기에서 최신 데이터가 반환된다. 데이터 일관성은 NoSQL 데이터베이스의 경우 ‘최종적’인 것부터 ‘엄격한’ 것까지 무엇이든 될 수 있다. 이벤트적 일관성(Eventual consistency)은 지연 속도를 낮추는 대신에 오래된 데이터를 읽을 위험이 있다.

한편 일관성은 오류, 네트워크 파티션, 정전 발생 시 유효성을 위해 필요한 ACID 속성 중 ‘C’에 해당된다. 4개의 ACID 속성은 Atomicity(원자성), Consistency(일관성), Isolation(고립), Durability(내구성)이다.

데이터베이스 체계는 안정적인가?
데이터베이스 체계가 시간이 지나도 크게 바뀔 가능성이 없고 대부분의 필드에서 레코드 간에 일관된 유형이 있기를 원한다면 SQL 데이터베이스가 좋은 선택일 것이다. 그렇지 않으면 (일부는 스키마를 지원조차 하지 않지만) NoSQL 데이터베이스가 애플리케이션에 더 좋을 수 있다. 하지만 예외가 있다. 예를 들어, 록셋(Rockset)의 경우 가져오는 데이터에 고정된 스키마나 일관된 유형을 부여하지 않고 SQL 쿼리가 가능하다.

사용자의 지리적 분포
데이터베이스 사용자가 모두 전 세계에 퍼져 있을 때 해당 지역에 추가적인 서버를 제공하지 않는 한 원격 사용자의 데이터베이스 레이턴시 한계가 설정된다. 빛의 속도 때문이다. 일부 데이터베이스는 분산형 읽기-쓰기 서버를 허용하며, 분산형 읽기 전용 서버를 제공하고 모든 쓰기는 단일 마스터 서버를 통하도록 강제하는 것들도 있다. 지리적 분포 때문에 일관성과 레이턴시도 사이의 균형이 더 어려워진다.

전 세계적으로 분산된 노드와 엄격한 일관성을 지원하는 대부분의 데이터베이스는 일반적으로 팍소스(Paxos, 램포트(Lamport), 1990년) 또는 라프트(Raft, 온가로(Ongaro) 및 오스터하우트(Ousterhout), 2013년) 알고리즘을 사용하여 일관성을 크게 훼손하지 않으면서 쓰기 속도를 높이기 위해 컨센서스 그룹을 사용한다. 

궁극적으로 일관된 분산형 NoSQL 데이터베이스는 일반적으로 비 컨센서스 P2P 중복을 사용하며, 이 때문에 2개의 복제본이 같은 레코드에 대한 동시 쓰기를 수신할 때 충돌이 발생할 수 있다. 이 충돌은 일반적으로 발견적으로(heuristically) 해결된다.

데이터 형태
SQL데이터베이스는 전통적으로 엄격한 유형의 데이터를 열과 행이 있는 사각형의 테이블에 저장한다. 이것들은 테이블들 사이에 정의된 관계에 의존하며 색인을 사용하여 선택된 쿼리의 속도를 높이고 JOINS를 사용하여 여러 테이블을 한 번에 쿼리 처리한다. 

문서 데이터베이스는 일반적으로 어레이와 내포 문서가 포함될 수 있는 주간 유형의 JSON을 저장한다. 그래프 데이터베이스는 결절점과 엣지(Edge) 또는 트리플(Triple)이나 쿼드(Quad)를 저장한다. 다른 NoSQL 데이터베이스 카테고리로는 키 값 및 칼럼식 스토어가 있다.

때로는 데이터가 하나의 형태로 생성되고 분석에도 사용할 수 있지만, 때로는 그렇지 않아 변환이 필요할 수 있다. 때로는 한 종류의 데이터베이스가 다른 종류의 데이터베이스 위에 구축된다. 예를 들어, 키 값 스토어는 거의 모든 종류의 데이터베이스의 기저를 이룰 수 있다.

OLTP, OLAP, HTAP?
상기 약어를 제대로 정리하려면 애플리케이션에 트랜잭션, 분석 또는 둘 모두를 위한 데이터베이스가 필요한지 고민해야 한다. 빠른 트랜잭션이 필요하면 빠른 쓰기 속도와 최소한의 색인이 필요하다. 분석이 필요하면 빠른 읽기 속도와 많은 색인이 필요하다.

하이브리드 시스템은 다양한 트릭을 이용해 두 요건을 뒷받침하며, 여기에는 복제를 통해 제2 분석 스토어에 공급하는 제1 트랜잭션 스토어를 확보하는 것도 포함된다.

읽기/쓰기 비율
일부 데이터베이스는 읽기 및 쿼리 속도가 빠르고 쓰기가 빠른 것들도 있다. 애플리케이션에서 기대되는 읽기 및 쓰기의 조합은 데이터베이스 선택 기준에 포함시키기에 유용한 수치이며 벤치마크 노력의 기준이 될 수 있다. 

최적의 색인 유형 선택은 읽기 특화 애플리케이션(일반적으로 B 트리)과 쓰기 특화 애플리케이션(LSM(Long-Structured Merge) 트리인 경우가 많음) 사이에서 달라진다.

지리공간 색인 및 쿼리
지리적 또는 기하학적 데이터가 있고 경계 안의 객체 또는 한 위치의 주어진 거리 안에서 객체를 찾기 위해 효율적인 쿼리를 수행해야 하는 경우 일반적인 관계형 데이터와 비교하여 다른 색인이 필요하다. 

지리공간 색인에는 R-트리를 선호하는 경우가 많지만 수십 가지의 다른 지리공간 색인 데이터 구조가 존재한다. 공간 데이터를 지원하는 수십 가지의 데이터베이스가 존재하며, 대부분은 OGC(Open Geospatial Consortium) 표준의 일부 또는 전부를 지원한다.

전체 텍스트 색인 및 쿼리
마찬가지로 효율적인 텍스트 필드의 전체 텍스트 검색을 위해서는 관계형 또는 지리공간 데이터와는 다른 색인이 필요하다. 일반적으로 토큰화된 단어의 역전(inverted) 목록 색인을 구축해 이를 검색하도록 함으로써 값비싼 테이블 스캔을 피한다.

선호하는 프로그래밍 언어
대부분의 데이터베이스는 많은 프로그래밍 언어의 API를 지원하지만 때로는 애플리케이션에서 선호하는 프로그래밍 언어가 데이터베이스 선택에 영향을 끼칠 수 있다. 예를 들어, JSON은 자바스크립트를 위한 자연스러운 데이터 형식이기 때문에 자바스크립트 애플리케이션을 위해 JSON 데이터베이스 유형을 지원하는 데이터베이스를 선택할 수 있다. 엄격한 유형의 프로그래밍 언어를 사용하는 경우 엄격한 유형의 데이터베이스를 선택할 수 있다.

예산 제약
데이터베이스는 무료도 있지만 매우 비싼 것도 있다. 많은 데이터베이스가 무료 및 유료 버전을 모두 가지고 있으며, 때로는 기업용 버전과 다른 서비스 응답 시간을 제공하는 등 유료 제품의 레벨이 하나 이상인 경우도 있다. 또한 일부 데이터베이스는 클라우드에서 종량제 조건으로 이용할 수 있다.

무료 오픈소스 데이터베이스를 선택하는 경우 벤더 지원을 포기해야 할 수 있다. 자체적인 전문지식이 있는 경우 괜찮을 수 있다. 한편, 직원들이 애플리케이션에 더욱 집중하고 데이터베이스 관리 및 유지보수는 벤더나 클라우드 제공자에게 맡겨 두는 것이 더욱 생산적일 수 있다.

법적 한계
데이터 보안과 프라이버시에 대한 많은 법률이 있다. EU에서는 개인정보보호규정(GDPR)이 프라이버시, 데이터 보호, 데이터 위치에 광범위한 영향을 끼친다. 미국에서는 건강보험 양도 및 책임에 관한 법(HIPAA)에서 의료정보를 규제하며 그램-리치-블라일리 법(GLBA)은 금융기관들이 고객의 개인 정보를 처리하는 방식을 규제한다. 캘리포니아에서는 새로운 소비자 개인정보 보호법(CCPA)이 프라이버시 권리 및 소비자 보호를 강화한다.

일부 데이터베이스는 모범 사례를 준수하는 한 이런 규정의 일부 또는 전부를 준수하는 방식으로 데이터를 처리할 수 있다. 그러나 내재적 결함이 있어 아무리 주의해도 개인 식별 정보에 사용하기 어려운 데이터베이스도 존재한다. 

사실 데이터베이스를 제대로 선택하기란 어렵다. 생각하는 것보다 많은 요소를 고려해야 한다. 그럼에도 불구하고 프로젝트에 부적절하거나 과도하게 비싼 데이터베이스를 적용하는 위험을 피해야 한다. 적어도 이 모든 질문에 답할 만한 가치가 있다. 

* 인포월드 기고 편집자이자 리뷰어인 Martin Heller는 웹 및 윈도우 프로그래밍 컨설턴트 경력을 보유자다. 1986년부터 2010년까지는 데이터베이스, 소프트웨어, 웹사이트 개발자로 일했으며 그 이후에는 알파 소프트웨어의 기술 및 교육 부사장, 튜브파이의 의장이자 CEO를 역임했다. dl-ciokorea@foundryco.com