RDBMS와 NoSQL의 차이점 및 Modular RAG에 적합한 선택
Modular RAG는 다양한 모듈을 조합하며 유연성과 확장성을 중요하게 여기는 프로젝트다. 이를 구현하기 위한 데이터베이스 선택에서 RDBMS와 NoSQL의 특성을 비교하고, Modular RAG에 더 적합한 데이터베이스를 선택하고자 한다.
RDBMS vs NoSQL: 비교 테이블
| 특징 | RDBMS | NoSQL |
|---|---|---|
| 데이터 구조 | 정형 데이터를 스키마 기반으로 저장 | 스키마 없이 비정형 데이터를 유연하게 저장 |
| 확장성 | 수직적 확장(서버 성능 업그레이드) 중심 | 수평적 확장(샤딩과 클러스터링 지원)에 적합 |
| 데이터 일관성 | ACID 트랜잭션을 통해 강력한 데이터 무결성 보장 | eventual consistency로 일부 데이터 불일치 허용 |
| 처리 속도 | 읽기와 쓰기 성능이 균형 잡혀 있으나 대규모 데이터 처리에 한계 | 빠른 쓰기 성능, 대규모 데이터 처리에 최적화 |
| 관계형 데이터 관리 | 복잡한 관계형 데이터 처리와 조인(Join)에 강점 | 관계형 연산에 부적합하며 별도 로직이 필요 |
| 비정형 데이터 처리 | JSON이나 XML 데이터를 처리할 수 있으나 비효율적 | JSON, 로그, 센서 데이터 등 비정형 데이터 처리에 강점 |
| 생태계 및 도구 | 성숙한 SQL 기반 도구와 ORM 지원 | 쿼리 도구가 제한적이며, 특정 상황에서 학습 곡선이 높음 |
| 사용 사례 | ERP 시스템, 금융 서비스 등 데이터 무결성이 중요한 경우 | 로그 저장, JSON 기반 서비스, 빠른 데이터 쓰기 요구 |
RDBMS의 장단점
RDBMS가 Modular RAG에 적합한 이유
- 데이터 관계 관리에 강점
LangGraph의 노드와 엣지, 사용자 데이터와 모듈 간의 관계를 정의하고 조작하는 데 적합하다. 데이터 관계가 복잡한 경우 RDBMS가 더 나은 선택이 될 수 있다. - 복잡한 데이터 분석에 유리
SQL 쿼리와 조인 기능으로 복잡한 데이터 연산과 분석 작업을 효율적으로 처리할 수 있다. - 성숙한 도구와 라이브러리
RDBMS는 성숙한 생태계와 함께, SQLAlchemy와 같은 ORM으로 쉽게 사용할 수 있다.
RDBMS의 한계
- 스키마 유연성이 부족
데이터 구조가 자주 변경되는 Modular RAG에서는 데이터 마이그레이션 비용이 높다. - 수평적 확장에 제약
데이터가 증가할수록 서버를 업그레이드하는 방식으로 확장해야 하며, 클러스터링이나 샤딩 구현이 까다롭다. - 비정형 데이터 처리 비효율성
JSON, 로그, 벡터 데이터와 같은 비정형 데이터를 처리할 때 성능이 떨어지고, 별도 변환 과정이 필요하다.
NoSQL의 장단점
NoSQL이 Modular RAG에 적합한 이유
- 스키마 없는 유연한 데이터 저장
LangGraph 노드 설정, 메타데이터, 사용자 요청 데이터를 자유롭게 저장할 수 있어 변경이 잦은 데이터 구조에 적합하다. - 수평적 확장에 강점
데이터와 트래픽이 증가해도 서버를 추가해 확장할 수 있다. - 비정형 데이터 처리 최적화
JSON 형식인 메타데이터나 로그 데이터를 저장하고 검색하는 데 최적화되어 있다. - 쓰기 성능이 우수
빠른 데이터 저장이 가능해 실시간 작업 로그나 메타데이터 저장에 용이하다.
NoSQL의 한계
- 데이터 관계 관리 부족
조인 기능이 없거나 제한적이며, 데이터 관계를 관리하려면 별도의 응용 계층 로직이 필요하다. - 일관성 부족
eventual consistency 특성상 데이터 간 불일치가 발생할 수 있다. 강한 일관성이 요구되는 작업에는 적합하지 않다. - 생태계 미성숙
SQL과 같은 표준 쿼리 언어가 없어 복잡한 쿼리 작성이 어렵고, 학습 곡선이 더 높을 수 있다.
Modular RAG에 적합한 데이터베이스 선택
Modular RAG의 요구사항 분석
- 유연성
모듈별 설정 데이터, 검색 메타데이터, 벡터 데이터 등 다양한 형식의 데이터를 저장하고 조작할 수 있어야 한다. - 확장성
노드가 증가하거나 사용자 요청이 급증해도 확장 가능한 구조를 지원해야 한다. - 비정형 데이터 처리
메타데이터와 같은 비정형 데이터를 저장하고 빠르게 검색할 수 있는 기능이 요구된다. - 속도와 효율성
빠른 데이터 쓰기와 조회 성능이 중요한 요소다.
제안
- NoSQL(MongoDB): Modular RAG의 유연성과 확장성을 고려할 때 MongoDB를 사용하는 것이 더 적합하다. JSON 기반 데이터 관리와 수평적 확장 기능이 특히 강점으로 작용한다.
- RDBMS(PostgreSQL): 데이터 관계가 명확하고 강력한 무결성이 필요한 특정 부분(예: 사용자 관리)에는 RDBMS를 보조적으로 활용할 수 있다.
- Hybrid 구조: NoSQL과 RDBMS를 병행하여 각각의 강점을 활용하는 방법도 효과적이다. NoSQL은 비정형 데이터를, RDBMS는 관계형 데이터를 처리하는 데 사용한다.
벡터 스토어와 NoSQL/RDBMS의 역할
벡터 스토어의 역할
벡터 스토어(예: Chroma, Faiss, Milvus)는 벡터화된 데이터(특징 벡터)를 저장하고, 이를 기반으로 유사도 검색이나 빠른 검색을 수행하는 데 특화되어 있다.- 저장 데이터: 벡터(숫자 배열), 기본적으로 벡터와 연결된 간단한 메타데이터(예: 문서 ID, 태그 등)를 포함
- 주요 기능: 벡터 간의 유사도 계산, 빠른 검색, 클러스터링
NoSQL/RDBMS의 역할
- 벡터와 직접적인 연산이 필요하지 않은 추가 메타데이터나 검색 로그 같은 부가 정보를 저장하는 데 사용 가능
- 벡터 스토어에서 검색된 결과의 상세 정보를 저장하고 관리
- 예를 들어, 벡터 스토어에서 반환된 문서 ID를 기준으로 해당 문서의 전체 내용, 작성자 정보 등을 NoSQL이나 RDBMS에서 가져오는 방식으로 활용
왜 벡터 스토어를 따로 구축하나?
- 벡터 연산의 특화된 요구
RDBMS나 NoSQL은 벡터 간 유사도 계산, 거리 계산(KNN)과 같은 작업에 적합하지 않다. 벡터 스토어는 이와 같은 작업을 고속으로 처리하도록 설계되었다. - 성능 최적화
벡터 데이터를 수백만~수십억 단위로 저장하고 실시간 검색을 수행하는 데 있어, 벡터 스토어는 더 효율적이다. - 확장성
벡터 스토어는 분산 저장과 병렬 처리를 지원해 대규모 데이터를 효율적으로 관리할 수 있다.
벡터 스토어와 NoSQL/RDBMS의 협업 가능성
벡터 스토어와 NoSQL/RDBMS는 서로 다른 역할을 하며, 다음과 같은 방식으로 함께 활용할 수 있다:
벡터 스토어
- 벡터 데이터와 간단한 메타데이터(예: 문서 ID, 제목, 태그)를 저장
- 유사도 검색을 수행해 결과를 반환
NoSQL 또는 RDBMS
- 벡터 스토어의 검색 결과(ID)를 기반으로 더 풍부한 데이터를 제공
- 예를 들어, 벡터 스토어에서 반환된 문서 ID를 NoSQL/RDBMS에서 조회해 전체 내용, 작성자 정보, 추가 메타데이터를 반환
Modular RAG에서의 적합성
Modular RAG는 벡터 스토어와 데이터베이스를 조합해 데이터를 관리하는 것이 더 효율적이다. 벡터 스토어는 벡터 데이터 검색에 특화되어 있으므로, 비정형 데이터의 메타데이터나 사용 기록은 NoSQL에 맡기고, 검색 연산은 벡터 스토어로 분리하는 방식을 추천한다.
제안 구조
- 벡터 스토어: 검색 및 유사도 계산 전용
- NoSQL: 벡터와 연결된 상세 메타데이터 관리
- 사용 예시
- 벡터 스토어에서 검색 결과(예: 문서 ID)를 반환
- 해당 ID를 NoSQL에서 조회해 상세 데이터를 반환
- 사용자 로그, LLM 설정 등 비정형 데이터도 NoSQL에서 관리