Примечания к выпуску
Узнайте, что нового в Milvus! На этой странице представлены новые функции, улучшения, известные проблемы и исправления ошибок в каждом выпуске. Рекомендуем регулярно посещать эту страницу, чтобы узнавать о обновлениях.
v3.0-beta
Дата выпуска: 9 мая 2026 г.
| Версия Milvus | Версия Python SDK | Версия Node.js SDK |
|---|---|---|
| 3.0-beta | 3.0.0 | 3.0.0 |
Milvus 3.0-beta расширяет векторную базу данных Milvus за счет новой интеграции с экосистемой Open Lake: External Collection позволяет Milvus запрашивать внешние таблицы Lake без копирования, а Spark может считывать коллекции Milvus напрямую через Snapshot. В этом выпуске также представлены более расширенные возможности поиска, более выразительная схема, более глубокая настройка текстового поиска, более точный контроль жизненного цикла данных и моделей, а также больше возможностей управления со стороны оператора. Milvus 3.0 является ядром Zilliz Lakebase, обеспечивая его унифицированное обслуживание, обнаружение и пакетную обработку.
Посмотрите видео ниже, чтобы узнать больше о Milvus 3.0 и поучаствовать в сессии вопросов и ответов с основными разработчиками:
Ключевые особенности
Внешняя коллекция
В типичных конвейерах данных ИИ терабайты вложений и метаданных уже находятся в объектном хранилище в виде таблиц Parquet, Lance или Iceberg. Копирование этих данных в Milvus удваивает затраты на хранение, добавляет конвейер ETL, который необходимо синхронизировать, и лишает клиента контроля над управлением данными.
Функция «Внешняя коллекция» устраняет необходимость копирования. Коллекция Milvus может ссылаться на файлы там, где они уже находятся, а Milvus управляет только схемой, индексами и выполнением запросов. Инкрементальное обновление обеспечивает согласованность коллекции с базовыми файлами. Клиенты, чьи данные не могут покидать озеро, например, финансовые и медицинские команды, могут выполнять векторный поиск по этим данным там, где они находятся. Один набор данных, хранящийся в озере, также может обслуживаться сразу несколькими экземплярами Milvus.
Дополнительные сведения см. в разделе «Создание внешней коллекции».
Снимок
Обслуживание и пакетный поиск часто требуют одновременного доступа к одной и той же коллекции. Оценка A/B-моделей, крупномасштабная дедупликация, проверка заполнения и откат версий — все эти процессы требуют стабильного представления коллекции, пока в нее продолжают вноситься записи.
Снимок создает представление коллекции на определенный момент времени, доступное только для чтения, путем ссылки на существующие сегменты вместо копирования данных, поэтому предельные затраты на хранение близки к нулю. Пакетные задания могут считывать данные из снимка в режиме изоляции типа MVCC, в то время как активная коллекция продолжает принимать записи.
Дополнительные сведения см. в разделах «Снимки», «Управление снимками» и «Варианты использования снимков».
Запрос / Поиск с сортировкой
Поиск и запросы теперь поддерживают сортировку по нескольким полям, при этом сортировка переносится в ядро Milvus, а параметры « ASC » и « DESC » можно настраивать для каждого поля. Это устраняет распространенный пробел в производственной среде: сортировка Top-K только по расстоянию часто не соответствует бизнес-потребностям, когда наиболее похожий элемент не является самым дешевым, самым свежим или самым популярным.
Приложениям больше не нужно избыточно извлекать результаты и повторно сортировать их на клиенте для отображения составного ранжирования.
Дополнительные сведения см. в разделах «Сортировка результатов поиска по скалярным полям » и «Сортировка результатов запроса».
Агрегирование запросов
Для получения статистики распределения арендаторов, подсчета полноты полей или прогресса развертывания версий из коллекции Milvus раньше требовалось извлекать соответствующие сущности обратно на клиент и агрегировать их там. В Milvus 3.0 скалярная агрегация в стиле SQL перенесена в ядро. Вызов запроса принимает выражения типа « group_by_fields » и выражения агрегации в формате « output_fields », включая « count(*) », « count(<field>) », « sum(<field>) », « avg(<field>) », « min(<field>) » и « max(<field>) ». Агрегация вычисляется на стороне сервера после фильтрации.
Дополнительные сведения см. в разделе «Агрегирование результатов запросов».
Нулевой вектор
Встраивания часто генерируются асинхронно, поэтому сущность может поступить раньше, чем ее вектор. Мультимодальные данные также имеют естественные пробелы, например видео без субтитров или продукт без изображения. В предыдущих версиях не было хорошего решения: приложения либо откладывали запись до готовности вектора, либо заполняли его заглушкой, и оба варианта ухудшали качество поиска.
Milvus 3.0 поддерживает NULL в векторных полях для всех шести типов векторов. Поиск автоматически пропускает векторы NULL, качество поиска не ухудшается, а векторы NULL фактически не занимают места в хранилище. В рамках этого изменения функция « AddField » также распространяется на векторные поля: с помощью команды « nullable=True » существующая коллекция может пополняться новыми векторными полями в режиме онлайн без перестроения.
Для получения дополнительной информации см. раздел «Поля, допускающие значение NULL».
Пользовательский словарь и словарь синонимов
Готовые токенизаторы не всегда соответствуют требованиям к качеству поиска в производственной среде. Китайский язык, вертикальные области, такие как медицина, право и химия, а также многоязычные корпуса могут существенно выиграть от использования пользовательских словарей и таблиц синонимов. До сих пор эти ресурсы в основном использовались в виде переформулировок запросов на стороне приложения.
В Milvus 3.0 добавлен механизм FileResource для регистрации пользовательских словарей токенизаторов, списков синонимов, списков стоп-слов и правил декомпозиции сложных слов. После регистрации на ресурс можно ссылаться из любого токенизатора или фильтра, и он будет применяться к BM25, анализаторам и Text Match. Теперь словари и синонимы можно версионировать и управлять ими централизованно, а не разбрасывать по коду приложения.
Дополнительную информацию см. в разделе «Управление файловыми ресурсами».
TTL сущности
TTL на уровне коллекции и на уровне раздела слишком грубы для многих сценариев жизненного цикла и соответствия требованиям. Различные арендаторы внутри одной и той же коллекции часто имеют разные правила хранения, и отдельные сущности могут нуждаться в истечении срока действия по графику, который не совпадает с остальной частью коллекции.
Milvus 3.0 поддерживает TTL на уровне сущностей. Определите поле « TIMESTAMPTZ » в схеме, отметьте его как поле TTL с помощью свойства коллекции, и Milvus автоматически удалит просроченные сущности. Это охватывает запросы на право на забвение, истекающие данные сеанса и ограниченную историю переписки без очистки на стороне приложения.
Для получения дополнительной информации см. раздел «Установка TTL на уровне сущности».
MinHash DIDO (Doc-in, Doc-out)
В Milvus 2.6 был добавлен индекс MINHASH_LSH для обнаружения почти-дубликатов на основе наборов, но приложениям по-прежнему приходилось вычислять сигнатуры MinHash перед записью данных в Milvus.
В Milvus 3.0 добавлена функция MinHash на стороне сервера. Объявите в схеме поле ввода « VARCHAR » и поле вывода « BINARY_VECTOR », присоедините функцию « FunctionType.MINHASH », и Milvus будет вычислять сигнатуры во время вставки, массовой вставки и поиска. Вместе с « MINHASH_LSH » это поддерживает рабочие процессы дедупликации для больших наборов данных, создание отпечатков и обнаружение плагиата внутри Milvus.
Для получения дополнительной информации см. раздел «Функция MinHash».
EmbList + DISKANN
Предположение «одна сущность = один вектор» больше не соответствует современному поиску. Длинные документы разбиваются на множество фрагментов, модели позднего взаимодействия, такие как ColBERT, генерируют один вектор на каждый токен, а мультимодальные сущности могут иметь несколько представлений.
EmbList хранит список векторов переменной длины для каждого объекта, используя « DISKANN » в качестве индекса на диске. Использование дискового пространства позволяет контролировать потребление ОЗУ, когда объем корпуса превышает доступную память. EmbList + « DISKANN » — это первый вариант из более широкого семейства StructList в данной RC-версии. Остальные элементы семейства, включая фильтрацию StructList и ускорение с помощью нескольких векторов Muvera / Lemur, планируется включить в официальный релиз версии 3.0.
Дополнительную информацию см. в разделе «Поиск с использованием списков вложений».
Принудительное слияние
Производственные рабочие нагрузки со временем приводят к фрагментации сегментов, что вызывает колебания задержки запросов и увеличение объема хранилища.
В Milvus 3.0 добавлена возможность явного запуска уплотнения сегментов в периоды низкой нагрузки как в синхронном, так и в асинхронном режимах.
Дополнительную информацию см. в разделе «Принудительная уплотнение слияния».
Хранилище V3
В Milvus 3.0 представлено хранилище V3 — столбчатый механизм хранения на основе манифестов, в котором данные и метаданные хранятся в объектном хранилище, совместимом с S3. Каждая версия набора данных фиксируется в виде неизменяемого моментального снимка манифеста — файла в кодировке Avro, в котором фиксируется, какие группы столбцов, дельта-журналы и статистические данные входят в набор данных.
Манифесты представляют собой компактные файлы Avro, а дельта-журналы фиксируют удаления на уровне сущностей без перезаписи файлов данных. Это позволяет минимизировать накладные расходы на метаданные по мере роста наборов данных. Манифест также отделяет отслеживание метаданных от пути запроса, позволяя коллекции управлять большим количеством сегментов без ухудшения производительности запросов.
Поскольку состояния хранятся в объектном хранилище, набор данных является самоописательным: любой читатель, имеющий доступ к пути хранения, может обнаружить и интерпретировать его без центрального каталога. Это свойство лежит в основе интеграции с External Collection, Snapshot и будущими озерами данных.