L’exécution des requêtes de complexité croissante en relationnelle (MySQL) et NoSQL (MongoDB et existent) taille-de plus en plus les bases de données de 13606 DSE normalisé ISO/fr
Summary
Cette étude compare relationnelles et non relationnelles (NoSQL) normalisé des systèmes d’information médicale. La complexité du calcul des temps de réponse de l’interrogation de ces systèmes de gestion de base de données (SGBD) est calculée à l’aide de doubler de taille des bases de données. Ces résultats à l’examen de la pertinence de chaque approche de base de données à différents scénarios et problèmes.
Abstract
Cette recherche montre un protocole pour évaluer la complexité du calcul des requêtes relationnelle et non relationnelles (NoSQL (non seulement Structured Query Language)) standardisé des systèmes de bases de données information médicale santé électronique (DSE) compte rendu (SGBD). Il utilise un ensemble de trois taille doublement de bases de données, c’est-à-dire les bases de données stockant les 5000, 10 000 et 20 000 réaliste normalisés DSE extraits, dans trois systèmes de gestion de base de données différente (SGBD) : relationnel MySQL mapping objet-relationnel (ORM), basés sur des documents NoSQL MongoDB et langage de balisage extensible native NoSQL (XML) existent.
On a calculé les temps de réponse moyen aux six questions de complexité croissante, et les résultats ont montré un comportement linéaire dans les cas de NoSQL. Dans le domaine de NoSQL, MongoDB présente une pente linéaire beaucoup plus plate qu’eXist.
Les systèmes NoSQL peuvent également être préférable de maintenir des systèmes d’information médicale normalisée en raison de la nature particulière de la politique mise à jour des informations médicales, qui ne devrait pas affecter la cohérence et l’efficacité des données stockées dans les bases de données NoSQL.
Une des limites du présent protocole sont le manque de résultats directs de l’amélioration des systèmes relationnels tels que mappage relationnel d’archétype (ARM) avec les mêmes données. Toutefois, l’interpolation des résultats doublement de taille de base de données à celles présentées dans la littérature et autres résultats publiés suggère que les systèmes NoSQL pourraient être plus appropriés dans de nombreux scénarios spécifiques et les problèmes à résoudre. Par exemple, NoSQL peut convenir pour des tâches basées sur des documents tels que des extraits de DSE utilisés en pratique clinique, édition et visualisation ou des situations où le but est non seulement pour demander des informations médicales, mais aussi de rétablir le DSE exactement sa forme originale.
Introduction
NoSQL (non seulement SQL) SGBD ont récemment émergé comme alternative aux SGBD relationnels traditionnels (RDMBS). SGBDR ont dominé la façon dont les données étaient stockées dans les systèmes de base de données depuis des décennies. Calcul et algèbre relationnelle bien étudié et compris ont garanti l’efficacité et la cohérence des SGBDR1. Systèmes NoSQL ne deviendra pas de substituts aux systèmes relationnels, mais ils pourraient se comporter avantageusement dans certains scénarios et dans diverses conditions.
Certains de ces scénarios particuliers se produirait lors de la conception de la persistance de la base de données des systèmes de dossier de santé électronique (DSE) utilisé pour gérer et stocker des informations médicales. Pour être interopérable et durable dans la pratique, plusieurs normes internationales comme ISO/EN 13606, openEHR et HL72,3,4,,,5 ont servi à normaliser DSE extraits.
Plusieurs normes comme ISO/EN 13606 et openEHR ont séparées information et au savoir dans deux différents niveaux d’abstraction, représentée par le modèle de référence (RM) et de structures de données spéciales appelées archétypes. Cette séparation est souvent appelée le modèle double et il permet à des systèmes de DSE connaissance sémantiquement interopérables et médical d’évoluer sans reprogrammer le système de DSE entier et, par conséquent, pour être plus facile à maintenir et durable dans la pratique6 . Toutefois, le modèle double, mis en œuvre dans les systèmes de DSE normalisés exige que l’organisation de l’information suit une structure spécifique, et cela a des conséquences profondes dans la façon dont le niveau de base de données de persistance du système est conçu7.
Object Relational Mapping (ORM)8 est une méthodologie pour mettre en œuvre un système de DSE en utilisant le paradigme de base de données relationnelle. ORM cartes exhaustivement la structure de fichiers normalisés DSE extraits XML (eXtensible Markup Language) utilisé par le système pour une base de données relationnelle. ORM construit plusieurs tables relationnelles exhaustivement suivant la structure des fichiers XML extraits normalisés EHR. Ces tables relationnelles sont liées par plusieurs clés étrangères, et le système qui en résulte n’est peut-être pas très efficace.
Plusieurs améliorations relationnelles ORM ont été proposées. chemin d’accès + nœud9 d’openEHR réduit le nombre de tables relationnelles par sérialisation sous-arborescences de l’extrait de tout fichier XML dans des objets BLOB (objets volumineux binaires). Toutefois, cette simplification provoque une logique complexe d’extraction, endommageant des requêtes complexes. Archétype Mapping relationnel (ARM)10 génère un modèle de base de données pilotée par des archétypes, construction d’un nouveau schéma relationnel issu des mappages entre les archétypes et tables relationnelles. Par conséquent, certaines informations non médicales de l’extrait de DSE est perdue.
Plusieurs bases de données NoSQL basés sur des documents stockent des documents entiers comme toute BLOBs respectant un original XML ou JSON (JavaScript Object Notation) format. Cela signifie qu’aucune des tables relationnelles ne sont construits. Ces bases de données NoSQL n’ont aucun schéma et ils ne supportent pas soit les jointures ou (acide) propriétés11, c’est-à-dire, atomicité, cohérence, isolement ou durabilité. Ainsi, ils peuvent être très inefficaces, si un élément d’un document fait référence à des éléments de la même ou d’autres documents utilisant un lien d’indirection. Cela arrive parce que, pour assurer la cohérence, l’intégralité des documents référencés doivent être traitées de façon séquentielle. Cependant, une base de données non relationnelles peut être encore approprié si la principale tâche exécutée par le SGBD est une tâche basée sur des documents. C’est parce que les données peuvent demeurer sous une forme plus rapprocher étroitement sa représentation fidèle à l’aide d’une base NoSQL basés sur des documents, mais c’est aussi grâce à la politique de persistance spécial réalisée par documents médicaux EHR (voir la section « discussion »).
Le but de ces méthodes est de présenter plusieurs expériences pour comparer la mise en œuvre de la couche de persistance d’un système de DSE normalisé à l’aide de trois différents SGBD : un relationnelle (MySQL) et deux NoSQL (basés sur des documents MongoDB et native XML existent). Leur théorie de la complexité a été calculée et comparée à l’aide de trois bases différentes de taille croissante et six différentes requêtes de complexité croissante. Les trois serveurs ont été installés et configurés localement sur le même ordinateur où les requêtes ont été exécutées. Voir la Table des matières pour plus de détails techniques.
Simultanéité expériences ont également été effectuées afin de comparer les performances de MySQL et de NoSQL MongoDB SGBD relationnel. Les améliorations décrites de ORM (nœud + chemin d’accès et bras) ont également été comparées en utilisant des résultats pertinents et appropriés de la littérature10.
Systèmes de gestion de bases de données évoluent continuellement à un rythme accéléré. Personne ne songerait à ce développement exponentiel quand le seul paradigme existant était le modèle relationnel. Pour prendre un exemple, voir par exemple12, où il a été proposé un modèle à mettre en œuvre des temps de réponse améliorés bases de données relationnelles conservant les propriétés ACID.
Protocol
Representative Results
Discussion
Ce protocole indique que purs systèmes relationnels de ORM ne semblent pas pratiques pour les requêtes individuelles (Q1, Q3 et Q4) temps de réponse étant plus lents, probablement en raison d’un grand nombre de tables relationnelles, effectuant de nombreuses opérations de jointure coûteuse et due à la système de stockage utilisé par le type spécifique de base de données. Bases de données NoSQL stockent des données dans un mode basés sur des documents, alors que les systèmes relationnels utilisent un mode basée sur une table qui se propage à chaque document tout au long de la base de données entière. NoSQL systèmes montrent une pente linéaire, avec MongoDB exécuter beaucoup plus rapidement qu’il existe des SGBD. En simultanéité, MongoDB se comporte aussi beaucoup mieux que relationnelles MySQL ORM7.
Ce protocole présente un protocole de dépannage pour les résultats présentés dans7 concernant le SGBD MySQL de ORM. Le système de MySQL a été mis à jour vers la dernière version et les résultats ont été légèrement modifiés. En outre, est un point critique dans les systèmes NoSQL document comme MongoDB est qu’ils peuvent conserver la cohérence lorsque stockant des informations médicales7 parce que lorsqu’un extrait de DSE est mis à jour, il n’est pas écrasé, mais un tout nouveau extrait avec les nouvelles données générées et stockées dans le système, et l’extrait original est maintenue. Il s’agit d’une exigence stricte de l’information médicale, parce que certains médecins ont pu importantes décisions médicales basées sur les données d’origine.
Le système de bras relationnel amélioré considérablement diminue le nombre de tables relationnelles et améliore les performances relationnelles. Cependant, puisqu’il modifie le schéma relationnel, medical information détenue par les extraits peut-être être interrogée, mais extraits ne peuvent être récupérés dans leurs formes d’origine exactes.
Pour utilisent de très grandes bases de données dans le secondaire (recherche), on ne sait pas quel système de base de données est plus approprié, étant donné que les requêtes de tous les patients (Q2 et Q5) se comportent mieux dans ORM que dans les systèmes NoSQL, mais ces systèmes obtiennent de meilleurs résultats que le simplifié/relationnel systèmes en 12. Nous considérons Q6 une requête spéciale entre la pratique clinique et secondaire utiliser dont le comportement ne peut être déterminé par les résultats générés par ces expériences.
Cependant, une des limites de la méthode sont l’indisponibilité des expériences directes en comparant le système de bras relationnel amélioré avec NoSQL MongoDB au sujet des requêtes individuelles, médical pratique avec exactement les mêmes données utilisées dans le protocole. Nous avons maintenu les résultats en interpolant tableau 3 et tableau 5 concernant les requêtes individuelles jusqu’à ce que l’expérience y compris bras optimisée dans le protocole a été effectuée. Nous quittons ces expériences pour de futures applications. Une étape critique dans le protocole est le choix de la base de données gratuite, des versions de logiciels similaires de ces dernières années, afin que nous puissions comparer l’exacte-de-pointe des trois technologies suivantes.
C’est une des premières tentatives de comparer directement relationnelles et systèmes NoSQL à l’aide de renseignements médicaux réels, réalistes, standardisés. Toutefois, le système spécifique à utiliser dépend beaucoup sur le scénario réel et le problème d’être résolu8.
Disclosures
The authors have nothing to disclose.
Acknowledgements
Les auteurs tiennent à remercier m. Dipak Kalra, chef de l’Equipe de EHRCom qui a défini le 13606 EN/ISO standard et son équipe de l’University College de Londres pour leur aimable autorisation à utiliser la norme ISO/EN 13606 W3C XML Schema.
Ce travail a été soutenu par l’Instituto de Salud Carlos III [grant Grant numbers IP15/00321, IP15/00003, PI1500831, PI15CIII/00010 et 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).
