4.3 KiB
4.3 KiB
tags
| tags | |||||
|---|---|---|---|---|---|
|
260316 모든 DB를 PostgreSQL로 통일하는 아이디어
상위 원칙
관련 문서
문제 인식
- 지금 인프라와 서비스 계층에는
PostgreSQL,ChromaDB,Neo4j, 경우에 따라Redis/검색 전용 계층처럼 역할이 나뉘는 구조가 남아 있다. - 이 구조는 각 역할에 최적화된 장점이 있지만, 운영자 입장에서는 백업, 장애 추적, 권한, 런타임 SSOT, 복구 절차, 데이터 정합성 관리가 분산된다.
- 특히 팀 규모가 작고 서비스 경계가 자주 바뀌는 단계에서는
DB를 여러 개 운영하는 비용이 기능 이점보다 더 크게 느껴질 수 있다.
현재상태 -> 기대상태
현재상태
- 관계형 데이터는 PostgreSQL이 맡는다.
- 일부 벡터/메모리/RAG 계층은 ChromaDB 같은 별도 저장소가 맡는다.
- 관계 탐색 일부는 Neo4j 같은 graph-native 저장소를 전제로 해석된다.
- 캐시/검색도 기능별로 분리 여지가 있다.
- 결과적으로 저장소 선택 이유가
현재 필수 요구보다과거 선택의 잔존일 가능성이 섞여 있다.
기대상태
- 가능한 많은 데이터를 PostgreSQL 하나로 모은다.
- 벡터는
pgvector계열로, 텍스트 검색은 PostgreSQL FTS로, 캐시성 데이터는 PostgreSQL 내부 구조로 먼저 수용 가능한지 본다. - 전용 DB는
구조적으로 대체 불가능한 요구가 있는 경우에만 남긴다. - 운영 SSOT, 백업, 접근통제, 모니터링, 장애 복구 기준을 PostgreSQL 중심으로 단순화한다.
아이디어
- 기본 전략을
polyglot by default가 아니라PostgreSQL first로 바꾼다. - 새 기능을 열 때 먼저 묻는 질문을 아래처럼 바꾼다.
이 요구를 PostgreSQL로 먼저 수용할 수 있는가정말 전용 DB가 없으면 안 되는 구조적 이유가 있는가전용 DB를 유지할 경우 운영 복잡도 증가를 어떤 가치로 상쇄하는가
핵심 한 줄은 아래와 같다.
전용 DB를 기본값으로 두지 말고, PostgreSQL에서 막히는 요구가 확인될 때만 별도 저장소를 남긴다.
기대 효과
- 백업, 복구, 권한, 감사, 접근 경로가 단순해진다.
- 서비스 간 데이터 동기화와 이중 저장 부담이 줄어든다.
workspace-config와 런타임 SSOT 해석도 더 직접적이 된다.- 운영자가 장애 시 봐야 하는 저장소 종류와 복구 절차가 줄어든다.
검증이 필요한 이유
- 캐시, 벡터, 텍스트, 그래프는 단순 저장이 아니라
질의 패턴이 다르다. - 특히 그래프 순회와 대규모 분산 벡터 검색은 PostgreSQL 통합 전략의 약한 지점일 수 있다.
- 따라서 이 아이디어는
좋아 보이는 단순화만으로 채택하면 안 되고, 대표 워크로드 기준으로 병목과 손실을 먼저 확인해야 한다.
이 문서에서 빼야 하는 내용
- 어떤 저장소를 언제 끌 것인지, 마이그레이션 순서, 롤백 방식, 성능 게이트는
plans로 보낸다. - 실제 벤치마크 결과, 운영 로그, cut-over 기록은
research또는worklog로 보낸다. - 이미 운영 중인 특정 서비스의 개별 장애 원인은
troubleshooting으로 보낸다.
현재 판단
- 이 아이디어는 충분히 검토할 가치가 있다.
- 다만
모든 DB를 바로 없앤다가 아니라PostgreSQL 중심 단일화가 기본값이 되는가를 묻는 방향이 더 안전하다. - 현재 시점에서 가장 현실적인 해석은 아래 문장이다.
인프라 기본 전략을 전용 DB 우선이 아니라 PostgreSQL 우선으로 바꾸고, 전용 DB는 구조적으로 필요한 경우에만 남기는 방향을 검토할 가치가 있다.