Индексы в OpenSearch
Когда документ сохраняется в OpenSearch, он индексируется и помещается в определенный индекс по выбору пользователя, становясь доступным для поиска и анализа. Индекс можно рассматривать как аналог таблицы с данными в классических СУБД.
С точки зрения OpenSearch, документ — это набор полей, где каждое поле — это пара ключ: значение. Индекс хранит документ в оптимизированном виде, чтобы обеспечить возможность быстрого поиска по полям в документе. Оптимизация достигается за счет того, что каждое поле документа имеет определенный тип — это позволяет эффективно хранить данные этого поля в индексе. Подробнее о такой оптимизации см. в документации OpenSearch.
В отличие от классических СУБД, OpenSearch не требует явного задания схемы (взаимосвязей между полями документа и их типами), чтобы сохранить документ в индексе. Хотя это и рекомендуемый подход, можно сохранять документы в индекс без явного указания типа полей — OpenSearch попытается определить тип автоматически для каждого поля документа. Это позволяет быстро наполнить хранилище OpenSearch документами и начать работу с ними.
Подробнее об устройстве индексов см. в документации OpenSearch.
В многохостовых кластерах доступны шардирование и репликация индексов. Это упрощает масштабирование кластера и обеспечивает высокую доступность.
Кодеки индексов
Кодеки индексов определяют способ сжатия и хранения полей индекса на диске. Список поддерживаемых кодеков для OpenSearch см. в документации OpenSearch.
Для кластеров Managed Service for OpenSearch дополнительно доступен кодек lzma. Рекомендуется использовать его для хранения архивных данных, обращение к которым происходит очень редко.
Для всех кодеков можно указать уровень сжатия в диапазоне от 1 до 6 включительно. Чем выше этот уровень, тем выше коэффициент сжатия (меньше размер файла), но ниже скорость сжатия и распаковки. Уровень сжатия по умолчанию — 3.
Сравнение кодеков
Для сравнения были взяты кодеки (в скобках указан уровень сжатия):
- lz4(3),
- zlib(3),
- zstd(5),
- lzma(1),
- lzma(5).
Среда тестирования
Тестирование выполнялось для кластера Managed Service for OpenSearch в Yandex Cloud. Измерения проводились в следующем окружении:
-
Конфигурация кластера Managed Service for OpenSearch:
- Количество хостов:
1. - Класс хостов:
s2.micro - Тип диска:
network-ssd. - Размер диска:
10ГБ.
- Количество хостов:
-
Параметры инструмента для тестирования OpenSearch Benchmark:
- Профиль:
http_logs. - Количество клиентов:
8. - Размер батча:
5000документов.
- Профиль:
-
Конфигурация виртуальной машины для запуска OpenSearch Benchmark:
- ОС:
Ubuntu 24.04 LTS. - vCPU:
8. - RAM:
16ГБ. - Объем дискового пространства:
55ГБ.
- ОС:
Результаты тестирования
Результаты измерений:
| Критерий | lz4(3) | zlib(3) | zstd(5) | lzma(1) | lzma(5) |
|---|---|---|---|---|---|
| Объем на диске (ГБ) | 17.5 | 13.4 | 13.3 | 12.6 | 12.5 |
| Скорость индексации (документов в секунду) | 81083 | 96835 | 97487 | 97873 | 89375 |
| match-all (медианное время, мс) | 4.7 | 5.6 | 5.7 | 7.4 | 7.5 |
| term (медианное время, мс) | 17.0 | 17.7 | 18.9 | 45.1 | 43.4 |
| scroll (медианное время, мс) | 302.9 | 509.8 | 416.4 | 794.6 | 740.9 |
| hourly_agg (медианное время, мс) | 50.6 | 53.3 | 47.1 | 47.4 | 59.5 |
| multi_term_agg (медианное время, мс) | 2730.8 | 2772.8 | 2681.1 | 2901.8 | 2923.5 |
Изменение результатов относительно кодека lz4, используемого по умолчанию:
| Критерий | zlib(3) | zstd(5) | lzma(1) | lzma(5) |
|---|---|---|---|---|
| Объем на диске (чем меньше, тем лучше) | -23% | -24% | -28% | -29% |
| Скорость индексации (чем больше, тем лучше) | +20% | +21% | +21% | +11% |
| match-all (чем меньше, тем лучше) | +19% | +20% | +57% | +60% |
| term (чем меньше, тем лучше) | +4% | +11% | +165% | +155% |
| scroll (чем меньше, тем лучше) | +68% | +38% | +162% | +145% |
| hourly_agg (чем меньше, тем лучше) | +5% | -7% | -6% | +18% |
| multi_term_agg (чем меньше, тем лучше) | +2% | -2% | +6% | +7% |
Смена кодека
Если вы хотите изменить используемый способ сжатия данных, то в политике индекса можно указать действие, которое сменит кодек. Сделать это можно через API-запрос или в интерфейсе OpenSearch Dashboards.
Пример действия в API-запросе:
{
"repack":{
"new_codec": "<название_кодека>"
}
}
Где new_codec — новый кодек для индекса. Значением может быть один из поддерживаемых кодеков для OpenSearch, а также кодек lzma.
Это действие закрывает индекс на непродолжительное время, чтобы установить значение нового кодека в настройки индекса. После обновления кодека индекс открывается и существующие данные заново пакуются с помощью нового кодека.
Примеры использования
- Поставка данных из Yandex Managed Service for Apache Kafka® с помощью Yandex Data Transfer
- Миграция данных из стороннего кластера OpenSearch с помощью Yandex Data Transfer
- Миграция данных из Elasticsearch
- Настройка политики индексов в Managed Service for OpenSearch
- Копирование данных из Managed Service for OpenSearch в Managed Service for ClickHouse® с помощью Yandex Data Transfer
- Использование плагина yandex-lemmer в Managed Service for OpenSearch