초기 기획과 너무 많이 바뀐 현재
현재 회사 프로젝트를 진행하면서 사업팀의 초기 기획과 너무 많은 것이 바뀌어버렸다.
예를 들면, 초기에 '순위의 변동'을 꼭 저장해놓아야 한다고 했기 때문에 '순위 로그'를 DB에 계속 저장하는 상황이었다. 하지만 현재는 순위의 변동을 아예 사용하지 않고 있다. 또한 상품에 필요한 정보라며 모두 저장하라고 했던 데이터들이 지금 와선 거의 쓸모가 없어졌다.
이처럼 갑자기 추가된 정보, 사라진 정보들이 꽤 많았다. 뿐만 아니라 현재 db구조가 초기 기획 의도에 맞춰져있다보니 현재와는 맞지 않는 경우도 많았다. 그래서 개발팀에서는 db 구조를 재설계하기로 했다.
mongodb의 구조를 재설계하는 원칙
개발을 시작하고 처음 사용했던 데이터베이스는 MySQL과 같은 관계형 데이터베이스였다. 관계형 데이터베이스의 스키마를 디자인할 땐 정규화 과정을 통해 데이터를 중복되지 않게 만드는 것이 매우 중요하다고 배웠다. 하지만 스키마에 대한 제약이 있기 때문에 스키마를 수정하기는 어렵다는 단점이 있다.
그러나 mongodb와 같은 비관계형 데이터베이스의 경우 스키마의 변경이 자유롭다. 개발팀에서는 이미 초기 프로젝트 상 많은 변경이 있을 거라고 예상하고 mongodb를 사용했기 때문에 이번 스키마 변경은 크게 부담스럽지 않았다.
그렇다면 mongodb를 설계하는 원칙은 보통 어떻게 될까? 일반적으로 Embedding 방식과 referencing 방식이 있다.
영어라 어려워보이지만 사실 Embedding은 하나의 테이블에 필요한 정보들을 모아놓는 것이고, referencing 방식은 마치 관계형 데이터베이스의 foreign key로 서로 참조하도록 하는 것과 같다.
이 원칙을 기본으로 현재 우리 db의 스키마 변경 원칙을 다음과 같이 세웠다.
- 조회 시 항상 함께 사용하지만 현재 분리되어있는 정보들은 Embedding 방식으로 변경한다.
- 조회 시 굳이 함께 있을 필요 없는 정보들은 referencing 방식으로 변경한다.
- 불필요한 필드 및 데이터는 모두 삭제한다.
- 데이터에서 혼란을 주는 부분을 변경한다. (초기 버전에서는 혼란스럽지 않았지만 현재는 혼란스러운 구조가 있었다)
이제 이 기준을 가지고 이제 전체 스키마를 점검 후 재설계를 하려고 한다.
이제 시작이므로 완성이 되면 다시 관련 글을 작성해보려고 한다.
