Logo Море(!) аналитической информации!
IT-консалтинг Software Engineering Программирование СУБД Безопасность Internet Сети Операционные системы Hardware
Обучение от Mail.Ru Group.
Онлайн-университет
для программистов с
гарантией трудоустройства.
Набор открыт!
2004 г

Microsoft SQL Server против MySQL в медицинских информационных системах

Гусев А.В., к.т.н, ст. инженер-программист ОАО "Кондопога"
Дмитриев А.Г., инженер-программист ОАО "Кондопога"

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


Рис. 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

Новости мира IT:

Архив новостей

Последние комментарии:

Вышло обновление Firefox 57.0.1 (1)
Среда 06.12, 09:14

IT-консалтинг Software Engineering Программирование СУБД Безопасность Internet Сети Операционные системы Hardware

Информация для рекламодателей PR-акции, размещение рекламы — adv@citforum.ru,
тел. +7 985 1945361
Пресс-релизы — pr@citforum.ru
Обратная связь
Информация для авторов
Rambler's Top100 TopList liveinternet.ru: показано число просмотров за 24 часа, посетителей за 24 часа и за сегодня This Web server launched on February 24, 1997
Copyright © 1997-2000 CIT, © 2001-2015 CIT Forum
Внимание! Любой из материалов, опубликованных на этом сервере, не может быть воспроизведен в какой бы то ни было форме и какими бы то ни было средствами без письменного разрешения владельцев авторских прав. Подробнее...