CC BY
32
Выбор СУБД и определение оптимального числа датчиков для локального сервера
в составе САГМ
Бубнов В. П., Мочалов А. В., Соловьева В. Г. Петербургский государственный университет путей сообщения Императора Александра I
Санкт-Петербург, Россия [email protected], [email protected], [email protected]
Аннотация. В статье рассматривается процесс выбора СУБД, наиболее пригодной для использования на локальном сервере системы автоматизированного геодезического мониторинга. Описывается архитектура программного комплекса автоматизированной системы геодезического мониторинга искусственных сооружений. Проводятся сравнительный анализ СУБД и обоснование их выбора. Определяется наибольшее число датчиков, подключаемых к серверу, при котором работа данного сервера не будет нарушена.
Ключевые слова: САГМ, СУБД, мониторинг, датчик, программный комплекс, локальный сервер.
Введение
Для объективного анализа получаемых данных и своевременного реагирования на опасные отклонения искусственных сооружений от нормальной работы требуется, чтобы в составе системы комплексной безопасности движения находилась подсистема автоматизированного мониторинга искусственных сооружений.
Мониторинг критически важных и опасных объектов -процесс инструментального автоматизированного круглосуточного наблюдения за определенными параметрами этих объектов. Задачей мониторинга считается предотвращение опасных ситуаций, нанесения ущерба объектам или их разрушения. Проблема мониторинга искусственных сооружений рассмотрена в [1-6].
В данной статье предлагается организовать систему автоматизированного геодезического мониторинга (САГМ). САГМ производит сбор, систематизацию, хранение, анализ, преобразование, отображение и распространение пространственно-координированных данных о контролируемых элементах особо опасного объекта для своевременного обнаружения опасных величин деформаций, определения причин их появления, составления прогнозов развития деформаций, определения и принятия мер для ликвидации развития опасных процессов и их последствий.
Организация САГМ
Созданный программный комплекс (ПК), представляющий собой ядро САГМ, дает возможность подключить любые наборы датчиков, производить сбор, передачу, анализ и хранение данных. В будущем возможности комплекса могут расширяться в соответствии с актуальностью технических требований к таким комплексам.
ПК включает следующие основные компоненты:
• программное обеспечение локального сервера (ПОЛС);
• программное обеспечение удалённого сервера (REST API);
• графический интерфейс (Web Application) (рис. 1).
ПОЛС должно соответствовать следующим требованиям:
• независимость от платформы;
• способность к гибкой настройке при различных типах и количестве датчиков, помещенных на объекте;
• способность к самовосстановлению (при утрате соединения с одним из датчиков система должна продолжать работать и пытаться восстановить потерянное соединение) [7].
Процесс выбора СУБД
Мониторинг важных ж/д объектов - одно из основных направлений предотвращения аварий и разрушения этих объектов. Учитывая важность этой задачи, при выборе системы управления базами данных (СУБД), входящей в систему мониторинга, следует принимать во внимание следующие факторы:
• моделирование данных:
- триггеры и хранимые процедуры;
• особенности архитектуры и функциональные возможности:
- масштабируемость;
- сетевые возможности;
• особенности разработки приложений:
- поддерживаемые языки программирования;
• надежность:
- восстановление после сбоев;
- резервное копирование;
- многоуровневая система защиты;
• требования к рабочей среде:
- поддерживаемые аппаратные платформы;
- операционные системы, под управлением которых способна работать СУБД;
• смешанные критерии:
- стоимость.
СУБД выбирали из четырех наиболее подходящих под эти требования продуктов:
• MySQL;
• PostgreSQL;
• Oracle;
• DB2.
Первые две СУБД бесплатные, другие - платные.
Рис. 1. Схема САГМ
Среди бесплатных СУБД наиболее подходящая - Post-greSQL. Ее достоинства:
• соответствие стандартам. Так как MySQL не ставит для себя цель полностью соответствовать стандартам SQL, эта СУБД не полностью поддерживает SQL. Если в будущем планируется переход на платные СУБД, например, Oracle, то сделать это с PostgreSQL будет довольно просто по сравнению с другими бесплатными СУБД;
• многопоточность. Параллельные операции чтения-записи могут создать проблемы в MySQL. Помимо этого, представление каждого клиента СУБД PostgreSQL в виде отдельного процесса позволяет повысить надежность и безопасность системы;
• функционал. Несмотря на то, что MySQL предоставляет достаточно богатый функционал, соответствие самым новым стандартам и огромное количество дополнений делают Post-greSQL более функциональной СУБД, позволяя получить все необходимые возможности;
• целостность данных. PostgreSQL обеспечивает большую надежность и целостность данных, чем MySQL;
• сложная структура данных. По сравнению с другими открытыми СУБД, PostgreSQL предоставляет больше возможностей для создания сложных структур данных без необходимости жертвовать какими-либо аспектами [8, 9].
И Oracle, и DB2 отвечают требованиям к использованию с рассматриваемой системой мониторинга. Обладая в целом схожими характеристиками и возможностями, более логичным выбором будет СУБД Oracle, поскольку у нее:
• более высокая производительность и надежность, хотя и при более высокой стоимости;
• более простая интеграция сторонних приложений;
• количество специалистов по работе с СУБД Oracle значительно превышает это количество у DB2 [10].
Расчет числа датчиков
Для определения оптимального числа датчиков, подключаемых к одному локальному серверу в системе мониторин-
га, проведен эксперимент. Предпочтение было отдано СУБД PostgreSQL. И PostgreSQL, и Oracle обеспечивают требуемый функционал, однако бесплатная PostgreSQL более выгодна с экономической точки зрения.
Нагрузка на сервер БД проверялась для следующих ситуаций:
• число клиентских подключений к БД:
- 50;
- 100;
- 150;
- 200;
- 250;
• суммарное число заявок от одного клиента за время эксперимента:
- 500;
- 1000;
- 1500.
Интервал между заявками от одного клиента 0,2 с.
Для эксперимента было написано приложение на языке программирования Java [11], которое подключало к БД PostgreSQL [12] и генерировало заявки согласно заданным параметрам - числу клиентов и количеству заявок от каждого клиента. Заявка представляла собой объект вида «целочисленное значение + строка» (int + String).
В качестве сервера БД выступал ПК со следующими характеристиками:
• 4-ядерный процессор с частотой 1,5 ГГц;
• 8 ГБ оперативной памяти;
• жесткий диск с частотой 5400 об/мин.
Схема эксперимента и схема работы программы представлены на рис. 2, 3.
В ходе эксперимента получены следующие результаты:
• объем одного клиентского процесса составляет 2 МБ;
• дисковая активность одного клиентского процесса не превысила 50 КБ/с;
• измерено среднее число транзакций в секунду для разного числа клиентов (табл. 1);
^
Задание начальных значений переменных
о
Выполнение про< раммы
Л
Получение и анализ результатов работы программы
,- 5
Конец
Рис. 2. Схема проведения эксперимента
п
Создание подключений к БД
Очистка тестовой таблицы
Л Ч
Выполнение заявок INSERT
5
Вывод результатов работы
Конец
Рис. 3. Схема работы программы Среднее число транзакций в секунду
Таблица 1
Число клиентов Число транзакций/с
50 279
100 613
150 1017
200 1254
250 1617
• измерено время в минутах, необходимое для завершения эксперимента при разных исходных данных (табл. 2);
• измерена средняя нагрузка на жесткий диск для разного числа клиентов (табл. 3);
• измерена средняя нагрузка на ЦП для разного числа клиентов (табл. 4).
Таблица 2
Время, требуемое для завершения эксперимента
Число клиентов Число заявок
500 1000 1500
50 1,97 3,96 5,93
100 1,93 3,86 5,8
150 2,14 4,41 6,33
200 2,3 4,27 6,34
250 2,35 4,62 6,49
Таблица 3
Средняя нагрузка на жесткий диск
Число клиентов Средняя нагрузка, %
50 20
100 26
150 31
200 35
250 40
Таблица 4 Средняя нагрузка на процессор
Число клиентов Средняя нагрузка, %
50 10
100 12
150 15
200 17
250 20
На рис. 4 представлены графики зависимости времени, затраченного на эксперимент, от числа клиентов. Для всех трех ситуаций прослеживается тенденция увеличения времени при увеличении числа клиентов.
Принимая во внимание неполное использование аппаратных ресурсов ПК (ЦП, ОЗУ, жесткий диск) во время эксперимента, можно улучшить ситуацию:
a) снизить частоту заявок от клиентов;
b) ограничить максимальное число клиентов (50-100).
Наиболее выгодно в данном случае снизить частоту заявок, так как это позволит наиболее эффективно использовать аппаратные ресурсы ПК.
На рис. 5, 6 представлены графики зависимости нагрузки на жесткий диск и ЦП от числа клиентов.
Выводы
Оба графика нагрузки представляют собой линейную зависимость, что позволяет определить максимально допу-
6,5 5,5 4,5 3,5 2,5 1,5
50 100 150 200 250
Рис. 4. Зависимость затраченного на эксперимент времени от числа клиентов
-500 заявок -1000 заявок 1500 заявок
стимое число клиентов. В данном случае это число будет определяться по нагрузке на жесткий диск как на наиболее медленное устройство в системе. Рекомендуемое значение числа клиентов - 350, так как нагрузка на жесткий диск в этом случае будет находиться в пределах 50 %. Однако замена жесткого диска на более производительную версию позволит увеличить число пользователей. Необходимое для данного числа клиентов количество ОЗУ составит 700 МБ (без учета любого другого ПО). Объем пересылаемых на сервер данных составит около 20 МБ/с; для передачи потребуется два канала по 100 Мбит/с или один канал 1 Гбит/с.
Литература
1. Watanabe E. On longevity and monitoring technologies of bridges: a survey study by the Japanese Society of Steel Construc-
tion / E. Watanabe, H. Furuta, T. Yamaguchi, M. Kano // Struct. Infrastruct. Eng. 2014. Vol. 10, N 4. P. 471-491.
2. Li S. L. SMC structural health monitoring benchmark problem using monitored data from an actual cable-stayed bridge / S. L. Li, H. Li, Y. Liu et al. // Struct. Control and Health Monit. 2014. Vol. 21, N 2. P. 156-172.
3. Li A. Q. Analysis and assessment of bridge health monitoring mass data - progress in research/development of «Structural Health Monitoring» / A. Q. Li, Y. L. Ding, H. Wang, T. Guo // Sci. China Technol. Sci. 2012. Vol. 55, N 8. P. 2212-2224.
4. Spencer B. F. Campaign Monitoring of Railroad Bridges in High-Speed Rail Shared Corridors using Wireless Smart Sensors / B. F. Spencer // Report No NSEL-040, Department of Civil and Environ. Eng. Univ. of Illinois at Urbana-Champaign, June 2015.
5. Брынь М. Я. Геодезический мониторинг деформаций вантовых мостов на основе спутниковых техноло-
гий / М. Я. Брынь, А. А. Никитчин, Е. Г. Толстов и др. // Изв. ПГУПС. 2009. № 2 (19). С. 120-128.
6. Брынь М. Я. Программный комплекс для мониторинга деформаций особо опасных объектов / М. Я. Брынь, А. Д. Хо-моненко, В. П. Бубнов и др. // Проблемы информационной безопасности. Компьютерные системы. 2014. № 1. С. 36-41.
7. Бубнов В. П. Программный комплекс автоматизированного геодезического мониторинга искусственных сооружений для высокоскоростной железнодорожной магистрали «Москва - Казань - Екатеринбург» / В. П. Бубнов, А. А. Никитчин, С. А. Сергеев // Интеллектуальные технологии на транспорте. 2015. № 4. С. 27-33.
8. SQLite vs MySQL vs PostgreSQL: сравнение систем управления базами данных. URL: http://devacademy.ru/posts/ sqlite-vs-mysql-vs-postgresql (дата обращения 12.05.2017).
9. Уорсли Дж. PostgreSQL. Для профессионалов / Дж. Уорсли, Дж. Дрейк. - СПб.: Питер, 2003. 496 с.
10. Как выбрать систему управления базами данных. URL: http://www.getinfo.ru/article896.html (дата обращения 12.05.2017).
11. Документация к Java. URL: http://docs.oracle.com/ javase/7/docs/api (дата обращения 12.05.2017).
12. PostgreSQL. URL: https://www.postgresql.org (дата обращения 12.05.2017).
Database System Management Selection and Determination Optimal Number of Sensors for the Local Server as a part of AGMS
Bubnov V. P., Mochalov A. V., Solovyeva V. G. Emperor Alexander I Petersburg State Transport University St. Petersburg, Russia [email protected], [email protected], [email protected]
Abstract. The selection process of DBMS, which is the most usable on the local server of AGMS is considered. The architecture of the software complex of AGMS is described. A comparative analysis of DBMS and the reason for its selection are given. The maximum number of sensors connected to the server, at which the work of the given server will not be violated, is determinated.
Keywords: AGMS, DBMS, monitoring, sensors, program package, local server.
References
1. Watanabe E., Furuta H., Yamaguchi T., Kano M. On Longevity and Monitoring Technologies of Bridges: a Survey Study by the Japanese Society of Steel Construction. Struct. Infrastruct. Eng., 2010, vol. 10, no. 4, pp. 471-491.
2. Li S. L., Li H., Liu Y., Lan C., Zhou W., Ou J. SMC Structural Health Monitoring Benchmark Problem Using Monitored Data From an Actual Cable-stayed Bridge. Struct. Control and Health Monit., 2014, vol. 21, no. 2, pp. 156-172.
3. Li A. Q., Ding Y. L., Wang H., Guo T. Analysis and Assessment of Bridge Health Monitoring Mass Data - Progress in Research/Development of 'Structural Health Monitoring'. Sci. China Technol. Sci., 2012, vol. 55, no. 8, pp. 2212-2224.
4. Spencer B. F. Campaign Monitoring of Railroad Bridges in High-Speed Rail Shared Corridors Using Wireless Smart Sensors. Report No NSEL-040, Department of Civil and Environ. Eng. Univ. of Illinois at Urbana-Champaign, June 2015.
5. Bryn M. Ya., Nikitchin A. A., Tolstov E. G. et al. Geodetic Deformation Monitoring Cable-stayed Bridges Based on Satellite Technology [Geodezicheskii monitoring deformatcii vantovykh
mostov na osnove sputnikovykh tekhnologii], Proc. Petersburg Transp. Univ. [Izvestiia Peterburgskogo universitetaputei soob-shcheniia], 2009, no. 2 (19), pp. 120-128.
6. Bryn M. Ya., Khomonenko A. D., Bybnov V. P., Nikitchin A. A., Sergeev S. A., Novikov P. A., Titov A. I. Software for Monitoring Strain Especially Dangerous Objects [Program-mnyi kompleks dlia monitoringa deformatcii osobo opasnykh obektov], Prob. Inform. Security. Computer systems [Proble-my informatcionnoi bezopasnosti. Kompiuternye sistemy], 2014, no. 1, pp. 36-41.
7. Bubnov V. P., Nikitchin A.A., Sergeev S. A. Software for Automated Geodetic Monitoring of Artificial Structures for High-Speed Railway "Moscow - Kazan - Yekaterinburg" [Pro-grammnyy kompleks avtomatizirovannogo geodezicheskogo monitoringa iskusstvennykh sooruzheniy dlya vysokoskorost-noy zheleznodorozhnoy magistrali «Moskva - Kazan - Ekaterinburg»], Intellectual technologies on transport [Intellektualnye tekhnologii na transporte], 2015, no.4, pp. 27-33.
8. SQLite vs MySQL vs PostgreSQL: Comparison of Database Management Systems. Available at: http://devacademy. ru/posts/sqlite-vs-mysql-vs-postgresql (accessed 12 May 2017).
9. Worsley J., Dreik J. PostgreSQL. For Professionals [PostgreSQL. Dlya professionalov], St. Petersburg, Piter, 2003, 496 p.
10. How to Choose a Database Management System [Kak vybrat' sistemu upravleniya bazami dannyh]. Available at: http://www.getinfo.ru/article896.html (accessed 12 May 2017).
11. Java Documentation. Available at: https://docs.oracle. com/javase/7/docs/api (accessed 12 May 2017).
12. PostgreSQL. Available at: https://www.postgresql.org (accessed 12 May 2017).
