Выполнение повышения сложности запросов в реляционных (MySQL) и NoSQL (MongoDB и существуют) растущий размер баз данных ISO/EN 13606 стандартизированных EHR
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
Representative Results
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
The authors have nothing to disclose.
Acknowledgements
Авторы хотели бы поблагодарить д-ра Dipak Калра, руководитель Целевой группы EHRCom, которая определена ISO/EN 13606 стандарта и его команда из университетского колледжа Лондона за их любезное разрешение использовать ISO/EN 13606 схемы W3C XML.
Эта работа была поддержана Институту Salud Карлоса III [номера грантов PI15/00321, PI15/00003, PI1500831, PI15CIII/00010 и RD16CIII].
Materials
| 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. , (2008).
- Kalra, D., et al. . Electronic health record communication part 2: archetype interchange specification. , (2008).
- Kalra, D., Beale, T., Heard, S. The openEHR foundation. Stud. Health Technol. Inform. 115, 153-173 (2005).
- 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, (2017).
