Summary
Это исследование сравнивает реляционных и нереляционных (NoSQL) стандартизированных систем медицинской информации. Вычислительная сложность время отклика запроса таких систем управления базами данных (СУБД) вычисляется с помощью удвоения размера баз данных. Эти результаты помогут обсуждение целесообразности подхода каждой базы данных проблем и различных сценариев.
Abstract
Это исследование показывает протокол для оценки вычислительная сложность запроса реляционных и нереляционных (NoSQL (не только язык структурированных запросов)) стандартизированных электронных медицинских записей (ЭМК) системы медицинской информации базы данных (СУБД). Он использует набор трех удвоение размера баз данных, т.е. баз хранения 5000, 10000 и 20000 реалистичные стандартизированные экстракты EHR, в трех систем управления различными базами данных (СУБД): реляционного MySQL объектно реляционного сопоставления (ORM), на основе документа NoSQL MongoDB и родной расширяемый язык разметки (XML) NoSQL существуют.
Среднее время ответа для шести увеличения сложности запросов были рассчитаны, и результаты показали линейное поведение в случаях NoSQL. В поле NoSQL MongoDB представляет много льстить линейной наклон, чем существует.
NoSQL системы также могут быть более целесообразным сохранить стандартизированных медицинских информационных систем из-за особого характера обновления политики медицинской информации, которая не должна затрагивать согласованности и эффективности данных, хранящихся в базах данных NoSQL.
Одно ограничение этого протокола является отсутствие прямых результатов улучшения реляционных систем, таких как архетип реляционного сопоставления (ARM) с теми же данными. Однако интерполяции результатов удвоение размера базы данных для тех, кто представил в литературе и других опубликованных результатов свидетельствует о том, что NoSQL системы может быть более подходящим во многих конкретных сценариев и решить проблемы. К примеру NoSQL может подходить для задач, на основе документов, например EHR экстракты, используемые в клинической практике, издание и визуализация или в ситуациях, где целью является не только медицинской информации запроса, но и для восстановления EHR в точно в его первоначальном виде.
Introduction
NoSQL (не только SQL) СУБД недавно появились как альтернатива традиционной реляционной СУБД (ВЫСОКОМАСШТАБИРУЕМЫЙ). РСУБД доминировали как данные хранились в базе данных систем на протяжении десятилетий. Хорошо изучена и понял Реляционная алгебра и математический анализ гарантируют эффективность и согласованность РСУБД1. NoSQL системы не станут заменителей для реляционных систем, но они могут вести себя выгодно, в некоторых сценариях и при нескольких условиях.
Некоторые из этих конкретных сценариев и условий произойдет при проектировании базы данных сохраняемости систем электронного здравоохранения запись (EHR) используется для управления и хранения медицинской информации. Для того, чтобы быть совместимой и устойчивым на практике, некоторые международные стандарты, как ISO/EN 13606, openEHR и HL72,,345 ,были использованы для стандартизации EHR экстрактов.
Некоторые стандарты, как ISO/EN 13606 и openEHR отделили информации и знаний на двух различных уровнях абстракции, представлены в модели ссылки (RM) и специальных данных структур, называемых архетипов. Это разделение часто называют двойной модель и позволяет EHR систем быть семантически интероперабельной и медицинских знаний развиваться без перепрограммирования системы в целом EHR и, следовательно, в сопровождении и устойчивым на практике6 . Однако двойной модели реализованы в стандартизированных систем EHR требует что организации информации соответствует определенной структуре, и это имеет серьезные последствия в способ сохранения уровень базы данных системы разработанные7.
Объект Relational Mapping (ORM)8 является одной методологии внедрить систему EHR, с использованием парадигмы реляционной базы данных. ORM исчерпывающим образом сопоставляет структуры стандартизированных файлов XML (расширяемый язык разметки) EHR экстракты, используемые системой для реляционной базы данных. ORM создает много реляционных таблиц исчерпывающе после структуры стандартизированных экстрактов EHR XML-файлов. Эти реляционные таблицы связаны посредством многих внешних ключей и результирующая система не может быть очень эффективным.
Были предложены несколько реляционных улучшения ORM. openEHR путь узла +9 уменьшает число реляционных таблиц путем сериализации поддеревья экстракта всего XML-файла в капли (больших двоичных объектов). Однако это упрощение вызывает сложные поиска логики, повредив сложных запросов. Архетип реляционного сопоставления (ARM)10 генерирует обусловлен архетипы, строительство новой реляционной схемы, на основе сопоставлений между архетипы и реляционными таблицами модели базы данных. Следовательно некоторые сведения немедицинских EHR экстракта теряется.
Многие на основе документов баз данных NoSQL хранить целые документы как весь капли, уважая оригинальный XML или JSON (объектная нотация JavaScript) формат. Это означает, что не реляционные таблицы строятся. Эти базы данных NoSQL имеют не схема и они не поддерживают либо соединения или (кислота) свойства11, т.е., атомарности, согласованности, изоляции или прочность. В результате они могут быть очень неэффективно, если элемент документа ссылается на элементы одного и того же или других таких документов, используя ссылку косвенного обращения. Это происходит, потому что, с тем чтобы сохранить последовательность, полностью ссылочные документы должны обрабатываться последовательно. Однако нереляционная база данных может быть еще уместным, если основная задача, выполняемая СУБД на основе документа задача. Это потому, что данные могут оставаться в форме, более тесно приближения его истинное представление, с использованием базы данных на основе документа NoSQL, хотя это также из-за специальных сохранение политики, проделанную EHR медицинские документы (см. раздел "обсуждение").
Цель этих методов заключается в демонстрации нескольких экспериментов, чтобы сравнить реализации сохраняемости слоя стандартизованной системы EHR, используя три различных СУБД: один реляционных (MySQL) и два NoSQL (на основе документа MongoDB и поддержкой XML существуют). Был их вычислительной сложности вычисляется и сравнивается используя три различных увеличение размера базы данных и шесть различных увеличения сложности запросов. Три базы данных серверов были установлены и настроены локально в том же компьютере, где были выполнены запросы. Смотрите Таблицу материалы для технических деталей.
Проводились также параллелизма эксперименты с целью сравнения производительности реляционных СУБД MongoDB NoSQL и MySQL. Описаны улучшения ORM (+ путь узла и ARM) также были по сравнению с использованием соответствующих соответствующие результаты из литературы10.
Систем управления базами данных непрерывно развиваются быстрыми темпами. Никто бы думать об этом экспоненциальное развитие когда единственной существующей парадигмы является реляционная модель. В качестве примера, увидеть например12, где модель была предложена для реализации время отклика более реляционных баз данных, сохраняя свойства ACID.
Protocol
1. Построьте реляционной СУБД MySQL для хранения трех двойной размера EHR стандартизированных экстрактов баз данных
- Импорт W3C (World Wide Web Consortium) XML-схема, соответствующая ISO/EN13606 RM и типы данных ISO21090 в «Java IDE» (интегрированной среды разработки).
Примечание: ISO стенды для международной организации по стандартизации. EN стенды для европейской нормой. - Выполнение JAXB (Java XML Binding) плагина в среде IDE; Это производит Java-классы, соответствующие структуры элементов EHR экстракты XML-файлов.
- Тег вручную Java-классы, производятся с метками JPA. Эти метки относятся к мощности и других отношений между реляционными таблицами базы данных MySQL.
- Импорт библиотеки JPA (Java Persistence API) в среде IDE и выполнить метод, который создает базы данных MySQL из тегами Java-классов.
- Создайте три каталоги с 5000, 10000 и 20000 реалистичные EHR извлекает XML-файлов.
- Выполните метод JPA для загрузки XML экстракт в СУБД MySQL на всех экстрактов в каталоге 5000 экстрактов.
- Повторите шаг 1.6 дважды, один раз с каталогом 10000 экстрактов и один раз с каталогом 20000 экстрактов.
2. Построьте NoSQL MongoDB СУБД для хранения трех двойной размера EHR стандартизированных экстрактов баз данных
- Процесс каждый три названия директорий, содержащих 5000, 10000 и 20000 реалистичные EHR экстракты XML-файлы с помощью стандартной программы для преобразования XML-файлов в файлы JSON, например json.org.XML. Три каталоги с 5000, 10000 и 20000 JSON файлов должны быть произведены.
- Запуск MongoDB GUI (графический пользовательский интерфейс, смотрите Таблицу материалы).
- Запуск MongoDB 2.6 сервер , выполнение программы mongod из окна системы DOS (диск операционной системы).
- MongoDB GUI подключение к серверу localhost, порт 27017.
- Выберите в меню «Connect».
- Введите имя для подключения (например, «первый»).
- Напишите localhost:27017 в текстовом поле сервер БД.
- Нажмите кнопку «Connect»; дерево с текущей базы данных должен появиться на левой стороне.
- Постройте базу данных, содержащую 5000 стандартизированных EHR экстрактов.
- Нажмите на имя подключения в верхней части дерева слева.
- Выберите меню «файл».
- Выберите «Добавить базу данных».
- Введите имя базы данных в диалоговом окне, которое появляется.
- Нажмите кнопку ОК.
- Создать коллекцию, содержащую 5000 стандартизированных EHR экстрактов.
- Нажмите на имя базы данных в дереве слева.
- Выберите в меню «база данных».
- Выберите «AddCollection».
- Введите имя коллекции в диалоговом окне, которое появляется.
- Нажмите кнопку « создать».
- Щелкните имя коллекции.
- Выберите в меню «Импорт».
- Выберите переключатель ''JSON - Монго оболочки / / mongoexport».
- Нажмите кнопку «Следующая».
- Нажмите кнопку «Добавить исходные файлы».
- Перейдите на компьютер с помощью диалогового окна.
- Открыть каталог, содержащий 5000 JSON извлечь файлы.
- Выберите все файлы в каталоге.
- Нажмите кнопку «Открыть». Список файлов JSON должны появиться в диалоговом окне импорта.
- Нажмите кнопку «следующий»; Предваротельный просмотр новой коллекции в базе данных появляется на левой стороне.
- Нажмите кнопку «Следующая».
- Нажать кнопку «начать импорт». Хода выполнения импорта появляется вниз слева, указывающее количество файлов, импортированных и затраченное время.
- Повторите шаги 5 и 6 для создания коллекции 10000 EHR стандартизированных экстрактов.
- Повторите шаги 5 и 6 для создания коллекции EHR 20 000 стандартизированных экстрактов.
3. Построение NoSQL существует СУБД для магазина три двойной размера стандартизированных EHR извлекает баз данных
- Запуск базы данных существуют .
- Используя значок базы данных, откройте клиент Admin Java.
- Введите пароль администратора.
- Нажмите кнопку «Connect».
- Создать коллекцию, содержащую 5000 стандартизированных EHR экстрактов.
- В панели инструментов выберите в меню «создать новую коллекцию».
- В диалоговом окне, которое появляется введите имя новой коллекции.
- Нажмите «принять»; появится новая коллекция.
- Выберите имя коллекции.
- В панели инструментов выберите в меню «файлы хранилища в базе данных».
- Перейдите на компьютер, с помощью диалогового окна.
- Выберите каталог, содержащий 5000 стандартизированный экстракт XML-файлы.
- Нажмите кнопку «выбрать файлы или каталоги для хранения». Обратите внимание, что диалоговое окно показать прогресс, файлы и процент созданной базы данных.
- Повторите шаг 5, чтобы создать коллекцию, содержащую 10 000 стандартизированных EHR экстрактов.
- Повторите шаг 5, чтобы создать коллекцию, содержащую 20 000 стандартизированных EHR экстрактов.
4. дизайн и в реляционных MySQL баз данных 3 6 увеличение сложности запросов
- Дизайн шести увеличения сложности запросов в соответствии с архетипы, используемые EHR экстрактов.
- Программа сценарий SQL с первого запроса в базе данных MySQL. SQL должны адаптироваться к особой структуры MySQL базы данных за счет стандартизации экстрактов (архетипы). База данных сопоставляет всю структуру экстрактов. В результате SQL-запрос является довольно сложным.
- Определите атрибуты баз данных, которые бы ускорить время отклика запросов, если индекс был построен на них, а затем построить такие индексы, хотя большинство индексы создаются автоматически с СУБД.
- Если запрос должен автоматически построен индекс, построить его вручную.
- Подключитесь к серверу MySQL (дополнительный рис. 1).
- Выберите и нажмите на имя базы данных на левой стороне.
- Выберите и нажмите на реляционной таблице, где проживает индексированного поля.
- Щелкните на вкладке «Структура».
- И нажать на столбце, где будет построен индекс.
- Нажмите на «индекс». Обратите внимание, что появляется в предложении SQL создания индекса, и появляется сообщение о том, что приговор был построен успешно.
- Выполните первый запрос.
- Выберите и нажмите на имя базы данных на левой стороне.
- Перейдите на вкладку «SQL».
- Напишите или вставьте SQL код первого запроса (см. дополнительный рисунок 2).
- Нажмите «продолжить». Обратите внимание, что на первом экране список результатов появится сообщение с времени выполнения запроса.
- Повторите выполнение 5 раз и вычислить среднее время отклика.
- Повторите шаг 5 с запросами 2-6.
- Сделайте весь процесс в три раза, с 5000, 10000 и 20000 экстракты баз данных.
5. Разработка и выполнение в NoSQL MongoDB баз данных 3 6 увеличение сложности запросов
- Запуск пользовательского интерфейса MongoDB (см. Таблицу материалы).
- Запуск сервера MongoDB 2.6, выполнение программы mongod из окна системы DOS (см. дополнительный рис. 3).
- Выполните шаг 2.4 к серверу localhost, порт 27017 MongoDB GUI.
- Выберите и разверните базу данных MongoDB, на левой стороне.
- Выберите коллекцию.
- Нажмите на меню «коллекции» в панели инструментов.
- Выполните первый запрос MongoDB.
- Дважды щелкните кнопку «Построитель запросов».
- Дважды щелкните на «поле запросов» построителя запросов на право.
- Записи поля MongoDB запроса в текстовом поле панели запроса (см. дополнительный рисунок 4).
- Заполните значение в MongoDB запрос в текстовое поле значение панели запроса.
Примечание: Этот запрос должен быть что-то вроде {«ns3:EHRExtract.allCompositions.content.items.parts.parts.name.ns2:originalText. значение»: «Описание»}. Поля и значения указаны и разделенных точкой с запятой. - Дважды щелкните на поле проекции построителя запросов
- Написать первый проекции в текстовое поле проекции (см. дополнительный рисунок 5).
- Дважды щелкните на поле проекции, чтобы добавить новый textbox проекции.
- Напишите второй проекции в текстовое поле проекции.
Примечание: Проекция выбирает частью документа, извлекаемых посредством запроса. Это должно быть что-то вроде {«ns3:EHRExtract. allCompositions.content.items.parts.parts.value.value»: 1} и {«ns3: EHRExtract.all Compositions.content.items.parts.parts.value.nullFlavor»: 1} - Нажмите на кнопку играть в синий для выполнения запроса.
- Визуализируйте код запроса на вкладке запросов кода.
- Просмотр сведений о результат на вкладке Объяснение: количество результатов, время выполнения в миллисекундах.
- Просмотр, расширять и проанализировать результаты на вкладке результат.
- Если требуется дальнейшая обработка запроса, напишите программу Java с MongoDB Java драйвер с запросом и метод для обработки результатов.
- Повторите выполнение 5 раз и вычислить среднее время отклика.
- Шаг 5.7 для оставшихся 2 через 6 запросов.
- Повторите весь процесс в 5000, 10000 и 20000 экстрактов MongoDB баз данных.
6. Разработка и выполнение в 3 NoSQL существует растущая сложность запросов баз данных 6
- Запуск, существуют СУБД.
- Откройте клиент Admin Java.
- Нажмите на кнопку «соединиться с базой данных».
- Выберите базу данных и нажмите на него.
- Выберите в меню «консультироваться базы данных с помощью XPath»; Откроется диалоговое окно Консалт.
- Первый запрос XPath (см. дополнительный рис. 6).
- Напишите или вставьте код XPath первого запроса в верхней части диалогового окна.
- Нажмите кнопку «выполнить» в меню панели инструментов диалогового окна.
- Просмотр результатов XML, используя вкладку «XML» в нижней части диалогового окна.
- Посмотреть количество результатов и компиляции и времени выполнения в нижней части диалогового окна.
- Повторите выполнение 5 раз и вычислить среднее время отклика.
- Повторите шаг 6 для запросов 2-6.
- Сделайте весь процесс в три раза, 5000, 10000 и 20000 экстракты существует баз данных.
7. Разработка и выполнение параллелизма эксперимент с использованием MySQL и баз данных экстрактов MongoDB 5000
Примечание: Существует база данных удалена из эксперимента на данном этапе ввиду хуже, производительность в предыдущих экспериментах.
- Выберите запросы с тремя кратчайшее время ответы в предыдущих экспериментах с использованием баз данных 5000 экстрактов (обычно в несколько секунд).
- Идентифицировать и вручную создавать соответствующий атрибут индексы для этих запросов, в случае необходимости.
- Многопоточных приложений Java программы два, один для MySQL и другой для MongoDB; Каждое приложение будет иметь три различных приоритетных потоков, один для каждого запроса, выбранной на шаге 1.
- Выполнение и вычислить CPU (Центральный процессор) распределение используется для каждого потока (запрос).
- Выполнение каждого многопоточного приложения, нажав на кнопку execute пять раз в течение каждого 10-мин интервал и вычислить наиболее исполнения (наивысший приоритет) средняя пропускная способность и среднее время реакции трех запросов запросов.
- Просмотр запросов в исполнении, с приоритетами и времени выполнения.
- Вычислите среднее пропускную способность и среднее время ответа каждого из трех запросов.
Representative Results
Шесть различных запросов, выполненных на реалистичные стандартизированных экстрактов EHR, содержащий информацию о проблемах пациентов, включая их имена, начальная и конечная даты и серьезности, показаны в таблице 1.
Среднее время ответа шесть запросов в трех удвоение размера баз данных в каждой СУБД приведены в таблицах 2-4. Цифры 1-6 показать те же результаты графически (Обратите внимание, что вертикальных осей используют очень разные шкалы на протяжении эти цифры).
Сильный линейное поведение вычислительной сложности очевидно на протяжении всех запросов баз данных NoSQL, хотя с соответствующей осторожностью ввиду относительно небольшого размера 3 наборов данных, используемые. Однако в реляционной базе данных ORM показывает неясным линейное поведение. В базе данных MongoDB имеет много льстить наклон, чем база данных существует.
Результаты улучшения реляционных систем, обсуждались в введении, опубликованных в литературе приводится в таблице 5. Интерполяции MongoDB результаты из таблицы 3 с сходных запросов и баз данных размеров руки результаты из таблицы 5 равна обе базы данных системы в Q1, но способствует MongoDB в Q3.
Результаты экспериментов параллелизма можно найти в таблице 5 и Таблица6. MongoDB бьет MySQL как в пропускную способность и время отклика. В самом деле MongoDB ведет себя лучше чем параллелизма в изоляции и стоит впечатляющий базу данных в качестве параллельного выполнения.
Рисунок 1 : Алгоритмической сложности ORM MySQL, MongoDB, и существуют СУБД для запросов Q1 и Q4. Эта цифра была изменена от7 с использованием лицензии Creative Commons (http://creativecommons.org/ licenses/by/4.0/) и показывает время отклика в секундах для 5000, 10000 и 20000 размера EHR извлекает баз данных для каждой СУБД и запросы Q1 и Q4. Пожалуйста, нажмите здесь, чтобы посмотреть большую версию этой фигуры.
Рисунок 2 : Алгоритмическая сложность СУБД MySQL ORM для запроса Q2. Эта цифра показывает время отклика в секундах для 5000, 10000 и 20000 размера EHR извлекает ORM MySQL базу данных для запроса Q2. Пожалуйста, нажмите здесь, чтобы посмотреть большую версию этой фигуры.
Рисунок 3 : Алгоритмической сложности MongoDB и существуют СУБД для запроса Q2 и Q5. Эта цифра была изменена от7 с использованием лицензии Creative Commons (http://creativecommons.org/licenses/, / 4.0) и показывает время отклика в секундах для 5000, 10000 и 20000 размера EHR извлекает баз данных для каждой СУБД и запросы Q2 и Q5. Пожалуйста, нажмите здесь, чтобы посмотреть большую версию этой фигуры.
Рисунок 4 : Алгоритмической сложности ORM СУБД MySQL запросов Q3 и Q5. Показывает время отклика в секундах для 5000, 10000 и 20000 размера EHR извлекает баз данных для каждой СУБД и запросы Q3 и Q5. Пожалуйста, нажмите здесь, чтобы посмотреть большую версию этой фигуры.
Рисунок 5: алгоритмической сложности существуют и MongoDB СУБД для запроса Q3. Эта цифра была изменена от7 с использованием лицензии Creative Commons (http://creativecommons.org/licenses//4.0 /) и показывает время отклика в секундах для 5000, 10000 и 20000 размера EHR извлекает баз данных для каждой СУБД и запроса Q3. Пожалуйста, нажмите здесь, чтобы посмотреть большую версию этой фигуры.
Рисунок 6 : Алгоритмическая сложность ORM MySQL, существуют и MongoDB СУБД для запроса Q6. Эта цифра была изменена от7 с использованием лицензии Creative Commons (http://creativecommons.org/licenses//4.0 /) и показывает время отклика в секундах для 5000, 10000 и 20000 размера EHR извлекает баз данных для каждой СУБД и запросов Q6. Пожалуйста, нажмите здесь, чтобы посмотреть большую версию этой фигуры.
| Запрос | |
| Q1 | Найти все проблемы одного пациента |
| Q2 | Найти все проблемы всех пациентов |
| Q3 | Начальная дата, Дата резолюции и тяжести |
| из одной проблемы одного пациента | |
| Q4 | Начальная дата, Дата резолюции и тяжести |
| из всех проблем проблемы одного пациента | |
| Q5 | Начальная дата, Дата резолюции и тяжести |
| все проблемы проблемы всех пациентов | |
| Q6 | Найти все больные проблемы «фарингит», |
| Начало > = ' 16/10/2007 ', резолюции Дата | |
| < = ' 06/05/2008 ' и «высокий» |
Таблица 1: шесть запросов выполняются на реляционных и баз данных NoSQL содержащие стандартизированные EHR извлекает о проблемах пациентов. Эта таблица была изменена от7 с использованием лицензии Creative Commons (http://creativecommons.org/ licenses/by/4.0/) и показывает шесть растущей сложности запросов осуществляется на трех баз данных становится размера для каждой СУБД, выраженная в природных язык.
| ORM/MySQL | 5000 документов | 10 000 документов | 20 000 документов |
| Q1 (s) | 25.0474 | 32.6868 | 170.7342 |
| Q2 (s) | 0.0158 | 0.0147 | 0.0222 |
| Q3 (s) | 3.3849 | 6.4225 | 207.2348 |
| Q4 (s) | 33.5457 | 114.6607 | 115.4169 |
| Q5 (s) | 9.6393 | 74.3767 | 29.0993 |
| Q6 (s) | 1.4382 | 2.4844 | 183.4979 |
| Размер базы данных | 4,6 ГБ | 9,4 ГБ | 19.4 ГБ |
| Всего экстракты | 5000 | 10 000 | 20 000 |
Таблица 2: среднее время отклика в секундах шесть запросов на удвоение размера баз данных реляционной СУБД ORM MySQL. Эта таблица показывает шесть время отклика для каждого запроса для трех удвоение размера базы данных с помощью реляционной СУБД ORM MySQL и размер в памяти трех баз данных.
| MongoDB | 5000 документов | 10 000 документов | 20 000 документов | склон (*10exp(-6)) |
| Q1 (s) | 0,046 | 0,057 | 0.1221 | 5.07 |
| Q2 (s) | 34.5181 | 68.6945 | 136.2329 | 6,780.99 |
| Q3 (s) | 0,048 | 0,058 | 0.1201 | 4.81 |
| Q4 (s) | 0.052 | 0,061 | o.1241 | 4.81 |
| Q5 (s) | 38.0202 | 75.4376 | 149.933 | 7460.85 |
| Q6 (s) | 9.5153 | 18.5566 | 36.7805 | 1,817.68 |
| Размер базы данных | 1,95 ГБ | 3.95 ГБ | 7,95 ГБ | |
| Всего экстракты | 5000 | 10 000 | 20 000 |
Таблица 3: среднее время отклика в секундах шесть запросов на удвоение размера баз данных NoSQL СУБД MongoDB. Эта таблица была изменена от7 с использованием лицензии Creative Commons (http://creativecommons.org/ licenses/by/4.0/) и показывает шесть отклика каждого запроса для трех удвоение размера базы данных с использованием СУБД MongoDB NoSQL и размер в памяти из трех баз данных. Показано также линейной склоне каждого запроса.
| Существует | 5000 документов | 10 000 документов | 20 000 документов | склон (*10exp(-6)) |
| Q1 (s) | 0.6608 | 3.7834 | 7.3022 | 442.76 |
| Q2 (s) | 60.7761 | 129.3645 | 287.362 | 15,105.73 |
| Q3 (s) | 0.6976 | 1,771 | 4.1172 | 227.96 |
| Q4 (s) | 0.6445 | 3.7604 | 7.3216 | 445.17 |
| Q5 (s) | 145.3373 | 291.2502 | 597.7216 | 30,158.93 |
| Q6 (s) | 68.3798 | 138.9987 | 475.2663 | 27,125.82 |
| Размер базы данных | 1,25 ГБ | 2.54GB | 5.12 ГБ | |
| Всего экстракты | 5000 | 10 000 | 20 000 |
Таблица 4: среднее время отклика в секундах шесть запросов на удвоение размера базы данных существуют NoSQL СУБД. Эта таблица была изменена от7 с использованием лицензии Creative Commons (http://creativecommons.org/ licenses/by/4.0/) и показывает, что существуют шесть отклика каждого запроса для трех удвоение размера баз данных, используя NoSQL СУБД и размер в памяти три базы данных. Показано также линейной склоне каждого запроса.
| ARM бумага | РУКА (s) | Путь узла + (s) | |
| Q1 | Запрос 2.1 | 0.191 | 24.866 |
| Q3 | Запрос 3.1 | 0,27 | 294.774 |
| Размер базы данных | 2.90 ГБ | 43.87 ГБ | |
| Всего экстракты | 29,743 | 29,743 |
Таблица 5: среднее время отклика в секундах запросов похож на Q1 и Q3 улучшение реляционных систем, представленных в 10 . Эта таблица была изменена от7 с использованием лицензии Creative Commons (http://creativecommons.org/ licenses/by/4.0/) и показывает два наиболее сходных запросов Q1 и Q3, представлены в10 соответствующих двух систем повышения реляционной базы данных и времени их отклика. Также отображаются размеры двух баз данных.
| ORM/MySQL | Пропускная способность | Время отклика |
| Q1 (s) | 4,711.60 | 0.0793 |
| Q3 (s) | 4,711.60 | 0.1558 |
| Q4 (s) | 4,711.60 | 0.9674 |
Таблица 6: средняя пропускная способность и время отклика в секундах запросов Q1, Q3 и Q4 ORM MySQL в параллельного выполнения реляционных СУБД. Эта таблица была изменена от7 с использованием лицензии Creative Commons (http://creativecommons.org/ licenses/by/4.0/) и показывает высокая средняя пропускная способность трех запросов одного пациента и их среднего времени отклика в одновременных Выполнение эксперимента с помощью реляционной системы ORM MySQL.
| MongoDB | Пропускная способность | Время отклика |
| Q1 (s) | 178,672.60 | 0.003 |
| Q3 (s) | 178,672.60 | 0,0026 |
| Q4 (s) | 178,672.60 | 0,0034 |
Таблица 7: средняя пропускная способность и время отклика в секундах запросов Q1, Q3 и Q4 MongoDB NoSQL СУБД в параллельного выполнения. Эта таблица была изменена от7 с использованием лицензии Creative Commons (http://creativecommons.org/ licenses/by/4.0/) и показывает высокая средняя пропускная способность трех запросов одного пациента и их среднего времени отклика в одновременных Выполнение эксперимента с использованием системы MongoDB NoSQL.
Дополнительный рисунок 1: скриншот показывает экран программного обеспечения для подключения к MySQL серверу. Пожалуйста, нажмите здесь, чтобы скачать этот показатель.
Дополнительные рис: скриншот показывает интерфейс SQL в MySQL сервер где был написан первый запрос SQL. Пожалуйста, нажмите здесь, чтобы скачать этот показатель.
Дополнительная цифра 3: 2.6 MongoDB localhost сервер запускается в окне DOS системы путем выполнения сервера mongod. Пожалуйста, нажмите здесь, чтобы скачать этот показатель.
Дополнительный рисунок 4: скриншот показывает запрос, написанные в текстовые поля построитель запросов, как показано в шагах 5.7.1 через 5.7.4. Скриншот иллюстрирует шаг 5.7.3. Пожалуйста, нажмите здесь, чтобы скачать этот показатель.
Дополнительная цифра 5: скриншот показывает шаг 5.7.6. Пожалуйста, нажмите здесь, чтобы скачать этот показатель.
Дополнительный рис: скриншот иллюстрирует написания запроса XPath части диалогового окна. Пожалуйста, нажмите здесь, чтобы скачать этот показатель.
Discussion
Этот протокол показывает, что чисто реляционных систем ORM не представляется практичным для одного пациента запросов (Q1, Q3 и Q4), поскольку время отклика медленнее, вероятно из-за большого числа реляционных таблиц, выполнение многих операций дорогих join и из-за система хранения данных используется особый вид базы данных. NoSQL баз данных хранят данные в моде, на основе документа, в то время как реляционные системы используют таблицы на основе моды, который распространяется в каждом документе на протяжении всей базы данных. NoSQL системы показывают линейной склон, с MongoDB, выполняя значительно быстрее, чем существует СУБД. В параллелизма MongoDB также ведет себя гораздо лучше, чем реляционных MySQL ORM7.
Этот протокол представляет неполадок протокола для получения результатов, представленных в7 относительно СУБД MySQL ORM. Система MySQL был обновлен до последней версии, и результаты были слегка изменены. Кроме того критической точки в документе NoSQL системах таких как MongoDB является, что они могут сохранить согласованность при хранении медицинской информации7 , потому что когда Выдержка EHR обновляется, он не перезаписывается, но целый новый экстракт с новыми данными генерируется и хранится в системе, и сохраняется оригинальный экстракт. Это строгое требование медицинской информации, потому что некоторые врачи сделали важные медицинские решения, основанные на исходных данных.
Улучшенная система реляционной РУКУ резко уменьшается число реляционных таблиц и улучшает производительность реляционного. Однако поскольку она изменяет реляционной схемы, медицинской информации, хранящейся в экстракты могут быть запрошены, но выдержки не могут быть восстановлены в их точное оригинальные формы.
Для очень больших баз данных вторичного использования (исследования), не ясно, какая система базы данных более подходящим, поскольку все пациент запросов (Q2 и Q5) себя лучше в ORM, чем в системах NoSQL, но эти системы работают лучше, чем упрощенной реляционных системы в 12. Мы считаем Q6, специальных запросов между клинической практики и вторичного использования, поведение которых не может определяться результаты принесли эти эксперименты.
Однако одно ограничение метода является отсутствие прямых экспериментов, сравнивая усовершенствованной системы реляционных РУКУ с NoSQL MongoDB относительно одного пациента, медицинской практике запросы с точно те же данные, используемые в протоколе. Мы поддерживали результатов интерполяции таблицы 3 и Таблица 5 относительно одним пациентом запросы до тех пор, пока был проведен эксперимент, включая оптимизированные РУКУ в протоколе. Мы оставим эти эксперименты для будущих приложений. Один важный шаг в рамках протокола является выбор бесплатные базы данных, аналогичные версии программного обеспечения в последние годы, так что мы может сравнить точное состояние о--искусство трех технологий.
Это одна из первых попыток непосредственно сравнить реляционных и NoSQL систем с использованием фактических, реалистичные, стандартизированные медицинской информации. Однако системе определенных использоваться зависит гораздо фактический сценарий и проблема быть выполнено8.
Disclosures
Авторы не имеют ничего сообщать. Наборы данных, используемые в этих экспериментов были предоставлены несколько испанских больницах под лицензией для этих экспериментов и поэтому не являются общедоступными. ISO/EN 13606 RM XML-схема была представлена центром Университета Колледж Лондон для здравоохранения информатики и Multiprofessional образования (звон).
Acknowledgments
Авторы хотели бы поблагодарить д-ра Dipak Калра, руководитель Целевой группы EHRCom, которая определена ISO/EN 13606 стандарта и его команда из университетского колледжа Лондона за их любезное разрешение использовать ISO/EN 13606 схемы W3C XML.
Эта работа была поддержана Институту Salud Карлоса III [номера грантов PI15/00321, PI15/00003, PI1500831, PI15CIII/00010 и RD16CIII].
Materials
| Name | Company | Catalog Number | Comments |
| MySQL 5.7.20 | MySQL experiments | ||
| Red Hat Enterprise Linux Server release 7.4 (Maipo), 2.60GHz, RAM 16GB | |||
| MongoDB 2.6 | MongoDB experiments | ||
| Windows 7, 2.66GHz, RAM 12GB | |||
| eXist 3.0RC1 | eXist experiments | ||
| Windows 7, 2.66GHz, RAM 12GB | |||
| Studio 3T 5.5.1 | 3T Software Labs Gmbh | MongoDB GUI |
References
- Codd, E. F. A relational model for large shared data banks. Comm ACM. 13 (6), 377-387 (1970).
- Kalra, D., Lloyd, D. ISO 13606 electronic health record communication part 1: reference model. , ISO. Geneva. ISO 13606-1 (2008).
- Kalra, D., et al. Electronic health record communication part 2: archetype interchange specification. , ISO. Geneva. ISO 13606-2 (2008).
- Kalra, D., Beale, T., Heard, S. The openEHR foundation. Stud. Health Technol. Inform. 115, 153-173 (2005).
- Health Level seven. Health Level Seven International. , Available from: http://www.hl7.org (2017).
- Beale, T. Archetypes: constraint-based domain models for future proof information systems. OOPSLA, Workshop Behav Semant. , (2002).
- Sánchez-de-Madariaga, R., et al. Examining database persistence of ISO/EN 13606 standardized electronic health record extracts: relational vs. NoSQL approaches. BMC Medical Informatics and Decision Making. 32 (2), 493-503 (2017).
- Ireland, C., Bowers, D., Newton, M., Waugh, K. Understanding object-relational mapping: a framework based approach. Int. J. Adv. Softw. 2, 202-216 (2009).
- Node+Path Persistence. , Available from: https://openehr.atlassian.net/wiki/spaces/dev/pages/6553626/Node+Path+Persistence (2017).
- Wang, L., Min, L., Wang, R., et al. Archetype relational mapping - a practical openEHR persistence solution. BMC Medical Informatics and Decision Making. 15, 88 (2015).
- Kaur, K., Rani, R. Managing data in healthcare information systems: many models, one solution. Computer. March. , 52-59 (2015).
- Sabo, C., Pop, P. C., Valean, H., Danciulescu, D. An innovative approach to manage heterogeneous information using relational database systems. Advances in Intelligent Systems and Computing. 557, Springer. (2017).
