Проектируют журнал событий на три года: какой расчёт покажет требуемый объём хранилища?
Требуемый объём нужно оценивать как поток записываемых данных за весь срок хранения, умноженный на коэффициенты репликации, индексов, служебных накладных расходов и запаса роста. Базовая формула: RPS × средний размер записи × секунды хранения × коэффициенты накладных расходов. Средний объём без этих коэффициентов почти всегда занижает реальные требования к инфраструктуре.
Первоначально ёмкость часто оценивали по размеру самих записей и доступному диску. По мере появления репликации, вторичных индексов, резервных копий и многоуровневого хранения стало необходимо считать не только логический объём данных, но и физический объём, занимаемый системой.
Такой расчёт относится к capacity planning: он позволяет заранее понять, когда закончится место, сколько узлов потребуется и какую стоимость будет иметь выбранная схема хранения.
Пусть журнал принимает 20 000 событий в секунду, средний размер сериализованной записи — 1,5 КБ, а срок хранения составляет три года. Если умножить только эти значения, получится логический объём примерно 2,9 ПБ без учёта индексов, реплик, метаданных и свободного места.
Ошибка в оценке приводит к переполнению дисков, остановке записи, ухудшению производительности фоновых операций и невозможности безопасно выполнить перестроение индекса или восстановление данных. Отдельно нужно учитывать, что средняя скорость записи не описывает кратковременные пики, а средний размер записи может существенно отличаться от размера крупных событий.
Сначала определяют измеряемые параметры:
Для приведённого примера при десятичном пересчёте необработанный объём равен примерно 30,72 МБ в секунду, 2,65 ТБ в сутки и 2,91 ПБ за три года. Если заложить 30% на индексы и служебные данные, трёхкратную репликацию и 25% свободного запаса, потребуется около 14,2 ПБ физического пространства до учёта дополнительной компрессии.
Коэффициенты нельзя считать универсальными константами. Доля индексов зависит от схемы запросов, репликация — от требований к доступности и восстановлению, а эффективность сжатия — от характера данных и настроек хранилища. Поэтому итог нужно проверять измерениями на representative-наборе данных и отдельно считать горячий, тёплый и архивный уровни хранения.
Для пиков записи обычно требуется дополнительный расчёт: выдержит ли система максимальный входящий поток, успеют ли реплики и фоновые процессы обрабатывать данные, хватит ли буфера при временном росте нагрузки. Пиковая производительность и долгосрочная ёмкость — связанные, но разные ограничения.
Команда спроектировала журнал аудита для 20 000 событий в секунду и сначала заложила 3 ПБ, исходя из размера полезной нагрузки. После уточнения выяснилось, что каждому событию нужны несколько индексов, три копии данных и запас для обслуживания узлов. Оценка выросла примерно до 14,2 ПБ, поэтому хранить весь срок на дорогом быстром диске стало нецелесообразно.
Рассматривались два варианта. Первый — хранить все события в одном быстром кластере: это упрощает запросы, но резко увеличивает стоимость и усложняет масштабирование. Второй — оставить часто запрашиваемый период на быстром уровне, а старые данные перемещать в более дешёвое объектное или архивное хранилище: это снижает стоимость, но добавляет задержку и усложняет восстановление старых данных.
Выбрали многоуровневое хранение с явным сроком нахождения данных на каждом уровне. Результат оценивали не только по объёму, но и по времени восстановления, стоимости хранения, скорости удаления по сроку давности и влиянию миграции на рабочие запросы.
Для долгосрочного объёма обычно используют средний поток, взвешенный по реальному профилю нагрузки, потому что именно он определяет накопленный объём за период. Для производительности записи, размера буферов и способности пережить всплески нужен пиковый поток. Если пик длится долго, он одновременно увеличивает и фактический объём хранения, поэтому его нельзя полностью игнорировать.
Одного среднего значения может быть недостаточно: несколько крупных событий способны определять требования к пропускной способности, памяти и сетевым буферам. Нужно изучить распределение размеров, отдельно учитывать типичные и крупные записи, а для capacity planning использовать взвешенную оценку с запасом. Также следует включать размер метаданных, ключей, выравнивания и внутреннего формата хранения, а не только размер бизнес-полей.
Нужно взять репрезентативную выборку реальных или реалистично сгенерированных данных, загрузить её в целевое хранилище и измерить фактическое соотношение логического и физического объёма. Затем проверяют запись при пиковом потоке, построение индексов, репликацию, удаление старых данных и восстановление из резервной копии. Полученные коэффициенты применяют к нескольким сценариям — базовому, росту нагрузки и отказу части инфраструктуры, — а не маскируют неопределённость одним произвольным запасом.