OpenSearch избыточность

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

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

Как решить проблему

Если ваши шарды слишком малы, то у вас есть 3 варианта решения проблемы:

Удаление пустых индексов

Хотя пустые индексы не занимают места на диске, OpenSearch все равно должен хранить в памяти местоположение и маппинг шардов, поэтому целесообразно регулярно обнаруживать и удалять пустые индексы на кластере OpenSearch. Для этого можно использовать скрипт:

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

Удаление или закрытие индексов со старыми или ненужными данными

Закрытие определенных индексов часто является хорошей быстрой опцией, позволяющей быстро запустить кластер, пока вы решаете, какое решение лучше выбрать в долгосрочной перспективе. Закрытие индекса освобождает ресурсы памяти, используемые индексом, при этом индекс остается на диске, и легко и быстро отменяется (POST myindex/_open).

Переиндексация в более крупные индексы

Ниже приводится переиндексация нескольких ежедневных или ежемесячных индексов в один индекс за год (чтобы не возникло обратной проблемы - слишком большого размера шардов, настройте количество шардов в новом индексе в соответствии с общим объемом данных. Убедитесь, что размер шардов в новом индексе не превышает 50 ГБ/шард).

Примечания, которые следует иметь в виду

Осторожно, взрывы полей и маппинги

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

Следите за дублированием данных в процессе переиндексации

Если в процессе переиндексации (см. наши советы по переиндексации) в имени индекса используются подстановочные знаки (например, logs-*), то результаты могут дублироваться, поскольку до завершения процесса у вас будет две копии данных. Этого можно избежать, используя псевдонимы.

Следите за модификациями и обновлениями в процессе переиндексации

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

Как избежать этой проблемы

Существуют различные механизмы оптимизации размера шардов, например:

Применить ILM (управление жизненным циклом индекса).

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

Изменение стратегии работы приложения

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

Подход, основанный на дате

myindex-yyyy.MM.dd или myindex-yyy.MM

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

Подход, основанный на атрибутах

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

Недостатком является то, что разные клиенты могут производить разные объемы документов (и, соответственно, разные размеры шардов). Это можно в некоторой степени компенсировать, регулируя количество шардов для каждого клиента, но при большом количестве клиентов может возникнуть обратная проблема (избыточное количество шардов).

Подход на основе диапазона идентификаторов

Это возможно, если документы имеют идентификатор, полученный из другой системы или приложения (например, sql-идентификатор или идентификатор клиента), что позволяет равномерно распределять документы.

Например, myindex-<последний_цифровой_идентификатор_ID>

В результате мы получим 10 индексов, которые, вероятно, будут равномерно распределены, а также детерминированы (мы знаем, какой индекс нам нужно обновить).