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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Настройки Warm Up определяются в разделе Tiered Storage на сайте milvus.yaml. Вы можете включить или отключить предварительную загрузку для каждого типа полей или индексов и указать предпочтительную стратегию. Подробные настройки см. в разделе Warm Up.

Этап 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 во время выполнения?

Нет. Все параметры должны быть установлены в milvus.yaml перед запуском Milvus. Для вступления изменений в силу требуется перезапуск.

Влияет ли Tiered Storage на долговечность данных?

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

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

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

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

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

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

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

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

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

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

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

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

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

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