Примечания к выпуску
Узнайте, что нового в Milvus! На этой странице представлен обзор новых функций, улучшений, известных проблем и исправлений ошибок в каждом выпуске. Рекомендуем регулярно посещать эту страницу, чтобы быть в курсе обновлений.
v3.0.0
Дата выпуска: 29 июля 2026 г.
| Версия Milvus | Версия SDK для Python | Версия Node.js SDK | Версия SDK для Java | Версия SDK для Go |
|---|---|---|---|---|
| 3.0.0 | 3.0.1 | 3.0.3 | 3.0.5 | 3.0.0 |
Официально выпущена версия Milvus 3.0.0! Опираясь на архитектуру lake-native, представленную в версии 3.0-beta, этот выпуск завершает то, что было начато в бета-версии: External Collection охватывает больше рабочих процессов lakehouse; схема поддерживает добавление, заполнение и удаление данных в режиме онлайн; разреженный индекс перестроен на основе SINDI; StructArray и фасетный поиск дополняют механизм извлечения данных; пропуск FAISS и TEXT расширяют выбор индексов и модальностей; а Woodpecker работает как автономный сервис.
Посмотрите видео ниже, чтобы узнать больше о Milvus 3.0 и принять участие в сессии вопросов и ответов с основными разработчиками:
Если вы только знакомитесь с линейкой версий 3.0, в разделе «Обзор основных функций 3.0» ниже приведен краткий обзор возможностей, представленных в версии 3.0-beta; полное описание можно найти в примечаниях к выпуску 3.0-beta.
Что нового в версии 3.0.0 (по сравнению с 3.0-beta)
Внешняя коллекция: более полные рабочие процессы lakehouse
В версии 3.0-beta была представлена функция «Внешняя коллекция»: возможность ссылаться на файлы озера данных на месте, создавать индексы и выполнять поиск по ним без копирования данных в Milvus. В этом выпуске эта функция расширена до полноценных рабочих процессов поиска в «lakehouse». Внешние поля теперь могут служить входными данными для полей, генерируемых функциями, таких как разреженные векторы BM25, сигнатуры MinHash и вложения текста, благодаря чему поля поиска, основанные на тексте и результатах моделирования, создаются внутри Milvus без копирования исходной таблицы. Функция обновления также поддерживает аддитивную эволюцию схемы: когда во внешней таблице появляются новые столбцы, Milvus обновляет затронутые сегменты вместо перестроения коллекции.
В этом выпуске также добавлен внешний формат « milvus-table », который рассматривает метаданные Milvus Snapshot и манифесты Storage V3 в качестве внешнего источника, благодаря чему сам снимок коллекции может использоваться в качестве внешней таблицы — пакетные и сервисные системы получают общий, основанный на манифесте вид одних и тех же данных.
Дополнительную информацию см. в разделах «Создание внешней коллекции » и «Снимки».
Гибкая схема: добавление, заполнение и удаление столбцов в режиме реального времени
В производственной среде схемы не остаются неизменными — модели встраивания заменяются, признаки итеративно обновляются, поля становятся устаревшими — и раньше это означало полную перестройку коллекции с простоями или двойной записью. Версия 3.0.0 замыкает цикл: столбцы можно добавлять, заполнять и удалять без прерывания обслуживания.
Заполнение данных работает в обоих направлениях. Внешнее заполнение обрабатывает значения, вычисленные за пределами Milvus: добавьте столбец, создайте моментальный снимок коллекции в качестве согласованной отправной точки, запустите задание в автономном режиме, запишите значения обратно, и Milvus индексирует новый столбец инкрементально — обновление модели встраивания для сотен миллионов строк становится «горячим» процессом без простоев. Внутреннее пополнение охватывает значения, полученные с помощью ядра: присоедините функцию BM25 или MinHash к существующей коллекции, и её поле вывода будет автоматически вычисляться на основе имеющихся данных.
Дополнительную информацию см. в разделе «Добавление полей в существующую коллекцию».
Переработка индекса разреженных данных: SINDI, Block-Max WAND и Block-Max MaxScore
В Milvus 3.0 полностью обновлен индекс разреженных векторов. В него внедрены новые алгоритмы поиска — SINDI, Block-Max WAND и Block-Max MaxScore — наряду с сжатием инвертированного списка, настраиваемой квантованием и выбором алгоритма поиска для каждой рабочей нагрузки. Также оптимизированы загрузка через mmap, сериализация и вычисление оценок по алгоритму BM25, что сокращает объем хранения индекса и накладные расходы на загрузку при крупномасштабном поиске по разреженным векторам и полнотекстовом поиске. По результатам внутренних тестов сжатый индекс BM25 примерно в 3 раза меньше, чем разреженный индекс 2.6, при сопоставимом коэффициенте полноты, а SINDI достигает производительности (QPS) примерно в 10 раз выше, чем у MaxScore, при использовании обученных разреженных вложений. После включения новой версии индекса (см. «Примечания по совместимости и поведению») SINDI становится алгоритмом по умолчанию для поиска по разреженным IP, а MaxScore — для BM25.
Расширение поддержки StructArray
StructArray теперь поддерживает нулевые значения, битовые индексы, динамическое добавление полей в активные коллекции и частичное обновление полей структур посредством операции upsert, а также соответствующие возможности REST и массового импорта.
Поиск на уровне элементов добавляет гибридный поиск по подполям векторов с настраиваемым сворачиванием по объектам (варианты max / sum / avg / top-k), а также поиск по диапазону и группировку внутри него. Вложенная фильтрация охватывает предикаты element_filter, кванторы MATCH_ANY / MATCH_ALL / MATCH_LEAST / MATCH_MOST / MATCH_EXACT, позиционный доступ к подполям, например tags[0][name], а также array_length() для столбца структуры.
Дополнительные сведения см. в разделах «StructArray » и «Операторы StructArray».
Агрегация по запросу и фасетный поиск
Агрегация запросов из бета-версии вычисляет точные статистические данные по отфильтрованным данным; в версии 3.0.0 добавлен фасетированный поиск в поисковом пути. Укажите поле фасета во время поиска, и Milvus вернет ведущие значения фасета, каждое из которых представлено элементом, наилучшим образом соответствующим ранжированию ANN, и аннотировано агрегатами, такими как COUNT и AVG — боковая панель фасетного поиска (бренд, ценовой диапазон, атрибуты) в одном запросе, вместо избыточного извлечения и подсчёта на стороне клиента.
Переранжирование с помощью цепочки функций
Переранжирование теперь можно компоновать с помощью API «Цепочки функций», который выполняет упорядоченный типизированный конвейер в рамках одного поискового запроса. Цепочка может объединять раннее переоценки L0 на QueryNode с переранжированием L2 после редукции на Proxy, поддерживая преобразование и комбинацию оценок, переранжирование на основе моделей, сортировку и отсев кандидатов без оркестрации на стороне клиента. В этом выпуске также добавлено встроенное вычисление оценок XGBoost для переранжирования L0 с использованием моделей UBJ, зарегистрированных в качестве FileResources, а также провайдеры инференса Hugging Face для управляемого сервером встраивания текста и переранжирования по сходству предложений.
Поля TEXT для длинных текстов
Поля TEXT обеспечивают полноценную поддержку длинных текстов, устраняя ограничения на длину со стороны хранилища: они поддерживают алгоритмы « text_match », « phrase_match » и BM25. Значения размером до 64 КБ хранятся непосредственно в столбце; более крупные значения перемещаются в файлы LOB на уровне партиций в формате Vortex, при этом в столбце хранятся только ссылки (file_id, offset). Файлы LOB используются совместно всеми сегментами, поэтому при уплотнении перемещаются ссылки, а не переписывается текст. Для RAG это означает извлечение векторов и исходного текста из одного и того же хранилища за один цикл ввода-вывода — не требуется работа с внешним хранилищем BLOB.
Пропуск индекса FAISS
Новый тип индекса « FAISS » принимает произвольные строки-фабрики индексов Faiss через параметр faiss_index_name — IVF64,Flat, HNSW16,Flat, OPQ16,IVF64,PQ16x4 — с передачей параметров поиска, благодаря чему рецепты Faiss воспроизводятся непосредственно в Milvus.
Поддержка форматов Vortex и Lance
Уровень хранения пополняется двумя открытыми столбчатыми форматами: Vortex в качестве внутреннего формата нового поколения — с адаптивными кодировками (словарная, RLE, упаковка битов, сжатие с учетом типов с плавающей запятой), распаковкой без копирования, оптимизированным для смешанных векторно-скалярных рабочих нагрузок — и Lance наряду с Parquet для обмена данными в рамках открытой экосистемы. Vortex станет внутренним форматом по умолчанию, а в планах развития предусмотрены фильтрация с переносом вниз и локальный вариант.
Автономное развертывание Woodpecker
Woodpecker, журнал WAL, лежащий в основе пути потоковой записи, теперь можно развертывать как независимый сервис вместо встраивания в другие узлы — с независимым масштабированием, изоляцией неисправностей и наблюдаемостью, как и любой другой микросервис. Это особенно важно для крупных кластеров и рабочих нагрузок с высокой интенсивностью записи.
Краткий обзор основных функций версии 3.0
Перечисленные ниже функции были представлены в версии 3.0-beta и входят в состав версии 3.0.0; полное описание см. в примечаниях к бета-версии.
- Внешняя коллекция — запрос данных lakehouse (Parquet, Lance, Iceberg, Vortex) на месте: без копирования, только для чтения, синхронизация посредством инкрементального обновления.
- Snapshot — представления коллекций, доступные только для чтения на определенный момент времени по ссылке на сегмент, с практически нулевыми дополнительными затратами на хранение.
- Хранилище V3 (Loon) — столбчатое хранилище на основе манифеста в объектном хранилище; основа для функций «Снимок» и «Внешняя коллекция».
- Запрос / Поиск ORDER BY — сортировка по нескольким полям на стороне сервера с ASC / DESC для каждого поля.
- Агрегация запросов — COUNT / SUM / AVG / MIN / MAX с группировкой, вычисляемая на стороне сервера.
- EmbList + DiskANN — многовекторная индексация на диске для списков вложений StructArray с путями ускорения, такими как Muvera и Lemur.
- Функция MinHash (doc-in, doc-out) — сигнатуры MinHash на стороне сервера плюс «
MINHASH_LSH» для обнаружения почти-дубликатов. - Векторы, допускающие значение NULL — NULL для всех шести типов векторов; поиск пропускает строки с NULL, а функция AddField распространяется на векторные поля.
- TTL сущности — срок действия для каждой строки, определяемый полем TIMESTAMPTZ.
- FileResource — управляемые кластером словари, списки синонимов и списки стоп-слов для анализаторов, BM25 и Text Match.
- Принудительное слияние — уплотнение сегментов, запускаемое оператором, в синхронном или асинхронном режиме.
Примечания по совместимости и поведению
- Storage V3 (Loon) по умолчанию отключен. Функции, зависящие от него — такие как Snapshot и поля TEXT — требуют его включения вручную через
common.storage.useLoonFFI. В более поздних версиях Storage V3 будет включен по умолчанию. - Совместимость между версиями 2.6 и 3.0, а также возможность отката гарантированы — развернутую версию 3.0 можно откатить до версии 2.6. Однако после включения или использования функций, изменяющих формат сериализованных данных (например, Storage V3), откат становится невозможным.
- На данный момент новые версии индекса доступны по выбору. Для вступления в силу вновь введенных алгоритмов индексирования необходимо вручную повысить целевую версию индекса (
dataCoord.targetVecIndexVersionдо 10,dataCoord.targetScalarIndexVersionдо 4); в более поздней версии они будут включены по умолчанию. - Образы с поддержкой GPU переходят на CUDA 12.9 и больше не сохраняют совместимость с GPU в Ubuntu 20.04.
v3.0-beta
Дата выпуска: 9 мая 2026 г.
| Версия Milvus | Версия SDK для Python | Версия 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, обеспечивая его унифицированное обслуживание, обнаружение и пакетную обработку.
Ключевые особенности
Внешняя коллекция
В типичных конвейерах данных для ИИ терабайты вложений и метаданных уже хранятся в объектном хранилище в виде таблиц 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 представлен Storage V3 — столбчатый механизм хранения на основе манифестов, в котором данные и метаданные хранятся в объектном хранилище, совместимом с S3. Каждая версия набора данных фиксируется в виде неизменяемого моментального снимка манифеста — файла в кодировке Avro, в котором фиксируется, какие группы столбцов, дельта-журналы и статистические данные входят в состав набора данных.
Манифесты представляют собой компактные файлы Avro, а дельта-журналы фиксируют удаления на уровне сущностей без перезаписи файлов данных. Это позволяет свести накладные расходы на метаданные к минимуму по мере роста наборов данных. Манифест также отделяет отслеживание метаданных от пути запроса, что позволяет коллекции управлять большим количеством сегментов без ухудшения производительности запросов.
Поскольку состояния хранятся в объектном хранилище, набор данных является самоописательным: любой читатель, имеющий доступ к пути хранения, может обнаружить и интерпретировать его без центрального каталога. Это свойство лежит в основе интеграции с External Collection, Snapshot и будущими озерами данных.
