Разочарованы новыми данными? Наша векторная база данных может помочь
В эпоху Big Data какие технологии и приложения баз данных выйдут на первый план? Что станет следующим фактором, меняющим правила игры?
Поскольку неструктурированные данные составляют примерно 80–90% всех хранимых данных, что нам следует делать с этими растущими озёрами данных? Можно подумать об использовании традиционных аналитических методов, но они не способны извлечь полезную информацию, если вообще какую-либо. Чтобы ответить на этот вопрос, «Три мушкетёра» команды Research and Developement Zilliz, Dr. Rentong Guo, Mr. Xiaofan Luan и Dr. Xiaomeng Yi, совместно написали статью, чтобы обсудить проектирование и вызовы, возникающие при создании векторной базы данных общего назначения.
Эта статья была включена в Programmer, журнал, выпускаемый CSDN, крупнейшим сообществом разработчиков программного обеспечения в Китае. Этот выпуск Programmer также включает статьи Jeffrey Ullman, лауреата Turing Award 2020 года, Yann LeCun, лауреата Turing Award 2018 года, Mark Porter, CTO MongoDB, Zhenkun Yang, основателя OceanBase, Dongxu Huang, основателя PingCAP и др.
Ниже мы делимся с вами полной версией статьи:
Проектирование и практика AI-ориентированных векторных систем баз данных общего назначения
Введение
Современные приложения для работы с данными могут легко обрабатывать структурированные данные, которые составляют примерно 20% сегодняшних данных. В их инструментарии есть такие системы, как реляционные базы данных, базы данных NoSQL и т. д.; напротив, для неструктурированных данных, которые составляют примерно 80% всех данных, не существует каких-либо надёжных систем. Чтобы решить эту проблему, в этой статье будут рассмотрены болевые точки, с которыми традиционная аналитика данных сталкивается при работе с неструктурированными данными, а также архитектура и вызовы, с которыми мы столкнулись при создании собственной векторной базы данных общего назначения.
Революция данных в эпоху AI
С быстрым развитием технологий 5G и IoT отрасли стремятся расширить каналы сбора данных и ещё глубже перенести реальный мир в цифровое пространство. Хотя это принесло с собой серьёзные вызовы, оно также принесло огромные преимущества развивающейся индустрии. Один из таких сложных вызовов — как получить более глубокие инсайты из этих новых поступающих данных.
Согласно статистике IDC, только в 2020 году во всём мире было сгенерировано более 40 000 эксабайт новых данных. Из общего объёма лишь 20% составляют структурированные данные — данные, которые хорошо упорядочены и легко организуются и анализируются с помощью численных вычислений и реляционной алгебры. Напротив, неструктурированные данные (составляющие оставшиеся 80%) чрезвычайно богаты вариациями типов данных, что затрудняет раскрытие глубинной семантики традиционными методами анализа данных.
К счастью, мы наблюдаем параллельную, быструю эволюцию неструктурированных данных и AI, причём AI позволяет нам лучше понимать данные с помощью различных типов нейронных сетей, как показано на Figure 1.
Figure 1: Процесс embedding
Технология embedding быстро приобрела популярность после появления Word2vec, а идея «embed everything» проникла во все области машинного обучения. Это приводит к появлению двух основных слоёв данных: слоя исходных данных и слоя векторных данных. Слой исходных данных состоит из неструктурированных данных и определённых типов структурированных данных; векторный слой — это совокупность легко анализируемых embeddings, которые возникают из исходного слоя после прохождения через модели машинного обучения.
По сравнению с исходными данными, векторизованные данные обладают следующими преимуществами:
- Векторы эмбеддингов — это абстрактный тип данных, что означает, что мы можем построить унифицированную алгебраическую систему, предназначенную для снижения сложности неструктурированных данных.
- Векторы эмбеддингов выражаются через плотные векторы с плавающей точкой, что позволяет приложениям использовать преимущества SIMD. Поскольку SIMD поддерживается GPU и почти всеми современными CPU, вычисления по векторам могут достигать высокой производительности при относительно низких затратах.
- Векторные данные, закодированные с помощью моделей машинного обучения, занимают меньше места в хранилище, чем исходные неструктурированные данные, что обеспечивает более высокую пропускную способность.
- Над векторами эмбеддингов также можно выполнять арифметические операции. На рисунке 2 показан пример кросс-модального семантического приближенного сопоставления — изображения, показанные на рисунке, являются результатом сопоставления эмбеддингов слов с эмбеддингами изображений.
Рисунок 2: Визуализация семантического эмбеддинга на основе кросс-модальной нейронной языковой модели
Как показано на рисунке 3, объединение семантики изображений и слов может быть выполнено с помощью простого сложения и вычитания векторов между их соответствующими эмбеддингами.
Рисунок 3: Унифицированная визуализация семантического эмбеддинга на основе кросс-модальной нейронной языковой модели
Помимо перечисленных выше возможностей, эти операторы поддерживают более сложные запросы в практических сценариях. Хорошо известным примером является рекомендация контента. Как правило, система встраивает как сам контент, так и пользовательские предпочтения просмотра. Затем система сопоставляет встроенные предпочтения пользователя с наиболее похожим встроенным контентом с помощью анализа семантической близости, в результате чего подбирается новый контент, похожий на предпочтения пользователей. Этот слой векторных данных не ограничивается только рекомендательными системами; варианты использования включают электронную коммерцию, анализ вредоносного ПО, анализ данных, биометрическую верификацию, анализ химических формул, финансы, страхование и т. д.
Неструктурированные данные требуют полного базового программного стека
Системное программное обеспечение лежит в основе всех приложений, ориентированных на данные, но программное обеспечение систем данных, созданное за последние несколько десятилетий, например базы данных, движки анализа данных и т. д., предназначено для работы со структурированными данными. Современные приложения данных почти полностью полагаются на неструктурированные данные и не получают преимуществ от традиционных систем управления базами данных.
Чтобы решить эту проблему, мы разработали и выпустили в открытый доступ ориентированную на ИИ векторную базу данных общего назначения под названием Milvus (ссылки № 1~2). По сравнению с традиционными системами баз данных Milvus работает на другом уровне данных. Традиционные базы данных, такие как реляционные базы данных, KV-базы данных, текстовые базы данных, базы данных изображений/видео и т. д., работают на уровне сырых данных, тогда как Milvus работает на уровне векторных данных.
В следующих главах мы обсудим новые возможности, архитектурный дизайн и технические проблемы, с которыми мы столкнулись при создании Milvus.
Основные атрибуты векторной базы данных
Векторные базы данных хранят, извлекают, анализируют векторы и, как и любая другая база данных, также предоставляют стандартный интерфейс для операций CRUD. Помимо этих «стандартных» функций, перечисленные ниже атрибуты также являются важными качествами векторной базы данных:
- Поддержка высокоэффективных векторных операторов
Поддержка векторных операторов в аналитическом движке сосредоточена на двух уровнях. Во-первых, векторная база данных должна поддерживать различные типы операторов, например упомянутые выше сопоставление семантической близости и семантическую арифметику. Кроме того, она должна поддерживать различные метрики близости для базовых вычислений сходства. Такая близость обычно количественно выражается как пространственное расстояние между векторами, при этом распространенными метриками являются евклидово расстояние, косинусное расстояние и расстояние внутреннего произведения.
- Поддержка векторной индексации
По сравнению с индексами на основе B-tree или LSM-tree в традиционных базах данных, высокоразмерные векторные индексы обычно потребляют намного больше вычислительных ресурсов. Мы рекомендуем использовать алгоритмы кластерных и графовых индексов и отдавать приоритет матричным и векторным операциям, тем самым в полной мере используя упомянутые ранее возможности аппаратного ускорения векторных вычислений.
- Единообразный пользовательский опыт в разных средах развертывания
Векторные базы данных обычно разрабатываются и развертываются в разных средах. На предварительном этапе специалисты по данным и инженеры по алгоритмам работают в основном на своих ноутбуках и рабочих станциях, поскольку они уделяют больше внимания эффективности проверки и скорости итераций. Когда проверка завершена, они могут развернуть полноразмерную базу данных в частном кластере или в облаке. Поэтому квалифицированная система векторной базы данных должна обеспечивать стабильную производительность и пользовательский опыт в разных средах развертывания.
- Поддержка гибридного поиска
По мере повсеместного распространения векторных баз данных появляются новые приложения. Среди всех этих требований наиболее часто упоминается гибридный поиск по векторам и другим типам данных. Несколько примеров этого — поиск приблизительных ближайших соседей (ANNS) после скалярной фильтрации, многоканальный recall из полнотекстового поиска и векторного поиска, а также гибридный поиск по пространственно-временным данным и векторным данным. Такие задачи требуют эластичной масштабируемости и оптимизации запросов для эффективного объединения механизмов векторного поиска с KV, текстовыми и другими поисковыми механизмами.
- Облачная нативная архитектура
Объем векторных данных стремительно растет вместе с экспоненциальным ростом сбора данных. Триллионные масштабы высокоразмерных векторных данных соответствуют тысячам ТБ хранилища, что значительно превышает предел одного узла. В результате горизонтальная расширяемость является ключевой способностью векторной базы данных и должна удовлетворять требованиям пользователей к эластичности и гибкости развертывания. Кроме того, она также должна снижать сложность эксплуатации и обслуживания системы, одновременно повышая наблюдаемость при поддержке облачной инфраструктуры. Некоторые из этих потребностей проявляются в виде мультитенантной изоляции, снимков и резервного копирования данных, шифрования данных и визуализации данных, что обычно для традиционных баз данных.
Архитектура системы векторной базы данных
Milvus 2.0 следует принципам проектирования «журнал как данные», «унифицированная пакетная и потоковая обработка», «отсутствие состояния» и «микросервисы». На рисунке 4 показана общая архитектура Milvus 2.0.
Рисунок 4: Общая архитектура Milvus 2.0
Журнал как данные: Milvus 2.0 не поддерживает никаких физических таблиц. Вместо этого он обеспечивает надежность данных с помощью персистентности журналов и снимков журналов. Брокер журналов (основа системы) хранит журналы и разъединяет компоненты и сервисы посредством механизма публикации-подписки (pub-sub) журналов. Как показано на рисунке 5, брокер журналов состоит из «последовательности журналов» и «подписчика журнала». Последовательность журналов записывает все операции, изменяющие состояние коллекции (эквивалент таблицы в реляционной базе данных ); подписчик журнала подписывается на последовательность журналов, чтобы обновлять свои локальные данные и предоставлять сервисы в виде копий только для чтения. Механизм pub-sub также создает возможности для расширяемости системы в плане захвата измененных данных (CDC) и глобально распределенного развертывания.
Рисунок 5: Упрощенная модель хранения журналов
Унифицированная пакетная и потоковая обработка: потоковая передача журналов позволяет Milvus обновлять данные в реальном времени, тем самым обеспечивая доставку в реальном времени. Кроме того, преобразуя пакеты данных в снимки журналов и строя индексы на снимках, Milvus способен достигать более высокой эффективности запросов. Во время запроса Milvus объединяет результаты запроса как из инкрементальных данных, так и из исторических данных, чтобы гарантировать целостность возвращаемых данных. Такой дизайн лучше балансирует производительность в реальном времени и эффективность, снижая нагрузку на обслуживание как онлайн-, так и офлайн-систем по сравнению с традиционной архитектурой Lambda.
Без состояния: облачная инфраструктура и компоненты хранения с открытым исходным кодом освобождают Milvus от необходимости сохранять данные внутри собственных компонентов. Milvus 2.0 сохраняет данные с помощью трех типов хранилищ: хранилища метаданных, хранилища журналов и объектного хранилища. Хранилище метаданных не только хранит метаданные, но также обрабатывает обнаружение сервисов и управление узлами. Хранилище журналов выполняет сохранение инкрементальных данных и публикацию-подписку данных. Объектное хранилище хранит снимки журналов, индексы и некоторые промежуточные результаты вычислений.
Микросервисы: Milvus следует принципам разделения плоскости данных и плоскости управления, разделения чтения/записи и разделения онлайн-/офлайн-задач. Он состоит из четырех уровней сервисов: уровня доступа, уровня координатора, уровня рабочих узлов и уровня хранения. Эти уровни взаимно независимы с точки зрения масштабирования и аварийного восстановления. Как фронтальный уровень и пользовательская конечная точка, уровень доступа обрабатывает клиентские подключения, проверяет клиентские запросы и объединяет результаты запросов. Как «мозг» системы, уровень координатора берет на себя задачи управления топологией кластера, балансировки нагрузки, декларации данных и управления данными. Уровень рабочих узлов содержит «конечности» системы, выполняя обновления данных, запросы и операции построения индексов. Наконец, уровень хранения отвечает за сохранение и репликацию данных. В целом этот дизайн на основе микросервисов обеспечивает контролируемую сложность системы, где каждый компонент отвечает за свою соответствующую функцию. Milvus уточняет границы сервисов через четко определенные интерфейсы и разделяет сервисы на основе более мелкой гранулярности, что дополнительно оптимизирует эластичную масштабируемость и распределение ресурсов.
Технические вызовы, с которыми сталкиваются векторные базы данных
Ранние исследования векторных баз данных были в основном сосредоточены на проектировании высокоэффективных индексных структур и методов запросов — это привело к появлению множества библиотек алгоритмов векторного поиска (ссылки № 3~5). За последние несколько лет все больше академических и инженерных команд заново взглянули на проблемы векторного поиска с точки зрения системного проектирования и предложили некоторые системные решения. Обобщая существующие исследования и пользовательский спрос, мы классифицируем основные технические вызовы для векторных баз данных следующим образом:
- Оптимизация соотношения стоимости и производительности относительно нагрузки
По сравнению с традиционными типами данных анализ векторных данных требует гораздо больше ресурсов хранения и вычислений из-за их высокой размерности. Более того, пользователи продемонстрировали различные предпочтения в отношении характеристик нагрузки и оптимизации стоимости-производительности в решениях для векторного поиска. Например, пользователи, работающие с чрезвычайно большими наборами данных (десятки или сотни миллиардов векторов), предпочтут решения с более низкими затратами на хранение данных и меньшей вариативностью задержки поиска, тогда как другим может требоваться более высокая производительность поиска и неизменяющаяся средняя задержка. Чтобы удовлетворить такие разнообразные предпочтения, ключевой индексный компонент векторной базы данных должен быть способен поддерживать индексные структуры и алгоритмы поиска с различными типами аппаратного обеспечения для хранения и вычислений.
Например, хранение векторных данных и соответствующих индексных данных на более дешевых носителях (таких как NVM и SSD) следует учитывать при снижении затрат на хранение. Однако большинство существующих алгоритмов векторного поиска работают с данными, считываемыми непосредственно из памяти. Чтобы избежать потери производительности, вызванной использованием дисковых накопителей, векторная база данных должна уметь использовать локальность доступа к данным в сочетании с алгоритмами поиска, а также адаптироваться к решениям хранения для векторных данных и индексной структуры (Reference No. 6~8). В целях повышения производительности современные исследования сосредоточены на технологиях аппаратного ускорения с использованием GPU, NPU, FPGA и т. д. (Reference No. 9). Однако специализированное аппаратное обеспечение и чипы для ускорения различаются по архитектурному дизайну, и проблема наиболее эффективного выполнения на разных аппаратных ускорителях пока не решена.
- Автоматизированная конфигурация и настройка системы
Большинство существующих исследований алгоритмов векторного поиска стремятся к гибкому балансу между затратами на хранение, вычислительной производительностью и точностью поиска. Как правило, как параметры алгоритма, так и характеристики данных влияют на фактическую производительность алгоритма. Поскольку требования пользователей к затратам и производительности различаются, выбор метода векторного запроса, который соответствует их потребностям и характеристикам данных, представляет собой значительную проблему.
Тем не менее ручные методы анализа влияния распределения данных на алгоритмы поиска неэффективны из-за высокой размерности векторных данных. Для решения этой проблемы академическое сообщество и индустрия ищут решения по рекомендации алгоритмов на основе машинного обучения (Reference No. 10).
Разработка интеллектуального алгоритма векторного поиска на основе ML также является актуальным направлением исследований. В целом существующие алгоритмы векторного поиска разрабатываются универсально для векторных данных с различной размерностью и шаблонами распределения. В результате они не поддерживают конкретные индексные структуры в соответствии с характеристиками данных и, следовательно, имеют мало пространства для оптимизации. Будущие исследования также должны изучить эффективные технологии машинного обучения, которые могут адаптировать индексные структуры для различных характеристик данных (Reference No. 11-12).
- Поддержка расширенной семантики запросов
Современные приложения часто полагаются на более сложные запросы по векторам — традиционная семантика поиска ближайших соседей больше не применима к поиску векторных данных. Кроме того, возникает спрос на комбинированный поиск по нескольким векторным базам данных или по векторным и невекторным данным (Reference No. 13).
В частности, быстро растет разнообразие метрик расстояния для векторного сходства. Традиционные оценки сходства, такие как евклидово расстояние, расстояние внутреннего произведения и косинусное расстояние, не могут удовлетворить все требования приложений. С популяризацией технологии искусственного интеллекта многие отрасли разрабатывают собственные специализированные для своей области метрики векторного сходства, такие как расстояние Танимото, расстояние Махаланобиса, Superstructure и Substructure. Интеграция этих оценочных метрик в существующие алгоритмы поиска и разработка новых алгоритмов, использующих указанные метрики, являются сложными исследовательскими задачами.
По мере роста сложности пользовательских сервисов приложениям потребуется выполнять поиск как по векторным, так и по невекторным данным. Например, рекомендательная система контента анализирует предпочтения пользователей, социальные связи и сопоставляет их с текущими популярными темами, чтобы предоставлять пользователям подходящий контент. Такие поиски обычно включают запросы по нескольким типам данных или по нескольким системам обработки данных. Эффективная и гибкая поддержка такого гибридного поиска является еще одной задачей проектирования систем.
Авторы
Д-р Рентонг Го (Ph.D. в области компьютерного программного обеспечения и теории, Хуачжунский университет науки и технологий), партнер и директор по R&D в Zilliz. Он является членом Технического комитета Китайской компьютерной федерации по распределенным вычислениям и обработке (CCF TCDCP). Его исследования сосредоточены на базах данных, распределенных системах, системах кэширования и гетерогенных вычислениях. Его научные работы были опубликованы на нескольких ведущих конференциях и в журналах, включая Usenix ATC, ICS, DATE, TPDS. Как архитектор Milvus, д-р Го ищет решения для разработки высокомасштабируемых и экономически эффективных систем аналитики данных на основе ИИ.
Сяофань Луань, партнер и инженерный директор Zilliz, а также член Технического консультативного комитета LF AI & Data Foundation. Он последовательно работал в штаб-квартире Oracle в США и в Hedvig, стартапе в области программно-определяемого хранения данных. Он присоединился к команде Alibaba Cloud Database и отвечал за разработку NoSQL-базы данных HBase и Lindorm. Луань получил степень магистра в области электронной компьютерной инженерии в Корнеллском университете.
Д-р Сяомэн И (Ph.D. в области компьютерной архитектуры, Хуачжунский университет науки и технологий), старший исследователь и руководитель исследовательской группы Zilliz. Его исследования сосредоточены на управлении данными высокой размерности, крупномасштабном поиске информации и распределении ресурсов в распределенных системах. Научные работы д-ра И были опубликованы в ведущих журналах и на международных конференциях, включая IEEE Network Magazine, IEEE/ACM TON, ACM SIGMOD, IEEE ICDCS и ACM TOMPECS.
Филип Халтмайер, инженер данных Zilliz, окончил Калифорнийский университет в Санта-Крузе со степенью BS в области компьютерных наук. После присоединения к Zilliz Филип проводит большую часть своего времени, работая над облачными развертываниями, взаимодействием с клиентами, техническими выступлениями и разработкой приложений ИИ.
Ссылки
- Проект Milvus: https://github.com/milvus-io/milvus
- Milvus: специализированная система управления векторными данными, SIGMOD'21
- Проект Faiss: https://github.com/facebookresearch/faiss
- Проект Annoy: https://github.com/spotify/annoy
- Проект SPTAG: https://github.com/microsoft/SPTAG
- GRIP: многохранилищный, оптимизированный по емкости высокопроизводительный поиск ближайших соседей для векторной поисковой системы, CIKM'19
- DiskANN: быстрый точный поиск ближайших соседей среди миллиарда точек на одном узле, NIPS'19
- HM-ANN: эффективный поиск ближайших соседей среди миллиарда точек на гетерогенной памяти, NIPS'20
- SONG: приблизительный поиск ближайших соседей на GPU, ICDE'20
- Демонстрация сервиса настройки автоматической системы управления базами данных ottertune, VLDB'18
- Обоснование изучаемых индексных структур, SIGMOD'18
- Улучшение приблизительного поиска ближайших соседей с помощью обучаемого адаптивного раннего завершения, SIGMOD'20
- AnalyticDB-V: гибридный аналитический движок для объединения запросов к структурированным и неструктурированным данным, VLDB'20
Взаимодействуйте с нашим open-source-сообществом:
Читать далее
VDBBench Adds Cost-Aware Benchmarking for Vector Databases
Compare Zilliz Cloud, Pinecone, and turbopuffer with VDBBench cost-aware vector database benchmarks across latency, freshness, multitenancy, and cold starts.
The Great AI Agent Protocol Race: Function Calling vs. MCP vs. A2A
Compare Function Calling, MCP, and A2A protocols for AI agents. Learn which standard best fits your development needs and future-proof your applications.
Vector Databases vs. Time Series Databases
Use a vector database for similarity search and semantic relationships; use a time series database for tracking value changes over time.