-
Notifications
You must be signed in to change notification settings - Fork 0
[BE] Database 선택 이유
저희 서비스는 데이터를 기반으로 거동이 불편한 분들에게 네비게이션 정보를 제공하는 것을 목표로 하고 있습니다. 이와 같은 서비스를 제공하는 데 있어 RDB가 GDB보다 더 적합한 이유를 다음과 같이 정리할 수 있습니다.
- GDB는 고유의 데이터 구조와 쿼리 방식으로 인해, 특정 요구사항에 맞는 튜닝이 어렵다는 단점이 있습니다.
- 메모리 관리 및 알고리즘 튜닝의 복잡성: GDB는 대규모 그래프 데이터를 처리하기 위해 고도화된 알고리즘을 사용하는데, 이러한 알고리즘을 우리 서비스의 요구사항에 맞게 커스터마이징하려면 많은 시간이 소요됩니다. 예를 들어, 그래프 탐색 알고리즘의 최적화는 직접 설계가 필요할 수 있어 개발 부담이 큽니다.
우리 서비스는 데이터 정합성이 무엇보다도 중요합니다. 이는 특히 네비게이션 정보 제공이라는 특성상 서비스 신뢰도와 직결됩니다. GDB는 데이터 정합성을 보장하는 데 있어 구조적인 한계가 있는 반면, RDB는 이를 효과적으로 관리할 수 있습니다.
-
중복 데이터 제거: 우리 서비스는 정규화를 통해 중복 데이터를 최소화하고, 이를 통해 데이터 일관성을 유지해야 합니다. 네비게이션 서비스에서 중복된 데이터는 잘못된 경로 정보를 제공할 가능성을 높이며, 이는 사용자 경험을 저해할 뿐만 아니라 서비스 신뢰도에도 치명적입니다.
-
오류 및 오차 방지: 거동이 불편한 사용자에게 잘못된 정보를 제공하면 단순한 불편을 넘어 안전 문제로 이어질 수 있습니다. 이는 데이터를 설계 단계에서부터 철저히 정합성을 유지해야 하는 이유입니다.
-
추가, 수정 및 삭제 작업의 비효율성: GDB는 데이터 모델상 노드와 엣지 간의 관계를 기반으로 설계되어 있습니다. 이로 인해 데이터를 수정하거나 삭제할 때 관계를 다시 검증하고 유지하는 작업이 복잡합니다.
-
예를 들어, Neo4j와 같은 GDB는 CASCADE와 같은 기본적인 데이터 일관성 보장 기능이 부족합니다. (관련 이슈 링크)
-
반면, RDB는 외래 키 제약 조건을 활용해 데이터의 추가, 수정 및 삭제 작업에서 정합성을 보다 쉽게 보장할 수 있습니다.
우리 서비스의 데이터 크기는 국내에서 가장 큰 캠퍼스인 서울대학교를 기준으로 하더라도 30MB 미만입니다. 이는 서비스 데이터 전체를 메모리에 올려 처리할 수 있을 만큼 작은 규모로, RDB를 사용하는 데 있어 성능 문제를 야기하지 않습니다. 따라서 데이터 크기 측면에서도 RDB는 충분히 적합한 선택입니다.
우리 서비스는 사용자에게 신뢰성 있는 정보를 제공해야 하며, 이를 위해 데이터의 정합성과 관리 용이성이 필수적입니다. GDB는 그래프 데이터 처리에서 강점을 가지지만, 데이터 정합성과 튜닝의 유연성 측면에서 한계가 있습니다. 반면, RDB는 정형화된 데이터 처리 및 정합성 보장에서 유리하므로 우리의 서비스 목적에 더 적합한 선택입니다.
- 🚏 완벽한 길을 그리기 위한 노력
- 🪖 버그데이 UT 결과 리포트
- 🐜 어드민 페이지
- 🌊 1차 자체 QA
- 🌊 2차 자체 QA
- 🌊 3차 자체 QA
- 🌊 4차 외부 QA
- 🌊 5차 외부 QA
- ☁️ FE의 GCP를 활용한 배포 방식 및 내부 아키텍쳐
- 🍀 UNIRO의 자연스러운 로딩 화면, 어떤 원리일까? (Suspense)
- 🧪 완벽한(?) 페이지를 위한 LightHouse 점수 개선기
- 🌎 구글 구면 좌표계 도입 여부
⚠️ API 통신 에러 처리- 🥷 바텀시트 만들기
- 💨 최적화 : 효율적인 길 렌더링(Event Capturing)
- 📀 최적화 : 오브젝트 캐싱
- 😎 최적화 : 모든 길 조회 SSE 적용