Обзор многоуровневого хранилищаCompatible with Milvus 2.6.4+

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

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

Рассмотрите возможность включения многоуровневого хранилища в таких сценариях, как:

• Коллекции, которые превышают доступную память или емкость NVMe одного узла QueryNode

• Аналитические или пакетные рабочие нагрузки, для которых более быстрая загрузка важнее, чем задержка первого запроса

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

Как это работает

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

Режим полной загрузки против режима многоуровневого хранения

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

• Режим полной загрузки: Во время загрузки QueryNode кэширует полные данные коллекции, включая метаданные, данные полей и индексы, из объектного хранилища.

• Режим многоуровневого хранения: Во время загрузки QueryNode кэширует только метаданные. Данные полей извлекаются по требованию с гранулярностью чанка. Файлы индексов остаются удаленными до тех пор, пока они не понадобятся первому запросу; затем извлекается и кэшируется весь индекс каждого сегмента.

На диаграмме ниже показаны эти различия.

Режим полной загрузки и режим многоуровневого хранения

Рабочий процесс загрузки узла QueryNode

В режиме Tiered Storage рабочий процесс Tiered Storage состоит из следующих этапов:

Рабочий процесс загрузки Querynode

Фаза 1: Ленивая загрузка

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

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

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

Конфигурация

Автоматически применяется при включении многоуровневого хранения. Ручная настройка не требуется.

Этап 2: разогрев

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

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

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

Конфигурация

Warmup можно настроить на трех уровнях:

• Уровень кластера: Определите значения по умолчанию в milvus.yaml, которые применяются ко всем коллекциям.

• Уровень коллекции: Переопределите значения по умолчанию кластера для конкретной коллекции с помощью методов SDK (create_collection, alter_collection_properties).

• Уровень полей/индексов: Тонкая настройка отдельных полей или индексов с помощью методов SDK (add_field, alter_collection_field, add_index, alter_index_properties).

Настройки более высокого уровня переопределяют настройки более низкого уровня (Field/Index > Collection > Cluster). Подробные настройки см. в разделе "Прогрев".

Фаза 3: Частичная загрузка

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

• Поля: Загружаются по требованию на уровне чанков. Извлекаются только те блоки данных, которые соответствуют текущим условиям запроса, что минимизирует ввод-вывод и использование памяти.

• Индексы: Загружаются по требованию на уровне сегментов. Файлы индексов должны загружаться как целые единицы и не могут быть разделены на фрагменты.

Конфигурация

Частичная загрузка применяется автоматически, если включено многоуровневое хранение. Ручная настройка не требуется. Для минимизации задержки при первом попадании критически важных данных сочетайте с Warm Up.

Фаза 4: Выселение

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

Вытеснение происходит в соответствии с политикой наименее часто используемых данных (LRU), что гарантирует, что редко используемые данные будут удаляться первыми, а активные данные останутся в кэше.

Вытеснение регулируется следующими настраиваемыми параметрами:

• Водяные знаки: Определите пороговые значения для памяти или диска, которые запускают и останавливают вытеснение.

• TTL кэша: удаление устаревших кэшированных данных после определенного периода бездействия.

Конфигурация

Включите и настройте параметры выселения в файле milvus.yaml. Подробную информацию о настройке см. в разделе Выселение.

Начало работы

Необходимые условия

• Milvus 2.6.4+

• QueryNodes с выделенной памятью и дисковыми ресурсами

• Бэкэнд для хранения объектов (S3, MinIO и т. д.).

Базовый шаблон конфигурации

Отредактируйте файл конфигурации Milvus (milvus.yaml), чтобы настроить параметры Tiered Storage на уровне кластера:

# milvus.yaml
queryNode:
  segcore:
    tieredStorage:
      # Warm Up Configuration
      warmup:
        scalarField: sync      # Preload scalar field data
        scalarIndex: sync      # Preload scalar indexes
        vectorField: disable   # Don't preload vector field data (large)
        vectorIndex: sync      # Preload vector indexes
      
      # Eviction Configuration
      evictionEnabled: true
      backgroundEvictionEnabled: true
      
      # Memory Watermarks
      memoryLowWatermarkRatio: 0.75   # Stop evicting at 75%
      memoryHighWatermarkRatio: 0.80  # Start evicting at 80%
      
      # Disk Watermarks  
      diskLowWatermarkRatio: 0.75
      diskHighWatermarkRatio: 0.80
      
      # Cache TTL (7 days)
      cacheTtl: 604800

Следующие шаги

1. Настройка Warm Up - оптимизация предварительной загрузки для ваших шаблонов доступа. См. раздел "Разминка".

2. Настройка выселения - установите соответствующие водяные знаки и TTL в соответствии с ограничениями ресурсов. См. раздел Выселение.

3. Мониторинг производительности - отслеживайте частоту обращений к кэшу, частоту вытеснения и задержку запросов.

4. Итерация конфигурации - корректировка настроек на основе наблюдаемых характеристик рабочей нагрузки.

ЧАСТО ЗАДАВАЕМЫЕ ВОПРОСЫ

Можно ли изменять параметры Tiered Storage во время выполнения?

Это зависит от типа параметра:

• Параметры разогрева: Прогрев на уровне коллекции и на уровне полей/индексов можно настроить через SDK до загрузки коллекции. После загрузки коллекции ее необходимо сначала освободить, изменить настройки, а затем снова загрузить.

• Настройки выселения и водяных знаков: Они должны быть установлены в milvus.yaml перед запуском Milvus. Изменения требуют перезапуска для вступления в силу.

Влияет ли многоуровневое хранение на долговечность данных?

Нет. Сохранность данных по-прежнему обеспечивается удаленным хранилищем объектов. Tiered Storage управляет кэшированием только на QueryNodes.

Всегда ли запросы будут выполняться быстрее при использовании Tiered Storage?

Не обязательно. Tiered Storage сокращает время загрузки и использование ресурсов, но запросы, обращающиеся к некэшированным (холодным) данным, могут работать с большей задержкой. Для рабочих нагрузок, чувствительных к задержкам, рекомендуется использовать режим полной загрузки.

Почему на узле QueryNode не хватает ресурсов даже при включенном многоуровневом хранении?

Две распространенные причины:

• Узел QueryNode был настроен со слишком малым количеством ресурсов. Водяные знаки соотносятся с доступными ресурсами, поэтому недостаточное выделение ресурсов усиливает ошибочные суждения.

• Ресурсы QueryNode используются совместно с другими рабочими нагрузками, поэтому Tiered Storage не может правильно оценить фактическую доступную емкость.

Чтобы решить эту проблему, мы рекомендуем выделить выделенные ресурсы для узлов QueryNode.

Почему некоторые запросы терпят неудачу при высоком параллелизме?

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

Почему после включения многоуровневого хранилища увеличивается задержка поиска/запроса?

Возможные причины включают:

• Частые запросы к холодным данным, которые приходится извлекать из хранилища.

• Водяные знаки установлены слишком близко друг к другу, что приводит к частому синхронному вытеснению.