Выбор базы данных векторов для поиска ANN на Reddit
Это сообщение было написано Крисом Фурни, штатным инженером-программистом Reddit, и первоначально опубликовано на Reddit, а здесь перепощено с разрешения.
В 2024 году команды Reddit использовали различные решения для выполнения векторного поиска по приближенному ближайшему соседу (ANN). От векторного поиска Vertex AI от Google и экспериментов с использованием векторного поиска ANN от Apache Solr для некоторых больших наборов данных до библиотеки FAISS от Facebook для небольших наборов данных (размещенных в вертикально масштабированных боковых машинах). Все больше и больше команд в Reddit хотели получить широко поддерживаемое решение для векторного поиска ANN, которое было бы экономически эффективным, обладало необходимыми функциями поиска и могло масштабироваться для данных размера Reddit. Чтобы удовлетворить эту потребность, в 2025 году мы искали идеальную базу данных векторов для команд Reddit.
В этом посте описан процесс, который мы использовали для выбора лучшей векторной базы данных для сегодняшних потребностей Reddit. Она не описывает лучшую векторную базу данных в целом или самый необходимый набор функциональных и нефункциональных требований для всех ситуаций. Здесь описано то, что Reddit и его инженерная культура оценили и расставили приоритеты при выборе векторной базы данных. Этот пост может послужить вдохновением для вашего собственного сбора и оценки требований, но у каждой организации своя культура, ценности и потребности.
Процесс оценки
В целом, этапы выбора были следующими:
1. Сбор информации от команд
2. Качественная оценка решений
3. Количественная оценка лучших претендентов
4. Окончательный выбор
1. Сбор информации от команд
Команды, заинтересованные в выполнении векторного поиска ANN, собирали информацию о трех аспектах контекста:
Функциональные требования (например, гибридный векторный и лексический поиск? Диапазон поисковых запросов? Фильтрация по невекторным атрибутам?)
Нефункциональные требования (например, может ли он поддерживать 1B векторов? Может ли он достичь <100 мс задержки P99?)
Векторные базы данных уже интересовали команды.
Опрос команд на предмет требований не является тривиальным. Многие из них будут описывать свои потребности с точки зрения того, как они решают проблему в настоящее время, и ваша задача - понять и устранить эту предвзятость.
Например, команда уже использовала FAISS для векторного поиска ANN и заявила, что новое решение должно эффективно возвращать 10 тыс. результатов за один поисковый запрос. После дальнейшего обсуждения выяснилось, что причина 10 000 результатов в том, что им нужно было выполнить пост-специальную фильтрацию, а FAISS не предлагает фильтрацию результатов ANN во время запроса. На самом деле проблема заключалась в том, что им нужна фильтрация, поэтому подойдет любое решение, предлагающее эффективную фильтрацию, а возврат 10 тыс. результатов - это просто обходной путь, необходимый для улучшения запоминания. В идеале они хотели бы предварительно отфильтровать всю коллекцию перед поиском ближайших соседей.
Ценным был и вопрос о векторных базах данных, которые команды уже используют или которыми интересуются. Если хотя бы одна команда положительно отзывалась о своем текущем решении, это признак того, что векторная база данных может стать полезным решением для всей компании. Если команды высказывали только негативные мнения о решении, то нам не следует включать его в число возможных вариантов. Принятие решений, которые заинтересовали команды, также позволило убедиться, что команды чувствуют себя вовлеченными в процесс, и помогло нам сформировать первоначальный список ведущих претендентов для оценки; существует слишком много решений векторного поиска ANN в новых и существующих базах данных, чтобы исчерпывающе протестировать их все.
2. Качественная оценка решений
Начиная со списка решений, которые заинтересовали команды, для качественной оценки того, какое решение векторного поиска ANN лучше всего подходит для наших нужд, мы:
Изучили каждое решение и оценили, насколько оно удовлетворяет каждому требованию в сравнении с весовой важностью этого требования.
Исключили решения, основываясь на качественных критериях и обсуждении
Отобрали N лучших решений для количественного тестирования.
Наш начальный список решений для векторного поиска ANN включал:
Qdrant
Weviate
Open Search
Pgvector (уже использует Postgres в качестве RDBMS)
Redis (уже используется в качестве KV-хранилища и кэша)
Cassandra (уже используется для не-ANN поиска)
Solr (уже используется для лексического поиска и экспериментирует с векторным поиском)
Vespa
Pinecone
Vertex AI (уже используется для векторного поиска ANN)
Затем мы взяли все функциональные и нефункциональные требования, которые были упомянуты командами, плюс еще несколько ограничений, представляющих наши инженерные ценности и цели, сделали эти строки в электронной таблице и взвесили, насколько они важны (от 1 до 3; показано в сокращенной таблице ниже).
Для каждого решения, которое мы сравнивали, мы оценивали (по шкале от 0 до 3), насколько хорошо каждая система удовлетворяет этому требованию (как показано в таблице ниже). Такая оценка была несколько субъективной, поэтому мы выбрали одну систему, привели примеры оценок с письменным обоснованием и попросили рецензентов обратиться к этим примерам. Мы также дали следующее руководство по присвоению каждой оценки: присвойте это значение, если:
0: Нет поддержки/доказательства поддержки требований
1: Базовая или неадекватная поддержка требований
2: Требование разумно поддерживается
3: Надежная поддержка требований, выходящая за рамки сопоставимых решений.
Затем мы создали общую оценку для каждого решения, взяв сумму произведения оценки требований решения и важности этого требования (например, Qdrant получил 3 балла за повторное ранжирование/сочетание баллов, которое имеет важность 2, поэтому 3 x 2 = 6, повторите это для всех строк и суммируйте). В итоге мы получаем общий балл, который можно использовать как основу для ранжирования и обсуждения решений, а также того, какие требования имеют наибольшее значение (обратите внимание, что балл используется не для принятия окончательного решения, а как инструмент для обсуждения).
Примечание редактора: этот обзор был основан на Milvus 2.4. С тех пор мы выпустили Milvus 2.5, Milvus 2.6, а Milvus 3.0 уже не за горами, поэтому некоторые показатели могут быть устаревшими. Тем не менее, сравнение все еще предлагает сильные идеи и остается очень полезным.
| Категория | Важность | Qdrant | Milvus (2.4) | Cassandra | Weviate | Solr | Vertex AI |
| Тип поиска | |||||||
| Гибридный поиск | 1 | 3 | 2 | 0 | 2 | 2 | 2 |
| Поиск по ключевым словам | 1 | 2 | 2 | 2 | 2 | 3 | 1 |
| Приближенный поиск NN | 3 | 3 | 3 | 2 | 2 | 2 | 2 |
| Поиск по диапазону | 1 | 3 | 3 | 2 | 2 | 0 | 0 |
| Повторное ранжирование/объединение баллов | 2 | 3 | 2 | 0 | 2 | 2 | 1 |
| Метод индексации | |||||||
| HNSW | 3 | 3 | 3 | 2 | 2 | 2 | 0 |
| Поддержка нескольких методов индексирования | 3 | 0 | 3 | 1 | 2 | 1 | 1 |
| Квантование | 1 | 3 | 3 | 0 | 3 | 0 | 0 |
| Локально-чувствительное хэширование (LSH) | 1 | 0 | 0Примечание: Milvus 2.6 поддерживает его. | 0 | 0 | 0 | 0 |
| Данные | |||||||
| Типы векторов, отличные от float | 1 | 2 | 2 | 0 | 2 | 2 | 0 |
| Атрибуты метаданных на векторах (поддерживает множество атрибутов, большой размер записи и т.д.) | 3 | 3 | 2 | 2 | 2 | 2 | 1 |
| Параметры фильтрации метаданных (можно фильтровать по метаданным, есть фильтрация до и после) | 2 | 3 | 2 | 2 | 2 | 3 | 2 |
| Типы данных атрибутов метаданных (надежная схема, например, bool, int, string, json, arrays) | 1 | 3 | 3 | 2 | 2 | 3 | 1 |
| Ограничения атрибутов метаданных (запросы диапазона, например, 10 < x < 15) | 1 | 3 | 3 | 2 | 2 | 2 | 1 |
| Разнообразие результатов по атрибутам (например, получение не более N результатов из каждого сабреддита в ответе) | 1 | 2 | 1 | 2 | 3 | 3 | 0 |
| Масштаб | |||||||
| Сотни миллионов векторных индексов | 3 | 2 | 3 | 1 | 2 | 3 | |
| Индекс вектора миллиарда | 1 | 2 | 2 | 1 | 2 | 2 | |
| Векторы поддержки не менее 2k | 2 | 2 | 2 | 2 | 2 | 1 | 1 |
| Векторы с поддержкой более 2k | 2 | 2 | 2 | 2 | 1 | 1 | 1 |
| P95 Задержка 50-100 мс при X QPS | 3 | 2 | 2 | 2 | 1 | 1 | 2 |
| Задержка P99 <= 10 мс @ X QPS | 3 | 2 | 2 | 2 | 3 | 1 | 2 |
| 99,9% доступности | 2 | 2 | 2 | 3 | 2 | 2 | 2 |
| Индексирование/хранение с доступностью 99,99 % | 2 | 1 | 1 | 3 | 2 | 2 | 2 |
| Операции хранения данных | |||||||
| Возможность размещения в AWS | 3 | 2 | 2 | 2 | 2 | 3 | 0 |
| Мультирегион | 1 | 1 | 2 | 3 | 1 | 2 | 2 |
| Обновления с нулевым временем простоя | 1 | 2 | 2 | 3 | 2 | 2 | 1 |
| Мультиоблако | 1 | 3 | 3 | 3 | 2 | 2 | 0 |
| API/библиотеки | |||||||
| gRPC | 2 | 2 | 2 | 2 | 2 | 0 | 2 |
| RESTful API | 1 | 3 | 2 | 2 | 2 | 1 | 2 |
| Перейти в библиотеку | 3 | 2 | 2 | 2 | 2 | 1 | 2 |
| Библиотека Java | 2 | 2 | 2 | 2 | 2 | 2 | 2 |
| Python | 2 | 2 | 2 | 2 | 2 | 2 | 2 |
| Другие языки (C++, Ruby и т.д.) | 1 | 2 | 2 | 3 | 2 | 2 | 2 |
| Операции во время выполнения | |||||||
| Метрики "Прометея | 3 | 2 | 2 | 2 | 3 | 2 | 0 |
| Основные операции с БД | 3 | 2 | 2 | 2 | 2 | 2 | 2 |
| Апсерты | 2 | 2 | 2 | 2 | 1 | 2 | 2 |
| Оператор Kubernetes | 2 | 2 | 2 | 2 | 2 | 2 | 0 |
| Пагинация результатов | 2 | 2 | 2 | 2 | 2 | 2 | 0 |
| Встраивание поиска по идентификатору | 2 | 2 | 2 | 2 | 2 | 2 | 2 |
| Возвращение вкраплений с идентификатором кандидата и его оценками | 1 | 3 | 2 | 2 | 2 | 2 | 2 |
| Идентификатор пользователя | 2 | 2 | 2 | 2 | 2 | 2 | 2 |
| Возможность поиска в крупномасштабном пакетном контексте | 1 | 2 | 1 | 1 | 2 | 1 | 2 |
| Резервное копирование / моментальные снимки: поддерживает возможность создания резервных копий всей базы данных | 1 | 2 | 2 | 2 | 3 | 3 | 2 |
| Эффективная поддержка больших индексов (различие между холодным и горячим хранением) | 1 | 3 | 2 | 2 | 2 | 1 | 2 |
| Поддержка/общество | |||||||
| Нейтралитет к поставщикам | 3 | 3 | 2 | 3 | 2 | 3 | 0 |
| Надежная поддержка api | 3 | 3 | 3 | 2 | 2 | 2 | 2 |
| Поддержка поставщиков | 2 | 2 | 2 | 2 | 2 | 2 | 0 |
| Скорость сообщества | 2 | 3 | 2 | 2 | 2 | 2 | 0 |
| База производственных пользователей | 2 | 3 | 3 | 2 | 2 | 1 | 2 |
| Ощущение сообщества | 1 | 3 | 2 | 2 | 2 | 2 | 1 |
| Звезды Github | 1 | 2 | 2 | 2 | 2 | 2 | 0 |
| Конфигурация | |||||||
| Обработка секретов | 2 | 2 | 2 | 2 | 1 | 2 | 2 |
| Источник | |||||||
| Открытый источник | 3 | 3 | 3 | 3 | 2 | 3 | 0 |
| Язык | 2 | 3 | 3 | 2 | 3 | 2 | 0 |
| Выпускает | 2 | 3 | 3 | 2 | 2 | 2 | 2 |
| Тестирование в верхнем течении | 1 | 2 | 3 | 3 | 2 | 2 | 2 |
| Наличие документации | 3 | 3 | 3 | 2 | 1 | 2 | 1 |
| Стоимость | |||||||
| Эффективная стоимость | 2 | 2 | 2 | 2 | 2 | 2 | 1 |
| Производительность | |||||||
| Поддержка настройки использования ресурсов процессора, памяти и диска | 3 | 2 | 2 | 2 | 2 | 2 | 2 |
| Разделение на несколько узлов (стручков) | 3 | 2 | 2 | 3 | 2 | 2 | 2 |
| Возможность настройки системы для баланса между задержкой и пропускной способностью | 2 | 2 | 2 | 3 | 2 | 2 | 2 |
| Пользовательское разбиение (запись) | 1 | 3 | 2 | 3 | 1 | 2 | 0 |
| Многоарендный | 1 | 3 | 2 | 1 | 3 | 2 | 2 |
| Разделы | 2 | 2 | 2 | 3 | 2 | 2 | 2 |
| Репликация | 2 | 2 | 2 | 3 | 2 | 2 | 2 |
| Резервирование | 1 | 2 | 2 | 3 | 2 | 2 | 2 |
| Автоматический отказ | 3 | 2 | 0 Примечание: Milvus 2.6 поддерживает эту функцию. | 3 | 2 | 2 | 2 |
| Балансировка нагрузки | 2 | 2 | 2 | 3 | 2 | 2 | 2 |
| Поддержка GPU | 1 | 0 | 2 | 0 | 0 | 0 | 0 |
| Qdrant | Милвус | Кассандра | Weviate | Solr | Vertex AI | ||
| Общая оценка решений | 292 | 281 | 264 | 250 | 242 | 173 |
Мы обсудили общую оценку и оценку требований различных систем и попытались понять, правильно ли мы взвесили важность требований и не являются ли некоторые требования настолько важными, что их следует считать основными ограничениями. Одним из таких требований было наличие или отсутствие открытого исходного кода, поскольку мы хотели получить решение, в котором мы могли бы участвовать, вносить свой вклад и быстро устранять небольшие проблемы, если бы они возникли в нашем масштабе. Вклад в разработку и использование программного обеспечения с открытым исходным кодом - важная часть инженерной культуры Reddit. Поэтому мы исключили из рассмотрения решения, работающие только на хостинге (Vertex AI, Pinecone).
В ходе обсуждения мы пришли к выводу, что несколько других ключевых требований имеют для нас первостепенное значение:
Масштаб и надежность: мы хотели видеть доказательства того, что другие компании используют решение с 100М+ или даже 1В векторов.
Сообщество: Мы хотели получить решение, имеющее здоровое сообщество с большой динамикой развития в этом быстро развивающемся пространстве.
Выразительные типы метаданных и фильтрация, позволяющие реализовать большее количество наших сценариев использования (фильтрация по дате, булевым значениям и т.д.)
Поддержка нескольких типов индексов (не только HNSW или DiskANN), чтобы лучше соответствовать производительности для наших многочисленных уникальных случаев использования.
В результате наших обсуждений и уточнения ключевых требований мы решили провести количественное тестирование (в порядке убывания):
Qdrant
Milvus
Vespa и
Weviate .
К сожалению, подобные решения требуют времени и ресурсов, а ни одна организация не располагает неограниченным количеством ни того, ни другого. Учитывая наш бюджет, мы решили протестировать Qdrant и Milvus, а тестирование Vespa и Weviate оставить в качестве растяжимых целей.
Qdrant против Milvus также был интересным тестом двух разных архитектур:
Qdrant: Однородные типы узлов, выполняющие все операции с векторной базой данных ANN.
Milvus: гетерогенные типы узлов (Milvus; один для запросов, другой для индексирования, третий для приема данных, прокси и т. д.).
Какой из них было легко настроить (проверка документации)? Какой из них было легко запустить (тест на отказоустойчивость и отлаженность)? И какой из них лучше всего подходит для тех случаев использования и масштабов, которые нас интересовали? На эти вопросы мы пытались ответить в ходе количественного сравнения решений.
3. Количественная оценка лучших претендентов
Мы хотели лучше понять, насколько масштабируемым является каждое из решений, и в процессе работы получить представление о том, каково это - устанавливать, настраивать, поддерживать и запускать каждое из них в масштабе. Для этого мы собрали три набора данных с векторами документов и запросов для трех разных сценариев использования, настроили каждое решение с аналогичными ресурсами в Kubernetes, загрузили документы в каждое решение и отправили идентичные запросы с помощью Grafana K6 с исполнителем с нарастающей скоростью поступления, чтобы разогреть системы перед достижением целевой пропускной способности (например, 100 QPS).
Мы проверяли пропускную способность, точку разрыва каждого решения, соотношение между пропускной способностью и задержкой, а также реакцию на потерю узлов под нагрузкой (количество ошибок, влияние на задержку и т. д.). Ключевой интерес представляло влияние фильтрации на задержку. Также мы проводили простые тесты "да/нет", чтобы проверить, что возможности, описанные в документации, работают так, как описано (например, апсерт, удаление, получение по ID, администрирование пользователей и т. д.), и оценить эргономику этих API.
Тестирование проводилось на Milvus v2.4 и Qdrant v1.12. Из-за нехватки времени мы не стали настраивать и тестировать все типы индексов; в каждом решении использовались схожие настройки, с уклоном на высокий уровень запоминания ANN, а тесты были сфокусированы на производительности индексов HNSW. Каждому решению также были выделены одинаковые ресурсы процессора и памяти.
В ходе экспериментов мы обнаружили несколько интересных различий между двумя решениями. В следующих экспериментах каждое решение имело примерно 340 М пост-векторов Reddit 384 размеров каждый, для HNSW, M=16, и efConstruction=100.
В одном из экспериментов мы обнаружили, что при одинаковой пропускной способности запросов (100 QPS без одновременного ввода данных) добавление фильтрации повлияло на задержку Milvus сильнее, чем Qdrant.
Латентность запросов с фильтрацией
В другом случае мы обнаружили, что взаимодействие между ингестированием и нагрузкой на запросы на Qdrant гораздо сильнее, чем на Milvus (показано ниже при постоянной пропускной способности). Вероятно, это связано с их архитектурой: Milvus разделяет большую часть своего ингестирования на отдельные типы узлов и узлы, обслуживающие трафик запросов, в то время как Qdrant обслуживает и ингестирование, и трафик запросов с одних и тех же узлов.
Задержка запроса при 100 QPS во время захвата
При тестировании разнообразия результатов по атрибутам (например, получение не более N результатов из каждого сабреддита в ответе) мы обнаружили, что при одинаковой пропускной способности Milvus имеет худшую задержку, чем Qdrant (при 100 QPS).
Задержка после запроса с учетом разнообразия результатов
Мы также хотели посмотреть, насколько эффективно каждое решение масштабируется при добавлении большего количества реплик данных (т. е. фактор репликации, RF, был увеличен с 1 до 2). Изначально, при RF=1, Qdrant смог обеспечить удовлетворительную задержку при большей пропускной способности, чем Milvus (более высокий QPS не показан, поскольку тесты не завершились без ошибок).
Qdrant показывает задержку RF=1 при различной пропускной способности
Milvus показывает задержку RF=1 при различной пропускной способности
Однако при увеличении коэффициента репликации задержка p99 у Qdrant улучшилась, но Milvus смог выдержать более высокую пропускную способность, чем Qdrant, при приемлемой задержке (Qdrant 400 QPS не показан, так как тест не был завершен из-за высокой задержки и ошибок).
Milvus показывает задержку RF=2 при различной пропускной способности
Qdrant показывает задержку RF=2 при различной пропускной способности
Из-за нехватки времени у нас не было достаточно времени, чтобы сравнить отзыв ANN между решениями на наших наборах данных, но мы приняли во внимание измерения отзыва ANN для решений, предоставленных https://ann-benchmarks.com/, на общедоступных наборах данных.
4. Окончательный выбор
С точки зрения производительности, без особых настроек и с использованием только HNSW, Qdrant во многих тестах оказался лучше, чем Milvus. Однако Milvus, похоже, лучше масштабируется при увеличении репликации и имеет лучшую изоляцию между вводом данных и нагрузкой на запросы благодаря архитектуре с несколькими узлами.
Несмотря на сложность архитектуры Milvus (несколько типов узлов, опора на внешний журнал с возможностью записи, как у Kafka, и хранилище метаданных, как у etcd), нам было легче отлаживать и исправлять Milvus, чем Qdrant, когда оба решения входили в плохое состояние. Milvus также имеет автоматическую ребалансировку при увеличении коэффициента репликации коллекции, в то время как в Qdrant с открытым исходным кодом для увеличения коэффициента репликации требуется вручную создавать или удалять шарды (эту функцию нам пришлось бы создавать самим или использовать версию без открытого исходного кода).
Milvus - более "реддитовская" технология, чем Qdrant; у нее больше сходства с остальными частями нашего технологического стека. Milvus написан на Golang, нашем предпочтительном языке программирования бэкенда, и поэтому нам легче вносить в него свой вклад, чем в Qdrant, который написан на Rust. По сравнению с Qdrant, Milvus отличается высокой скоростью реализации проектов с открытым исходным кодом и отвечает большему числу наших ключевых требований.
В итоге оба решения удовлетворили большинство наших требований, и в некоторых случаях Qdrant имел преимущество в производительности, но мы почувствовали, что можем масштабировать Milvus дальше, нам было удобнее работать с ним, и он лучше подходил для нашей организации, чем Qdrant. Жаль, что у нас не было больше времени на тестирование Vespa и Weaviate, но они тоже могли быть выбраны по организационным причинам (Vespa основана на Java) и архитектуре (Weaviate - одноузловая, как Qdrant).
Основные выводы
Оспорьте полученные требования и постарайтесь устранить существующие предубеждения в отношении решений.
Оценивайте решения-кандидаты и используйте это для обсуждения основных требований, а не как абсолютную истину.
Оценивайте решения количественно, но по ходу дела обращайте внимание на то, каково это - работать с решением.
Выбирайте решение, которое лучше всего подходит вашей организации с точки зрения обслуживания, стоимости, удобства использования и производительности, а не только потому, что оно работает лучше всех.
Благодарности
Эту работу по оценке выполнили Бен Кочи, Чарльз Нджороге, Амит Кумар и я. Спасибо также другим людям, которые внесли свой вклад в эту работу, в том числе Энни Янг, Конраду Райхе, Сабрине Конг и Эндрю Джонсону за качественное исследование решений.
Примечания редактора
Мы хотим выразить искреннюю благодарность команде инженеров Reddit - не только за то, что они выбрали Milvus для своих рабочих нагрузок векторного поиска, но и за то, что нашли время для публикации такой подробной и справедливой оценки. Редко можно увидеть такой уровень прозрачности в сравнении реальных инженерных команд с базами данных, и их статья будет полезна всем членам сообщества Milvus (и не только), которые пытаются разобраться в растущем ландшафте векторных баз данных.
Как отметил Крис в своем посте, не существует какой-то одной "лучшей" векторной базы данных. Важно то, соответствует ли система вашей рабочей нагрузке, ограничениям и философии работы. Сравнение Reddit хорошо отражает эту реальность. Milvus не возглавляет все категории, и это вполне ожидаемо, учитывая компромиссы между различными моделями данных и целями производительности.
Стоит уточнить один момент: В оценке Reddit использовалась версия Milvus 2.4, которая на тот момент была стабильным релизом. Некоторые функции - например, LSH и несколько оптимизаций индексов - в версии 2.4 либо еще не существовали, либо не были зрелыми, поэтому некоторые оценки, естественно, отражают более ранний базовый уровень. С тех пор мы выпустили Milvus 2.5, а затем Milvus 2.6, и это уже совсем другая система с точки зрения производительности, эффективности и гибкости. Сообщество отреагировало на это очень бурно, и многие команды уже обновились.
Вот краткий обзор того, что нового появилось в Milvus 2.6:
Снижение использования памяти на 72 % и ускорение запросов в 4 раза благодаря 1-битному квантованию RaBitQ
Снижение затрат на 50 % благодаря интеллектуальному многоуровневому хранению
4× более быстрый полнотекстовый поиск BM25 по сравнению с Elasticsearch
100× более быстрая фильтрация JSON с помощью нового индекса Path.
Новая архитектура с нулевым диском для более свежего поиска при меньших затратах
Упрощенный рабочий процесс "данные - внутрь, данные - наружу" для встраивания конвейеров
Поддержка 100K+ коллекций для работы с большими многопользовательскими средами.
Если вам нужен полный обзор, вот несколько хороших продолжений:
Блог: Представляем Milvus 2.6: доступный векторный поиск в миллиардных масштабах
VDBBench 1.0: Бенчмаркинг реального мира для векторных баз данных - Блог Milvus
У вас есть вопросы или вы хотите получить подробную информацию о какой-либо функции? Присоединяйтесь к нашему каналу Discord или создавайте проблемы на GitHub. Вы также можете заказать 20-минутную индивидуальную сессию, чтобы получить знания, рекомендации и ответы на свои вопросы в Milvus Office Hours.
Try Managed Milvus for Free
Zilliz Cloud is hassle-free, powered by Milvus and 10x faster.
Get StartedLike the article? Spread the word
