Если в кластере слишком много шардов, можно предпринять несколько шагов, чтобы уменьшить их количество. Удаление или закрытие индексов, а также переиндексация в более крупные индексы рассматриваются в этом руководстве.
Ниже мы рассмотрим, как уменьшить количество шардов для вновь создаваемых индексов, как уменьшить количество шардов для уже существующих индексов, как уменьшить количество первичных шардов и как уменьшить количество шардов для индексов, основанных на времени.
Как уменьшить число шардов вновь создаваемых индексов
При создании новых индексов следует обязательно настроить количество вновь создаваемых шардов на минимально возможное.
Для демонстрации этой возможности предположим, что вы работаете с OpenSearch и используете его для хранения журналов. По умолчанию для каждого индекса создается 1 первичный шард. На этих 5 шардах легко помещается 100-250 Гбайт данных. Если вы знаете, что генерируете гораздо меньший объем данных, то вам следует изменить значение по умолчанию для вашего кластера на 1 шард на 50 ГБ данных на индекс.
Самый простой способ добиться этого - создать шаблон индекса и сохранить его в состоянии кластера.
Этот запрос создаст шаблон индекса под названием "template_1". Он будет применен ко всем вновь создаваемым именам индексов, начинающимся с "log", и установит число хранилищ на индекс равным 1.
| 1 2 3 4 5 6 7 8 9 | PUT _index_template/template_1 { "index_patterns": ["log*"], "template": { "settings": { "index.number_of_shards": 1 } } } |
Как уменьшить количество шардов в существующих индексах
Сокращение числа реплик шардов
Простым способом уменьшения количества шардов является уменьшение количества реплик. Изменение числа реплик может быть выполнено динамически с помощью запроса и занимает всего несколько секунд.
Обычно рекомендуется иметь 1 реплику шарда на индекс, т.е. одну копию каждого шарда, которая будет выделена на другом узле (если только у вас нет большого количества параллельно выполняющихся поисковых запросов). Реплики используются для обеспечения отказоустойчивости, чтобы в случае выхода из строя одного узла ваши данные все еще были доступны для поиска и хранения. Они повышают отказоустойчивость кластера и более равномерно распределяют нагрузку.
Однако если ваш кластер полностью перегружен, то быстрым и простым решением может быть установка реплик на ноль. При этом следует помнить, что это не идеальный вариант и его не следует держать в таком состоянии в течение длительного времени.
Этот запрос установит число реплик шардов в 0 для всех имен индексов, начинающихся с "log":
| 1 2 3 4 5 6 | PUT log*/_settings { "index" : { "number_of_replicas" : 0 } } |
Сокращение числа первичных шардов
Количество первичных шардов в индексе не может быть изменено динамически - оно неизменно. Алгоритм маршрутизации, используемый для распределения новых документов между несколькими шардами, зависит от общего числа первичных шардов. Поэтому уменьшить количество первичных шардов существующего индекса несколько сложнее.
В основном необходимо создать новый индекс и скопировать в него все данные. Для этого можно использовать два API: Shrink API и Reindex API. У каждого API, конечно, есть свои плюсы и минусы, но один из них, как правило, является более идеальным в зависимости от ваших настроек и требований. Shrink API работает быстрее, но его можно использовать только для индексов, предназначенных только для чтения (индексы, в которые не обновляются и не вставляются документы). API Reindex можно использовать для активных индексов.
Уменьшение количества шардов с помощью API Shrink
Перегруженные индексы можно сократить до 1 шарда, а возможно, и больше, в зависимости от размера индекса - см. документацию о размерах. Существуют довольно строгие требования к количеству шардов, до которых можно сократить индекс. Пожалуйста, прочитайте документацию, чтобы убедиться, что этот вариант вам подходит.
Следует помнить, что при уменьшении индексов необходимо некоторое время на обслуживание. Во-первых, все первичные шарды индекса должны быть выделены на одном узле. Убедитесь, что на этом узле достаточно места для хранения (если это не так, то можно воспользоваться API Reindex, как показано ниже). Затем индекс необходимо пометить как доступный только для чтения.
Этот запрос установит индекс в режим "только чтение" для всех имен индексов, начинающихся с "log", и переместит все шарды на тот же узел.
| 1 2 3 4 5 6 7 | PUT log*/_settings { "settings": { "index.blocks.write": true, "index.routing.allocation.require._name": "shrink_node_name" } } |
С помощью этой команды необходимо поочередно сжимать индексы. Распределение шардов вернется к значению по умолчанию, и индекс снова будет доступен для записи.
| 1 2 3 4 5 6 7 | POST log-1/_shrink/log-shrink-1 { "settings": { "index.routing.allocation.require._name": null, "index.blocks.write": null } } |
Упомянутые ниже методы Shrink API и Reindex API предполагают создание нового индекса и копирование данных. Это может потребовать значительных ресурсов и повлиять на производительность кластера. Поэтому эти операции следует планировать и выполнять тщательно, желательно в непиковые часы.
Уменьшение количества шардов с помощью API Reindex
Если в индекс, который вы пытаетесь уменьшить, по-прежнему активно записываются документы, можно воспользоваться API Reindex.
Reindex API может использоваться для пакетного копирования документов из одного индекса в другой. В этом случае вся работа, которая должна быть выполнена во время индексации, должна быть повторена. Это делает использование Reindex API более медленным, чем копирование целых шардов, но все же это достаточно быстрый процесс.
Reindex API создает снимок текущего состояния индекса и затем копирует все документы. Документы, созданные заново в процессе переиндексации, игнорируются. Для копирования вновь созданных документов в новый индекс необходимо повторить процесс переиндексации с некоторыми настройками, обеспечивающими создание только новых документов.
Если в индекс ведется активная запись и нельзя допустить, чтобы в новом индексе отсутствовали документы, рекомендуется в течение некоторого времени вести запись в оба индекса, чтобы убедиться в отсутствии дельты.
Данный запрос скопирует все документы из индекса с именем "log-1" в новый индекс с именем "log-shrink-1".
Убедитесь, что применен шаблон индекса из первого раздела.
| 1 2 3 4 5 6 7 8 9 10 | POST _reindex { "source": { "index": "log-1" }, "dest": { "index": "log-shrink-1", "op_type" : "index" } } |
Вторая итерация для добавления только тех документов, которые были созданы во время операции переиндексации:
| 1 2 3 4 5 6 7 8 9 10 | POST _reindex { "source": { "index": "log-1" }, "dest": { "index": "log-shrink-1", "op_type" : "create" } } |
Помните, что это следует делать в непиковые часы, так как это может потребовать значительных ресурсов и повлиять на производительность кластера.
Сокращение количества шардов временных индексов
Если вы используете имена индексов, основанных на времени, например, ежедневные индексы для ведения журнала, и у вас недостаточно данных, хорошим способом уменьшить количество шардов будет переход на еженедельный или ежемесячный шаблон.
Можно также сгруппировать старые индексы, доступные только для чтения, по месяцам, кварталам или годам. Самый простой способ сделать это - использовать API Reindex.
Сокращение количества шардов для индексов с несколькими тенантами
При использовании многопользовательской системы с индексом на одного клиента уменьшить количество шардов гораздо сложнее.
В ситуации многопользовательского использования у вас может быть несколько крупных клиентов с одним или несколькими шардами на индекс, и их размер кажется вполне подходящим. В то же время у вас будет много клиентов с меньшими индексами.
Если в такой ситуации необходимо уменьшить количество шардов, но при этом сохранить индекс для каждого клиента, можно использовать фильтрованные псевдонимы.
Сокращение числа шардов с помощью фильтрованных псевдонимов (алиасов)
Фильтрованные псевдонимы не так хорошо известны, как "обычные" псевдонимы индексов, но они позволяют создавать несколько представлений одного индекса.
Вместо того чтобы создавать один индекс для каждого арендатора или клиента, вы создаете один индекс для всех мелких арендаторов, которые слишком малы, чтобы заслужить свой собственный индекс. Затем вы добавляете ключевое слово или числовое поле для различения этих арендаторов (имя клиента или идентификатор клиента).
После создания индекса можно просто сохранить фильтр по этому индексу и указать имя арендатора в качестве имени индекса.
Приложения не заметят, что вы используете фильтр в фоновом режиме. Они могут просто использовать имя индекса. При этом в одном индексе можно хранить множество различных арендаторов, что позволит избежать избыточного резервирования.
Все это при условии, что вы используете совместимую модель данных для всех клиентов.
Как создать фильтрованный псевдоним для индекса:
| 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 | POST _aliases { "actions":[ { "add":{ "index":"small-customers", "alias":"customer-1", "filter":{ "term":{ "customer-id":"1" } } } } ] } |
Для уменьшения количества шардов в многопользовательской среде можно создать новый индекс для всех мелких арендаторов и просто скопировать данные с помощью Reindex API. Если необходимо добавить новое поле для различения арендаторов, например "customer-id", можно использовать конвейер ингеста для добавления нового поля.