데이터베이스란 무엇인가? 옛날 옛적에는 아주 간단한 것이었다. 데이터베이스는 항목당 한 개의 행으로 채워진 여러 개의 아주 깔끔한 열로 구성된 테이블에 데이터를 넣고 있는 현대판 밥 그래칫(스쿠루지에 나오는 박봉의 직원)이었다. 길고, 끝이 없는 정보의 사각형이 미래로 펼쳐지고 있다.
관계형 데이터베이스(Relational Database)는 현대 컴퓨팅의 기반이 되었다. 대부분 웹사이트는 단지 SQL 상부에 덧칠해진 한 묶음의 CSS에 불과하다. 우리를 특별하게 만드는 것은 커다란 삶의 테이블에 있는 또 다른 행일 뿐이다.
하지만 개발자들이 모든 것이 단순한 테이블에 적합하지 않다는 것을 알아채면서 수 많은 비트로 구성된 커다란 매트릭스와의 애정 행각도 서서히 시들고 있다. 그리고 개발자들은 똑똑하며 모든 필요사항에 대한 솔루션을 찾는 것에 강박을 가지고 있기 때문에, 정보를 저장하기 위한 새롭고 더 나은 장소를 만들기 시작했다. 이로 인해 지난 몇 년 동안 데이터를 저장하기 위한 다른 메커니즘이 우후죽순처럼 생겨났다.
이런 멋진 새 옵션들을 여전히 데이터베이스라 해도 될까? 데이터베이스이기 위해서는 데이터가 어떤 커다란 행렬에 꼭 들어 맞아야만 하는 건가? 일부에서는 “데이터베이스”란 용어가 우리 머릿속에는 과거의 테이블형 구조와 너무 밀접하게 연결되어 있기 때문에 최신 메커니즘을 차별화하기 위해서 “데이터 저장소(Data Store)”라는 용어를 쓰고 싶어한다. 이 문제는 철학자들에게 남기기로 한다. 데이터가 들어가면 답이 나오기 마련이다.
데이터베이스가 새로운 모양과 형태로 재탄생되는 8가지 방법을 살펴본다.
GPU 컴퓨팅
예전에는 아동용 게임을 위한 정교한 장면을 그리기 위해 비디오 카드가 제작되었지만, 지금은 소위 GPU(Graphics Processing Unit)라는 것이 비 그래픽 처리 작업에 더 많이 사용되고 있다. 데이터를 검색하는 것은 GPU가 처리할 수 있는 최상의 비 그래픽 작업 중 한 가지일 뿐이다. 이렇게 하지 않을 이유가 없다. 일치하는 것을 찾기 위해 무수한 자료 더미를 찾는 것은 근본적으로 수백만 번 반복되는 엄청난 수의 (같은 지를 시험하는) 기초적인 작업으로 이루어진 병렬 작업이다. 그렇기 때문에 작업을 GPU에 있는 수천 개의 프로세서로 넘기는 것은 아주 간단하다.
GPU 컴퓨팅의 가장 큰 이점은 각각의 쿼리(Query)에 답하는 것(확실히 몇 배는 더 빠르다)에 있는 것이 아니라 준비 작업에 있다. 별 다른 사전처리가 필요 없기 때문이다. 많은 데이터베이스가 인덱스를 유지함으로써 시간을 절약하고 있는데, 이는 실질적으로는 가능한 모든 검색에 대해 사전에 계산된 결과이다. 이 인덱스에 오류가 생기거나 잃어버리면, 인덱스를 재구축하는데 몇 시간, 며칠, 또는 심지어 몇 개월이 걸릴 수 있다. 그렇지만, 데이터를 GPU의 메모리 안에 넣을 수만 있다면, 대개는 인덱스 없이도 버텨낼 수 있다. 데이터가 빠르게 변경되거나 인덱스 대부분이 전혀 사용되지 않고 있다면, 사전처리를 생략하는 것이 매우 효율적이다.
보유하고 있는 데이터와 검색이 가속화될 수 있는지를 알아보려면 맵D(MapD), 키네티카(Kinetica), 브라이트라이트(Brytlyt)를 비롯한 다른 것들을 확인해보라.
VRAM(Non-volatile Memory, 비 휘발성 메모리)
50년 전에 경험을 쌓은 프로그래머들은 작업이 쉬웠다. 일관성을 보장하기 위해 정교한 프로토콜을 사용해서 데이터를 RAM과 디스크 간에 효율적으로 움직일 필요가 없었다. 당시의 메모리는 철로 된 코어였고 전원이 꺼져도 삭제되지 않았기 때문이다. 하지만 칩 제조업체들이 RAM을 NVRAM 혹은 비 휘발성 메모리로 대체하는 것에 대해서 논의하고 있기 때문에 그런 좋은 시절이 조만간 다시 올 수도 있다.
가장 커다란 난제 중 하나(그리고 더 나가서는 가장 큰 삶의 이유)가 없어지는 것이기 때문에 이는 데이터베이스 프로그래머들에게는 대단한 사건이다. 일부에서는 트랜잭션 시맨틱스(Semantics)가 더 간단해질 수 있기 때문에 데이터베이스가 훨씬 더 빨라질 수 있다고 말한다. 또 한편으로는 데이터가 매체에 기록되기 전이 아니라, 기록된 후에 복구 로그를 구축하자는 아이디어도 제시하고 있다.
결과가 어떻게 될지는 아무도 모른다. 영구 기록이 필요 없게 되어도 사람들이 여전히 데이터베이스를 사용하고 있을 것인가? 아니면 검색 작업과 인덱스 작업이 데이터베이스를 계속해서 필요로 할 것인가? 모든 알고리즘과 모든 아키텍처는 재고 대상이다. 10년 정도 지나면 NVRAM을 사용하기 위한 최선의 방법을 알게 될 것이다.
스케일 아웃(Scale-out) SQL
NoSQL 운동이 시작되었을 때, 가장 큰 특징 중 한 가지는 여러 대의 노드에 데이터 스토리지를 분산시킬 수 있는 능력이었다. 카산드라(Cassandra)와 몽고DB(MongoDB)같은 NoSQL 데이터베이스는 대규모 스토리지의 좋은 기능을 모두 이용할 수 있을 것처럼 보였고, 사람들이 SQL이란 익숙한 세상을 버릴 것처럼 보였다.
현실은, 이런 것들이 상충할 필요가 없다는 것이다. 대규모 데이터베이스의 초창기 실험은 SQL의 모든 짐을 내려 놓았었기 때문에 구축하기가 더 쉬웠고, 그 덕분에 SQL이 엄청난 규모로 구동하는 여러 대의 머신에 걸쳐서 동작하지 않을 이유가 전혀 없었다. 실제로 오라클 같은 업체는 몇 년 동안 그렇게 해오고 있다.
가장 최신의 대규모 데이터베이스는 커다란 클러스터 전체에 퍼져 있는 데이터 세트를 사용해서 사용자가 자신의 모든 SQL 지식과 편리성을 활용할 수 있게 해준다. 예를 들면, 카크로치DB(CockroachDB)는 여러 대의 노드에 복제되어 있는 데이터에 액세스하는 표준 SQL 쿼리 엔진을 제공하고 있으며, 모두 ACID(원자성, 일관성, 고립성, 지속성)가 보장된다. 그렇다, 데이터 일관성에 대한 이런 철두철미한 지원에 대해 어느 정도는 대가를 지급하겠지만, 예상보다는 적을 것이다.
일관성 보장이 중요하다면, 카크로치DB, 구글 클라우드 스패너(Spanner), 클러스트릭스(Clustrix), 애저 SQL, 그리고 누오DB(NuoDB) 같은 스택들을 확인해보라.
공간 정보 데이터베이스(Geospatial Database)
전통적인 데이터베이스들은 지리 같은 2차원 좌표가 아니라 1차원 데이터 세트용으로 구축되어 있다. 물론 전통적인 데이터베이스를 속여서 지리학적 좌표를 사용하는 기초적인 작업을 완수하기 위해 표준 데이터베이스를 사용할 수도 있다. 경도와 위도를 별도의 열에 저장하면, 특정 범위의 경도와 위도로 정의되는 박스에 들어가는 행을 검색하는 것이 어렵지 않다. 그렇지만, 이런 기초적인 박스를 넘어서고 싶다면, 표준 SQL 쿼리가 해결할 수 없다.
공간 정보 데이터베이스는 2차원 공간에서 검색, 정렬, 그리고 교차를 훨씬 더 쉽게 해주는 몇 가지 추가 기능을 가지고 있다. 예를 들어, 공간 인덱스는 대개 2차원 세계와 3차원 세계에서 이웃해 있는 행들에 대한 검색을 더욱 빠르게 만들어주기 위해 좌표 공간 위에 그리드를 추가함으로써 동작한다.
이런 인덱스를 사용하면 폴리곤(Polygon)으로 정의된 데이터 세트에 대해 “포함(contain)”, “중첩(overlap)” 그리고 심지어는 “접촉(touch)” 같은 작업을 하는 쿼리를 작성하는 것이 가능하다. 이 모든 것들은 실 세계에 대한 추론을 그만큼 더 효율적으로 만들어준다.
네오4j 스페이셜(Neo4j Spatial), 지오메사(GeoMesa), 맵D, 그리고 포스트GIS(PostGIS)가 처음 시작하기에 좋다.