Общие сведения
СУБД (система управления базами данных) представляет собой комплекс программ, предназначенных для создания и управления базой данных. С помощью СУБД можно выполнять различные операции с данными, такие как добавление, изменение, удаление и выборка.
Производительность СУБД зависит от нескольких факторов: аппаратных характеристик сервера, конфигурации СУБД, оптимизации структуры таблиц и индексов, а также объема и интенсивности операций записи и чтения архивных данных.
Рекомендации по выбору СУБД
В Симплайт 5 доступны следующие системы управления базами данных:
- SQLite — компактная встраиваемая база данных.
- PostgreSQL — свободно распространяемая объектно-реляционная СУБД.
- Tantor SE — российский форк PostgreSQL. Для систем подпадающих под требования регуляторов по использованию отечественного ПО.
- Авадс СА — компактная и высокоскоростная база данных временных рядов (TSDB) для архивирования в системах реального времени.
По результатам внутренних тестов компании, производительность SQLite и PostgreSQL на малых и средних нагрузках может быть сопоставима. Однако для SQLite есть ограничение. Оно заключается в том, что база является встраиваемой и представляет собой единый файл, привязанный к файловой системе конкретного ПК. Это исключает возможность ее прямого переноса на другой сервер в работающем виде для распределенных или отказоустойчивых конфигураций. Поэтому SQLite рационально использовать только для небольших локальных проектов.
Для средних и крупных проектов рекомендуется выбирать между PostgreSQL (или его отечественным аналогом Tantor SE) и Авадс СА. Следует отметить, что классические реляционные СУБД, такие как PostgreSQL, Tantor SE могут демонстрировать деградацию производительности операций вставки и выборки данных по мере роста объема базы данных.
С этой точки зрения Авадс СА, будучи специализированной СУБД, изначально оптимизированной для работы с временными рядами, обладает преимуществом — её архитектура минимизирует деградацию производительности при росте объема данных и обеспечивает стабильно высокую скорость как записи текущих данных, так и выполнения запросов к историческому архиву. К недостаткам данной СУБД можно отнести только то, что данный продукт является коммерческим.
Хранение исторических данных
Если в разрабатываемом проекте необходимо архивировать большое количество тегов или вести архивацию с высокой частотой, или требуется высокая скорость загрузки трендов за большие интервалы времени, то на сервере целесообразно использовать RAID-массив HDD (RAID 0/1/1+0).
Справка
RAID 0 — чередование (striping) данных без резервирования, которое значительно увеличивает скорость работы, но выход из строя любого диска ведет к полной потере данных.
RAID 1 — полное зеркалирование (mirroring) данных на двух или более дисках, обеспечивающее высокую надежность и доступность данных, но эффективная емкость равна емкости одного диска.
RAID 1+0 — комбинированный уровень, который создает из дисков зеркальные пары (RAID 1), а затем объединяет их в общий чередующийся массив (RAID 0), что дает высокую производительность и отказоустойчивость при потере до половины дисков. Для RAID 1+0 требуется минимум четыре физических диска.
Примерный объем хранилища исторических данных можно вычислить по формуле:
V — расчетный объем хранилища, байт.F — количество тегов.
P — необходимый период хранения, сек.
S — место, занимаемое одной записью, байт.
Расчет объема архивации
Пример:
Произвести расчет объема архивации при условии, что необходимо хранить данные для 5000 тегов с плавающей точкой (4 байта) и меткой времени (8 байт). Период записи составляет 1 раз в секунду. Глубина хранения — 30 дней.