Реляционные базы данных против векторных баз данных
Базы данных давно создают трудности для производительности приложений, часто требуя обширной тонкой настройки. В ответ появились новые архитектуры баз данных, призванные улучшить масштабируемость, производительность и продуктивность разработчиков, упрощая создание определенных типов приложений.
Тем не менее у этих новых решений для баз данных есть свои компромиссы. Каждая архитектура предполагает уступки, при которых одни преимущества достигаются за счет других. Понимание этих вариантов и связанных с ними компромиссов крайне важно для выбора лучшего инструмента под ваши нужды. В этой статье мы рассмотрим векторные базы данных и сравним их с традиционными реляционными базами данных, чтобы помочь вам принять хорошо обоснованное решение.
Зачем выбирать специализированную базу данных для вашего приложения?
В последние годы наблюдается всплеск специализированных баз данных, адаптированных под конкретные сценарии использования:
Графовая база данных: Предназначенные для эффективного хранения и анализа данных с большим количеством связей, графовые базы данных отлично справляются с управлением отношениями между точками данных (knowledge graph).
Поисковая база данных: Эти базы данных работают с неструктурированными или полуструктурированными данными и оптимизированы для быстрого и эффективного поиска и выполнения запросов.
База данных временных рядов: Оптимизированные для высокой пропускной способности записи и time-based queries, базы данных временных рядов обрабатывают рабочие нагрузки с частыми и масштабными записями данных с временными метками.
База данных ключ-значение: Известные своей высокой производительностью и масштабируемостью, базы данных ключ-значение хранят данные в виде простых пар ключ-значение без дополнительных метаданных, что делает их идеальными для быстрых операций чтения и записи.
База данных в памяти: Эти базы данных хранят данные в RAM, а не на диске, устраняя задержки доступа к диску и значительно повышая производительность.
Векторная база данных: Эти базы данных созданы для хранения векторных эмбеддингов и оптимизированы для обработки вычислительно интенсивного semantic search.
Хотя реляционные базы данных (RDBMS) по-прежнему доминируют по доле рынка, специализированные базы данных быстро набирают популярность, при этом векторные базы данных, базы данных временных рядов, базы данных ключ-значение и графовые базы данных демонстрируют наиболее значительный рост за последние два года.
Сдвиг в сторону специализированных баз данных обусловлен растущими требованиями к производительности и расширенным функциям, поскольку пользователи ожидают, что программное обеспечение будет соответствовать высоким стандартам, заданным ведущими технологическими компаниями. Кроме того, рост архитектур микросервисов способствовал внедрению специализированных баз данных. Микросервисы, независимо развертываемые и абстрагированные друг от друга, позволяют командам выбирать лучшие инструменты для конкретных функций приложения без глубокого знания технологий других сервисов.
Однако интеграция еще одной базы данных в архитектуру добавляет сложности. Крайне важно оценить, перевешивают ли преимущества специализированной базы данных затраты и сложности. Тщательная оценка плюсов и минусов необходима перед принятием решений, которые в долгосрочной перспективе повлияют на ваше приложение.
"На практике создание единой системы управления данными, поддерживающей различные рабочие нагрузки и приложения, представляет собой сложную задачу. Если сравнить это с автомобильной индустрией, мы не можем представить одно транспортное средство, которое служило бы всем целям, — внедорожники, грузовики, седаны и школьные автобусы проектируются с учетом конкретных функций. Аналогично, в мире баз данных системы оптимизируются под разные потребности, и универсальное решение, подходящее для всех, маловероятно. Будущее заключается в разработке более специализированных баз данных, адаптированных под конкретные требования. Хотя мы можем увидеть единые интерфейсы или SDK для взаимодействия с разнообразными системами баз данных, тенденция будет продолжаться в сторону все более специализированных решений." Charles Xie, основатель и CEO Zilliz.**
Обзор реляционных баз данных
Реляционные базы данных, также известные как традиционные базы данных, — это универсальные инструменты, которые управляют данными в табличном формате. Эта структура, организованная в строки и столбцы, обеспечивает эффективное хранение и извлечение данных, обычно управляемых на диске. Использование SQL еще больше повышает их универсальность, поддерживая широкий спектр запросов. Такая адаптивность делает реляционные базы данных подходящими для различных приложений. Они особенно ценятся за способность обеспечивать структурированные связи между наборами данных, гарантируя согласованность и целостность данных с помощью заранее определенных схем.
Хранение данных: строки и столбцы
Реляционные базы данных используют систематическое расположение строк и столбцов для хранения данных. Каждая строка представляет отдельную запись, а каждый столбец — поле данных или атрибут. Этот организованный формат облегчает доступ к данным и управление ими, позволяя пользователям эффективно перемещаться по хранилищам данных и обновлять информацию в базе данных.
Возможности запросов
Structured Query Language (SQL) — ключевая особенность реляционных баз данных, позволяющая пользователям формулировать точные запросы для извлечения и совместной обработки сложных данных. SQL предоставляет надежную основу для фильтрации, сортировки и извлечения данных, упрощая выполнение сложных поисков и операций с большими наборами данных. Используя SQL, пользователи могут быстро находить релевантную информацию и создавать подробные отчеты на основе конкретных критериев.
Свойства ACID
Транзакции реляционных баз данных регулируются четырьмя ключевыми свойствами, известными как ACID: атомарность, согласованность, изоляция и долговечность. Атомарность гарантирует, что все аспекты транзакции выполняются как единое целое, не оставляя частичных обновлений. Согласованность поддерживает целостность данных, гарантируя, что транзакции приводят к допустимым состояниям. Изоляция не позволяет транзакциям влиять друг на друга до их полного подтверждения, тем самым предотвращая конфликты. Наконец, долговечность гарантирует, что после подтверждения транзакции изменения становятся постоянными, даже в случае сбоя системы.
Обзор векторных баз данных
Итак, что же такое векторная база данных? По своей сути векторная база данных — это специализированная система, предназначенная для работы с неструктурированными данными за счет использования их векторных представлений и эмбеддингов. Такой подход позволяет быстро извлекать семантическую информацию и эффективно выполнять поиск по сходству.
Векторные базы данных играют ключевую роль в современной экосистеме AI, особенно в генерации с дополненным поиском (RAG). RAG повышает производительность больших языковых моделей (LLMs) за счет интеграции внешних знаний, что помогает снизить количество галлюцинаций AI и повышает точность генерируемых ответов. Эти базы данных управляют контекстной информацией и извлекают ее, а LLMs используют ее для создания более надежных ответов.
Они широко применяются в различных областях, включая чат-боты, рекомендательные системы и мультимедийный поиск, такой как извлечение изображений, видео и аудио.
Векторные базы данных и реляционные базы данных
Традиционные реляционные базы данных отлично справляются с управлением структурированными данными, использованием заранее определенных схем и выполнением точного поиска в табличных форматах данных. В отличие от них, векторные базы данных, обладая уникальной способностью работать с неструктурированными данными, такими как изображения, аудио, видео и текст, путем представления этих типов данных в виде многомерных векторов, открывают целый мир возможностей. В отличие от реляционных баз данных, которые используют строки и столбцы, векторные базы данных хранят данные как векторы с несколькими измерениями, группируя их на основе сходства.
Хотя реляционные базы данных, такие как MySQL и PostgreSQL, уже давно являются предпочтительным выбором для многих разработчиков, в индустрии заметен сдвиг в сторону внедрения возможностей векторного поиска в эти системы. Например, пользователи PostgreSQL всё чаще обращаются к Pgvector для своих потребностей в векторных базах данных, что указывает на растущий тренд в ландшафте баз данных.
Для поддержки операций на основе векторов реляционные базы данных обычно добавляют технологии индексирования, такие как HNSW (Hierarchical Navigable Small World), чтобы выполнять приближённый поиск ближайших соседей в векторном пространстве. Это необходимо для поиска похожих элементов в приложениях на базе ИИ. Кроме того, эти базы данных предлагают хранение векторов наряду с традиционными данными и сохраняют совместимость с SQL, позволяя пользователям использовать знакомые команды SQL для управления векторными данными и выполнения запросов к ним.
Однако, в отличие от Pgvector, который является не полноценным движком векторного поиска, а скорее плагином для баз данных PostgreSQL, специализированные векторные базы данных, такие как Milvus и Zilliz Cloud, изначально создавались для управления миллиардами многомерных векторов и выполнения запросов к ним с производительностью, близкой к реальному времени. Эти специализированные базы данных используют передовые методы индексирования для эффективной обработки поиска по сходству, обеспечивают более высокую производительность для операций на основе сходства и поддерживают управление векторными данными большого масштаба. Они также предлагают надёжные API, адаптированные для приложений ИИ и машинного обучения, что делает их хорошо подходящими для сложных и крупномасштабных потребностей в векторных данных.
Почему векторные индексы важны
На этапе прототипирования загрузка всех данных в память является распространённой практикой для более быстрой обработки и более простой разработки. Однако по мере масштабирования данных в production такой подход становится непрактичным из-за:
Ограничений памяти: Память ограничена и дороже дискового хранилища.
Проблем с ёмкостью: Большие наборы данных могут превышать доступный объём памяти.
Влияния на производительность: Хранение всех данных в памяти может увеличить время запуска и потребление ресурсов.
Для эффективной обработки больших наборов данных в production выбор правильной стратегии индексирования имеет решающее значение. Подходящий векторный индекс оптимизирует производительность вашего приложения Retrieval Augmented Generation (RAG), балансируя скорость запросов, потребности в хранении и задержку. Диаграмма ниже помогает визуализировать, как различные индексы работают по трём ключевым метрикам, подчёркивая значимость вашей роли в этом процессе.
Индексы, поддерживаемые Milvus
Запросы в секунду (QPS): Измеряет способность индекса обрабатывать запросы в секунду, указывая на пропускную способность и эффективность.
Хранилище: Отражает дисковое пространство, необходимое для индекса, влияя на затраты на инфраструктуру и масштабируемость.
Задержка: Представляет время, необходимое для обработки и возврата результатов запроса, влияя на отзывчивость приложения.
Сравнивая эти метрики, вы можете выбрать индекс, который лучше всего соответствует вашему сценарию использования и требованиям к производительности.
Milvus предлагает гибкую систему выбора индексов, адаптированную к различным требованиям к хранению и производительности:
GPU Index: Идеален для высокопроизводительных сред, поддерживает быструю обработку и извлечение данных.
Memory Index: Обеспечивает баланс между производительностью и ёмкостью, подходит для показателей запросов в секунду (QPS) и масштабируется до терабайтов хранилища со средней задержкой около десяти миллисекунд.
Дисковый индекс: Обрабатывает десятки терабайт с задержкой около 100 миллисекунд, подходит для более крупных, менее чувствительных ко времени наборов данных. Milvus уникален как единственная векторная база данных с открытым исходным кодом, поддерживающая дисковые индексы.
Индекс Swap: Обеспечивает обмен данными между S3 или другим объектным хранилищем и памятью, снижая затраты примерно в десять раз при управлении задержкой. Типичное время доступа составляет около 100 миллисекунд, но может увеличиваться до нескольких секунд для менее часто используемых данных, что делает его подходящим для офлайн-использования и приложений, чувствительных к стоимости.
После выбора индекса оцените его производительность на основе времени построения, точности, производительности и использования ресурсов. Например, неоптимизированный индекс может поддерживать только 20 запросов в секунду, тогда как оптимизированный индекс может увеличивать QPS в десять раз с каждой итерацией настройки, хотя это также может увеличить время построения.
Чтобы эффективно выбрать и тонко настроить ваш индекс:
Выберите тип индекса на основе ваших потребностей.
Настройте параметры индекса для оптимизации производительности.
Проведите бенчмаркинг ваших сценариев использования, чтобы убедиться в ожидаемой производительности.
Настройте параметры поиска, чтобы дополнительно улучшить результаты.
Для сопровождения процесса оптимизации используйте инструменты бенчмаркинга, такие как VectorDBBench. Разработанный и открытый Zilliz, VectorDBBench оценивает различные векторные базы данных, позволяя проводить комплексные эксперименты и тонкую настройку системы для оптимальной производительности.
Для быстрого справочника доступна шпаргалка, описывающая производительность каждого индекса в нашем каталоге GPU-индексов, помогая вам оптимизировать производительность и экономическую эффективность, направляя вас к лучшему индексу для вашего приложения.
Шпаргалка по индексам
Бенчмарки производительности реляционных баз данных для векторного поиска
Как упоминалось, традиционные реляционные базы данных часто используют 1-2 векторных индекса, что может приводить к проблемам производительности при обработке векторных данных большого масштаба. Чтобы подчеркнуть эту проблему, VectorDBBench — это инструмент с открытым исходным кодом, разработанный для бенчмаркинга векторных баз данных. Он оценивает различные популярные векторные индексы, базы данных и облачные сервисы, предоставляя объективные метрики по количеству запросов в секунду (QPS), запросам на доллар (QP$) и задержке P99.
Например, VectorDBBench может сравнивать Pgvector с Milvus или Zilliz. Результаты бенчмарков последовательно показывают, что Milvus и Zilliz обеспечивают превосходную производительность по QPS, скорости и задержке по сравнению с Pgvector.
Примечание: Это оценка от 1 до 100, основанная на производительности каждой системы в разных случаях согласно конкретному правилу. Более высокая оценка означает лучшую производительность.
Примечание: Это оценка >1, основанная на производительности каждой системы в разных случаях согласно конкретному правилу. Более низкая оценка означает лучшую производительность.
С помощью VectorDBBench вы можете быстро понять, какая база данных показывает лучшие результаты по различным метрикам. Вы также можете определить, какая база данных лучше всего соответствует вашим конкретным потребностям.
Сценарии использования векторных баз данных
Традиционные базы данных в основном используются для обработки транзакций, отслеживания запасов или управления заработной платой, тогда как векторные базы данных превосходно поддерживают разработку впечатляющих сценариев использования на основе ИИ.
Retrieval Augmented Generation (RAG)
Расширяйте знания LLM, включая внешние источники данных в LLM и ваши AI-приложения.
Recommender System
Рекомендуйте пользователям информацию или продукты на основе их прошлого поведения и предпочтений.
Multimodal Similarity Search
Выполняйте запросы по различным модальностям, таким как тексты, видео, аудио и изображения.
Molecular Similarity Search
Ищите похожие подструктуры, суперструктуры и другие структуры для заданной молекулы.
Заключение: векторная база данных vs реляционная база данных
Выбор правильной базы данных для вашего приложения не просто важен; он необходим. Реляционные базы данных сильны в управлении структурированными данными и выполнении сложных запросов с помощью SQL. В отличие от них, векторные базы данных предназначены для обработки неструктурированных данных и высокоразмерного поиска, обеспечивая лучшую производительность для задач ИИ и машинного обучения. Значимость этого решения невозможно переоценить.
Благодаря своим передовым возможностям индексирования и поиска векторные базы данных часто превосходят традиционные реляционные базы данных при работе с крупномасштабными высокоразмерными данными. Однако добавление специализированных векторных баз данных может усложнить вашу инфраструктуру и повысить сложность, поэтому важно оценить, оправдывают ли преимущества дополнительную сложность.
Выбор правильной стратегии индексирования и инструментов бенчмаркинга, таких как VectorDBBench, может помочь оптимизировать производительность и гарантировать, что вы сделаете лучший выбор для своих потребностей.
Для получения дополнительной информации о решениях для баз данных и производительности ознакомьтесь с Zilliz Cloud.
Читать далее
The AWS Outage Was a Wake-Up Call for Vector Database Cross-Region Disaster Recovery
Zilliz Cloud Had the Answer Before the Crisis. Zilliz Cloud is the world's first vector database with native cross-region disaster recovery.
Why and How to Migrate from Self-Hosted Milvus to Zilliz Cloud
A simple, step-by-step guide to migrating from Milvus to Zilliz Cloud. Learn both endpoint and backup methods for a smooth, scalable vector database migration.
Demystifying the Milvus Sizing Tool
Explore how to use the Sizing Tool to select the optimal configuration for your Milvus deployment.