Поисковые снимки

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

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

Поиск в индексе поискового снимка такой же, как поиск в любом другом индексе.

По умолчанию индексы поисковых снимков не имеют реплик. Базовый снимок обеспечивает отказоустойчивость, а объём запросов ожидается достаточно низким, чтобы одной копии фрагмента было достаточно. Однако, если вам нужно поддерживать более высокий объём запросов, вы можете добавить реплики, настроив значение index.number_of_replicas индекса.

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

Обычно поисковые снимки управляются через ILM. Действие поисковых снимков автоматически преобразует обычный индекс в индекс поискового снимка, когда он достигает фазы cold или frozen. Вы также можете сделать индексы в существующих снимках поисковыми, вручную подключив их с помощью API подключения снимка.

Чтобы подключить индекс из снимка, содержащего несколько индексов, рекомендуется создать копию снимка, содержащего только индекс, который вы хотите искать, и подключить эту копию. Не следует удалять снимок, если он содержит подключенные индексы, поэтому создание копии позволяет управлять жизненным циклом резервного снимка независимо от любых поисковых снимков. Если вы используете ILM для управления поисковыми снимками, он автоматически позаботится о клонировании снимка по мере необходимости.

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

Скорость восстановления индекса поискового снимка ограничена настройкой репозитория max_restore_bytes_per_sec и настройкой узла indices.recovery.max_bytes_per_sec, как и при обычной операции восстановления. По умолчанию max_restore_bytes_per_sec не ограничено, но значение по умолчанию для indices.recovery.max_bytes_per_sec зависит от конфигурации узла. См. Настройки восстановления.

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

Используйте любой из следующих типов репозиториев с поисковыми снимками:

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

При подключении индекса из снимка Elasticsearch распределяет его фрагменты по узлам данных в кластере. Узлы данных затем автоматически извлекают соответствующие данные фрагментов из репозитория в локальное хранилище на основе указанных параметров подключения. Если возможно, поиски используют данные из локального хранилища. Если данные недоступны локально, Elasticsearch загружает необходимые данные из репозитория снимков.

Если узел, на котором расположен один из этих фрагментов, выходит из строя, Elasticsearch автоматически распределяет затронутые фрагменты на другой узел, и этот узел восстанавливает соответствующие данные фрагментов из репозитория. Реплики не нужны, и для восстановления потерянных фрагментов не требуется сложный мониторинг или оркестрация. Хотя индексы поисковых снимков по умолчанию не имеют реплик, вы можете добавить реплики в эти индексы, настроив index.number_of_replicas. Реплики фрагментов поисковых снимков восстанавливаются путем копирования данных из репозитория снимков, как и первичные фрагменты поисковых снимков. В отличие от этого, реплики обычных индексов восстанавливаются путем копирования данных с первичного фрагмента.

Чтобы выполнить поиск в снимке, необходимо сначала подключить его локально как индекс. Обычно это делает ILM автоматически, но вы также можете самостоятельно вызвать API подключения снимка. Существуют два варианта подключения индекса из снимка, каждый с различными характеристиками производительности и размером локального хранилища:

Для частичного подключения индекса требуется один или несколько узлов с доступным общим кэшем. По умолчанию у узлов специализированного уровня замороженных данных (узлы с ролью data_frozen и без других ролей данных) настроен общий кэш, использующий большую величину из 90% общего дискового пространства и общего дискового пространства за вычетом 100 ГБ резерва.

Использование специализированного уровня замороженных данных крайне рекомендуется для использования в производстве. Если у вас нет специализированного уровня замороженных данных, вы должны настроить настройку xpack.searchable.snapshot.shared_cache.size, чтобы зарезервировать место для кэша на одном или нескольких узлах. Частично подключенные индексы назначаются только узлам, у которых есть общий кэш.

Чтобы проиллюстрировать, как эти настройки работают совместно, рассмотрим два примера при использовании значений по умолчанию для настроек на выделенном замороженном узле:

Вы можете настроить эти настройки в elasticsearch.yml:

xpack.searchable.snapshot.shared_cache.size: 4TB

Elasticsearch также использует специальный системный индекс с именем .snapshot-blob-cache для ускорения восстановления фрагментов поисковых снимков. Этот индекс используется в качестве дополнительного уровня кэширования поверх частично или полностью смонтированных данных и содержит минимально необходимые данные для запуска фрагментов поисковых снимков. Elasticsearch автоматически удаляет документы, которые больше не используются в этом индексе. Эту периодическую очистку можно настроить с помощью следующих настроек:

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

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

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

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

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

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

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

Поскольку индексы поисковых снимков не являются обычными индексами, нельзя использовать хранилище только для источника для создания снимков индексов поисковых снимков.

Единственной копией данных в индексе поискового снимка является базовый снимок, хранящийся в хранилище. Например:

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