Оценка «тысяча датчиков поместится на обычном диске» почти ничего не говорит об архиве. Тысяча сигналов, записываемых раз в минуту, и столько же сигналов с записью каждую секунду дают разную нагрузку. К значению добавляются время, качество, идентификатор, индексы и служебные данные. Кроме постоянного архива нужно место для обслуживания и восстановления.
Полезный результат предварительного расчёта — перечень допущений и диапазон ёмкости, который затем уточняют измерением. Ниже приведён условный пример. Его размеры записи и запасы не являются характеристиками Спектра или универсальной нормой для SCADA.
Начните с правил хранения, а не с модели диска
Разделите сигналы по способу записи. Для каждой группы выясните:
- сколько сигналов действительно будет архивироваться;
- записывается ли каждое значение по расписанию или только изменение;
- сохраняются ли изменения качества и пропуски;
- сколько времени нужны исходные значения;
- требуются ли более длительные агрегированные ряды;
- какой период обычно запрашивают пользователи;
- где находятся резервные копии и как долго их хранят.
Частота опроса не всегда равна частоте архивирования. Значение может обновляться каждую секунду на экране, а архивироваться иначе. При записи по изменению объём зависит от процесса, шума и режима фильтрации. Для бюджета нельзя автоматически считать такую запись редкой.
Отдельно учитывайте события, тревоги, комментарии, журналы действий и вложения. Они не превращаются в измерения только потому, что находятся рядом с трендом. Для выбора частот используйте материал о частоте опроса.
Формула для периодической записи
Для одной группы количество записей в сутки рассчитывается как число сигналов, умноженное на 86 400 секунд и разделённое на интервал записи в секундах. Для нескольких групп результаты складывают.
Логический объём получается умножением количества записей на размер одной записи. Физический объём дополнительно зависит от структуры хранения, индексов, сжатия и обслуживания базы. Например, документация PostgreSQL различает размеры собственно данных и полного объекта с индексами. Это иллюстрирует метод измерения, но не устанавливает используемую в вашем проекте базу.
В расчёте подпишите единицы. Далее ГБ означает миллиард байтов, а ГиБ — 1 073 741 824 байта. Сравнивать цифры разных единиц без пересчёта нельзя: это создаёт искусственный запас либо кажущуюся нехватку места.
Заполненный пример: две группы и девяносто дней
Предположим, нужно сохранять 200 сигналов каждую секунду и 800 сигналов каждые десять секунд. Все записи периодические, круглосуточные, без сокращения по изменению.
- Первая группа: 200 × 86 400 / 1 = 17 280 000 записей в сутки.
- Вторая группа: 800 × 86 400 / 10 = 6 912 000 записей в сутки.
- Всего: 24 192 000 записей в сутки.
- За 90 суток: 2 177 280 000 записей.
Условный логический размер одной записи примем равным 32 байтам. Тогда сутки дают 774 144 000 байт, то есть примерно 0,774 ГБ. Девяносто суток дают 69 672 960 000 байт: примерно 69,673 ГБ, или 64,888 ГиБ.
Это ещё не размер диска. Для предварительной модели примем коэффициент 2 на физическое хранение вместе с индексами. Он взят только для демонстрации расчёта и должен быть заменён измерением. Получается 139,346 ГБ постоянного объёма.
Теперь зададим требование оставлять 25% выделенной ёмкости свободными. Делим постоянный объём на 0,75: 139,346 / 0,75 = 185,795 ГБ. Умножение на 1,25 дало бы другой результат и не обеспечило бы свободную четверть всей ёмкости.
В эти 185,795 ГБ не включены отдельные журналы, резервные копии и дополнительная рабочая область для операций, если они выходят за заложенную модель. Результат — одна строка сметы хранилища, а не готовая спецификация сервера.
Как посчитать запись по изменению
Для дискретных событий или аналоговых значений с фильтрацией сначала снимите фактическую интенсивность. Нужны обычная смена, запуск, остановка, смена режима и период нестабильного сигнала.
Допустим, отдельная группа создаёт 50 000 записей в обычные сутки и 400 000 при выбранном интенсивном режиме. Для сценария с 80 обычными и 10 интенсивными сутками получается 80 × 50 000 + 10 × 400 000 = 8 000 000 записей за период.
Умножайте этот результат на измеренный физический размер записи данной группы. Не используйте автоматически 32 байта из предыдущего примера: событие с текстом и атрибутами может храниться иначе.
Если статистики нет, составьте нижний и верхний сценарии, обозначьте неизвестную частоту и запланируйте испытание. Не выдавайте среднее между предположениями за подтверждённую оценку.
Минимальная карточка расчёта
Её удобно заполнить для каждой группы отдельным списком:
- Группа: давление насосного участка, 200 сигналов.
- Основание записи: периодическая запись раз в секунду.
- Режим: круглосуточно, 90 суток исходной истории.
- Поток: 17 280 000 записей за сутки.
- Состав: идентификатор, значение, время, качество; другие поля перечислить.
- Размер: предварительное допущение либо результат измерения с датой.
- Индексы и сжатие: включены в измерение или считаются отдельно.
- Резерв ёмкости: правило расчёта и назначение.
- Не включено: события, копии, журналы и временные файлы, если считаются отдельно.
- Проверка: ответственный, стенд, длительность и критерий достаточности.
Для агрегированных рядов добавьте размер окна и сохраняемые показатели: среднее, минимум, максимум, количество достоверных отсчётов. Одно среднее может скрыть кратковременный выброс. Решение об удалении исходных данных принимает владелец задачи анализа.
Резервные копии считайте отдельным контуром
Архив отвечает на вопрос о прошлых измерениях, резервная копия — о восстановлении после потери данных. Один не заменяет другой. Документация PostgreSQL по восстановлению показывает разные подходы к резервированию; нужный способ выбирают по применяемой системе и ограничениям.
В смете укажите объём одной копии, число поколений, дополнительные изменения между копиями и место для тестового восстановления. Не обещайте, что копия равна логическому размеру исходных значений: формат и сжатие нужно измерить.
Копия на том же отказавшем носителе может оказаться недоступной вместе с архивом. Проверьте расположение и восстановление практически. Допустимую потерю данных и время возврата к работе согласуют отдельно от срока хранения истории.
Что проверить на стенде до закупки
Загрузите представительный поток со значениями, качеством и событиями. Измерьте прирост полного хранилища после формирования индексов и завершения предусмотренного обслуживания. Затем воспроизведите интенсивный режим.
Параллельно проверьте чтение: тренд за смену, сравнение недели, выборку длинного периода несколькими пользователями. Достаточный объём диска не гарантирует приемлемой скорости записи или просмотра.
Проверьте удаление старой истории: логическое удаление не во всех системах немедленно освобождает пространство для операционной системы. Зафиксируйте поведение именно выбранной конфигурации.
Перед запуском назначьте ответственного за наблюдение за ростом и порог предупреждения. Порог выбирают с учётом времени, необходимого на расширение, и допустимого режима работы при нехватке места. Универсального безопасного процента для любого объекта нет.
Для обсуждения архива подготовьте карточки групп и результаты измерений. В Спектре заявлены архив и исторические тренды; конкретные сроки, размеры и режимы следует согласовать в требованиях к внедрению.
Проверьте чувствительность оценки к допущениям
Расчёт полезно пересчитать при изменении одного параметра. Если срок хранения исходной истории удвоится при прежнем потоке и структуре, соответствующая постоянная часть объёма также удвоится. Если удваивается только одна группа сигналов, увеличивается только её вклад. Так видно, какое решение действительно влияет на закупку.
Отдельный риск — расширение состава полей. Добавление длинного комментария к каждому событию меняет средний физический размер, а появление нового индекса увеличивает объём даже без роста количества значений. Поэтому фиксируйте версию схемы, для которой выполнено измерение.
Не считайте улучшение сжатия обязательным источником будущего запаса. Его результат зависит от данных и реализации. При подтверждении бюджета покажите исходный сценарий и вариант с более интенсивным потоком. Для каждого укажите, каким наблюдением будет проверено предположение и когда потребуется пересмотр. Тогда резерв ёмкости имеет объяснимое назначение, а не скрывает неизвестные условия внутри случайного коэффициента.