DB 선택하기

나는 지금까지 개인 프로젝트를 진행하면서 별 생각 없이 MySQL만 써 왔다. 학부 시절에 배운 것도 MySQL이고, MySQL만을 이용해서도 프로젝트를 진행하는 데 아무런 문제가 없었다.
그런데 이번에 인턴 생활을 하면서 DynamoDB를 사용해 볼 기회가 있었다. 이 DB를 사용하면서 인사이트를 얻을 수 있었는데 그 경험을 공유해볼까 한다.

먼저 내가 생각하는 이 DB의 대표적인 특성을 간단하게 말해 보자면

1. 믿음직한 AWS에서 제공하는, 쿼리 성능이 뛰어난 DB다.
2. NoSQL이라서 테이블에 없는 새로운 column을 자유롭게 insert할 수 있다.
3. 테이블 당 primary key로 최대 2개의 column을 가질 수 있다.
   (partition key 또는 partition + sort key의 복합 키. 테이블뿐만 아니라 인덱스도 마찬가지다)
4. unique constraint를 지정할 방법이 primary key로 지정하는 방법 외에는 없다.
5. 테이블 전체를 쿼리하는 scan, 조건식을 걸어 쿼리하는 query의 두 가지 Read 연산을 지원하고, Read 연산의 결과를 또다른 조건식으로 필터링할 수 있다(단, n개의 데이터를 스캔한 뒤 필터링해서 0개의 데이터를 얻었다고 해도, n개의 데이터를 스캔한 만큼의 비용이 든다).

이런 특성을 가지고 있다. 다른 특성은 그렇다 쳐도, 세 번째의 조건이 굉장히 까다롭다. 테이블의 key로 최대 두 개의 column만 넣을 수 있다는 게 굉장히 큰 제한으로 다가왔다.

이 제한을 레퍼런스를 찾아 본 결과 여러 column을 묶은 column을 만드는 등 트릭을 써서 여러 column을 key로 묶어서 구현할 수 있다는 것을 알았다. 예를 들어 다음과 같은 데이터를 테이블로 관리해야 한다고 하자.

|------|----------|-----------|-------|------|
| year | semester | studentId | class | name |
|------|----------|-----------|-------|------|
| 2022 |     1    |  20378925 |   C   |  Kim |
|------|----------|-----------|-------|------|

여기서 연도, 학기, 학번을 묶어서 키로 저장하고 싶다고 하자. 지금까지 내가 사용해 왔던 DB는 간단하게

ADD CONSTRAINT PK_STUDENT PRIMARY KEY (year, semester, studentId);

만 하면 여러 개의 column을 묶어 기본 키로 지정할 수 있었다. 그런데 DynamoDB는 이게 불가능해서 트릭을 사용해야 한다.

table student {
  year-semester-studentId: S (hash key)
  year: N
  semester: N
  studentId: N
  class: S
  name: S
}

또는

table student {
  year-semester: S (hash key)
  studentId: N (range key)
  year: N
  semester: N
  class: S
  name: S
}

또는

table student {
  studentId: S (hash key)
  year-semester: S (range key)
  year: N
  semester: N
  class: S
  name: S
}

이런 식으로 여러 column을 묶어서 표현하는 테크닉을 쓰면 쿼리 비용이 덜 들도록 테이블을 구성할 수 있고, 필요한 column들에 대해 unique constraint를 지키도록 테이블을 만드는 것도 가능하다.

몇 년 동안 MySQL(+H2)만 사용해 왔던 나는 이런 테크닉을 접하고 시야가 탁 트인 느낌을 받았다. DynamoDB의 성능이 아무리 좋다 해도 제한사항이 너무 크게 다가와서 사용하기 껄끄러웠는데, 이런 테크닉을 적용해 제한사항을 극복할 수 있다는 걸 깨달았다(지금 생각해 보면 이걸 제한사항이라고 불러도 되는지조차 모르겠다). 이제는 프로젝트를 진행할 때 무조건 MySQL을 고르고 시작하는 게 아니라, 프로젝트의 성격과 DB의 특성을 고려해 적절한 DB를 선택하려고 하고 있다.

---

지금은 검색 기능이 필요해 검색에 특화된 ElasticSearch를 사용하려다가, Array 자료형을 지원하는 PostgreSQL의 매력에 이끌려 개인 프로젝트에 PostgreSQL을 선택해서 진행하고 있다. 생각 없이 이전 프로젝트에서 선택했던 DB를 고르지 말고, 다양한 DB 가운데 특성을 알아보고 적절하게 선택한다면 프로젝트에 들어가는 비용도 아끼고 서비스의 성능도 끌어올릴 수 있지 않을까 생각한다.