Лучшие практики для многоуровневого хранения данныхCompatible with Milvus 2.6.4+

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

Перед началом работы

• Milvus v2.6.4 или более поздняя версия

• QueryNodes должны иметь выделенные локальные ресурсы (память и диск). Совместное использование ресурсов может исказить оценку кэша и привести к ошибкам при выселении.

Выберите правильную стратегию

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

Цель	Рекомендуемая направленность	Ключевой механизм
Минимизация задержки при первом запросе	Предварительная загрузка критических полей	Разминка
Эффективная работа с крупномасштабными данными	Загрузка по требованию	Ленивая загрузка + частичная загрузка
Поддерживайте долгосрочную стабильность	Предотвращение переполнения кэша	Выселение
Баланс производительности и емкости	Комбинируйте предварительную нагрузку и динамическое кэширование	Гибридная конфигурация

Сценарий 1: поиск в режиме реального времени с низкой задержкой

Когда использовать

• Задержка запроса критична (например, рекомендации в реальном времени или ранжирование поиска)

• К основным векторным индексам и скалярным фильтрам обращаются часто

• Постоянная производительность важнее скорости запуска

Рекомендуемая конфигурация

# milvus.yaml
queryNode:
  segcore:
    tieredStorage:
      warmup:
        # scalar field/index warm-up to eliminate first-time latency
        scalarField: sync
        scalarIndex: sync
        # warm-up of vector fields is disabled (if the original vector is not required)
        vectorField: disable
        # vector indexes warm-up to elminate first-time latenct
        vectorIndex: sync
      # enable cache eviction, and also turn on background asynchronous eviction
      # to reduce the triggering of synchronous eviction.
      evictionEnabled: true
      backgroundEvictionEnabled: true
      memoryLowWatermarkRatio: 0.75
      memoryHighWatermarkRatio: 0.8
      diskLowWatermarkRatio: 0.75
      diskHighWatermarkRatio: 0.8
      # no expiration time, which avoids frequent reloading
      cacheTtl: 0

Обоснование

• Прогрев устраняет задержку при первом обращении к скалярным и векторным индексам с высокой частотой.

• Фоновое вытеснение поддерживает стабильное давление на кэш, не блокируя запросы.

• Отключение TTL кэша позволяет избежать ненужных перезагрузок для "горячих" данных.

Сценарий 2: автономный пакетный анализ

Когда использовать

• Высокая устойчивость к задержкам запросов

• Рабочие нагрузки включают массивные наборы данных или множество сегментов.

• Пропускная способность и производительность приоритетнее скорости отклика.

Рекомендуемая конфигурация

# milvus.yaml
queryNode:
  segcore:
    tieredStorage:
      enabled: true
      warmup:
        # disable scalar field/index warm-up to speed up loading
        scalarField: disable
        scalarIndex: disable
        # disable vector field/index warm-up to speed up loading
        vectorField: disable
        vectorIndex: disable
      # enable cache eviction, and also turn on background asynchronous eviction
      # to reduce the triggering of synchronous eviction.
      evictionEnabled: true
      backgroundEvictionEnabled: true
      memoryLowWatermarkRatio: 0.7
      memoryHighWatermarkRatio: 0.85
      diskLowWatermarkRatio: 0.7
      diskHighWatermarkRatio: 0.85
      # use 1 day expiration to clean unused cache
      cacheTtl: 86400

Обоснование

• Отключение прогрева ускоряет запуск при инициализации многих сегментов.

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

• TTL кэша автоматически очищает неиспользуемые данные для освобождения локального пространства.

Сценарий 3: гибридное развертывание (смешанное онлайн + офлайн)

Когда использовать

• Один кластер обслуживает как онлайн, так и аналитические рабочие нагрузки

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

Рекомендуемая стратегия

• Применяйте конфигурацию реального времени для коллекций, чувствительных к задержкам

• Применять автономную конфигурацию для аналитических или архивных коллекций

• Настройте коэффициенты evictableMemoryCacheRatio, cacheTtl и watermark независимо для каждого типа рабочей нагрузки.

Обоснование

Комбинирование конфигураций позволяет осуществлять тонкий контроль над распределением ресурсов.

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

Дополнительные советы по настройке

Аспект	Рекомендация	Объяснение
Область разминки	Предварительно загружайте только поля или индексы с высокой частотой запросов.	Излишняя предварительная загрузка увеличивает время загрузки и потребление ресурсов.
Настройка выселения	Начните с водяных знаков по умолчанию (75-80 %) и постепенно регулируйте их.	Небольшой разрыв приводит к частому вытеснению; большой разрыв задерживает освобождение ресурсов.
TTL кэша	Отключите для стабильных горячих наборов данных; включите (например, 1-3 дня) для динамических данных.	Предотвращает накопление устаревшего кэша, балансируя накладные расходы на очистку.
Коэффициент избыточной коммисии	Избегайте значений > 0,7, если нет большого запаса ресурсов.	Чрезмерный overcommit может привести к переполнению кэша и нестабильной задержке.
Мониторинг	Отслеживайте коэффициент попадания в кэш, использование ресурсов и частоту вытеснения.	Частые холодные нагрузки могут указывать на то, что прогрев или водяные знаки нуждаются в корректировке.