Home
Blog
Как безопасно перейти с Milvus 2.5.x на Milvus 2.6.x

Как безопасно перейти с Milvus 2.5.x на Milvus 2.6.x

Tutorials

December 25, 2025

Yiqing Lu

Milvus 2.6 уже давно в продаже, и это серьезный шаг вперед для проекта. В релизе усовершенствована архитектура, повышена производительность в реальном времени, снижено потребление ресурсов и улучшено поведение при масштабировании в производственных средах. Многие из этих улучшений были сформированы непосредственно под влиянием отзывов пользователей, и первые пользователи 2.6.x уже сообщили о заметно более быстром поиске и более предсказуемой производительности системы при высоких или динамических нагрузках.

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

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

Изменения в архитектуре с Milvus 2.5 до Milvus 2.6

Прежде чем перейти к самому процессу обновления, давайте сначала разберемся, как изменилась архитектура Milvus в Milvus 2.6.

Архитектура Milvus 2.5

Milvus 2.5 Architecture Архитектура Milvus 2.5

В Milvus 2.5 потоковые и пакетные рабочие процессы были переплетены на нескольких рабочих узлах:

QueryNode обрабатывал как исторические запросы , так и инкрементные (потоковые) запросы.
DataNode выполнял как промывку в момент поступления , так и фоновое уплотнение исторических данных.

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

Архитектура Milvus 2.6

Milvus 2.6 Architecture Архитектура Milvus 2.6

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

QueryNode теперь обрабатывает только пакетные запросы к историческим сегментам.
DataNode теперь выполняет только задачи, связанные с историческими данными, такие как уплотнение и создание индексов.

StreamingNode поглощает все задачи, связанные с потоковой передачей данных, которые в Milvus 2.5 были разделены между DataNode, QueryNode и даже Proxy, внося ясность и уменьшая межролевое разделение состояний.

Milvus 2.5.x vs Milvus 2.6.x: Сравнение по компонентам

	Milvus 2.5.x	Milvus 2.6.x	Что изменилось
Сервисы координаторов	RootCoord / QueryCoord / DataCoord (или MixCoord)	MixCoord	Управление метаданными и планирование задач объединены в единый MixCoord, что упрощает логику координации и снижает сложность распределения.
Уровень доступа	Прокси	Прокси	Запросы на запись направляются только через потоковый узел для ввода данных.
Рабочие узлы	-	Узел потоковой обработки	Выделенный узел потоковой обработки, отвечающий за всю логику инкрементальной обработки (растущие сегменты), включая:- инкрементное получение данных- запрос инкрементных данных- сохранение инкрементных данных в объектном хранилище- запись на основе потоков- восстановление после сбоев на основе WAL
	Узел запросов	Узел запросов	Узел пакетной обработки, который обрабатывает запросы только к историческим данным.
	Узел данных	Узел данных	Узел пакетной обработки, отвечающий только за исторические данные, включая уплотнение и построение индексов.
	Индексный узел	-	Index Node объединен с Data Node, что упрощает определение ролей и топологию развертывания.

Одним словом, Milvus 2.6 проводит четкую границу между потоковыми и пакетными рабочими нагрузками, устраняя путаницу между компонентами, наблюдавшуюся в 2.5, и создавая более масштабируемую и удобную в обслуживании архитектуру.

Основные характеристики Milvus 2.6

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

Улучшения стоимости и эффективности

КвантованиеRaBitQ для первичных индексов - новый метод 1-битного квантования, который сжимает векторные индексы до 1/32 от их исходного размера. В сочетании с реранжированием SQ8 он сокращает использование памяти до ~28 %, увеличивает QPS на 4 × и поддерживает ~95 % запоминания, значительно снижая аппаратные затраты.
Оптимизированный полнотекстовый поискBM25 - встроенный скоринг BM25 на основе разреженных векторов веса терминов. Поиск по ключевым словам работает на 3-4× быстрее (до 7× на некоторых наборах данных) по сравнению с Elasticsearch, при этом размер индекса составляет около трети от исходных текстовых данных.
Индексирование путей JSON с измельчением JSON - структурированная фильтрация по вложенному JSON теперь работает значительно быстрее и гораздо более предсказуемо. Предварительно проиндексированные пути JSON сокращают время задержки фильтрации с 140 мс → 1,5 мс (P99: 480 мс → 10 мс), делая гибридный векторный поиск + фильтрацию метаданных значительно более отзывчивыми.
Расширенная поддержка типов данных - добавлены типы векторов Int8, поля геометрии (POINT / LINESTRING / POLYGON) и массивы структур. Эти расширения поддерживают геопространственные рабочие нагрузки, более богатое моделирование метаданных и более чистые схемы.
Upsert для частичных обновлений - теперь вы можете вставлять или обновлять сущности с помощью одного вызова первичного ключа. Частичные обновления изменяют только указанные поля, уменьшая усиление записи и упрощая конвейеры, которые часто обновляют метаданные или вставки.

Улучшения в области поиска и извлечения информации

Улучшенная обработка текста и многоязычная поддержка: Новые токенизаторы Lindera и ICU улучшают обработку японских, корейских и многоязычных текстов. Jieba теперь поддерживает пользовательские словари. run_analyzer помогает отладить поведение токенизации, а мультиязычные анализаторы обеспечивают согласованный межъязыковой поиск.
Высокоточное сопоставление текстов: Phrase Match обеспечивает выполнение упорядоченных запросов по фразам с настраиваемым отклонением. Новый индекс NGRAM ускоряет выполнение подстрочных запросов и запросов LIKE как по полям VARCHAR, так и по путям JSON, обеспечивая быстрое частичное и нечеткое сопоставление текста.
Реранжирование с учетом времени и метаданных: Ранжировщики с распадом (экспоненциальный, линейный, гауссовый) корректируют оценки, используя временные метки; ранжировщики с повышением применяют правила, основанные на метаданных, для продвижения или понижения результатов. Оба способа помогают точно настроить поведение поиска без изменения базовых данных.
Упрощенная интеграция моделей и автовекторизация: Встроенная интеграция с OpenAI, Hugging Face и другими провайдерами встраивания позволяет Milvus автоматически векторизовать текст во время операций вставки и запроса. Больше не нужно вручную создавать конвейеры встраивания для распространенных случаев использования.
Онлайн-обновление схемы для скалярных полей: Добавление новых скалярных полей в существующие коллекции без простоев и перезагрузки, что упрощает эволюцию схемы по мере роста требований к метаданным.
Обнаружение близких дубликатов с помощью MinHash: MinHash + LSH обеспечивает эффективное обнаружение близких дубликатов в больших наборах данных без дорогостоящих точных сравнений.

Обновления архитектуры и масштабируемости

Многоуровневое хранилище для управления "горячими" и "холодными" данными: Разделение горячих и холодных данных между SSD и объектными хранилищами; поддержка ленивой и частичной загрузки; устранение необходимости полной локальной загрузки коллекций; снижение использования ресурсов до 50 % и ускорение загрузки больших наборов данных.
Служба потоковой передачи данных в режиме реального времени: Добавляет выделенные узлы потоковой передачи, интегрированные с Kafka/Pulsar, для непрерывного ввода данных; обеспечивает немедленное индексирование и доступность запросов; повышает пропускную способность записи и ускоряет восстановление после сбоев для быстро меняющихся рабочих нагрузок в режиме реального времени.
Улучшенная масштабируемость и стабильность: Milvus теперь поддерживает 100 000+ коллекций для крупных многопользовательских сред. Обновления инфраструктуры - Woodpecker (WAL с нулевым диском), Storage v2 (уменьшение IOPS/памяти) и Coordinator Merge - повышают стабильность кластера и обеспечивают предсказуемое масштабирование при высоких рабочих нагрузках.

Полный список функций Milvus 2.6 можно найти в примечаниях к выпуску Milvus.

Как перейти с Milvus 2.5.x на Milvus 2.6.x

Чтобы сохранить максимальную доступность системы во время обновления, кластеры Milvus 2.5 следует обновлять до Milvus 2.6 в следующем порядке.

1. Сначала запустите узел потоковой передачи

Запустите узел потоковой передачи заранее. Новый Delegator (компонент в Query Node, отвечающий за обработку потоковых данных) должен быть перемещен в Milvus 2.6 Streaming Node.

2. Обновление MixCoord

Обновите компоненты координатора до MixCoord. На этом этапе MixCoord должен определить версии рабочих узлов, чтобы обеспечить кросс-версионную совместимость в распределенной системе.

3. Обновление узла запросов

Обновление узла запросов обычно занимает больше времени. На этом этапе узлы данных и индексные узлы Milvus 2.5 могут продолжать выполнять такие операции, как промывка и построение индексов, что помогает снизить нагрузку на сторону запроса во время обновления узлов запроса.

4. Обновление узла данных

После того как узлы данных Milvus 2.5 будут выведены из сети, операции Flush станут недоступны, а данные в растущих сегментах могут продолжать накапливаться до тех пор, пока все узлы не будут полностью обновлены до Milvus 2.6.

5. Обновление прокси-сервера

После обновления прокси до Milvus 2.6 операции записи на этом прокси будут недоступны до тех пор, пока все компоненты кластера не будут обновлены до версии 2.6.

6. Удалите индексный узел

После обновления всех остальных компонентов автономный индексный узел можно безопасно удалить.

Примечания:

С момента завершения обновления DataNode и до завершения обновления Proxy операции Flush недоступны.
С момента обновления первого Proxy до обновления всех узлов Proxy некоторые операции записи будут недоступны.
При обновлении непосредственно с Milvus 2.5.x до 2.6.6 операции DDL (Data Definition Language) будут недоступны в процессе обновления из-за изменений в структуре DDL.

Как обновиться до Milvus 2.6 с помощью Milvus Operator

Milvus Operator - это оператор Kubernetes с открытым исходным кодом, который обеспечивает масштабируемый, высокодоступный способ развертывания, управления и обновления всего стека сервисов Milvus на целевом кластере Kubernetes. Стек сервисов Milvus, управляемый оператором, включает в себя:

основные компоненты Milvus
Необходимые зависимости, такие как etcd, Pulsar и MinIO.

Milvus Operator следует стандартному шаблону Kubernetes Operator. Он представляет Milvus Custom Resource (CR), который описывает желаемое состояние кластера Milvus, такое как его версия, топология и конфигурация.

Контроллер постоянно следит за кластером и сверяет фактическое состояние с желаемым, определенным в CR. При внесении изменений (например, обновлении версии Milvus) оператор автоматически применяет их контролируемым и повторяющимся образом, обеспечивая автоматическое обновление и непрерывное управление жизненным циклом.

Пример пользовательского ресурса (CR) Milvus

apiVersion: milvus.io/v1beta1
kind: Milvus
metadata:
  name: my-milvus-mansion    
  namespace: dev       
spec:
  mode: cluster                  # cluster or standalone
  # Milvus Components
  components:
    image: milvusdb/milvus:v2.6.5
    imageUpdateMode: rollingUpgrade 
    proxy:                   
      replicas: 1          
    mixCoord:              
      replicas: 1           
    dataNode:               
      replicas: 1          
    queryNode:              
      replicas: 2           
      resources:
        requests:
          cpu: "2"
          memory: "8Gi"  
  # Dependencies, including etcd, storage and message stream
  dependencies:
    etcd:                   
      inCluster:
        values:
          replicaCount: 3    
    storage:                 
      type: MinIO
      inCluster:
        values:
          mode: distributed     
    msgStreamType: pulsar    
    pulsar:
      inCluster:
        values:
          bookkeeper:
            replicas: 3   
  # Milvus configs
  config:
    dataCoord:
      enableActiveStandby: true

Скользящее обновление с Milvus 2.5 до 2.6 с помощью Milvus Operator

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

1. Обнаружение сценариев обновления

Во время обновления Milvus Operator определяет целевую версию Milvus по спецификации кластера. Это делается либо путем:

Проверки тега изображения, определенного в spec.components.image, или
чтения явной версии, указанной в spec.components.version

Затем оператор сравнивает желаемую версию с текущей версией, которая записана в status.currentImage или status.currentVersion. Если текущая версия - 2.5, а желаемая - 2.6, оператор идентифицирует обновление как сценарий обновления 2.5 → 2.6.

2. Порядок выполнения скользящего обновления

Когда обнаружено обновление 2.5 → 2.6 и режим обновления установлен на скользящее обновление (spec.components.imageUpdateMode: rollingUpgrade, которое используется по умолчанию), Milvus Operator автоматически выполняет обновление в заранее определенном порядке, согласованном с архитектурой Milvus 2.6:

Запуск узла потоковой передачи → Обновление MixCoord → Обновление узла запросов → Обновление узла данных → Обновление прокси → Удаление индексного узла.

3. Автоматическая консолидация координаторов

В Milvus 2.6 несколько компонентов координатора заменяются одним MixCoord. Milvus Operator обрабатывает этот архитектурный переход автоматически.

Когда spec.components.mixCoord настроен, оператор вызывает MixCoord и ждет, пока он будет готов. После того как MixCoord полностью готов к работе, оператор плавно отключает устаревшие компоненты координатора - RootCoord, QueryCoord и DataCoord, завершая переход без необходимости ручного вмешательства.

Этапы перехода с Milvus 2.5 на 2.6

1.Обновите Milvus Operator до последней версии (в данном руководстве мы используем версию 1.3.3, которая была последней на момент написания статьи).

# Option 1: Using Helm
helm upgrade --install milvus-operator \
  -n milvus-operator --create-namespace \
  https://github.com/zilliztech/milvus-operator/releases/download/v1.3.3/milvus-operator-1.3.3.tgz
 # Option 2: Using kubectl & raw manifests
 kubectl apply -f https://raw.githubusercontent.com/zilliztech/milvus-operator/v1.3.3/deploy/manifests/deployment.yaml

2.Объедините компоненты координатора

kubectl patch milvus my-release -n demo-operator --type=merge -p '
{
  "spec": {
    "components": {
      "mixCoord": {
        "replicas": 1
      }
    }
  }
}'

3.Убедитесь, что кластер работает под управлением Milvus 2.5.16 или более поздней версии.

kubectl patch milvus my-release -n demo-operator --type=merge -p '
{
  "spec": {
    "components": {
      "image": "milvusdb/milvus:v2.5.22"
    }
  }
}'
# wait till updated
kubectl wait milvus my-release -n demo-operator --for=condition=milvusupdated --timeout=1h

4.Обновите Milvus до версии 2.6.

kubectl patch milvus my-release -n demo-operator --type=merge -p '
{
  "spec": {
    "components": {
      "image": "milvusdb/milvus:v2.6.5"
    }
  }
}'
# wait till updated
kubectl wait milvus my-release -n demo-operator --for=condition=milvusupdated --timeout=1h

Как обновить Milvus до версии 2.6 с помощью Helm

При развертывании Milvus с помощью Helm все ресурсы Kubernetes Deployment обновляются параллельно, без гарантированного порядка выполнения. В результате Helm не обеспечивает строгого контроля над последовательностью обновления компонентов. Поэтому для производственных сред настоятельно рекомендуется использовать Milvus Operator.

Milvus по-прежнему можно обновить с 2.5 до 2.6 с помощью Helm, выполнив следующие шаги.

Системные требования

Версия Helm: ≥ 3.14.0
Версия Kubernetes: ≥ 1.20.0

1.Обновите таблицу Milvus Helm до последней версии. В этом руководстве мы используем версию 5.0.7, которая была последней на момент написания руководства.

helm repo add zilliztech https://zilliztech.github.io/milvus-helm
helm repo update

2.Если кластер развернут с несколькими компонентами координаторов, сначала обновите Milvus до версии 2.5.16 или более поздней и включите MixCoord.

mixCoordinator
。
helm upgrade -i my-release zilliztech/milvus \
  --namespace=helm-demo \
  --set image.all.tag="v2.5.22" \
  --set mixCoordinator.enabled=true \
  --set rootCoordinator.enabled=false \
  --set indexCoordinator.enabled=false \
  --set queryCoordinator.enabled=false \
  --set dataCoordinator.enabled=false \
  --set streaming.enabled=false \
  --set indexNode.enabled=true \
  --reset-then-reuse-values \
  --version=5.0.7 \
  --wait --timeout 1h

3.Обновите Milvus до версии 2.6.

helm upgrade my-release zilliztech/milvus \
  --namespace=helm-demo \
  --set image.all.tag="v2.6.5" \
  --set streaming.enabled=true \
  --set indexNode.enabled=false \
  --reset-then-reuse-values \
  --version=5.0.7 \
  --wait --timeout 1h

Часто задаваемые вопросы по обновлению и работе Milvus 2.6

Q1: Milvus Helm против Milvus Operator - какой из них мне использовать?

Для производственных сред настоятельно рекомендуется использовать Milvus Operator.

Подробности см. в официальном руководстве: https://github.com/zilliztech/milvus-operator?tab=readme-ov-file#milvus-operator-vs-helm.

Q2: Как выбрать очередь сообщений (MQ)?

Рекомендуемый MQ зависит от режима развертывания и операционных требований:

1. Автономный режим: Для экономичных развертываний рекомендуется RocksMQ.

2. Кластерный режим

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

3. Woodpecker (представлен в Milvus 2.6): Woodpecker устраняет необходимость во внешней очереди сообщений, снижая стоимость и эксплуатационную сложность.

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

Вопрос 3: Можно ли переключать очередь сообщений во время обновления?

Нет. Переключение очереди сообщений во время обновления в настоящее время не поддерживается. В будущих выпусках будут представлены API-интерфейсы управления для поддержки переключения между Pulsar, Kafka, Woodpecker и RocksMQ.

Вопрос 4: Нужно ли обновлять конфигурации ограничения скорости для Milvus 2.6?

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

Вопрос 5: Изменяются ли роли или конфигурации мониторинга после слияния координаторов?

Роли мониторинга остаются неизменными (RootCoord, QueryCoord, DataCoord).
Существующие параметры конфигурации продолжают работать как прежде.
Вводится новый параметр конфигурации, mixCoord.enableActiveStandby, который будет возвращаться к rootcoord.enableActiveStandby, если он не задан явно.

Q6: Каковы рекомендуемые настройки ресурсов для StreamingNode?

Для легкой обработки данных в реальном времени или периодической записи и запросов достаточно небольшой конфигурации, например, 2 ядра CPU и 8 ГБ памяти.
При интенсивной обработке данных в реальном времени или постоянных нагрузках, связанных с записью и запросами, рекомендуется выделять ресурсы, сопоставимые с ресурсами узла Query Node.

Вопрос 7: Как обновить автономное развертывание с помощью Docker Compose?

Для автономных развертываний на базе Docker Compose достаточно обновить тег образа Milvus в docker-compose.yaml.

Подробности см. в официальном руководстве: https://milvus.io/docs/upgrade_milvus_standalone-docker.md.

Заключение

Milvus 2.6 знаменует собой значительное улучшение как архитектуры, так и операций. Разделив потоковую и пакетную обработку с помощью StreamingNode, объединив координаторы в MixCoord и упростив роли рабочих, Milvus 2.6 обеспечивает более стабильную, масштабируемую и простую в эксплуатации основу для крупномасштабных векторных рабочих нагрузок.

Эти архитектурные изменения делают обновления - особенно с Milvus 2.5 - более чувствительными к порядку. Успешное обновление зависит от соблюдения зависимостей компонентов и временных ограничений доступности. Для производственных сред рекомендуется использовать Milvus Operator, поскольку он автоматизирует последовательность обновлений и снижает операционный риск, в то время как обновления на базе Helm лучше подходят для непроизводственных сред.

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

У вас есть вопросы или вы хотите получить подробную информацию о любой функции последней версии Milvus? Присоединяйтесь к нашему каналу Discord или создавайте проблемы на GitHub. Вы также можете заказать 20-минутный индивидуальный сеанс, чтобы получить знания, рекомендации и ответы на свои вопросы в Milvus Office Hours.