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

Оптимизация запросов и записи

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

В сценариях крупномасштабного векторного поиска, по мере роста размерности векторов и объёма данных, кластеры могут сталкиваться с узкими местами производительности, такими как низкая пропускная способность записи и сильные колебания задержки запросов (P99). В отличие от традиционного поиска по ключевым словам, векторный поиск характеризуется вычислительно интенсивным построением индекса и интенсивным по использованию памяти извлечением. Стандартные конфигурации Elasticsearch и OpenSearch могут испытывать трудности с выполнением сложных топологических вычислений. Для решения этих проблем CSS vector database поддерживает сквозную настройку производительности кластеров, охватывающую как запись, так и запрос. Это помогает достичь оптимального баланса между производительностью системы и затратами, обеспечивая высокий уровень полноты.

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

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

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

  • Description

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

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

     
    PUT {index_name}/_settings
    {
        "number_of_replicas": 0
    }
  • Result

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

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

  • Description

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

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

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

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

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

  • Описание

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

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

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

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

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

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

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

  • Описание

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

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

     
    POST {index_name}/_forcemerge?max_num_segments=1
  • Result

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

Solution 2: Настройте политику автоматического слияния

  • Description

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

    Настройте политику автоматического слияния для индекса.

     
    PUT {index_name}/_settings
    {
      "index": {
        "merge": {
          "policy": {
            "max_merged_segment": "10gb",
            "max_merge_at_once": 10,
            "segments_per_tier": 5,
            "floor_segment": "200mb"
          }
        }
      }
    }
    Table 1 Параметры настройки политики автоматического слияния

    Parameter

    Type

    Default Value

    Description

    max_merged_segment

    String

    5GB

    Максимальный размер сегмента после слияния. Сегменты, превышающие этот размер, исключаются из автоматического слияния, но остаются доступными для принудительного слияния. Это предотвращает бесконечный рост сегментов, так как они могут блокировать I/O‑связи. Для векторных индексов увеличение этого значения помогает уменьшить общее количество сегментов.

    Формат значения: положительное целое число + единица измерения.

    Поддерживаемые единицы измерения: B, KB, MB и GB (без учёта регистра).

    max_merge_at_once

    Integer

    10

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

    Минимальное значение: 2

    segments_per_tier

    Integer

    10

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

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

    floor_segment

    String

    2MB

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

    Формат значения: положительное целое число + единица измерения.

    Поддерживаемые единицы измерения: B, KB, MB и GB (без учёта регистра).
  • Результат

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

Решение 3: Отрегулировать предел circuit breaker для off-heap memory

  • Описание

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

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

     
    PUT _cluster/settings
    {
      "persistent": {
        "native.cache.circuit_breaker.cpu.limit": "85%"
      }
    }
  • Результат

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

Решение 4: Оптимизировать возврат полей

  • Описание

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

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

     
    POST {index_name}/_search
    {
      "size": 2,
      "stored_fields": ["_none_"],
      "docvalue_fields": ["my_label"],
      "query": {
        "vector": {
          "my_vector": {
            "vector": [1, 1],
            "topk": 2
          }
        }
      }
    }
  • Result

    Нет необходимости разбирать весь документ _source. Колонко-ориентированное хранение (docvalues) снижает нагрузку во время фазы получения и повышает производительность запросов.
Родительская тема: CSS Vector Database
Предыдущая статья
Реализация вложенного векторного поиска
Следующая статья
Управление кэшем векторного поиска
Поддержка Юридические документы Политика конфиденциальности
© 2026 Cloud.ru