Microsoft SQL Server против MySQL в медицинских информационных системах
, к.т.н, ст. инженер-программист ОАО "Кондопога"
, инженер-программист ОАО "Кондопога"
Проектирование и разработка комплексной медицинской информационной системы (КМИС) – сложный, трудоемкий и дорогостоящий процесс. Известно, что в настоящее время в России себестоимость создания КМИС зачастую выше, чем реальная цена, по которой ее можно распространять. Поэтому поиск решений, снижающих сложность и трудоемкость процесса проектирования и практической разработки КМИС, является в настоящее время одной их приоритетных задач разработчиков, занятых в такой специфичной области, как медицина. Существует множество различных подходов для решения этой задачи, но пока говорить о безусловной приоритетности какого-то одного из них еще рано, т.к. комплексные информационные решения в медицинских учреждениях все еще являются скорее исключением, чем правилом. Остановимся на отдельном аспекте в проектировании КМИС, который, по нашему мнению, является основополагающим – это выбор системы управления базами данных (СУБД). Отметим, что, по нашим данным, с использованием СУБД на архитектуре «Клиент-Сервер» построено 71% всех известных нам медицинских информационных системы, эта доля продолжает увеличиваться.
На сегодня можно выделить 3 основных подхода в вопросе выбора СУБД:
1. КМИС разрабатывается на базе реляционной СУБД. Этот подход используется в подавляющем большинстве решений («Амулет», «Медкор-2000», « Medwork », «Дока+» и др.)
2. КМИС разрабатывается на базе пост-реляционной СУБД или объектно-ориентированной СУБД. Этот подход чаще всего используется при выборе СУБД Cache или Lotus Notes / Domino в качестве основы системы («Гиппократ», «MedTrak», «LabTrak»)
3. Объектно-реляционный подход. По нашему мнению [], это наиболее перспективное решение, учитывающее специфику предметной области и, вместе с тем, интегрирующее в себе все преимущества первых двух решений («Интерин», «ИС Кондопога»).
Выбор конкретной СУБД представляет собой сложную многопараметрическую задачу и является одним из важнейших этапов в разработке медицинской информационной системы. Выбранный программный продукт должен удовлетворять как текущим, так и будущим потребностям лечебно-профилактического учреждения (ЛПУ), при этом следует учитывать финансовые затраты на приобретение необходимого оборудования, самой системы, разработку необходимого программного обеспечения на ее основе, а также обучение персонала. [].
Очевидно, наиболее простой подход при выборе СУБД основан на оценке того, в какой мере существующие системы удовлетворяют основным требованиям создаваемого проекта информационной системы. Более сложным и дорогостоящим вариантом является создание испытательного проекта на основе нескольких СУБД и последующий выбор наиболее подходящего из кандидатов. Но, и в этом случае необходимо ограничивать круг возможных систем, опираясь на некие критерии отбора.
При разработке отечественных КМИС в основном применяются следующие СУБД: Oracle, IBM DB 2 и Informix, Borland Interbase Server, MS SQL Server, Cache, Lotus Notes / Domino, MySQL и некоторые другие. Преимущественно используется СУБД Microsoft SQL Server, чья доля составляет 62% (Рис. 1).
Рис. 1 . Соотношение СУБД на архитектуре «Клиент-сервер» в отечественных медицинских информационных системах
IBM и Oracle заслуженно считаются лидерами в области систем управления БД. Специалисты IBM первыми ввели понятие реляционных БД и разработали SQL. К достижениям Oracle (вне рынка мэйнфреймов) можно отнести выпуск первой коммерческой СУБД, поддерживающей SQL (1979), первой клиент-серверной версии (1987), первой 32-разрядной (1983) и 64-разрядной (1995) версий, а также первой коммерческой СУБД, перенесенной на Linux (1999) []. Вместе с тем, в медицинской предметной области все чаще предпочтение отдается 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), в задачи которой входит автоматическое связывание и масштабирование интегрированной объектно-реляционной БД []. В качестве СУБД мы апробировали вначале MySQL, а затем Microsoft SQL Server. При этом для нас очень важным был обоснованный выбор какой-то конкретной СУБД, с необходимым обоснованием и анализом результатов практической эксплуатации обоих СУБД и оценкой результатов этих эксплуатаций. Для этого мы выполнили ряд специальных тестов, изучали удобство в развертывании, администрировании и эксплуатации, оценивали устойчивость и другие параметры.
В качестве сценария для оценки этих СУБД мы использовали статью А. Аносова «» []. В ней предлагается анализировать СУБД по ряду признаков, объединенных в общие разделы. На основе анализа этих признаков предлагается решать вопрос о приоритетности каждой конкретной СУБД для выбранной предметной области. Даже если просто отмечать, насколько хороши или плохи выделенные параметры в случае каждой конкретной СУБД, то сравнение уже двух различных систем является трудоемкой задачей. Тем не менее, четкий и глубокий сравнительный анализ на основании вышеперечисленных критериев в любом случае поможет рационально выбрать подходящую систему для конкретного проекта, и затраченные усилия не будут напрасными. Перечень критериев поможет осознать масштабность задачи и выполнить ее адекватную постановку
Рассмотрим результаты исследования. Для этого процитируем важнейшие из предложенных А.Аносовым показателей и прокомментируем их особенности для КМИС.
1. Триггеры и хранимые процедуры. Триггер – программа базы данных, вызываемая всякий раз при вставке, изменении или удалении строки таблицы. Триггеры обеспечивают проверку любых изменений на корректность, прежде чем эти изменения будут приняты. Хранимая процедура – программа, которая хранится на сервере и может вызываться клиентом. Поскольку хранимые процедуры выполняются непосредственно на сервере базы данных, обеспечивается более высокое быстродействие, нежели при выполнении тех же операций средствами клиента БД. В различных программных продуктах для реализации триггеров и хранимых процедур используются различные инструменты.
MySQL версии 4.0.21, в отличии от Microsoft SQL Server, не поддерживает ни триггеры, ни хранимые процедуры, что значительно усложняет ее использование, т.к. в приложениях системы большую часть необходимых проверок введенных данных и всевозможных блокировок, а также обеспечение целостности базы данных приходится выполнять на уровне клиентского приложения, что очень усложняет процесс создания и эксплуатации КМИС.
2. Особенности разработки приложений. Многие производители СУБД выпускают средства разработки приложений для своих систем. Как правило, эти средства позволяют наилучшим образом реализовать все возможности сервера, поэтому при анализе СУБД стоит рассмотреть также возможности средств разработки приложений.
Таблица 1
Особенности разработки приложений
| Показатель | MS SQL Server | MySQL |
| Визуальные средства проектирования | + | + |
| Многоязыковая поддержка | + | + |
| Возможности разработки web -приложений | + | + |
| Поддержка JAVA | + | |
| Встроенный язык программирования | + | |
| Data Mining | + |
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) |
Как видно из таблицы ниже, а также по нашему опыту, требования к технической характеристике сервера у MySQL значительно ниже, чем у Microsoft SQL Server. За счет этого стоимость внедрения КМИС может быть в некоторой степени снижена.
Таблица 3
Минимальные требования к серверу.
| Показатель | ОС |
| MS SQL Server | Pentium II 350 MHz , ОЗУ – 128 Мбайт, HDD - 250 Мбайт |
| MySQL | Pentium 100 MHz , ОЗУ - 64 Мбайт (минимум), 100 Мбайт свободного места на диске |
Таблица 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 |
** - по данным сайта 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 |
Таблица 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 |
В данном исследовании было выбрано 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 |
Результаты выполнения запроса №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 |
