Analysis of the information base volume using the monitoring system of the regional medical information system (1C: Medicine)

Full Text

ВВЕДЕНИЕ

Высокая роль внедрения информационных систем (ИС) находит свое применение в медицинской сфере. Актуальность данного вектора развития подтверждается наличием стратегического направления в области цифровой трансформации здравоохранения, утвержденного распоряжением Правительства РФ от 17.04.2024 № 959-р [11]. Автоматизация процессов деятельности организаций здравоохранения позволяет значительно повысить эффективность их работы, что напрямую влияет на качество медицинского обслуживания пациентов.

Развитие информационных технологий в медицинской сфере является одной из приоритетных задач, установленных Правительством Тюменской области. В 2015 году в рамках федерального проекта было принято решение о разработке и внедрении продукта собственного производства на базе платформы 1С. Полный переход с SAP на 1С состоялся в 2018 году [1].

Достижение необходимого уровня быстродействия и отказоустойчивости системы невозможно без применения высокопроизводительного оборудования и организации непрерывного мониторинга его функционирования. В условиях обработки значительных объёмов данных, характерных для современных медицинских информационных систем, критическое значение приобретает своевременное выявление узких мест и оптимизация серверных процессов.

Следствием плановых обновлений системы становится возникновение ряда проблем со стороны пользовательского интерфейса: увеличение времени открытия экранных форм, формирования отчетных документов и выполнения учетных операций. Данные факторы приводят к росту временных затрат на обслуживание пациентов и, как следствие, к увеличению очередей в поликлиниках, что негативно отражается на доступности и качестве медицинской помощи.

Обоснованность управленческих решений в области разработки и администрирования информационных систем базируется на результатах анализа сводных данных, формируемых в процессе автоматического сбора показателей функционирования систем. Своевременный контроль и устранение выявленных факторов нестабильности позволили бы предотвратить значительную долю возникающих проблем. В связи с этим было принято решение о разработке и внедрении собственной системы мониторинга, ориентированной на решение специфических задач наблюдения за медицинскими информационными системами (МИС). Среда разработки – платформа «1С:Предприятие 8.3».

Система мониторинга серверной части региональной медицинской информационной системы Тюменской области (РМИС ТО) предназначена для непрерывного сбора, хранения и анализа данных о состоянии серверного оборудования и выполняемых на нём процессов как в круглосуточном режиме, так и в периоды пиковых нагрузок. Ключевая идея разработки заключается в создании специализированного инструментария, ориентированного на решение уникальных задач мониторинга, возникающих в процессе сопровождения РМИС ТО.

Целью создания системы является повышение эффективности мониторинга и сопровождения региональной медицинской информационной системы Тюменской области.

Для достижения поставленной цели были определены следующие задачи:

– изучение внутренней архитектуры РМИС ТО и анализ существующих методов сбора аналитики;

– разработка механизмов сбора и хранения счетчиков операционной системы;

– разработка механизмов сбора и хранения счетчиков СУБД PostgreSQL;

– разработка механизмов сбора и хранения счетчиков платформы 1С (серверная часть).

В рамках реализации данной работы разрабатываемая система должна обеспечивать следующий функционал, необходимый для поддержки бесперебойной работы РМИС:

– получение актуальной информации о состоянии операционной системы, базы данных, платформы 1С;

– сбор статистики по информационным базам и кластеру PostgreSQL;

– получение и анализ структуры хранения информационной базы в PostgreSQL с последующим сохранением результатов в базе системы мониторинга;

– мониторинг счетчиков платформы 1С в тестовой и продуктивной средах;

– получение текущей информации о проблемных (неоптимизированных в рамках времени выполнения) участках программного кода;

– отправка оповещений по электронной почте с возможностью гибкой настройки получателей для каждого сервера или информационной базы;

– выбор информационных баз, включаемых в плановый сбор статистики и рассылку уведомлений;

– планирование периодичности проведения анализа/тестирования процессов (еженедельно, ежемесячно и т. д.);

– установка приоритетов анализируемых процессов в системе мониторинга;

– формирование аналитических сводок и отчетов о состоянии системы;

– оценка производительности и масштабируемости информационной системы;

– анализ масштабируемости при варьировании параметров (объем базы данных, количество одновременно работающих пользователей, уровень нагрузки и др.);

– получение оценки сравнения показателей производительности при изменении функциональности и конфигурации;

– выявление конфликтов блокировок (при многопользовательской работе системы);

– хранение собираемой статистики.

РЕЗУЛЬТАТЫ И ОБСУЖДЕНИЕ

Система мониторинга РМИС ТО представляет собой программный комплекс, предназначенный для контроля состояния серверной части информационной системы, включая сбор аппаратной статистики, мониторинг базы данных и анализ работы платформы 1С [7]. В качестве источников данных выступают три среды: тестовая, продуктивная, а также корпоративный инструментальный пакет [6]. В тестовой и продуктивной средах сбор информации осуществляется напрямую из операционной системы, СУБД и платформы 1С [8]. Корпоративный инструментальный пакет, в свою очередь, обеспечивает выгрузку и передачу данных, полученных в ходе тестирований.

Система мониторинга хранит и обрабатывает все получаемые показатели и предоставляет доступ к ним для внешних систем обработки данных [3; 9; 14]. На рисунке 1 изображена наглядная схема основных компонентов, взаимодействующих с системой мониторинга.

 

Рисунок 1. Общая схема структуры системы мониторинга РМИС

 

Данная система является модульной, причем работа модулей может не зависеть друг от друга [5]. На рисунке 2 отображена схема межмодульного взаимодействия, а также показаны источники данных для каждого модуля.

 

Рисунок 2. Схема межмодульного взаимодействия системы

 

Основная идея данного модуля заключается в получении количественных показателей состояния таблиц, полей и индексов информационной базы [15, с. 312–362]:

– общая статистика;

– объем, занимаемый таблицами;

– статистика по обращениям к таблицам;

– статистика по операциям ввода/вывода для таблиц;

– статистика по обращениям к индексам;

– статистика по операциям ввода/вывода для индексов.

Поскольку в данном модуле работа связана напрямую с базами данных, то для обеспечения безопасной разработки, на случай каких-либо ошибок и непредвиденных обстоятельств, были сымитированы структура и порядок развертывания систем в реальных условиях [4]. Для этого на локальном компьютере была запущена виртуальная машина с операционной системой Linux CentOS 7, а также установлены такие компоненты, как система управления базами данных PostgreSQL и серверная платформа 1С. Были проведены настройки локальной сети для связи серверной и клиентской частей. Принцип работы данного модуля построен на получении статистической информации из системных таблиц, которая отражает текущее состояние информационной базы 1С в рамках статистики выполнения запросов и обращений к памяти [2].

Процесс получения статистических данных схематично изображен на рисунке 3. В конфигурации системы мониторинга формируется SQL-запрос, который напрямую передается в СУБД, и в зависимости от требуемых данных PostgreSQL возвращает значения.

 

Рисунок 3. Схема работы модуля для получения статистики ИБ

 

Модуль позволяет работать с получаемыми данными: сортировать по столбцам, находить необходимое значение и т. п. В работе модуля предусмотрена возможность сохранять значения в базе как вручную, так и автоматически по расписанию. В свойствах каждой конфигурации с помощью интерфейса пользователь может настроить подписку на сохранение и оповещения, отсылаемые в виде файла формата .xls на электронную почту.

Как уже было указано ранее, все запросы хранятся в общем модуле конфигурации «тмб_ТекстыЗапросов». Функции модуля не выполняют работу с информационной базой, они лишь возвращают текст запроса в строковой переменной. Основная задача данного модуля заключается в централизованном хранении всех запросов в одном месте [13, с. 189–207].

Для работы данного модуля было реализовано шесть функций:

1. Функция «РазмерыТаблиц» предназначена для получения данных о занимаемом объеме памяти таблицами в БД. На первом шаге получается список существующих имен таблиц из системной таблицы «information_schema.tables». Затем с помощью встроенных функций СУБД PostgreSQL (pg_table_size(), pg_indexes_size, pg_total_relation_size()) вычисляются размеры таблиц и индексов [15, с. 335–347]. По умолчанию размеры отображаются в байтах, но поскольку в системе хранятся большие объемы данных, было принято решение перевести байты в мегабайты [10].
2. Функция «СтатистикаОбращенийКТаблицам» предназначена для получения статистики по обращениям к таблицам. Информация получается из системной таблицы «pg_stat_all_tables» [10; 15, с. 315–324].
3. Функция «СтатистикаОперацийПоТаблицам()» предназначена для получения статистики по операциям ввода/вывода для таблиц. Информация получается из системной таблицы «pg_statio_all_tables» [10; 15, с. 328–334].
4. Функция «СтатистикаОбращенийКИндексам()» предназначена для получения статистики по обращениям к индексам. Информация получается из системной таблицы «pg_stat_all_indexes» [10; 15, с. 324–328].
5. Функция «СтатистикаОперацийПоИндексам()» предназначена для получения статистики по операциям ввода/вывода для индексов. Информация получается из системной таблицы «pg_statio_all_indexes» [10; 15, с. 331–335].
6. Функция «ПолучитьОбщуюСтатистикуПоКонфигурации()» предназначена для получения общей (сводной) статистики по информационной базе в PostgreSQL. Информация получается из двух таблиц «pg_stat_database» и «pg_stat_database_conflicts» [15, с. 335–339]. Первая таблица выводит общую системную информацию, а вторая отвечает за вывод статистики по отменам запросов, произошедшим вследствие конфликтов [10].

Для проведения эксперимента был выбран модуль получения статистики информационных баз в PostgreSQL, поскольку задача анализа объема информационных баз была наиболее актуальна для источника финансирования (предприятия).

В ходе эксперимента на протяжении одного месяца ежедневно выполнялись регламентные задания по сбору статистических показателей таблиц [16]. В качестве исследуемых таблиц были установлены три объекта: «Справочник.Картотека» (_reference95), «Документ.СменаФИО» (_document338), РегистрСведений.ДанныеПациентов (_inforg7304).

Решение о выборе данных таблиц для эксперимента было принято на основании проведения импорта данных пациентов в тестовый контур. Именно эти 3 объекта являются одними из важнейших при организации хранения данных пациентов. Главная задача этого эксперимента – проверить работу модуля на получении статистических показателей таблиц в PostgreSQL при импорте новых данных. За указанный период было загружено около 500 000 данных о пациентах. Загрузка данных была разбита на 29 частей, примерно по 17 000 новых записей [12, с. 178–195].

Первой областью для анализа являлся объем занимаемой памяти таблицами в базе данных. Были получены выборки данных для «Справочник.Картотека» (рисунок 4), «Документ.СменаФИО» (рисунок 5), «РегистрСведений.ДанныеПациентов» (рисунок 6).

 

Рисунок 4. Размеры таблицы «Справочник.Картотека»

 

Рисунок 5. Размеры таблицы «Документ.СменаФИО»

 

Рисунок 6. Размеры таблицы «РегистрСведений.ДанныеПациентов»

 

На основании полученных данных был рассчитан примерный объем памяти, занимаемый 1 пациентом (без учета медицинских данных), в рамках данного эксперимента. Расчеты приведены в таблице 1.

 

Таблица 1. Объем памяти, занимаемый одним пациентом (без учета медицинских данных)

№	Наименование таблицы	Объем памяти, занимаемый одним пациентом (Кб)
1	«Справочник.Картотека»	1,072	2,4917
2	«Документ.СменаФИО»	0,674
3	«РегистрСведений.ДанныеПациентов»	0,7457

 

При импорте данных была оценена статистика по обращениям к индексам. При создании объектов конфигурации 1С индексы автоматически создаются неявным образом, то есть с помощью набора полей, однозначно определяющих данные.

У каждой таблицы имеется свой ряд индексов [13, с. 89–112], например для объекта «Справочник.Картотека» перечень индексов приведен в таблице 2, для «Документ.СменаФИО» – в таблице 3.

 

Таблица 2. Перечень индексов для объекта «Справочник.Картотека»

№	Имя индекса хранения 1С	Состав индекса
		Имя поля 1С	Имя поля хранения SQL
1	_Reference95_Code	Код	_Code
2	_Reference95_Descr	Наименование	_Description
3	_Reference95_ByField1536	СтраховойНомерПФР	_Fld1534
4	_Reference95_ByField17484	ИдентификаторПациентаВРМИС	_Fld17483
5	_Reference95_ByField17826	сшп_Идентификатор	_Fld17493

 

Таблица 3. Перечень индексов для объекта «Документы.СменаФИО»

№	Имя индекса хранения 1С	Состав индекса
		Имя поля 1С	Имя поля хранения SQL
1	_Document338_ByDocNumPrefix	Префикс	_NumberPrefix
2	_Document338_ByDocNum	Номер	_Number
3	_Document338_ByDocDate	Дата	_Date_Time
4	_Document338_ByField5467	Пациент	_Fld5462RRef
5	_Document338_ByField5466	ДокументОснование	_Fld5457_RTRef
6	_Document338_ByField17826	сшп_Идентификатор	_Fld17493

 

Поскольку объект «РегистрСведений.ДанныеПациентов» является регистром сведений, то для него автоматически создаются таблицы: «СрезПоследних» и «СрезПервых», в зависимости от установленных параметров [13, с. 245–272]. В нашем случае учет статистики будет суммироваться по двум таблицам «_InfoRg7304» и «_InfoRgSL12162». Перечень индексов для данных объектов приведен в таблице 4.

 

Таблица 4. Перечень индексов для объекта «РегистрСведений.ДанныеПациентов»

№	Имя индекса хранения 1С	Состав индекса
		Имя поля 1С	Имя поля хранения SQL
1	_InfoRg7304_ByPeriod	Период	_Period
2	_InfoRg7304_ByRecorder	Регистратор	_RecorderRRef
3	_InfoRg7304_ByDims	Пациент (измерение)	_Fld7305RRef
4	_InfoRg7304_ByResource7313	Фамилия (ресурс)	_Fld7311
4	_InfoRg7304_ByResource7312	Имя (ресурс)	_Fld7307
5	_InfoRg7304_ByResource12161	ДатаРождения (ресурс)	_Fld7306
РегистрСведений.ДанныеПациентов.СрезПоследних
1	_InfoRgS12162_ByDims	Пациент (измерение)	_Fld7305RRef
2	_InfoRgS12162_ByResource7313	Фамилия (ресурс)	_Fld7311
3	_InfoRgS12162_ByResource7312	Имя (ресурс)	_Fld7307
4	_InfoRgS12162_ByResource12161	ДатаРождения (ресурс)	_Fld7306

 

После выполнения импорта была получена следующая статистика: для «Справочник.Картотека» результаты представлены на рисунке 7, «Документ.СменаФИО» – на рисунке 8, «РегистрСведений.ДанныеПациентов» – на рисунке 9.

 

Рисунок 7. Статистика по обращениям к индексам «Справочник.Картотека»

 

Рисунок 8. Статистика по обращениям к индексам «Документ.СменаФИО»

 

Рисунок 9. Статистика по обращениям к индексам «РегистрСведений.ДанныеПациентов»

 

ЗАКЛЮЧЕНИЕ И ВЫВОДЫ

Анализ полученных результатов позволяет заключить, что число выполненных сканирований и количество возвращённых элементов являются индикаторами операций чтения таблиц. Отсутствие обращений к таблицам «Справочник.Картотека» и «Документ.СменаФИО» в рамках эксперимента обусловило нулевые значения соответствующих показателей.

Для регистра сведений «ДанныеПациентов» показатели количества запущенных сканирований и числа возвращённых элементов имеют ненулевые значения. Это обусловлено тем, что при внесении новых записей в регистр выполняется автоматическая перестройка вспомогательной таблицы «СрезПоследних», которая предполагает выполнение операций чтения из основной таблицы.

Среди прочих ресурсов наибольшую востребованность демонстрирует индекс по реквизиту «Имя», что объясняется возможностью множественного совпадения значений данного реквизита у различных записей регистра. Следует также отметить, что для этого индекса количество сканирований превышает количество возвращённых элементов, а число считанных дисковых блоков при обращении к нему является максимальным среди всех рассматриваемых индексов.

Использование индекса по дате рождения в ходе сканирований носит частный характер и связано с условиями эксперимента: при импорте тестовых данных в качестве даты рождения пациента устанавливалась текущая дата на момент создания записи.

Число попаданий в буфер у всех индексов приблизительно одинаково, поскольку данный показатель не зависит ни от настроек СУБД, ни от параметров платформы 1С. Следует учитывать, что наличие индексов не всегда оказывает положительное влияние на производительность базы данных. Индексирование сопряжено с дополнительным расходом дискового пространства и замедлением операций вставки, обновления и удаления записей. В связи с этим выбор оптимального набора индексов требует проведения дополнительного анализа и экспертной оценки.

Применение разработанных модулей позволяет прогнозировать изменения в информационных базах и на основе полученных данных осуществлять обоснованное планирование модернизации аппаратного обеспечения, а также оптимизацию существующих программных решений.

About the authors

Mikhail V. Grigoriev

Tyumen State University

Email: m.v.grigorev@utmn.ru

Candidate of Engineering Science, Associate Professor

Russian Federation, Tyumen

Inna I. Grigorieva

Tyumen State University

Email: i.i.grigoreva@utmn.ru

Candidate of Engineering Science, Associate Professor

Russian Federation, Tyumen

Maxim M. Popovich

1C-Medicine-Region LLC

Author for correspondence.
Email: popm@1cmr.ru

Team Leader

Russian Federation, Tyumen

References

Supplementary files