관계형 데이터베이스 vs 벡터 데이터베이스
데이터베이스는 오랫동안 애플리케이션 성능에 과제를 제기해 왔으며, 종종 광범위한 세부 튜닝을 필요로 했습니다. 이에 대응하여 확장성, 성능, 개발자 생산성을 개선하고 특정 유형의 애플리케이션 생성을 단순화하기 위한 새로운 데이터베이스 설계가 등장했습니다.
그럼에도 불구하고 이러한 새로운 데이터베이스 솔루션에는 트레이드오프가 따릅니다. 각 설계에는 타협이 수반되며, 특정 장점은 다른 요소를 희생하는 대가로 얻어집니다. 이러한 선택지와 그 트레이드오프를 이해하는 것은 필요에 가장 적합한 도구를 선택하는 데 필수적입니다. 이 글에서는 벡터 데이터베이스를 살펴보고 이를 기존 관계형 데이터베이스와 비교하여 충분한 정보를 바탕으로 결정을 내릴 수 있도록 돕겠습니다.
애플리케이션에 특화된 데이터베이스를 선택해야 하는 이유는 무엇인가요?
최근 몇 년 동안 특정 사용 사례에 맞춘 특화 데이터베이스가 급증했습니다:
Graph Database: 고도로 연결된 데이터를 효율적으로 저장하고 분석하도록 설계된 그래프 데이터베이스는 데이터 포인트 간의 관계(knowledge graph)를 관리하는 데 탁월합니다.
Search Database: 이러한 데이터베이스는 비정형 또는 반정형 데이터를 처리하며 빠르고 효율적인 검색 및 쿼리에 최적화되어 있습니다.
Time Series Database: 높은 쓰기 처리량과 time-based queries에 최적화된 시계열 데이터베이스는 빈번하고 대규모의 타임스탬프 데이터 입력이 있는 워크로드를 처리합니다.
Key-Value Database: 높은 성능과 확장성으로 알려진 키-값 데이터베이스는 추가 메타데이터 없이 단순한 키-값 쌍으로 데이터를 저장하므로 빠른 읽기 및 쓰기 작업에 이상적입니다.
In-Memory Database: 이러한 데이터베이스는 데이터를 디스크가 아닌 RAM에 저장하여 디스크 접근 지연을 제거하고 성능을 크게 향상시킵니다.
Vector Database: 이러한 데이터베이스는 벡터 임베딩을 저장하도록 구축되었으며 계산 집약적인 semantic search를 처리하도록 최적화되어 있습니다.
관계형 데이터베이스(RDBMS)가 여전히 시장 점유율에서 우위를 점하고 있지만, 목적 기반 데이터베이스는 빠르게 주목받고 있으며, 지난 2년 동안 벡터, 시계열, 키-값, 그래프 데이터베이스가 가장 큰 성장을 보이고 있습니다.
특화 데이터베이스로의 전환은 성능과 고급 기능에 대한 수요 증가에 의해 주도되고 있으며, 사용자들은 소프트웨어가 선도적인 기술 기업들이 세운 높은 기준을 충족하기를 기대합니다. 또한 마이크로서비스 아키텍처의 부상은 특화 데이터베이스의 도입을 촉진했습니다. 독립적으로 배포 가능하고 서로 추상화된 마이크로서비스는 팀이 다른 서비스의 기술에 대한 광범위한 지식 없이도 특정 애플리케이션 기능에 가장 적합한 도구를 선택할 수 있게 해줍니다.
하지만 아키텍처에 또 다른 데이터베이스를 통합하면 복잡성이 증가합니다. 특화 데이터베이스의 장점이 비용과 복잡성을 능가하는지 평가하는 것이 중요합니다. 장기적으로 애플리케이션에 영향을 미칠 결정을 내리기 전에 장단점을 철저히 평가하는 것이 필수적입니다.
"실무에서 다양한 워크로드와 애플리케이션을 지원하는 통합 데이터 관리 시스템을 달성하는 것은 어렵습니다. 이를 자동차 산업에 비유하면, 모든 목적을 수행하는 단일 차량을 상상할 수 없습니다—SUV, 트럭, 세단, 스쿨버스는 특정 기능을 염두에 두고 설계되었습니다. 마찬가지로 데이터베이스 세계에서도 시스템은 서로 다른 요구에 맞게 최적화되며, 만능 솔루션은 가능성이 낮습니다. 미래는 특정 요구 사항에 맞춘 더 특화된 데이터베이스를 개발하는 데 있습니다. 다양한 데이터베이스 시스템과 상호작용하기 위한 통합 인터페이스나 SDK가 나타날 수는 있지만, 추세는 점점 더 특화된 솔루션으로 계속 나아갈 것입니다." Charles Xie, Zilliz의 창립자 겸 CEO.**
관계형 데이터베이스 개요
관계형 데이터베이스는 전통적인 데이터베이스라고도 하며, 데이터를 표 형식으로 관리하는 다재다능한 도구입니다. 행과 열로 구성된 이 구조는 효율적인 데이터 저장 및 검색을 가능하게 하며, 일반적으로 디스크에서 관리됩니다. SQL의 사용은 그 다재다능함을 더욱 향상시켜 광범위한 쿼리를 지원합니다. 이러한 적응성은 관계형 데이터베이스를 다양한 애플리케이션에 적합하게 만듭니다. 관계형 데이터베이스는 특히 데이터셋 간의 구조화된 관계를 강제하여, 사전 정의된 스키마를 통해 데이터 일관성과 무결성을 보장하는 능력으로 높이 평가됩니다.
데이터 저장: 행과 열
관계형 데이터베이스는 데이터를 저장하기 위해 행과 열의 체계적인 배열을 활용합니다. 각 행은 단일 레코드를 나타내며, 각 열은 데이터 필드 또는 속성을 나타냅니다. 이러한 체계적인 형식은 데이터에 쉽게 접근하고 관리할 수 있게 하여, 사용자가 데이터 저장소를 탐색하고 데이터베이스 내 정보를 효율적으로 업데이트할 수 있도록 합니다.
쿼리 기능
구조적 쿼리 언어(SQL)는 관계형 데이터베이스의 핵심 기능으로, 사용자가 복잡한 데이터를 함께 추출하고 조작하기 위한 정밀한 쿼리를 작성할 수 있게 합니다. SQL은 데이터를 필터링, 정렬 및 검색하기 위한 강력한 프레임워크를 제공하여, 대규모 데이터셋에서 복잡한 검색과 작업을 쉽게 수행할 수 있게 합니다. SQL을 사용하면 사용자는 관련 정보를 빠르게 식별하고 특정 기준에 기반한 상세 보고서를 생성할 수 있습니다.
ACID 속성
관계형 데이터베이스 트랜잭션은 ACID로 알려진 네 가지 핵심 속성인 원자성, 일관성, 격리성, 지속성에 의해 관리됩니다. 원자성은 트랜잭션의 모든 측면이 하나의 전체로 완료되도록 보장하여 부분 업데이트가 남지 않게 합니다. 일관성은 데이터의 무결성을 유지하여 트랜잭션이 유효한 상태로 이어지도록 보장합니다. 격리성은 트랜잭션이 완전히 커밋될 때까지 서로 영향을 주지 않도록 하여 충돌을 방지합니다. 마지막으로 지속성은 트랜잭션이 커밋되면 시스템 장애가 발생하더라도 변경 사항이 영구적으로 유지되도록 보장합니다.
벡터 데이터베이스 개요
그렇다면 벡터 데이터베이스란 정확히 무엇일까요? 핵심적으로, 벡터 데이터베이스는 벡터 표현과 임베딩을 활용하여 비정형 데이터를 처리하도록 설계된 특수 시스템입니다. 이 접근 방식은 의미 정보의 빠른 검색과 효율적인 유사도 검색을 가능하게 합니다.
벡터 데이터베이스는 현대 AI 생태계에서 특히 검색 증강 생성(RAG)에서 매우 중요합니다. RAG는 외부 지식을 통합하여 대규모 언어 모델(LLMs)의 성능을 향상시키며, 이는 AI 환각을 완화하고 생성된 응답의 정확성을 개선하는 데 도움이 됩니다. 이러한 데이터베이스는 LLM이 더 신뢰할 수 있는 답변을 생성하는 데 사용하는 문맥 정보를 관리하고 검색합니다.
벡터 데이터베이스는 챗봇, 추천 시스템, 이미지, 비디오, 오디오 검색과 같은 멀티미디어 검색을 포함한 다양한 분야에 널리 적용됩니다.
벡터 데이터베이스 vs 관계형 데이터베이스
전통적인 관계형 데이터베이스는 사전 정의된 스키마를 사용하고 표 형식 데이터 내에서 정밀한 검색을 수행하며 구조화된 데이터를 관리하는 데 뛰어납니다. 반면, 벡터 데이터베이스는 이미지, 오디오, 비디오, 텍스트와 같은 비정형 데이터를 이러한 데이터 유형을 고차원 벡터로 표현하여 처리하는 고유한 능력을 통해 가능성의 세계를 열어줍니다. 행과 열을 사용하는 관계형 데이터베이스와 달리, 벡터 데이터베이스는 데이터를 여러 차원의 벡터로 저장하고 유사성을 기반으로 클러스터링합니다.
MySQL 및 PostgreSQL과 같은 관계형 데이터베이스는 오랫동안 많은 개발자에게 가장 선호되는 선택지였지만, 업계에서는 이러한 시스템에 벡터 검색 기능을 통합하려는 뚜렷한 변화가 나타나고 있습니다. 예를 들어 PostgreSQL 사용자는 벡터 데이터베이스 요구 사항을 위해 점점 더 Pgvector를 선택하고 있으며, 이는 데이터베이스 환경에서 성장하는 추세를 보여줍니다.
벡터 기반 작업을 지원하기 위해 관계형 데이터베이스는 일반적으로 벡터 공간에서 근사 최근접 이웃 검색을 수행하기 위해 HNSW(Hierarchical Navigable Small World)와 같은 인덱싱 기술을 추가합니다. 이는 AI 기반 애플리케이션에서 유사한 항목을 찾는 데 필수적입니다. 또한 이러한 데이터베이스는 기존 데이터와 함께 벡터 저장소를 제공하고 SQL 호환성을 유지하여, 사용자가 익숙한 SQL 명령을 활용해 벡터 데이터를 관리하고 쿼리할 수 있도록 합니다.
그러나 완전한 벡터 검색 엔진이 아니라 PostgreSQL 데이터베이스용 플러그인인 Pgvector와 달리, Milvus 및 Zilliz Cloud와 같은 전용 벡터 데이터베이스는 거의 실시간 성능으로 수십억 개의 고차원 벡터를 관리하고 쿼리하도록 처음부터 목적에 맞게 구축되었습니다. 이러한 전문 데이터베이스는 고급 인덱싱 기술을 활용해 유사도 검색을 효율적으로 처리하고, 유사도 기반 작업에 대해 뛰어난 성능을 제공하며, 대규모 벡터 데이터 관리를 지원합니다. 또한 AI 및 머신 러닝 애플리케이션에 맞게 조정된 강력한 API를 제공하므로, 복잡하고 대규모인 벡터 데이터 요구 사항에 매우 적합합니다.
벡터 인덱스가 중요한 이유
프로토타이핑 단계에서는 더 빠른 처리와 더 간단한 개발을 위해 모든 데이터를 메모리에 로드하는 것이 일반적입니다. 그러나 프로덕션에서 데이터 규모가 커지면 이 접근 방식은 다음과 같은 이유로 비현실적이 됩니다:
메모리 제한: 메모리는 제한적이며 디스크 스토리지보다 더 비쌉니다.
용량 문제: 대규모 데이터셋은 사용 가능한 메모리를 초과할 수 있습니다.
성능 영향: 모든 데이터를 메모리에 저장하면 시작 시간이 늘어나고 리소스 소비가 증가할 수 있습니다.
프로덕션에서 대규모 데이터셋을 효율적으로 처리하려면 올바른 인덱싱 전략을 선택하는 것이 매우 중요하고 의미가 큽니다. 적절한 벡터 인덱스는 쿼리 속도, 스토리지 요구 사항, 지연 시간의 균형을 맞춰 Retrieval Augmented Generation (RAG) 애플리케이션의 성능을 최적화합니다. 아래 다이어그램은 세 가지 핵심 지표를 기반으로 다양한 인덱스가 어떻게 성능을 발휘하는지 시각화하는 데 도움을 주며, 이 과정에서 사용자의 역할이 얼마나 중요한지를 강조합니다.
Milvus가 지원하는 인덱스
Queries Per Second (QPS): 초당 인덱스의 쿼리 처리 용량을 측정하며, 처리량과 효율성을 나타냅니다.
Storage: 인덱스에 필요한 디스크 공간을 반영하며, 인프라 비용과 확장성에 영향을 미칩니다.
Latency: 쿼리 결과를 처리하고 반환하는 데 걸리는 시간을 나타내며, 애플리케이션 응답성에 영향을 미칩니다.
이러한 지표를 비교함으로써 사용 사례와 성능 요구 사항에 가장 적합한 인덱스를 선택할 수 있습니다.
Milvus는 다양한 스토리지 및 성능 요구 사항에 맞춘 유연한 인덱스 선택 프레임워크를 제공합니다:
GPU Index: 고성능 환경에 이상적이며, 빠른 데이터 처리와 검색을 지원합니다.
Memory Index: 성능과 용량 간의 균형을 제공하며, 초당 쿼리 수(QPS) 비율에 적합하고, 평균 지연 시간이 약 10밀리초인 상태에서 테라바이트 규모의 스토리지까지 확장됩니다.
디스크 인덱스: 약 100밀리초의 지연 시간으로 수십 테라바이트를 처리하며, 더 크고 시간 민감도가 낮은 데이터셋에 적합합니다. Milvus는 디스크 인덱스를 지원하는 유일한 오픈 소스 벡터 데이터베이스로서 독보적입니다.
스왑 인덱스: S3 또는 기타 객체 스토리지와 메모리 간의 데이터 스와핑을 용이하게 하여 지연 시간을 관리하면서 비용을 약 10분의 1로 줄입니다. 일반적인 액세스 시간은 약 100밀리초이지만, 액세스 빈도가 낮은 데이터의 경우 몇 초까지 늘어날 수 있어 오프라인 사용 및 비용 민감형 애플리케이션에 적합합니다.
인덱스를 선택한 후에는 빌드 시간, 정확도, 성능 및 리소스 사용량을 기준으로 성능을 평가하세요. 예를 들어, 최적화되지 않은 인덱스는 초당 20개의 쿼리만 지원할 수 있는 반면, 최적화된 인덱스는 각 튜닝 반복마다 QPS를 10배 증가시킬 수 있지만, 이로 인해 빌드 시간이 늘어날 수도 있습니다.
인덱스를 효과적으로 선택하고 세부 조정하려면:
필요에 따라 인덱스 유형을 선택하세요.
성능 최적화를 위해 인덱스 매개변수를 조정하세요.
예상 성능을 보장하기 위해 사용 사례를 벤치마킹하세요.
결과를 더욱 향상시키기 위해 검색 매개변수를 조정하세요.
최적화 프로세스 전반에 대한 지침을 얻으려면 VectorDBBench와 같은 벤치마킹 도구를 사용하세요. Zilliz가 개발하고 오픈 소스로 공개한 VectorDBBench는 다양한 벡터 데이터베이스를 평가하여 최적의 성능을 위한 포괄적인 실험과 시스템 세부 조정을 가능하게 합니다.
빠른 참조를 위한 치트 시트가 제공되며, GPU 인덱스 카탈로그의 각 인덱스 성능을 요약하여 애플리케이션에 가장 적합한 인덱스로 안내함으로써 성능과 비용 효율성을 최적화하는 데 도움을 줍니다.
인덱스 치트 시트
벡터 검색을 위한 관계형 데이터베이스의 성능 벤치마크
앞서 언급했듯이, 기존 관계형 데이터베이스는 보통 1~2개의 벡터 인덱스를 사용하며, 이는 대규모 벡터 데이터를 처리할 때 성능 문제로 이어질 수 있습니다. 이러한 과제를 강조하기 위해 VectorDBBench는 벡터 데이터베이스 벤치마킹을 위해 설계된 오픈 소스 도구입니다. 이 도구는 다양한 주류 벡터 인덱스, 데이터베이스 및 클라우드 서비스를 평가하여 초당 쿼리 수(QPS), 달러당 쿼리 수(QP$), P99 지연 시간에 대한 편향 없는 지표를 제공합니다.
예를 들어, VectorDBBench는 Pgvector를 Milvus 또는 Zilliz와 비교할 수 있습니다. 벤치마크 결과는 Pgvector와 비교했을 때 Milvus와 Zilliz가 QPS, 속도 및 지연 시간에서 일관되게 우수한 성능을 제공한다는 것을 보여줍니다.
참고: 이는 특정 규칙에 따라 다양한 사례에서 각 시스템의 성능을 기반으로 한 1~100점입니다. 점수가 높을수록 성능이 더 좋음을 의미합니다.
참고: 이는 특정 규칙에 따라 다양한 사례에서 각 시스템의 성능을 기반으로 한 >1 점수입니다. 점수가 낮을수록 성능이 더 좋음을 의미합니다.
VectorDBBench를 사용하면 다양한 지표 측면에서 어떤 데이터베이스가 더 나은 성능을 보이는지 빠르게 파악할 수 있습니다. 또한 특정 요구 사항에 가장 적합한 데이터베이스를 결정할 수도 있습니다.
벡터 데이터베이스 사용 사례
기존 데이터베이스는 주로 트랜잭션 처리, 재고 추적 또는 급여 관리에 사용되는 반면, 벡터 데이터베이스는 인상적인 AI 기반 사용 사례의 개발을 지원하는 데 탁월합니다.
검색 증강 생성(RAG)
외부 데이터 소스를 LLM과 AI 애플리케이션에 통합하여 LLM의 지식을 확장합니다.
추천 시스템
사용자의 과거 행동과 선호도를 기반으로 정보나 제품을 추천합니다.
멀티모달 유사도 검색
텍스트, 동영상, 오디오, 이미지와 같은 다양한 모달리티 전반에서 쿼리합니다.
분자 유사도 검색
지정된 분자에 대해 유사한 하위 구조, 상위 구조 및 기타 구조를 검색합니다.
결론: 벡터 데이터베이스 vs 관계형 데이터베이스
애플리케이션에 적합한 데이터베이스를 선택하는 것은 단지 중요한 것이 아니라 필수적입니다. 관계형 데이터베이스는 구조화된 데이터를 관리하고 SQL로 복잡한 쿼리를 실행하는 데 강점이 있습니다. 반면, 벡터 데이터베이스는 비정형 데이터와 고차원 검색을 처리하도록 설계되어 AI 및 머신 러닝 작업에 더 나은 성능을 제공합니다. 이 결정의 중요성은 아무리 강조해도 지나치지 않습니다.
고급 인덱싱 및 검색 기능을 갖춘 벡터 데이터베이스는 대규모 고차원 데이터를 처리하는 데 있어 기존 관계형 데이터베이스보다 뛰어난 성능을 보이는 경우가 많습니다. 그러나 전문화된 벡터 데이터베이스를 추가하면 설정에 더 많은 요소가 추가되고 복잡성이 증가할 수 있으므로, 그 이점이 추가된 복잡성을 정당화하는지 평가하는 것이 중요합니다.
적절한 인덱싱 전략과 VectorDBBench 같은 벤치마킹 도구를 선택하면 성능을 최적화하고 요구 사항에 가장 적합한 선택을 하는 데 도움이 될 수 있습니다.
데이터베이스 솔루션과 성능에 대한 자세한 정보는 Zilliz Cloud를 확인하세요.
계속 읽기
Zilliz Cloud Update: Tiered Storage, Business Critical Plan, Cross-Region Backup, and Pricing Changes
This release offers a rebuilt tiered storage with lower costs, a new Business Critical plan for enhanced security, and pricing updates, among other features.
Zilliz Cloud Audit Logs Goes GA: Security, Compliance, and Transparency at Scale
Zilliz Cloud Audit Logs are now GA, giving enterprises real-time visibility, compliance-ready trails, and stronger security across AWS, GCP, and Azure.
OpenAI o1: What Developers Need to Know
In this article, we will talk about the o1 series from a developer's perspective, exploring how these models can be implemented for sophisticated use cases.