/DOCS
Облачная платформаAdvanced

Оптимизация производительности векторного Кластера

Эта статья полезна?
Язык статьи: Русский
Показать оригинал
Страница переведена автоматически и может содержать неточности. Рекомендуем сверяться с английской версией.

В этой теме объясняется, как оптимизировать производительность CSS векторной базы данных с двух сторон — записи и запроса.

Оптимизация производительности записи

Запись векторных данных создает три основных накладных расхода: синхронизация реплик, обновление индекса и объединение сегментов. Когда индексные данные записываются в реальном времени, частые операции обновления индекса генерируют большое количество небольших сегментов. Это приводит к частому построению и объединению векторного индекса, что потребляет избыточные ресурсы CPU/IO. Вы можете попробовать следующие решения для оптимизации производительности записи.

Решение 1: временно отключить реплики

  • Описание

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

  • Операция

    Установите количество реплик:

    PUT my_index/_settings
    {
        "number_of_replicas": 0
    }
  • Результат

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

Решение 2: изменить интервал обновления

  • Описание

    Установите интервал обновления индекса на 120 s или более, чтобы уменьшить количество небольших сегментов, генерируемых при частых обновлениях индекса, а также снизить нагрузку на построение векторного индекса, вызываемую слиянием сегментов. Вы также можете отключить автоматическое обновление индекса, установив интервал обновления на –1. Используйте это решение в сценариях записи с высокой пропускной способностью (например, при записи векторизованных лог‑данных).

  • Операция

    Установить refresh_interval.

    PUT my_index/_settings
    {
        "refresh_interval": "120s"
    }
  • Результат

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

Решение 3: увеличить потоки индексации

  • Описание

    Увеличение количества потоков для построения векторного индекса ускоряет процесс индексирования. Однако слишком большое количество таких потоков будет конкурировать за ресурсы запросов. Используйте это решение, когда имеются достаточные CPU‑ресурсы, но задержка записи высока—например в средах с ускорением GPU.

  • Операция

    Значение по умолчанию native.vector.index_threads равно 4. При необходимости измените это значение.

    PUT _cluster/settings
    {
      "persistent": {
        "native.vector.index_threads": 8
      }
    }
  • Результат

    Построение векторного индекса ускоряется, а производительность одновременных записей повышается.

Оптимизация производительности запросов

На производительность запросов влияют следующие факторы: количество сегментов, механизм ограничения памяти и восстановление полей. Чрезмерно большое количество сегментов снижает эффективность поиска; когда off-heap память становится недостаточной, данные векторного индекса часто выгружаются из памяти и загружаются обратно; восстановление всех полей увеличивает нагрузку во фазе получения. Вы можете оптимизировать производительность запросов, устранив эти факторы.

Решение 1: выполнить принудительное слияние

  • Описание

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

  • Операция

    Выполните операцию принудительного слияния:

    POST my_index/_forcemerge?max_num_segments=1
  • Результат

    Несколько сегментов объединяются в один сегмент. Это уменьшает нагрузку на сканирование файлов и ускоряет скорость запросов.

Решение 2: изменить верхний предел размера сегмента

  • Описание

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

  • Операция

    Увеличьте максимальный размер сегмента:

    PUT my_index/_settings
    {
      "index.merge.policy.max_merged_segment": "10gb"
    }
  • Результат

    Увеличение максимального размера сегмента помогает уменьшить количество сегментов и, таким образом, ускорить производительность запросов.

Solution 3: настроить лимит circuit breaker для памяти off-heap

  • Description

    Когда требуемая для векторных индексов память off-heap превышает лимит circuit breaker, менеджер кэша индекса часто переключает данные индекса в кэш и из кэша, что замедляет запросы. Вы можете увеличить лимит circuit breaker, чтобы уменьшить срабатывание circuit breaking (что фиксируется в журнале как CircuitBreakingException), вызванное недостаточным объёмом памяти.

  • Operation

    Стандартный лимит circuit breaker для памяти off-heap составляет 80%. При необходимости вы можете изменить этот лимит.

    PUT _cluster/settings
    {
      "persistent": {
        "native.cache.circuit_breaker.cpu.limit": "85%"
      }
    }
  • Result

    Вероятность выгрузки данных векторного индекса из памяти снижается, а дрожание запросов уменьшается.

Solution 4: оптимизировать выборку полей

  • Description

    Если результат запроса должен включать только несколько полей, содержащих ключевые слова или числовые значения, вы можете воспользоваться параметром docvalue_fields для их получения. Этот метод подходит, когда требуется извлечь только числовые или перечислимые метаданные (например, идентификаторы продуктов и метки классов). Он может значительно снизить нагрузку на этапе выборки.

  • Операция

    Используйте параметр docvalue_fields, чтобы получить только определённые поля:

    POST my_index/_search
    {
      "size": 2,
      "stored_fields": ["_none_"],
      "docvalue_fields": ["my_label"],
      "query": {
        "vector": {
          "my_vector": {
            "vector": [1, 1],
            "topk": 2
          }
        }
      }
    }
  • Результат

    Нет необходимости разбирать весь документ _source. Колонко‑ориентированное хранение (docvalues) уменьшает нагрузку на этапе выборки и повышает производительность запросов.

Настройка тайм‑аута кеша

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

Выполните следующую команду, чтобы установить тайм‑аут кеша:

PUT _cluster/settings
{
  "persistent": {
    "native.cache.expiry.enabled": "true",
    "native.cache.expiry.time": "30m"
  }
}
Таблица 1 Описание параметра

Параметр

Тип

Описание

native.cache.expiry.enabled

Boolean

Включать ли автоматическое истечение срока кэша.

Диапазон значений:

  • true: Включить автоматическое истечение срока кэша. Неактивные данные в кэше будут очищены.
  • false (значение по умолчанию): Отключить автоматическое истечение срока кэша.

native.cache.expiry.time

String

Тайм-аут неактивных элементов кэша.

Этот параметр применяется только когда native.cache.expiry.enabled=true.

Значение: строка времени, например, 24h (24 часа) или 30m (30 минут).

Значение по умолчанию: 24h.

Поддержка Юридические документы
© 2026 Cloud.ru