🚀 Попробуйте Zilliz Cloud, полностью управляемый Milvus, бесплатно — ощутите 10-кратное увеличение производительности! Попробовать сейчас>

milvus-logo
LFAI

Введение

  • Engineering
November 08, 2021
Zilliz

В эпоху Больших Данных какие технологии и приложения баз данных выйдут на первый план? Что станет следующей революцией?

Поскольку неструктурированные данные составляют примерно 80-90% всех хранимых данных, что нам делать с этими растущими озерами данных? Можно подумать об использовании традиционных аналитических методов, но они не позволяют извлечь полезную информацию, если вообще таковая имеется. Чтобы ответить на этот вопрос, "три мушкетера" из команды исследователей и разработчиков Zilliz, доктор Рентонг Гуо, мистер Сяофан Луань и доктор Сяоменг Йи, написали статью, в которой обсуждают дизайн и проблемы, возникающие при создании векторной базы данных общего назначения.

Эта статья была включена в журнал Programmer, выпускаемый CSDN, крупнейшим сообществом разработчиков программного обеспечения в Китае. В этом номере журнала Programmer также опубликованы статьи Джеффри Ульмана, лауреата премии Тьюринга 2020 года, Янна ЛеКуна, лауреата премии Тьюринга 2018 года, Марка Портера, технического директора MongoDB, Чжэнькунь Яна, основателя OceanBase, Донгсу Хуана, основателя PingCAP, и других.

Ниже мы делимся с вами полным текстом статьи:

Введение

Современные приложения для работы с данными легко справляются со структурированными данными, которые составляют примерно 20 % от общего объема данных. В их арсенале такие системы, как реляционные базы данных, базы данных NoSQL и т. д.; в то время как для неструктурированных данных, на которые приходится около 80 % всех данных, надежных систем не существует. Чтобы решить эту проблему, в данной статье мы рассмотрим болевые точки, с которыми сталкивается традиционная аналитика данных при работе с неструктурированными данными, а также обсудим архитектуру и проблемы, с которыми мы столкнулись при создании собственной системы векторных баз данных общего назначения.

Революция данных в эпоху ИИ

С бурным развитием технологий 5G и IoT отрасли стремятся расширить каналы сбора данных и еще больше перенести реальный мир в цифровое пространство. Несмотря на то, что это породило ряд серьезных проблем, это также принесло огромные преимущества для растущей индустрии. Одна из таких сложных проблем - как получить более глубокие знания о новых поступающих данных.

Согласно статистике IDC, только в 2020 году в мире будет сгенерировано более 40 000 эксабайт новых данных. Из общего объема только 20 % составляют структурированные данные - данные, которые имеют высокий уровень упорядоченности и легко поддаются систематизации и анализу с помощью числовых вычислений и реляционной алгебры. В отличие от них, неструктурированные данные (составляющие оставшиеся 80 %) чрезвычайно богаты вариациями типов данных, что затрудняет раскрытие их глубокой семантики с помощью традиционных методов анализа данных.

К счастью, мы наблюдаем одновременную и быструю эволюцию неструктурированных данных и ИИ. ИИ позволяет нам лучше понять данные с помощью различных типов нейронных сетей, как показано на рисунке 1.

newdata1.jpeg newdata1.jpeg

Технология встраивания быстро набрала популярность после дебюта Word2vec, и идея "встраивать все" охватила все отрасли машинного обучения. Это привело к появлению двух основных слоев данных: слоя необработанных данных и слоя векторных данных. Слой необработанных данных состоит из неструктурированных данных и некоторых типов структурированных данных; векторный слой - это коллекция легко анализируемых вкраплений, полученных из необработанных данных и прошедших через модели машинного обучения.

По сравнению с необработанными данными векторизованные данные имеют следующие преимущества:

  • Векторы вкраплений - это абстрактный тип данных, а значит, мы можем построить единую систему алгебры, предназначенную для снижения сложности неструктурированных данных.
  • Векторы вложения выражаются через плотные векторы с плавающей точкой, что позволяет приложениям использовать преимущества SIMD. Поскольку SIMD поддерживается графическими процессорами и почти всеми современными CPU, вычисления с векторами могут достигать высокой производительности при относительно низкой стоимости.
  • Векторные данные, закодированные с помощью моделей машинного обучения, занимают меньше места для хранения, чем исходные неструктурированные данные, что позволяет повысить пропускную способность.
  • Арифметические действия также могут выполняться через векторы встраивания. На рисунке 2 показан пример кросс-модального семантического приближенного сопоставления - изображения, показанные на рисунке, являются результатом сопоставления вкраплений слов с вкраплениями изображений.

newdata2.png newdata2.png

Как показано на рисунке 3, объединение семантики изображений и слов может быть выполнено с помощью простого сложения и вычитания векторов соответствующих вкраплений.

newdata3.png newdata3.png

Помимо вышеперечисленных возможностей, эти операторы поддерживают более сложные запросы в практических сценариях. Известным примером является рекомендация контента. Как правило, в систему встраивается как контент, так и предпочтения пользователей по просмотру. Затем система сопоставляет встроенные предпочтения пользователя с наиболее похожим встроенным контентом с помощью анализа семантического сходства, в результате чего появляется новый контент, который соответствует предпочтениям пользователя. Векторный слой данных используется не только в рекомендательных системах, но и в электронной коммерции, анализе вредоносных программ, анализе данных, биометрической верификации, анализе химических формул, финансах, страховании и т. д.

Неструктурированные данные требуют полного стека базового программного обеспечения

Системное программное обеспечение лежит в основе всех приложений, ориентированных на работу с данными, но системное программное обеспечение, созданное за последние несколько десятилетий, например базы данных, механизмы анализа данных и т. д., предназначено для работы со структурированными данными. Современные приложения для работы с данными опираются почти исключительно на неструктурированные данные и не могут воспользоваться преимуществами традиционных систем управления базами данных.

Чтобы решить эту проблему, мы разработали и выложили в открытый доступ ориентированную на ИИ векторную базу данных общего назначения под названием Milvus (ссылки № 1~2). По сравнению с традиционными системами баз данных, Milvus работает на другом уровне данных. Традиционные базы данных, такие как реляционные базы данных, базы данных KV, текстовые базы данных, базы данных изображений/видео и т. д... работают на слое сырых данных, в то время как Milvus работает на слое векторных данных.

В следующих главах мы обсудим новые возможности, архитектурный дизайн и технические проблемы, с которыми мы столкнулись при создании Milvus.

Основные атрибуты векторной базы данных

Векторные базы данных хранят, извлекают, анализируют векторы и, как и любая другая база данных, предоставляют стандартный интерфейс для CRUD-операций. В дополнение к этим "стандартным" возможностям, перечисленные ниже атрибуты также являются важными качествами для векторной базы данных:

  • Поддержка высокоэффективных векторных операторов

Поддержка векторных операторов в аналитическом механизме сосредоточена на двух уровнях. Во-первых, векторная база данных должна поддерживать различные типы операторов, например, сопоставление семантического сходства и семантическую арифметику, о которых говорилось выше. Кроме того, она должна поддерживать различные метрики сходства для базовых расчетов сходства. Такое сходство обычно выражается в виде пространственного расстояния между векторами, а общими метриками являются евклидово расстояние, косинусное расстояние и расстояние внутреннего произведения.

  • Поддержка индексации векторов

По сравнению с индексами на основе B-дерева или LSM-дерева в традиционных базах данных, высокоразмерные векторные индексы обычно потребляют гораздо больше вычислительных ресурсов. Мы рекомендуем использовать алгоритмы кластеризации и графовых индексов, а также отдавать приоритет матричным и векторным операциям, чтобы в полной мере использовать возможности аппаратного ускорения векторных вычислений, о которых говорилось ранее.

  • Последовательность работы пользователей в различных средах развертывания

Векторные базы данных обычно разрабатываются и развертываются в разных средах. На предварительном этапе специалисты по обработке данных и инженеры-алгоритмисты работают в основном на своих ноутбуках и рабочих станциях, поскольку уделяют больше внимания эффективности проверки и скорости итераций. После завершения проверки они могут развернуть полноразмерную базу данных на частном кластере или в облаке. Поэтому квалифицированная система векторных баз данных должна обеспечивать стабильную производительность и удобство работы в различных средах развертывания.

  • Поддержка гибридного поиска

По мере повсеместного распространения векторных баз данных появляются новые приложения. Среди всех этих требований наиболее часто упоминается гибридный поиск по векторам и другим типам данных. В качестве примера можно привести приближенный поиск ближайших соседей (ANNS) после скалярной фильтрации, многоканальный поиск с использованием полнотекстового поиска и векторного поиска, а также гибридный поиск пространственно-временных и векторных данных. Такие задачи требуют эластичной масштабируемости и оптимизации запросов для эффективного объединения векторных поисковых систем с KV, текстовыми и другими поисковыми системами.

  • Архитектура, основанная на облачных вычислениях

Объем векторных данных растет по мере экспоненциального роста сбора данных. Высокоразмерные векторные данные триллионного масштаба соответствуют тысячам ТБ хранения, что далеко выходит за пределы возможностей одного узла. Таким образом, горизонтальная расширяемость является ключевой способностью для векторной базы данных и должна удовлетворять требованиям пользователей к эластичности и гибкости развертывания. Кроме того, она должна снизить сложность эксплуатации и обслуживания системы, а также улучшить наблюдаемость с помощью облачной инфраструктуры. Некоторые из этих потребностей проявляются в виде многопользовательской изоляции, моментального снимка и резервного копирования данных, шифрования данных и визуализации данных, которые характерны для традиционных баз данных.

Архитектура системы векторных баз данных

Milvus 2.0 следует принципам проектирования "журнал как данные", "унифицированная пакетная и потоковая обработка", "без статических данных" и "микросервисы". На рисунке 4 показана общая архитектура Milvus 2.0.

newdata4.png newdata4.png

Журнал как данные: Milvus 2.0 не поддерживает никаких физических таблиц. Вместо этого он обеспечивает надежность данных с помощью персистентности журнала и снимков журнала. Брокер журналов (основа системы) хранит журналы и разделяет компоненты и сервисы с помощью механизма публикации и подписки журналов (pub-sub). Как показано на рисунке 5, брокер журналов состоит из "последовательности журналов" и "подписчика журналов". Последовательность журналов записывает все операции, изменяющие состояние коллекции (эквивалент таблицы в реляционной базе данных); подписчик журналов подписывается на последовательность журналов для обновления своих локальных данных и предоставления услуг в виде копий, доступных только для чтения. Механизм pub-sub также позволяет расширить систему в плане сбора данных об изменениях (CDC) и глобально-распределенного развертывания.

newdata5.png newdata5.png

Унифицированная пакетная и потоковая обработка: Потоковая обработка журналов позволяет Milvus обновлять данные в режиме реального времени, обеспечивая тем самым их доставку в реальном времени. Кроме того, благодаря преобразованию пакетов данных в снимки журнала и созданию индекса на основе снимков Milvus может достичь более высокой эффективности запросов. Во время выполнения запроса Milvus объединяет результаты запроса, полученные из инкрементных и исторических данных, чтобы гарантировать целостность возвращаемых данных. Такая конструкция позволяет лучше сбалансировать производительность и эффективность в реальном времени, облегчая нагрузку по обслуживанию как онлайн-, так и офлайн-систем по сравнению с традиционной архитектурой Lambda.

Нестационарность: Облачная инфраструктура и компоненты хранения данных с открытым исходным кодом освобождают Milvus от необходимости сохранять данные внутри собственных компонентов. Milvus 2.0 сохраняет данные с помощью трех типов хранилищ: хранилища метаданных, хранилища журналов и объектного хранилища. Хранилище метаданных не только хранит метаданные, но и обрабатывает обнаружение сервисов и управление узлами. Хранилище журналов выполняет инкрементную персистенцию данных и публикацию-подписку данных. Объектное хранилище хранит снимки журналов, индексы и некоторые промежуточные результаты вычислений.

Микросервисы: Milvus следует принципам дезагрегации плоскости данных и плоскости управления, разделения чтения и записи, а также разделения задач на онлайн и офлайн. Он состоит из четырех сервисных уровней: уровня доступа, уровня координатора, рабочего уровня и уровня хранения. Эти уровни являются взаимно независимыми, когда речь идет о масштабировании и аварийном восстановлении. В качестве лицевого уровня и конечной точки пользователя уровень доступа обрабатывает клиентские соединения, проверяет запросы клиентов и объединяет результаты запросов. Являясь "мозгом" системы, уровень координаторов берет на себя задачи управления топологией кластера, балансировки нагрузки, объявления данных и управления данными. Рабочий слой содержит "конечности" системы, выполняя обновления данных, запросы и операции построения индексов. Наконец, слой хранения отвечает за сохранение и репликацию данных. В целом такой дизайн, основанный на микросервисах, обеспечивает контролируемую сложность системы, при этом каждый компонент отвечает за свою соответствующую функцию. Milvus уточняет границы сервисов с помощью четко определенных интерфейсов и разделяет сервисы на основе более тонкой гранулярности, что дополнительно оптимизирует эластичную масштабируемость и распределение ресурсов.

Технические проблемы, с которыми сталкиваются векторные базы данных

Ранние исследования векторных баз данных были сосредоточены в основном на разработке высокоэффективных индексных структур и методов запросов - это привело к появлению множества библиотек алгоритмов векторного поиска (ссылки № 3~5). За последние несколько лет все большее число научных и инженерных коллективов по-новому взглянули на проблемы векторного поиска с точки зрения системного дизайна и предложили несколько систематических решений. Обобщая результаты существующих исследований и запросы пользователей, мы классифицируем основные технические проблемы векторных баз данных следующим образом:

  • Оптимизация соотношения стоимости и производительности в зависимости от нагрузки

По сравнению с традиционными типами данных, анализ векторных данных требует гораздо больше ресурсов для хранения и вычислений из-за их высокой размерности. Кроме того, пользователи демонстрируют различные предпочтения в отношении характеристик нагрузки и оптимизации соотношения цены и производительности решений для векторного поиска. Например, пользователи, работающие с очень большими наборами данных (десятки или сотни миллиардов векторов), предпочтут решения с меньшими затратами на хранение данных и разбросом времени поиска, в то время как другие могут требовать более высокой производительности поиска и неизменного среднего времени ожидания. Чтобы удовлетворить такие разные предпочтения, основной индексный компонент векторной базы данных должен быть способен поддерживать индексные структуры и алгоритмы поиска с различными типами хранилищ и вычислительного оборудования.

Например, хранение векторных данных и соответствующих индексных данных на более дешевых носителях (таких как NVM и SSD) должно учитываться при снижении стоимости хранения. Однако большинство существующих алгоритмов векторного поиска работают с данными, считываемыми непосредственно из памяти. Чтобы избежать потерь производительности, связанных с использованием дисковых накопителей, векторная база данных должна использовать локальность доступа к данным в сочетании с алгоритмами поиска, а также уметь подстраиваться под решения для хранения векторных данных и индексной структуры (ссылки № 6~8). Для повышения производительности современные исследования сосредоточены на технологиях аппаратного ускорения, включающих GPU, NPU, FPGA и т. д. (ссылка № 9). Однако аппаратные средства ускорения и чипы различаются по архитектуре, и проблема наиболее эффективного выполнения на разных аппаратных ускорителях еще не решена.

  • Автоматизированная настройка и конфигурирование системы

Большинство существующих исследований алгоритмов векторного поиска направлены на поиск гибкого баланса между стоимостью хранения данных, вычислительной производительностью и точностью поиска. Как правило, на фактическую производительность алгоритма влияют как параметры алгоритма, так и характеристики данных. Поскольку требования пользователей различаются по стоимости и производительности, выбор метода векторного запроса, соответствующего их потребностям и особенностям данных, представляет собой серьезную проблему.

Тем не менее, ручные методы анализа влияния распределения данных на алгоритмы поиска неэффективны из-за высокой размерности векторных данных. Для решения этой проблемы научные и промышленные круги ищут решения по рекомендации алгоритмов на основе машинного обучения (ссылка № 10).

Разработка интеллектуального алгоритма векторного поиска, основанного на машинном обучении, также является одним из приоритетных направлений исследований. Вообще говоря, существующие алгоритмы векторного поиска разработаны универсально для векторных данных с различной размерностью и характером распределения. В результате они не поддерживают специфические структуры индексов в соответствии с особенностями данных и, таким образом, имеют мало возможностей для оптимизации. В будущем необходимо изучить эффективные технологии машинного обучения, которые позволят адаптировать индексные структуры к различным характеристикам данных (ссылки № 11-12).

  • Поддержка расширенной семантики запросов

Современные приложения часто используют более сложные запросы к векторам - традиционная семантика поиска ближайших соседей уже неприменима для поиска векторных данных. Более того, появляется потребность в комбинированном поиске по нескольким векторным базам данных или по векторным и невекторным данным (ссылка № 13).

В частности, быстро растут вариации метрик расстояния для векторного сходства. Традиционные показатели сходства, такие как евклидово расстояние, расстояние внутреннего произведения и косинусное расстояние, не могут удовлетворить все требования приложений. С популяризацией технологий искусственного интеллекта многие отрасли разрабатывают собственные метрики сходства векторов, такие как расстояние Танимото, расстояние Махаланобиса, суперструктура и субструктура. Интеграция этих оценочных метрик в существующие алгоритмы поиска и разработка новых алгоритмов, использующих эти метрики, являются сложными исследовательскими задачами.

По мере роста сложности пользовательских сервисов приложениям необходимо будет осуществлять поиск как в векторных, так и в невекторных данных. Например, система рекомендаций контента анализирует предпочтения пользователей, их социальные связи и сопоставляет их с актуальными темами, чтобы предложить пользователям подходящий контент. Такой поиск обычно включает в себя запросы к нескольким типам данных или к нескольким системам обработки данных. Эффективная и гибкая поддержка такого гибридного поиска - еще одна задача при проектировании системы.

Авторы

Д-р Рентонг Го (доктор философии компьютерного программного обеспечения и теории, Хуачжунский университет науки и технологий), партнер и директор по исследованиям и разработкам компании 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, окончил Калифорнийский университет в Санта-Крузе со степенью бакалавра в области компьютерных наук. После прихода в Zilliz Филип проводит большую часть своего времени, занимаясь развертыванием облачных систем, взаимодействием с клиентами, техническими переговорами и разработкой приложений искусственного интеллекта.

Ссылки

  1. Проект Milvus: https://github.com/milvus-io/milvus
  2. Milvus: специально разработанная система управления векторными данными, SIGMOD'21
  3. Проект Faiss: https://github.com/facebookresearch/faiss
  4. Проект Annoy: https://github.com/spotify/annoy
  5. Проект SPTAG: https://github.com/microsoft/SPTAG
  6. GRIP: высокопроизводительный поиск ближайших соседей в нескольких хранилищах, оптимизированный по емкости, для векторной поисковой системы, CIKM'19
  7. DiskANN: быстрый точный поиск ближайших соседей по миллиарду точек на одном узле, NIPS'19
  8. HM-ANN: эффективный поиск ближайших соседей по миллиарду точек на гетерогенной памяти, NIPS'20
  9. SONG: приближенный поиск ближайших соседей на GPU, ICDE'20
  10. Демонстрация сервиса автоматической настройки системы управления базами данных ottertune, VLDB'18
  11. The Case for Learned Index Structures, SIGMOD'18
  12. Улучшение приближенного поиска ближайших соседей с помощью обучаемого адаптивного раннего завершения, SIGMOD'20
  13. AnalyticDB-V: Гибридный аналитический движок для слияния запросов к структурированным и неструктурированным данным, VLDB'20

Присоединяйтесь к нашему сообществу разработчиков с открытым исходным кодом:

  • Найдите Milvus на GitHub или внесите в него свой вклад.
  • Общайтесь с сообществом на форуме.
  • Общайтесь с нами в Twitter.

Like the article? Spread the word

Продолжить чтение