Key-Value 데이터베이스는 간단하면서 빠르고 확장성이 좋다는 강한 장점을 가지고 있지만, 강점만큼 단점도 분명하게 존재한다. Key-Value 데이터베이스의 한계를 알아보자.
데이터 조회의 어려움
Key-Value 방식의 데이터 조작은 양날의 검이다. 빠르고 단순하다는 이점이 있지만, 오로지 Key 값만으로 데이터를 조작한다는 것은 단점이 되기도 한다. 특정 값을 조회를 한다는 것은 해당 값과 대칭되는 키를 알고 있어야 함을 의미한다.
만약 학번, 주민 등록 번호, 사원 번호 등으로 정보를 조회해야 된다고 가정했을 때 한 두명의 Key라면 기억하는 것이 어렵지 않다. 하지만 수천 수만 명의 정보를 다루고 있다면 특정 번호로 정보를 조회하기는 쉽지 않다. 특정 상황에서 단순함이 장점인 Key-Value 시스템은 역설적으로 복잡함을 야기한다.
Cust:1 {id: 999231, name: Sam, age: 18}
Cust:2 {id: 646038, name: Seo, age: 43}
Cust:3 {id: 321237, name: Lee, age: 54}
Cust:4 {id: 955234, name: Yoo, age: 25}
.
.
.
Cust::1000000 {id: 421323, name: Son, age: 28}
</br>
예를 들어 100만명의 고객이 있는 경우 id가 856454인 고객의 나이를 조회하고 싶다면 어떻게 해야될까? 일반적인 관계형 데이터베이스는 질의언어로 쉽게 조회할 수 있다.
SELECT Cust.age from Cust WHERE id=856454
</br>
관계형 데이터베이스는 위에 한 줄이면 쉽게 id가 856454인 고객의 나이를 조회할 수 있다. 하지만 Key-Value 데이터베이스는 간단한 조회를 위해 등장했기 때문에 질의 언어라는 개념은 존재하지 않는다.
또 나이가 25~45 사이의 고객을 검색하는 작업을 하고 싶다면? 특정 키워드로 한명의 정보를 찾는 것도 어려운데 특정 범위 조건으로 정보를 획득하는 것은 더욱 힘든 일이다.
따라서 기본적인 기능만으로는 100만개의 데이터에서 모든 키값을 외우지 않는 이상 특정 항목으로 정보를 조회하는 것은 쉽지 않다.
이 같은 문제를 대안으로 텍스트 검색 기능을 통한 정보 조회 방식이 주로 사용되고 있다. Riak 같은 검색 API를 사용하여 특정 키워드의 검색, 유사 항목 검색, 범위 검색 등의 기능을 사용하여 위의 단점을 보완할 수 있다.
또 최근에는 SQL과 같은 표준 질의 언어 수준은 아니지만 유사한 기능을 제공하는 언어도 등장하고 있어 조회에 대한 단점이 많이 개선되고 있다.
데이터가 큰 경우 성능 하락
위에서도 한번 언급했듯이 Key-Value 데이터베이스는 간단한 데이터의 조회를 위해 등장했다. 간단한 데이터를 처리하는데 Key-Value 데이터베이스는 높은 성능과 효율성을 보였다.
하지만 데이터의 단위가 커지는 경우는 성능 하락이 발생한다. 저장 장치에는 정해진 데이터 블록의 크기가 있다. 만약 데이터 블록을 넘어서는 데이터를 저장하려는 경우 저장되는 데이터는 여러 데이터 블록에 쪼개져 저장된다.
즉, 하나의 값을 수정하거나 조회할 때 연관된 여러개의 데이터 블록을 참조해야되기 때문에 데이터의 크기가 커질 수록 해당 항목에 대한 성능이 하락하게 된다.
또 Key-Value 데이터베이스는 데이터 캐시를 위해 메모리를 많이 사용하는데, 블록의 사이즈가 커진다는 것은 캐시할 수 있는 데이터 수가 줄어드는 것을 의미한다. 캐시할 수 있는 항목이 줄어들면 캐시 히트 비율도 함께 떨어지기 때문에 성능 하락이 발생한다.