Согласно наилучшей практике, размер шарда OpenSearch не должен превышать 50 ГБ для одного шарда.
Ограничение на размер шарда не поддерживается OpenSearch напрямую. Однако, если вы превысите этот лимит, вы можете столкнуться с тем, что OpenSearch не сможет переместить или восстановить шарды индекса (что приведет к потере данных), или вы можете достичь жесткого ограничения lucene в 2 ³¹ документов на индекс.
Как решить эту проблему
Если ваши шарды слишком велики, то у вас есть 3 варианта:
Удаление записей из индекса
Если это целесообразно для вашего приложения, вы можете рассмотреть возможность окончательного удаления записей из индекса (например, старых журналов или других ненужных записей).
| 1 2 3 4 5 6 7 8 9 10 11 | POST /my-index/_delete_by_query { "query": { "range" : { "@timestamp" : { "lte" : now-5d } } } } |
Переиндексация в несколько небольших индексов
Ниже приводится переиндексация в один индекс для каждого типа события (event_type).
| 1 2 3 4 5 6 7 8 9 10 11 12 13 | POST _reindex { "source": { "index": "logs-all-events" }, "dest": { "index": "logs-2-" }, "script": { "lang": "painless", "source": "ctx._index = 'logs-2-' + (ctx._source.event_type)" } } |
Переиндексировать в другой единый индекс, но увеличить количество шардов
| 1 2 3 4 5 6 | PUT /my_new_index/_settings { "index" : { "number_of_shards" : 2 } } |
| 1 2 3 4 5 6 7 8 9 | POST _reindex { "source": { "index": "my_old_index" }, "dest": { "index": "my_new_index" } } |
Основные моменты при переиндексации
Заметить дублирование данных в процессе переиндексации
Если в приложении используются подстановочные знаки в имени индекса (например, logs-*), то в процессе переиндексации результаты могут дублироваться, поскольку до завершения процесса у вас будет две копии данных. Этого можно избежать, используя псевдонимы.
Заметить модификации и обновления в процессе переиндексации
Если данные подвержены обновлениям в процессе переиндексации, то необходимо определить процедуру их учета и гарантировать, что в новых индексах будут отражены все модификации, внесенные в течение переходного периода переиндексации.
Как избежать этой проблемы
Существуют различные механизмы оптимизации размера шардов.
Применение ISM (Index State Management)
С помощью ISM можно заставить OpenSearch автоматически создавать новый индекс, когда текущий размер индекса достигает заданного максимального размера или возраста. ISM подходит для документов, не требующих обновлений, но не подходит для документов, требующих частого обновления, поскольку для этого необходимо знать, какой из предыдущих томов индекса содержит документ, который необходимо обновить.
Стратегия работы приложения
Вы можете спроектировать приложение таким образом, чтобы обеспечить создание шардов разумного размера:
Подход, основанный на дате
- myindex-yyyy.MM.dd
- или myindex-yyyy.MM
Преимущество этого подхода заключается в том, что старые данные можно легко удалить, просто удалив старые индексы.
Подход, основанный на атрибутах
| 1 | myindex-<clientID> |
Преимущество этого подхода заключается в том, что, зная идентификатор клиента, можно точно знать, в каком индексе производить поиск/обновление.
Недостатком является то, что разные клиенты могут производить разные объемы документов (и, соответственно, разные размеры шардов). Это можно в некоторой степени компенсировать, регулируя количество шардов для каждого клиента, но при большом количестве клиентов может возникнуть обратная проблема (избыточное количество шардов).
Подход на основе диапазона идентификаторов
Это возможно, если документы имеют идентификатор, полученный из другой системы или приложения (например, sql-идентификатор или идентификатор клиента), что позволяет равномерно распределять документы.
Например, myindex-<последний_цифровой_идентификатор_ID>
В результате мы получим 10 индексов, которые, вероятно, будут равномерно распределены, а также детерминированы (мы знаем, какой индекс нам нужно обновить).