Проектирование и разработка комплексной медицинской информационной системы (КМИС) – сложный, трудоемкий и дорогостоящий процесс. Известно, что в настоящее время в России себестоимость создания КМИС зачастую выше, чем реальная цена, по которой ее можно распространять. Поэтому поиск решений, снижающих сложность и трудоемкость процесса проектирования и практической разработки КМИС, является в настоящее время одной их приоритетных задач разработчиков, занятых в такой специфичной области, как медицина. Существует множество различных подходов для решения этой задачи, но пока говорить о безусловной приоритетности какого-то одного из них еще рано, т.к. комплексные информационные решения в медицинских учреждениях все еще являются скорее исключением, чем правилом. Остановимся на отдельном аспекте в проектировании КМИС, который, по нашему мнению, является основополагающим – это выбор системы управления базами данных (СУБД). Отметим, что, по нашим данным, с использованием СУБД на архитектуре «Клиент-Сервер» построено 71% всех известных нам медицинских информационных системы, эта доля продолжает увеличиваться.

На сегодня можно выделить 3 основных подхода в вопросе выбора СУБД:

1. КМИС разрабатывается на базе реляционной СУБД. Этот подход используется в подавляющем большинстве решений («Амулет», «Медкор-2000», « Medwork », «Дока+» и др.)

2. КМИС разрабатывается на базе пост-реляционной СУБД или объектно-ориентированной СУБД. Этот подход чаще всего используется при выборе СУБД Cache или Lotus Notes / Domino в качестве основы системы («Гиппократ», «MedTrak», «LabTrak»)

3. Объектно-реляционный подход. По нашему мнению [3], это наиболее перспективное решение, учитывающее специфику предметной области и, вместе с тем, интегрирующее в себе все преимущества первых двух решений («Интерин», «ИС Кондопога»).

Выбор конкретной СУБД представляет собой сложную многопараметрическую задачу и является одним из важнейших этапов в разработке медицинской информационной системы. Выбранный программный продукт должен удовлетворять как текущим, так и будущим потребностям лечебно-профилактического учреждения (ЛПУ), при этом следует учитывать финансовые затраты на приобретение необходимого оборудования, самой системы, разработку необходимого программного обеспечения на ее основе, а также обучение персонала. [1].

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

При разработке отечественных КМИС в основном применяются следующие СУБД: Oracle, IBM DB 2 и Informix, Borland Interbase Server, MS SQL Server, Cache, Lotus Notes / Domino, MySQL и некоторые другие. Преимущественно используется СУБД Microsoft SQL Server, чья доля составляет 62% (Рис. 1).

IBM и Oracle заслуженно считаются лидерами в области систем управления БД. Специалисты IBM первыми ввели понятие реляционных БД и разработали SQL. К достижениям Oracle (вне рынка мэйнфреймов) можно отнести выпуск первой коммерческой СУБД, поддерживающей SQL (1979), первой клиент-серверной версии (1987), первой 32-разрядной (1983) и 64-разрядной (1995) версий, а также первой коммерческой СУБД, перенесенной на Linux (1999) [2]. Вместе с тем, в медицинской предметной области все чаще предпочтение отдается Microsoft SQL Server, возможно в силу хорошей маркетинговой политике Microsoft и более простой процедуре установки и меньшей стоимости владения.

Практически все из перечисленных коммерческих СУБД являются достаточно дорогими программными продуктами. Их использование в процессе проектирования и разработки само по себе имеет значительную долю в себестоимости КМИС. Кроме того, наметившаяся в последнее время тенденция к повышению престижности и потребности в лицензионном программном обеспечении повышает общую стоимость внедрения КМИС. Это обусловлено тем, что еще пару лет назад главный врач ЛПУ, решившийся на внедрение КМИС у себя в клинике и обладающий определенной (при этом весьма ограниченной) суммой, решал главным образом два вопроса: какую КМИС выбрать и сколько необходимо компьютерной техники. Сейчас все чаще мы видим ситуацию, когда к этим двум вопросам добавляется третий: сколько необходимо лицензионного программного обеспечения?

Все вышесказанное является естественным стимулом для поиска более доступных по цене СУБД и обладающих, вместе с тем, достаточным запасом функциональности и производительности. И такое решение имеется – это использование в качестве платформы разработки КМИС продуктов Open Source, главным образом – СУБД MySQL (или ряда других, менее известных, но не менее доступных решений).

В связи с этим мы поставили себе целью на практике изучить двух наиболее ярких представителей СУБД и выяснить, какие преимущества и недостатки имеют коммерческие и свободно-распространяемые СУБД в медицинской предметной области. При этом в качестве образца коммерческой СУБД мы выбрали программное обеспечение Microsoft SQL Server версий 7.0 и 2000, а в качестве свободно-распространяемой СУБД мы выбрали MySQL версии 4.0.21.

Данное исследование выполнялось нами в течение 2004 г. на базе разработанной на основе объектно-реляционного подхода комплексной медицинской информационной системы "Кондопога". Основу системы составляет документно-ориентированное ядро, созданное на СУБД Lotus Domino . При этом небольшую часть системы, предназначенную для функционирования некоторых задач статистики и бухгалтерии, составляет реляционная база данных. Используется специально разработанная технология "вариабельного ядра" (http://iskondopoga.narod.ru/ sience/ files/ 2004/ auto_gus.pdf), в задачи которой входит автоматическое связывание и масштабирование интегрированной объектно-реляционной БД [4]. В качестве СУБД мы апробировали вначале MySQL, а затем Microsoft SQL Server. При этом для нас очень важным был обоснованный выбор какой-то конкретной СУБД, с необходимым обоснованием и анализом результатов практической эксплуатации обоих СУБД и оценкой результатов этих эксплуатаций. Для этого мы выполнили ряд специальных тестов, изучали удобство в развертывании, администрировании и эксплуатации, оценивали устойчивость и другие параметры.

В качестве сценария для оценки этих СУБД мы использовали статью А. Аносова «Критерии выбора СУБД при создании информационных систем» [1]. В ней предлагается анализировать СУБД по ряду признаков, объединенных в общие разделы. На основе анализа этих признаков предлагается решать вопрос о приоритетности каждой конкретной СУБД для выбранной предметной области. Даже если просто отмечать, насколько хороши или плохи выделенные параметры в случае каждой конкретной СУБД, то сравнение уже двух различных систем является трудоемкой задачей. Тем не менее, четкий и глубокий сравнительный анализ на основании вышеперечисленных критериев в любом случае поможет рационально выбрать подходящую систему для конкретного проекта, и затраченные усилия не будут напрасными. Перечень критериев поможет осознать масштабность задачи и выполнить ее адекватную постановку

Рассмотрим результаты исследования. Для этого процитируем важнейшие из предложенных А.Аносовым показателей и прокомментируем их особенности для КМИС.

1. Триггеры и хранимые процедуры. Триггер – программа базы данных, вызываемая всякий раз при вставке, изменении или удалении строки таблицы. Триггеры обеспечивают проверку любых изменений на корректность, прежде чем эти изменения будут приняты. Хранимая процедура – программа, которая хранится на сервере и может вызываться клиентом. Поскольку хранимые процедуры выполняются непосредственно на сервере базы данных, обеспечивается более высокое быстродействие, нежели при выполнении тех же операций средствами клиента БД. В различных программных продуктах для реализации триггеров и хранимых процедур используются различные инструменты.

MySQL версии 4.0.21, в отличии от Microsoft SQL Server, не поддерживает ни триггеры, ни хранимые процедуры, что значительно усложняет ее использование, т.к. в приложениях системы большую часть необходимых проверок введенных данных и всевозможных блокировок, а также обеспечение целостности базы данных приходится выполнять на уровне клиентского приложения, что очень усложняет процесс создания и эксплуатации КМИС.

2. Особенности разработки приложений. Многие производители СУБД выпускают средства разработки приложений для своих систем. Как правило, эти средства позволяют наилучшим образом реализовать все возможности сервера, поэтому при анализе СУБД стоит рассмотреть также возможности средств разработки приложений.

Таблица 1

Особенности разработки приложений

Показатель	MS SQL Server	MySQL
Визуальные средства проектирования	+	+
Многоязыковая поддержка	+	+
Возможности разработки web -приложений	+	+
Поддержка JAVA	+
Встроенный язык программирования	+
Data Mining	+

 

В этом разделе MySQL версии 4.0.21, по сравнению с Microsoft SQL Server, также значительно проигрывает. Такие возможности Microsoft SQL Server, как схема БД, более качественная многоязыковая поддержка, развитые средства визуального проектирования значительно облегчают процесс моделирования БД и создание приложений для нее. Это, в свою очередь, ведет к повышению качества КМИС и снижению себестоимости ее производства.

3. Перечень операционных систем, под управлением которых способна работать СУБД. В этом разделе, безусловно, лидирует MySQL, которая способна работать на большинстве из имеющихся на настоящее время операционных систем. Некоторые из них имеют значительно более низкую стоимость, чем продукты фирмы Microsoft, что, конечно, ведет к снижению затрат при внедрении КМИС.

Таблица 2

Поддерживаемые операционные системы.

Показатель	ОС
MS SQL Server	Windows NT,2000 (Intel и Alpha)
MySQL	Linux (x86, libc6,S/390,IA64, Alpha, Sparc), Windows 95/98/NT/2000/XP, Solaris 2.9 (Sparc, 64-bit, 32-bit), FreeBSD 4.x ELF (x86), Mac OS X v10.2, HP-UX 10.20 (RISC 1.0), HP-UX 11.11 (PA-RISC 1.1 или 2.0), AIX 5.1 (RS6000), QNX 6.2.0 (x86), Novell NetWare 6 (x86), SCO OpenUnix 8.0 (x86), м SGI Irix 6.5, Dec OSF 5.1 (Alpha)

 

4. Стоимость эксплуатации. Стоимость эксплуатации определяется многими факторами. Основные из них – стоимость лицензий, требования к серверному оборудованию и, как следствие, стоимость необходимого сервера.

Как видно из таблицы ниже, а также по нашему опыту, требования к технической характеристике сервера у MySQL значительно ниже, чем у Microsoft SQL Server. За счет этого стоимость внедрения КМИС может быть в некоторой степени снижена.

Таблица 3

Минимальные требования к серверу.

Показатель	ОС
MS SQL Server	Pentium II 350 MHz , ОЗУ – 128 Мбайт, HDD - 250 Мбайт
MySQL	Pentium 100 MHz , ОЗУ - 64 Мбайт (минимум), 100 Мбайт свободного места на диске

 

Для изучения стоимости лицензий приведем ориентировочные цены на указанные СУБД с целью их установки на сервер с 2 процессорами и 25-30 клиентских подключений (типичная для многих ЛПУ минимальная конфигурация сети, использующаяся на начальном этапе внедрения КМИС). Как видно из приведенных данных, стоимость начальных затрат на лицензии Microsoft SQL Server в 35,6 раза выше, чем у MySQL. Фактически, стоимость MySQL не зависит от количества подключаемых рабочих мест, поэтому с ростом количества необходимых лицензий это преимущество увеличивается пропорционально количеству рабочих мест в ЛПУ.

Таблица 4

Примерная стоимость СУБД для 30 подключений

Название СУБД	Цена, $	Кол-во	Стоимость,  $
SQL Server 2000 Enterprise Edition English OpenLicensePack B *	6643,97	1	6643,97
SQL Server 2000 ClientAccessLicense English OpenLicensePack B*	151,94	30	4558,2
Всего на использование SQL Server 2000			11202,17
MySQL Pro 10..49 licenses**	315	1	315

* - по данным softline на апрель 2003 г .

** - по данным сайта http :// www . mysql . com на апрель 2003 г .

5. Производительность. Рассмотрим подробнее результаты исследования производительности различных СУБД, т.к. этот показатель является одним из основных факторов, влияющих на качество работы КМИС. При этом изучались 2 версии Microsoft SQL Server: версия 7.0 с установленным пакетом исправлений и дополнений Service Pack 4, а также версия 2000. После установки каждой СУБД на ней встроенными средствами администрирования создавалась база данных R _ TEST _ DB, в которую помещалась одна таблица с именем LVN, содержащая 65 столбцов и 20 098 строк записей. Объем таблицы 74,06 Мбайт (в формате MyISAM). В этой таблице находилась реальная информация о выданных больничных листах в одном из медицинских учреждений Карелии в период с 2-го полугодия 2002 по первое полугодие 2004 г. (24 месяца). Таблица помещалась в указанную БД во всех тестах при помощи средства DataPump, входящего в состав пакета программ Borland Delphi 6 Professional. В исследовании участвовали 3 сервера, технические характеристики которых представлены в таблице ниже.

Таблица 5

Технические характеристики серверов, участвовавших в тестировании:

№	NetBios -имя сервера	Техническая характеристика
1	POLIKSERVER	Asus P4800Delux / P4 3,06 GHz / RAM 2 x 512 Mb DDR400 / HDD 120 Gb 7200 prn
2	SRV2	2 x 500 MHz Pentium III Xeon / RAM 1 Gb / RAID 5 24 Gb SCSI-160
3	PROSERVER	2 x 3,06 GHz Pentium 4 Xeon HT / RAM 2 Gb / RAID 5 102 Gb SCSI-320

 

В ходе исследования использовались 3 рабочие станции, имеющие следующие характеристики:

Таблица 6

Технические характеристики рабочих станций,
участвовавших в тестировании:

№	NetBios -имя ПК	Техническая характеристика
1	Admin	Asus P4533 / P4 1,5 MHz / RAM 512 Mb DDR333 / HDD 40 Gb 7200 prn
2	Admin2	Asus P4800Delux / P4 3,06 GHz / RAM 2 x 512 Mb DDR400 / HDD 120 Gb 7200 prn
3	Admin7	Asus P4533 / P4 1,5 MHz / RAM 512 Mb DDR333 / HDD 40 Gb 7200 prn

 

На всех них были установлены одинаковые версии ODBC -драйвера MySQL ver . 3.51.7, а также Borland BDE из пакета программ Borland Delphi 6 Professional. Также на все ПК была установлена одинаковая версия программы ReDataBaseTester , разработанная авторами для проведения этого исследования. В ходе исследования указанная программа по команде пользователя последовательно в течение 1 сессии выполняла все указанные в справочнике SQL -запросы. После непродолжительного промежутка времени (10-500 мсек.), выбираемого программой случайным образом, сессия повторялась. Количество повторов равняется 30. При этом для каждого теста вначале использовалась 1 рабочая станция, затем 2, затем 3. Результаты каждого теста программа записывала в журнал работы, который затем был обработан – вычислены среднее значение, среднеквадратическое отклонение и дисперсия. При этом на испытуемом сервере было запущено программное обеспечение System Monitor, в котором включен 1 счетчик – % загруженности процессора. Перед началом каждого теста работа счетчика начиналась сначала. После окончания теста фиксировались 2 показателя – средний и максимальный проценты использования процессора, которые затем вручную вносились в журнал работы программы тестирования.

В данном исследовании было выбрано 3 наиболее показательных вида SQL -запроса, тексты которых представлены в таблице ниже.

Таблица 7

SQL -запросы, выполнявшиеся в ходе тестирования

№	Название запроса	SQL запрос
1	Простой Select	S ELECT * FROM lvn
2	Вывод отчета по строкам статистики	SELECT UNWORKSTATLINE1, COUNT(UNWORKSTATLINE1), SUM(CNUMKOIKOD) FROM lvn GROUP BY UNWORKSTATLINE1
3	Среднее количество суток по группам возрастов	SELECT CNUMVOZRAST, AVG(VOZRAST) FROM lvn GROUP BY CNUMVOZRAST

 

В таблицах с результатами исследований используются следующие переменные:

U – количество пользователей;

P av – средняя загрузка процессора(ов);

P max – максимальная загрузка процессора(ов);

D – длительность выполнения запроса, мсек.

 

В таблицах ниже представлены результаты выполнения запросов №1, 2 и 3. В приложении приведена исходная таблица с результатами выполнения тестов.

Таблица 8

Результаты выполнения запроса №1

Тест	U=1			U=2			U=3
	D	P av	P max	D	P av	P max	D	P av	P max
POLIKSERVER + MySQL 4.020	5450,8 ( ± 66,5)	14,3	46,88	5608,2 ( ± 71,8)	28,8	64,3	6011,4 ( ± 68,0)	41,3	62,2
POLIKSERVER + MS SQL Server 7.0 SP4	15,7 ( ± 0,2)	30 ,1	92	14,1 ( ± 1,7)	73,5	100	13,6 ( ± 1,9)	97	100
POLIKSERVER + MS SQL Server 2000	16,2 ( ± 1,0)	7,5	32,8	17,7 ( ± 2,4)	21,2	43,7	19,3 ( ± 2,7)	18,9	67,1
SRV2 + MySQL 4.0.20	6304,3 ( ± 38,3)	28	51	6273,4 ( ± 23,2)	63	98	6222,9 ( ± 50,9)	86	100
SRV2 + MS SQL Server 7.0 SP4	19,2 ( ± 2,7)	10,3	30,4	18,2 ( ± 2,1)	19,2	55,5	32,4 ( ± 5,8)	14	77,3
SRV2 + MS SQL Server 2000	19,4 ( ± 2,3)	22,9	42,9	19,8 ( ± 2,8)	41 ,4	84,3	28,7 ( ± 14,1)	26,8	74,9
PROSERVER + MySQL 4.0.20	6290,2 ( ± 88,1)	8,4	22,8	6217,0 ( ± 83,9)	9,4	23,1	6831,3 ( ± 64,7)	9,8	23,5
PROSERVER + MS SQL Server 7.0 SP4	19,8 ( ± 2,9)	20,9	32,8	17,8 ( ± 1,9)	3,4	16,4	18,2 ( ± 2,0)	5,2	29,2
PROSERVER + MS SQL Server 2000	16,2 ( ± 0,9)	6,4	15,3	16,2 ( ± 0,9)	5,6	24,3	19,4 ( ± 2,8)	13,3	27,7

 

Таблица 9

Результаты выполнения запроса №2

Тест	U=1			U=2			U=3
	D	P av	P max	D	P av	P max	D	P av	P max
POLIKSERVER + MySQL 4.020	163,0 ( ± 3,2)	14,3	46,88	155,3 ( ± 4,0)	28,8	64,3	153,7 ( ± 14,5)	41,3	62,2
POLIKSERVER + MS SQL Server 7.0 SP4	153 ,3 ( ± 10,9)	30,1	92	233,9 ( ± 21,7)	73,5	100	340,8 ( ± 20,3)	97	100
POLIKSERVER + MS SQL Server 2000	17,1 ( ± 1,6)	7,5	32,8	27,0 ( ± 13,9)	21,2	43,7	18,2 ( ± 2,1)	18,9	67,1
SRV2 + MySQL 4.0.20	928,8 ( ± 5,4)	28	51	961,8 ( ± 11,0)	63	98	1276,1 ( ± 75,9)	86	100
SRV2 + MS SQL Server 7.0 SP4	26,1 ( ± 7,1)	10,3	30,4	31,8 ( ± 1,0)	19,2	55,5	33,8 ( ± 3,6)	14	77,3
SRV2 + MS SQL Server 2000	93,4 ( ± 6,7)	22,9	42,9	92,4 ( ± 2,2)	41,4	84,3	97,9 ( ± 8,0)	26,8	74 ,9
PROSERVER + MySQL 4.0.20	196,4 ( ± 6,9)	8,4	22,8	176,0 ( ± 7,9)	9,4	23,1	164,7 ( ± 4,9)	9,8	23,5
PROSERVER + MS SQL Server 7.0 SP4	17,0 ( ± 2,9)	20,9	32,8	9,9 ( ± 2,6)	3,4	16,4	24,5 ( ± 9,1)	5,2	29,2
PROSERVER + MS SQL Server 2000	18,8 ( ± 3,3)	6,4	15,3	26,0 ( ± 3,6)	5,6	24,3	25,5 ( ± 2,8)	13,3	27,7

 

Таблица 10

Результаты выполнения запроса №3

Тест	U=1			U=2			U=3
	D	P av	P max	D	P av	P max	D	P av	P max
POLIKSERVER + MySQL 4.020	89,0 ( ± 2,9)	14,3	46,88	85,3 ( ± 9,4)	28,8	64,3	68,3 ( ± 2,7)	41,3	62,2
POLIKSERVER + MS SQL Server 7.0 SP4	58,9 ( ± 3,4)	30,1	92	85,5 ( ± 7,6)	73,5	100	172,3 ( ± 19,9)	97	100
POLIKSERVER + MS SQL Server 2000	3,2 ( ± 2,3)	7,5	32,8	5,7 ( ± 2,7)	21,2	43,7	9,9 ( ± 2,7)	18,9	67,1
SRV2 + MySQL 4.0.20	630,9 ( ± 5,8)	28	51	640,6 ( ± 24,2)	63	98	933,9 ( ± 78,4)	86	100
SRV2 + MS SQL Server 7.0 SP4	8,2 ( ± 3,1)	10,3	30,4	10,3 ( ± 2,6)	19,2	55,5	11,0 ( ± 4,4)	14	77,3
SRV2 + MS SQL Server 2000	17,7 ( ± 1,9)	22,9	42,9	16,1 ( ± 1,0)	41,4	84,3	22,3 ( ± 6,4)	26,8	74,9
PROSERVER + MySQL 4.0.20	116,2 ( ± 4,9)	8,4	22,8	93,3 ( ± 4,9)	9,4	23,1	85,8 ( ± 2,8)	9,8	23,5
PROSERVER + MS SQL Server 7.0 SP4	5,3 ( ± 2,7)	20,9	32,8	2,0 ( ± 1,9)	3,4	16,4	6,3 ( ± 3,0)	5,2	29,2
PROSERVER + MS SQL Server 2000	4,7 ( ± 2,6)	6,4	15,3	5,2 ( ± 2,6)	5,6	24,3	7,3 ( ± 2,8)	13,3	27,7

Как уже было сказано, специфика используемой медицинской информационной системы состоит в применении объектно-реляционного подхода. При этом реляционной составляющей отведена второстепенная роль. Реляционная СУБД обслуживает лишь некоторые задачи, такие как бухгалтерия, статистика, автоматизация некоторых служб (профосмотр, питание и т.д.). В ходе изучения практического опыта использования этого подхода выявлено, что реляционная СУБД редко обслуживает сразу несколько запросов от пользователей, чаще все в единицу времени выполняются запросы от 1-2 пользователей, крайне редко – 3-4 пользователей. Применение качественного проектирования модели реляционной БД и современных СУБД позволяет выполнять запросы даже на больших таблицах с очень малым временем отклика. Специфика медицинской деятельности приводит к тому, что в системе редко исполняются запросы вида select * from <tablename>, когда необходима обработка всей таблицы и передача по сети больших объемов данных. Чаще всего используются либо запросы за агрегированной информацией, либо запросы к определенной выборке. Все вышесказанное определило основной интерес исследования: изучить, насколько быстро исполняются запросы №1, 2 и 3, являющиеся наиболее показательными представителями основных видов запросов в МИС, а также изучить зафиксированные в моменты исполнения запросов показатели загрузки процессоров.

Общее сравнение производительности СУБД

Таблица 11

Анализ производительности СУБД по различным видам запросов (для U=1)

СУБД	POLIKSERVER			SRV2			PROSERVER
	D	P av	P max	D	P av	P max	D	P av	P max
Запрос №1
MySQL 4.020	5450,8 ( ± 66,5)	14,3	46,88	6304,3 ( ± 38,3)	28	51	6290,2 ( ± 88,1)	8,4	22,8
MS SQL Server 7.0 SP4	15,7 ( ± 0,2)	30 ,1	92	19,2 ( ± 2,7)	10,3	30,4	19,8 ( ± 2,9)	20,9	32 ,8
MS SQL Server 2000	16,2 ( ± 1,0)	7,5	32,8	19,4 ( ± 2,3)	22,9	42,9	16,2 ( ± 0,9)	6,4	15,3
Запрос №2
MySQL 4.020	163,0 ( ± 3,2)	14,3	46,88	928,8 ( ± 5,4)	28	51	196,4 ( ± 6,9)	8,4	22,8
MS SQL Server 7.0 SP4	153 ,3 ( ± 10,9)	30,1	92	26,1 ( ± 7,1)	10,3	30,4	17,0 ( ± 2,9)	20,9	32,8
MS SQL Server 2000	17,1 ( ± 1,6)	7,5	32,8	93,4 ( ± 6,7)	22,9	42,9	18,8 ( ± 3,3)	6,4	15,3
Запрос №3
MySQL 4.020	89,0 ( ± 2,9)	14,3	46,88	630,9 ( ± 5,8)	28	51	116,2 ( ± 4,9)	8,4	22,8
MS SQL Server 7.0 SP4	58,9 ( ± 3,4)	30,1	92	8,2 ( ± 3,1)	10,3	30,4	5,3 ( ± 2,7)	20,9	32,8
MS SQL Server 2000	3,2 ( ± 2,3)	7,5	32,8	17,7 ( ± 1,9)	22,9	42,9	4,7 ( ± 2,6)	6,4	15,3

Как видно из таблицы, очень сильное влияние на результаты тестов оказывает используемый сервер. Наиболее сильно расходятся результаты в случае использования 2-х процессорных серверов (SRV 2 и PROSERVER). В случае использования обычной рабочей станции POLIKSERVER в качестве сервера для реляционной СУБД результаты менее отличаются. Так, выполнение запроса №3 осуществляется MySQL на 51,1% медленнее, чем MS SQL Server 7.0 на сервере POLIKSERVER. Применение сервера SRV 2 демонстрирует снижение производительности MySQL в 76,9 раза. Исходя из этого, можно сделать вывод о том, что СУБД MS SQL Server более эффективно использует серверную платформу, причем независимо от версии. В наиболее благоприятных технических условиях СУБД MySQL выполняет запрос №1 в 347,2 раза медленнее, чем СУБД MS SQL Server 7.0. Запрос №2 выполняется MySQL лишь на 6,3% медленнее. Запрос №3 выполняется на 51,1% медленнее. В случае использования последних версий серверов ( PROSERVER ) MySQL выполняет запрос №1 в 317,7 раза медленнее, чем СУБД MS SQL Server 7.0. Запрос №2 выполняется MySQL в 11,6 раза медленнее. Запрос №3 выполняется в 21,9 раза медленнее. Таким образом, необходимо сделать вывод о том, что практически по всем видам запросов СУБД MS SQL Server выполняет их значительно быстрее, причем эта разница возрастает в случае применения настоящих серверных платформ, особенно – последних версий.

Изучение влияния числа пользователей

Для изучения влияния числа пользователей на изменение производительности СУБД рассмотрим результаты тестирования на сервере PROSERVER, обладающим наиболее мощными техническими характеристиками.

Таблица 12

Анализ производительности СУБД и количество пользователей.

Тест	U=1			U=2			U=3
	D	P av	P max	D	P av	P max	D	P av	P max
Запрос №1
MySQL 4.0.20	6290,2 ( ± 88,1)	8,4	22,8	6217,0 ( ± 83,9)	9,4	23,1	6831,3 ( ± 64,7)	9,8	23,5
MS SQL Server 7.0 SP4	19,8 ( ± 2,9)	20,9	32 ,8	17,8 ( ± 1,9)	3,4	16,4	18,2 ( ± 2,0)	5,2	29,2
MS SQL Server 2000	16,2 ( ± 0,9)	6,4	15,3	16,2 ( ± 0,9)	5,6	24,3	19,4 ( ± 2,8)	13,3	27,7
Запрос №2
MySQL 4.0.20	196,4 ( ± 6,9)	8,4	22,8	176,0 ( ± 7,9)	9,4	23,1	164,7 ( ± 4,9)	9,8	23,5
MS SQL Server 7.0 SP4	17,0 ( ± 2,9)	20,9	32,8	9,9 ( ± 2,6)	3,4	16,4	24,5 ( ± 9,1)	5,2	29,2
MS SQL Server 2000	18,8 ( ± 3,3)	6,4	15,3	26,0 ( ± 3,6)	5,6	24,3	25,5 ( ± 2,8)	13,3	27,7
Запрос №3
MySQL 4.0.20	116,2 ( ± 4,9)	8,4	22,8	93,3 ( ± 4,9)	9,4	23,1	85,8 ( ± 2,8)	9,8	23,5
MS SQL Server 7.0 SP4	5,3 ( ± 2,7)	20,9	32,8	2,0 ( ± 1,9)	3,4	16,4	6,3 ( ± 3,0)	5,2	29,2
MS SQL Server 2000	4,7 ( ± 2,6)	6,4	15,3	5,2 ( ± 2,6)	5,6	24,3	7,3 ( ± 2,8)	13,3	27,7

 

Как видно из таблицы, достоверного снижения или увеличения производительности работы СУБД в зависимости от числа пользователей не отмечено. Вероятно, это объясняется искусственной природой запросов, а также высокой плотностью однотипного потока запросов к СУБД при многопользовательском режиме работы программы тестирования. Скорее всего, указанные особенности тестирования приводили к сильному влиянию кеширования результатов выполнения последних запросов, поэтому в ряде тестов отмечено даже снижение среднего времени выполнения запроса при увеличении числа пользователей. В условиях реальной работы пользователей с МИС вероятность появления одинакового запроса сразу от нескольких пользователей снижается практически до нуля. В связи с этим следует ожидать снижение эффекта влияние кеширования запросов совместно с увеличением числа пользователей. Достоверно (p=0,04 с U=1 до U=2, p=0,009 с U=2 до U=3) отмечено увеличение показателя средней загрузки процессора при увеличении числа пользователей. Менее достоверно (p=0,27) увеличивается показатель максимальной загрузки процессора при увеличении пользователей от 1 до 2. Однако уже при увеличении числа пользователей от 2 до 3 практически абсолютно достоверно (р=0,009) этот показатель увеличился.

В целом в ходе анализа результатов тестов следует отметить более экономный расход процессорных ресурсов СУБД MySQL по сравнению с СУБД MS SQL Server .

Выводы по выбору СУБД с учетом анализа производительности

По результатам этого исследования, разумеется, нельзя однозначно судить о приоритете СУБД MS SQL Server над MySQL. В ходе эксплуатации различных подсистем в составе нашей медицинской информационной системы, использующих реляционную базу данных на основе СУБД MySQL мы отмечали достаточно высокую производительность на гораздо больших объемах данных. Для ее достижения применялись стандартные методы проектирования реляционной БД, целочисленные поля в качестве ключей для связанных таблиц и т.д. Однако изучение результатов, полученных в данном тестировании, позволяет сделать вывод о значительно более высокой скорости работы СУБД MS SQL Server, как наиболее распространенного представителя коммерческих СУБД. Кроме того, следует отметить выдающиеся возможности администрирования и обслуживания СУБД MS SQL Server. Аналогичные по функциональном назначению средства, имеющиеся для СУБД MySQL, значительно уступают в своих возможностях средствам MS SQL Server. Кроме этого, имеющиеся на сайте MySQL на лето 2004 программы для управления СУБД имели низкую устойчивость в работе, а в ряде случаев – вообще не выполняли тех функций, которые декларировали. Однако не следует забывать, что СУБД MySQL – полностью бесплатный продукт, готовый к использованию на абсолютно законных основаниях (если Вы только не собираетесь распространять решения, основные на этом продукте на коммерческой основе). Анализируя все вышесказанное, можно сделать вывод о том, что в настоящее время решающую роль в медицинской предметной области может играть не какие-то конкретные параметры СУБД, такие как устойчивость или производительность, а совсем другие, относящиеся скорее к сфере субъектных моментов. Основные из них – это доступность технической поддержки, регулярность появления новых версий и выпуска т.н. пакетов исправлений, наличие (в том числе в сети Internet) русскоязычной и подробной документации, профессионализм разработчиков.

В качестве рекомендаций мы сформировали следующее правило: если коллектив разработчиков обладает достаточными финансовыми возможностями и если Ваши потенциальные заказчики также способны приобрести необходимое количество лицензий, следует отдавать безусловное предпочтение коммерческим СУБД, таким как Microsoft SQL Server. Если финансовые возможности как разработчика, так и потребителя информационной системы ограничены, следует выбрать СУБД MySQL, которая обладает достаточным уровнем устойчивости работы и приемлемой за свою стоимость производительностью.

Следует отметить, что по существующей практике решение об использовании той или иной СУБД принимает чаще один человек – обычно, руководитель проекта, а он может опираться отнюдь не на технические критерии. Здесь свою роль могут сыграть такие, с технической точки зрения, незначительные факторы, как рекламная раскрутка компании-производителя СУБД, использование конкретных систем на других предприятиях, стоимость. При этом последний фактор может трактоваться в двух противоположных смыслах в зависимости от финансового состояния и политики ЛПУ. С одной стороны это может быть принцип «если дороже, то значит - лучше». С другой стороны – культивирование почти бесплатного использования продукта, вплоть до «взлома» его лицензионной защиты. Очевидно, последний подход чреват коллизиями и не может привести к успеху в долгосрочной работе.

 

Литература:

1. Аносов А. Критерии выбора СУБД при создании информационных систем.
2. Бобровский C. Есть ли альтернативы Oracle и DB2?
3. Гусев А. В., Дуданов И. П., Романов Ф. А., Дмитриев А. Г. Особенности в проектировании и практической разработке медицинской информационной системы и информационные технологии, - 2004. - №5. - С.49-56 //Врач
   http://iskondopoga.narod.ru/ sience/ files/ 2004/ mis-2004.pdf
4. Гусев А.В. Моделирование и оценка эффективности функционирования медицинской информационной системы //Автореф., дис. к-та тех. наук: 05.13.18/ Петрозавод. гос. ун-т – Петрозаводск.: Изд-во ПетрГУ
   http://iskondopoga.narod.ru/ sience/ files/ 2004/ auto_gus.pdf

Приложение

Исходные данные тестирования СУБД

Таблица 13

Исходные результаты выполнения тестов СУБД и серверов

Код	Код теста	Код SQL -запроса	U	P max	P av	D	Ст.откл.	Дисперс.
1	1	1	1	46,88	14,3	5450,8	185,70952	66,4553
1	1	2	1	46,88	14,3	163,03333	8,86748	3,17319
1	1	3	1	46,88	14,3	89,03333	8,14241	2,91373
2	1	1	2	64,28	28,8	5608,23333	200,64125	71,79855
2	1	2	2	64,28	28,8	155,3	11,35826	4,0645
2	1	3	2	64,28	28,8	85,3	26,547	9,49972
3	1	1	3	62,2	41,3	6011,43333	190,11815	68,03291
3	1	2	3	62,2	41,3	153,66667	40,49307	14,49026
3	1	3	3	62,2	41,3	68,33333	7,57775	2,71166
4	2	1	1	92	30,1	15,67742	0,46746	0,16456
4	2	2	1	92	30,1	153,53333	30,39488	10,87667
4	2	3	1	92	30,1	58,96667	9,63495	3,44782
5	2	1	2	100	73,5	14,13333	4,73099	1,69296
5	2	2	2	100	73,5	233,86667	60,74742	21,73818
5	2	3	2	100	73,5	85,46667	21,17189	7,57626
6	2	1	3	100	97	13,63333	5,36335	1,91925
6	2	2	3	100	97	340,8	56,78814	20,32138
6	2	3	3	100	97	172,33333	55,49134	19,85732
7	3	1	1	51	28	6304,33333	107,14798	38,34241
7	3	2	1	51	28	928,76667	15,14966	5,42124
7	3	3	1	51	28	630,96667	16,11931	5,76822
8	3	1	2	98	63	6273,36667	64,86164	23,21044
8	3	2	2	98	63	961,8	30,92615	11,06678
8	3	3	2	98	63	640,63333	67,54578	24,17095
9	3	1	3	100	86	6622,86667	142,33429	50,93367
9	3	2	3	100	86	1276,13333	212,0303	75,87407
9	3	3	3	100	86	933,96667	219,14736	78,42088
10	4	1	1	22,8	8,4	6290,2	246,26184	88,12367
10	4	2	1	22,8	8,4	196,4	19,33667	6,91954
10	4	3	1	22,8	8,4	116,16667	13,70908	4,90573
11	4	1	2	23,1	9,4	6217,03333	234,53578	83,92755
11	4	2	2	23,1	9,4	176,03333	21,99012	7,86906
11	4	3	2	23,1	9,4	93,3	13,76989	4,92749
12	4	1	3	23,5	9,8	6831,26667	180,6955	64,66105
12	4	2	3	23,5	9,8	164,66667	13,81143	4,94236
12	4	3	3	23,5	9,8	85,83333	7,71182	2,75964
13	5	1	1	32,8	20,9	19,76667	8,07747	2,89049
13	5	2	1	32,8	20,9	17,06667	8,35836	2,991
13	5	3	1	32,8	20,9	5,26667	7,45177	2,66658
14	5	1	2	16,4	3,4	17,76667	5,50565	1,97017
14	5	2	2	16,4	3,4	9,9	7,54255	2,69907
14	5	3	2	16,4	3,4	2,03333	5,18641	1,85593
15	5	1	3	29,2	5,2	18,23333	5,72529	2,04877
15	5	2	3	29,2	5,2	24,5	25,4673	9,11336
15	5	3	3	29,2	5,2	6,26667	8,66	3,09894
16	6	1	1	30,4	10,3	19,23333	7,70577	2,75747
16	6	2	1	30,4	10,3	26,13333	19,90433	7,12267
16	6	3	1	30,4	10,3	8,23333	8,68594	3,10822
17	6	1	2	55,5	19,2	18,23333	5,90866	2,11439
17	6	2	2	55,5	19,2	31,83333	2,85287	1,02089
17	6	3	2	55,5	19,2	10,33333	7,31817	2,61877
18	6	1	3	77,3	14	32,4	16,08436	5,75571
18	6	2	3	77,3	14	33,76667	9,96221	3,56493
18	6	3	3	77,3	14	11	12,29634	4,40019
19	7	1	1	32,8	7,5	16,16667	2,97863	1,06589
19	7	2	1	32,8	7,5	17,13333	4,64567	1,66243
19	7	3	1	32,8	7,5	3,2	6,4	2,29021
20	7	1	2	43,7	21,2	17,73333	6,5774	2,35369
20	7	2	2	43,7	21,2	27,03333	38,80248	13,88529
20	7	3	2	43,7	21,2	5,73333	7,5407	2,69841
21	7	1	3	67,1	18,9	19,26667	7,62423	2,7283
21	7	2	3	67,1	18,9	18,2	5,83324	2,0874
21	7	3	3	67,1	18,9	9,93333	7,56718	2,70788
22	8	1	1	15,3	6,4	16,2	2,78568	0,99684
22	8	2	1	15,3	6,4	18,76667	9,31194	3,33223
22	8	3	1	15,3	6,4	4,7	7,18401	2,57076
23	8	1	2	24,3	5,6	16,2	2,78568	0,99684
23	8	2	2	24,3	5,6	26,03333	10,13076	3,62524
23	8	3	2	24,3	5,6	5,2	7,35935	2,63351
25	8	1	3	27,7	13,3	19,36667	7,7781	2,78336
25	8	2	3	27,7	13,3	25,5	7,79637	2,78989
25	8	3	3	27,7	13,3	7,33333	7,84573	2,80756
26	9	1	1	42,9	22,9	19,4	6,48896	2,32205
26	9	2	1	42,9	22,9	93,36667	18,75897	6,71281
26	9	3	1	42,9	22,9	17,73333	5,32249	1,90463
27	9	1	2	84,3	41,4	19,8	7,99333	2,86038
27	9	2	2	84,3	41,4	92,36667	6,07993	2,17568
27	9	3	2	84,3	41,4	16,1	2,80891	1,00516
28	9	1	3	74,9	26,8	28,73333	39,54823	14,15215
28	9	2	3	74,9	26,8	97,86667	22,45103	8,034
28	9	3	3	74,9	26,8	22,3	17,93349	6,41742