아래는 프로젝트 기획 단계에서 걸렸던, 데이터 설계의 일부 요약
타임랩스에 대하여 테이블을 분리해야하는가?
1️⃣ 문제사항
- 현재 프로젝트에 존재하는 '타임랩스' 개념은 진행/완료 상태에 따라 속성이 달리한다
- 진행 중인 타임랩스는 마이페이지에서만 조회되며, 완료된 타임랩스는 메인화면의 전체 피드로 조회된다
- 만약 진행/완료 상태에 구분없이 한 테이블에 관리한다면, 전체 데이터를 끌고와 완료된 전체피드만 쿼리해내는 것에 비용이 클 것같다
2️⃣ 초기 해결방안
타입랩스를 테이블 분리시키자
잔행중인 타임랩스는 'Challenges'로, 완료된 타임랩스는 'Feed'로 따로 관리한다면 별도의 쿼리 과정을 줄일 수 있다.
그치만... 이게.. 최선일까? 오빠?
3️⃣ FeedBack (ft. GPT)
✔ 테이블 분리 시 정말 장점이 존재하는가?
쿼리 최적화 측면
- Challenages와 Feed로 테이블을 분리한다면, 각 상황에 필요한 데이터만을 타겟으로 쿼리 수행 가능
- 전체 데이터 중 일부만 필요한 경우, 불필요한 데이터를 스캔하는 비용을 줄일 수 있음
구조의 명확성
- 각 테이블의 목적이 명확해지므로 코드의 가독성과 유지보수가 좋아짐
✔ 테이블 분리 시 단점이 존재하는가?
데이터 이동의 복잡성
- 타임랩스가 완료된다면 데이터를 'Challenges'에서 'Feeds'로 이전시켜야 함
- 코드의 복잡성과 데이터 무결성 유지에 주의를 기울여야 함
4️⃣ 다른 대안, 하나의 테이블에서 관리하기 (Status Column 도입)
✔ 한 테이블 관리 시, 장점이 존재하는가?
단순한 구조
- 데이터 이동 없이 상태만 변경하여 관리 가능
데이터의 무결성
- 데이터가 여러 테이블로 분산되지 않기에 무결성 유지가 쉬움
✔ 한 테이블 관리 시, 단점은 무엇인가?
쿼리의 복잡성
- 상태에 따른 필터링 필요, But 현대의 인덱싱과 최적화 기술이 있으므로 충분한 처리 결론
최초에 걱정했던 쿼리 시의 불필요한 연산은 인덱싱으로 해결되지 않을까? 싶지만, 인덱싱은 카디널리티 문제가 있어서 상태값이 0,1밖에 없기 때문에 좋지 못할 것이다.
5️⃣ 결론: 테이블 분리할 거에오
✔ 왜 테이블을 분리하려고 하는가?
데이터 Lock & 동기화 문제 우려
- Challenge 테이블은 생성/삭제가 일어난다
- Feed 테이블은 조회가 주로 일어난다
- 한 테이블에서 관리시, 이 경우가 엇갈려 문제가 생길 수 있다
인덱싱 처리시, 카디널리티 문제
- 상태값은 주로 0,1 로 존재하는데, 이렇게 카디널리티가 낮은 인덱싱을 사용하는 것은 전체 테이블 스캔과 거의 동일한 효율성을 가지므로 의미 없음
🍊: 카디널리티 관련해선, 상태값과 함께 카디널리티가 높은 컬럼을 함께 쓰는 복합 인덱스를 사용한다면 인덱싱 문제를 해결할 수 있어. 하지만 데이터의 무결성과 유지보수성을 위해서 테이블 분리시키자!
🐶: 조아