Временные индексы удобны для поиска по периодам и удаления устаревших данных целыми индексами. Основной минус фиксированного календарного разбиения — неравномерный объём: в тихие дни возникают мелкие шарды, в пики — слишком крупные. Деление по приложениям само по себе сезонность не устраняет и может увеличить число индексов. Часто группировку по требованиям сочетают с rollover по размеру и возрасту.
Зачем делить логи по временным индексам и выгоднее ли деление по приложениям при сезонности?
Плюсы временных индексов, неравномерный размер шардов при сезонной нагрузке и сочетание группировки потоков с rollover по размеру и возрасту.
Короткий ответ
Что ответить на собеседовании
Подробный разбор
Ответ с пояснениями
Предположим, речь об Elasticsearch и индексах логов за фиксированный период, например день. Это разбиение коллекции документов, а не создание B-tree-индекса по полю времени.
Преимущества такого подхода:
- можно выбирать нужные периоды для поиска;
- удобно управлять сроком хранения и удалять устаревшие индексы целиком;
- старые данные можно обслуживать иначе, чем поток текущей записи.
Основной минус календарного разбиения — время не определяет объём. В спокойный день получится небольшой индекс, но каждый его шард всё равно требует ресурсов. В сезонный пик тот же интервал может создать чрезмерно крупные шарды и нагрузку на запись. Множество мелких шардов увеличивает накладные расходы; очень крупные затрудняют восстановление и могут ухудшать поиск. Это разобрано в рекомендациях Elastic по размеру шардов.
Разделение по приложениям полезно, если различаются права доступа, схемы событий, сроки хранения или профиль запросов. Но отдельный индекс для каждого небольшого приложения способен усилить проблему мелких шардов. А популярное приложение не перестанет испытывать сезонный рост только потому, что получило собственный индекс.
Эти стратегии не обязательно взаимоисключающие. Можно сгруппировать совместимые источники в потоки, хранить имя приложения в поле и использовать data streams с rollover. Новый write index создаётся по условиям политики, например по размеру первичного шарда или возрасту, а не исключительно в полночь. Условия описаны в документации rollover. Это не мгновенный жёсткий ограничитель размера: ILM выполняет проверки периодически.
Решение проверяют на реальном распределении нагрузки и запросов, включая сезонный максимум. Сравнивают число и размеры шардов, задержку записи, поиск и восстановление. Также согласуют, как учитывать запоздавшие события и от какой временной точки считать срок хранения. Универсального ответа «по приложениям всегда выгоднее» нет.