Simple-Scada forum
Simple-Scada 2 => Ваши вопросы => Тема начата: Greeds74 от 20 Января 2020, 11:34:31
-
День добрый, уважаемые разработчики!
Сейчас возникает необходимость в системе с малым периодом записи в базу данных - 100 миллисекунд. Количество переменных - около 200. Если применить вашу систему, то есть ли методика расчёта размера базы данных? Например, на сколько увеличится размер при непрерывной записи в течении недели?
Далее, у вас механизм управления базой данных не имеет функционала, аналогичному той же WInCC - когда база не ведётся непрерывно, а разбивается на сегменты и хранятся подключёнными только те, которые находятся в заданном временном интервале подключения?
Вопрос про механизм управления базой возник потому, что при большом размере базы( например, 3 Gb) могут начать возникать фризы и задержки при обращении на выборку данных.
С уважением, Михаил.
-
Здравствуйте.
Если применить вашу систему, то есть ли методика расчёта размера базы данных? Например, на сколько увеличится размер при непрерывной записи в течении недели?
Потребуется немало памяти. С частотой в 100 миллисекунд за сутки будет создано 864000 записей в основной таблице + 240 строк в минутной + 96 в часовой + 4 в суточной. Итого: 864340 записей на одну переменную, что немало. Одна запись хранит id + отметку времени + значение + качество тега, общий объём этих данных 21 байт, не учитывая индексацию таблиц, которая тоже требует памяти. По грубой оценке, учитывая индексы, на одну неделю и 100 переменных с архивацией каждые 100мс потребуется примерно 20 Гб памяти.
когда база не ведётся непрерывно, а разбивается на сегменты и хранятся подключёнными только те, которые находятся в заданном временном интервале подключения?
Не совсем понятно о чем речь. Мы используем стандартное подключение к БД, новые записи добавляются в конец таблиц, учитывая индексацию. Остальные данные не используются пока к ним не обратится пользователь.
Вопрос про механизм управления базой возник потому, что при большом размере базы( например, 3 Gb) могут начать возникать фризы и задержки при обращении на выборку данных.
С чего Вы взяли? 3 Гб это очень маленькая БД. Вы планируете делать собственные выборки данных из архивных таблиц скады? Или думаете что скада начнёт "тормозить" при просмотре архивных данных (например трендов)? Если вопрос касается только скады - то при просмотре трендов она будет делать выборки быстро даже при объёме БД более 500 Гб и выше, т.к. будет использовать прореженные слои. Если Вы планируете делать собственные выборки, то всё зависит от того как будут написаны запросы и какой объём данных они будут выбирать. Если будете использовать выборки на основе индексируемых столбцов, то производительность будет высокой. Но, при желании, можно написать тяжелый запрос который будет выполняться очень долго, например не используя индексы, или выбрать сразу очень большой объём данных.
Также, если есть высокие требования к скорости работы с БД, то можно использовать ПК с RAID массивом на скорость.
-
Здравствуйте.
Не совсем понятно о чем речь. Мы используем стандартное подключение к БД, новые записи добавляются в конец таблиц, учитывая индексацию. Остальные данные не используются пока к ним не обратится пользователь.
Во вложении картинка, где показаны имена запасных копий файлов базы данных MS SQL server. Именно так WinCC производит сегментирование - каждый файл является базой, содержащей данные за определённый промежуток времени. Также есть механизм, позволяющий эти базы подключить и получить доступ к архивным данным.
Да, по объёмам данных всё понятно.Теперь осталось только проверить систему в деле.