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

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

Эта статья полезна?

Язык статьи: Русский

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

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

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

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

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

Описание
Временно отключайте реплики во время загрузки данных и включайте их после завершения загрузки данных. Используйте это решение при пакетном импорте исторических данных или выполнении полного обновления (например, при инициализации векторной базы данных).
Операция
Установите количество реплик:
```
PUT my_index/_settings
{
    "number_of_replicas": 0
}
```
Результат
Производительность записи повышается за счёт избегания построения векторного индекса в реальном времени на узлах‑репликах.

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

Описание
Установите интервал обновления индекса на 120s или больше, чтобы снизить количество небольших сегментов, создаваемых при частых обновлениях индекса, а также уменьшить затраты на построение векторного индекса, вызываемые слиянием сегментов. Вы также можете отключить автоматическое обновление индекса, установив интервал обновления в значение –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
  }
}
```
Результат
Построение векторного индекса ускорено, а производительность одновременных записей повышена.

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

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

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

Описание
После пакетного ввода данных выполните операцию принудительного слияния, чтобы принудительно объединить сегменты, тем самым уменьшив их количество. Как правило, эту операцию следует выполнять после ввода данных и до запроса данных (например, после запланированного пакетного ввода).
Операция
Выполните операцию принудительного слияния:
```
POST my_index/_forcemerge?max_num_segments=1
```
Результат
Несколько сегментов объединяются в один сегмент. Это уменьшает накладные расходы на сканирование файлов и ускоряет скорость запросов.

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

Описание
Во время пакетных записей максимальный размер сегментов, генерируемых системой, составляет 5 ГБ. Вы можете увеличить этот верхний предел, чтобы уменьшить количество сегментов, создаваемых после автоматического слияния. Как правило, эту операцию следует выполнять до начала пакетного ввода данных.
Операция
Увеличьте максимальный размер сегмента:
```
PUT my_index/_settings
{
  "index.merge.policy.max_merged_segment": "10gb"
}
```
Результат
Увеличение максимального размера сегмента помогает уменьшить количество сегментов и тем самым ускорить производительность запросов.

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

Описание
Когда требуемая off-heap память для векторных индексов превышает лимит circuit breaker, менеджер кэша индексов часто меняет местами данные индекса в кэше, что замедляет запросы. Вы можете повысить лимит circuit breaker, чтобы уменьшить срабатывание circuit breaking (отмеченное исключением CircuitBreakingException в журнале), вызванное недостатком памяти.
Операция
По умолчанию лимит circuit breaker для off-heap памяти составляет 80 %. Вы можете при необходимости отрегулировать этот лимит.
```
PUT _cluster/settings
{
  "persistent": {
    "native.cache.circuit_breaker.cpu.limit": "85%"
  }
}
```
Результат
Менее вероятно, что данные векторного индекса будут выгружаться из памяти, и дрожание запросов снижается.

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

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

Operation

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

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

Result
Не требуется разбирать весь документ _source. Колонко-ориентированное хранилище (docvalues) снижает нагрузку во время фазы получения и повышает производительность запросов.

Setting Cache Timeout

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

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

PUT _cluster/settings
{
  "persistent": {
    "native.cache.expiry.enabled": "true",
    "native.cache.expiry.time": "30m"
  }
}

Table 1 Parameter description
Parameter	Type	Description
native.cache.expiry.enabled	Boolean	Включать автоматическое истечение кэша. Диапазон значений: true: Включить автоматическое истечение кэша. Неактивные данные в кэше будут очищены. false (значение по умолчанию): Отключить автоматическое истечение кэша.
native.cache.expiry.time	String	Тайм‑аут неактивных элементов кэша. Этот параметр применяется только когда native.cache.expiry.enabled=true. Значение: строка времени, например, 24h (24 часа) или 30m (30 минут). Значение по умолчанию: 24h.

Родительская тема: Настройка векторного поиска для кластеров Elasticsearch

Поддержка Юридические документы