78 lines
4.3 KiB
Markdown
78 lines
4.3 KiB
Markdown
---
|
|
tags: [infra, database, postgres, ideas, consolidation]
|
|
---
|
|
|
|
# 260316 모든 DB를 PostgreSQL로 통일하는 아이디어
|
|
|
|
## 상위 원칙
|
|
- [Infra Project Identity](../../00_Philosophy/00_IDENTITY/Infra_Project_Identity.md)
|
|
- [Core Infrastructure Principles](../../00_Philosophy/01_PRINCIPLES/Core_Infrastructure_Principles.md)
|
|
- 공통 작성 원칙: [0_VALUE Writing Principles](https://github.com/happybell80/0_VALUE/blob/main/02_Governance/writing-principles.md)
|
|
|
|
## 관련 문서
|
|
- [Infra Journey](../README.md)
|
|
- [PostgreSQL 통합 vs 전용 DB 구조성능 리서치](../research/260316_postgres_통합_vs_전용db_구조성능_리서치.md)
|
|
- [PostgreSQL Neo4j TCP healthcheck](../troubleshooting/260115_postgresql_neo4j_tcp_healthcheck.md)
|
|
|
|
## 문제 인식
|
|
|
|
- 지금 인프라와 서비스 계층에는 `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는 구조적으로 필요한 경우에만 남기는 방향을 검토할 가치가 있다.`
|