DB 설계?

DB 설계를 바꾼 이유

첫 의도

우리가 처음 설계했던 DB 모델링은 **컬렉션(Collection)**을 최소한으로 사용했다.

MongoDB에서 JOIN은 성능이 너무 느렸고, 따라서 우리는 컬렉션간의 관계를 최소화하기위한 설계를 했다.

한 번에 많은 양의 정보를 FE로 보내서 네트워크 비용을 줄이고, Store를 통해 관리하고 렌더링을 했다.

---

문제 인식

처음 문제를 인식한 것은 거래내역(transaction) 에 관련된 작업에서 있었다.

모든 데이터를 accountbook model에서 관리하다보니 컬렉션을 따로 만들지 않았다 => Model이 없었다.

두 번째 인식은 생산성과 유지 보수에 있었다.

accountbook model에서 모든 작업을 하다보니, accountbook model 크기가 너무 커져버렸다.

점점 스파게티가 되어가고있었다.

또한 전체를 가지고있는 **가계부(accountbook)**를 읽어와서 후처리를 해줘야했다.

---

문제 발생

기획 단계에서 우리가 생각한 거래내역의 갯수는 많아야 1000개 정도라고 생각했다.

마지막 점검을 하면서 많은 양의 데이터를 넣어보았다.

하루 10개 = 1년 3650개 = 10년 36500개의 데이터를 넣었다.

결과는 매우 처참했다. 엄청난 성능저하가 있었고 첫 로딩이 20초가 넘게 걸렸다.

이를 해결하기위해 현재 보고있는 월을 기준으로 양 옆, 총 3개월의 데이터를 받아오기로 변경했다.

해당 가계부에 있는 거래내역을 보고 Date를 읽어 비교해서 response를 만들어 반환해야 했다.

문제는 account book 을 읽어와서 transactions 배열을 돌려야했다. 이 과정이 너무나도 비효율적이었다.

---

문제 해결

우리는 이 문제를 해결하기 위해서 결국 Embedded Document 방식을 포기하고 지금의 DB 구조로 변경했다.

account book과 transaction을 분리하고, transaction에 속해있는 accountbook id를 넣어줬다.

transaction model의 쿼리를 이용해서 date 계산을 간단하게 할 수 있었다.

accountbook에서 transactions를 읽어 처리해야할 로직에 대한 고민이 크게 줄었다.

굳이 JOIN연산에 대한 고민을 할 필요없이 두 개의 Colleciton에서 Read를 하고 읽어온 데이터를 가공해서 기획에 맞는 Response 를 만들어 날려주기만 했다.

이 과정에서 생산성이 크게 향상되었고, account book model의 코드 양을 크게 줄일 수 있었다.