나는 개발하면서 RDB를 제외하고 개발한 적이 없다.
그래서 RDB에 너무 익숙해져서 단점을 거의 느껴본 적이 없는데, 친구가 그래프 DB를 사용하는 것을 보고 다른 유형의 DB에 관심이 생겼다. 다른 유형의 DB에 대한 설명을 보다 보니 RDB와 비교하면서 생각하게 되었고, 그래서 프로젝트를 하면서 생긴 RDB의 단점에 대해 간단히 메모해보고자 한다.
가장 최근에 했던 심박수 데이터 수집 및 알림 프로젝트인 '강한날'에서도 물론 RDB를 사용하였다. 프로젝트에서 DB 선택의 가장 중요한 요소는 '심박수 데이터를 잘 저장하고 조회할 수 있는가'였다.
심박수 데이터는 각 사용자마다 2분에 한 번씩 저장하므로 수많은 데이터가 저장되고, 한번 저장되면 변경 또는 삭제될 가능성이 없다는 특징이 있었다. 이러한 특징은 시계열 DB가 적합하다고 생각하여 여러 시계열 DB를 비교해보았다.
인기있는 시계열 DB는 여기서 확인 가능하다. 다음 이미지는 2024년 7월 기준 Time Series DBMS 순위이다.
프로젝트에서 사용한 DB는 timescaleDB였는데 DB 선택 사유는 다음과 같다.
- 익숙한 RDB 기반이므로 빠르게 개발 가능하다.
- 5위 이내 DB 중 RDB 기반은 Kdb, TimescaleDB가 있다.
- 새로운 질의어를 배우지 않아도 된다.
- InfluxDB, Kdb 등은 새로운 질의어를 배워야 한다. 물론 어렵진 않으나 배우고 익히긴 해야한다.
- PostgreSQL의 확장 프로그램 같은 느낌이라서 시계열데이터만을 위한 DBMS를 따로 설치하지 않고 사용할 수 있다. 즉, 일반적인 데이터를 다루는 테이블과 시계열 DB를 다루는 테이블을 한 DBMS 내에서 처리 가능하다.
이렇게 열심히 선택한 TimescaleDB였는데, 개발 상 RDB의 특징에 의해 문제가 발생하였다.
RDB의 특징 중 하나는 스키마의 변경이 생기면 이를 반영하는 것이 통상의 NoSQL보다 어렵다는 점이다.
사실 이론적으로는 알고 있는데 솔직히 스키마에 컬럼 하나 추가하는게 뭐가 어렵다고 그러지 하는 생각을 가지고 있긴 했다.
이번에 개발하다보니 심박수 데이터마다 위기, 주의, 안정 등의 심박수 등급을 저장하는 기능이 추가되었다. 이를 반영하기 위해 심박수 테이블에 등급 컬럼도 추가하였다. 처음에는 영문 String으로 저장하였으나, 나중에 max() 함수를 이용하기 위해 숫자(Integer)로 변경하였다.
여기서 문제가 발생하게 되었다. 로컬 DB에서 테스트 진행할 때는 잘 됐으나 배포를 하니 기능이 동작하지 않았다. 알고 보니 배포 환경 db에서 심박수 등급 컬럼의 데이터 형식을 String인 상태 그대로였다. 로컬 DB 환경만 맞춰놓고 배포 DB 환경은 미처 신경쓰지 못한 것이다.
만약 NoSQL을 사용했다면 이러한 스키마 변경으로 인한 오류를 좀 더 줄일 수 있지 않을까 생각해본다.
