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
1. construire un SGBD relationnel de MySQL pour stocker trois Double taille DSE normalisés extraits de bases de données
- Importer le W3C (World Wide Web Consortium) XML Schema correspondant à la RM ISO/EN13606 et les types de données ISO21090 dans un «Java IDE» (Integrated Development Environment).
Remarque : ISO signifie International Standards Organization. FR est synonyme de norme européenne. - Exécuter le JAXB (Java XML Binding) plug-in dans l’IDE ; Cela provoque des classes Java correspondant à la structure des éléments des DSE extraits des fichiers XML.
- Étiqueter manuellement les classes Java produites avec des étiquettes JPA. Ces étiquettes consulter les cardinalités et autres relations entre les tables relationnelles de la base de données MySQL.
- Importer des bibliothèques de la JPA (Java Persistence API) dans l’IDE et exécute la méthode qui génère une base de données MySQL sur les classes Java étiquetés.
- Créez trois répertoires avec 5 000, 10 000 et 20 000 extraits de DSE réalistes des fichiers XML.
- Exécutez la méthode App pour charger un extrait XML dans le DBMS MySQL sur tous les extraits du répertoire 5 000 extraits.
- Répétez l’étape 1.6 deux fois, une fois avec le répertoire de 10 000 extraits et une fois avec le répertoire de 20 000 extraits.
2. construire un SGBD NoSQL MongoDB pour stocker trois Double taille DSE normalisés extraits de bases de données
- Processus de chacun des trois répertoires contenant 5 000, 10 000 et 20 000 fichiers XML des extraits de la DSE réalistes avec un programme standard pour convertir les fichiers XML des fichiers JSON, comme json.org.XML. Trois répertoires avec 5 000, 10 000 et 20 000 fichiers JSON doivent être produites.
- Lancer un MongoDB GUI (Graphic User Interface, voir la Table des matières).
- Lancer le MongoDB 2.6 serveur exécutant le programme mongod depuis une fenêtre DOS (Disk Operating System) du système.
- Connecter le GUI MongoDB au serveur localhost en utilisant le port 27017.
- Sélectionnez le menu «Connect».
- Écrire un nom pour la connexion (par exemple le « premier »).
- Écrire localhost:27017 dans la zone de texte serveur de DB.
- Appuyez sur le bouton «Connect» ; un arbre avec les bases de données actuelles doit apparaître sur la gauche.
- Construire une base de données contenant des DSE normalisée 5 000 extraits.
- Cliquez sur le nom de la connexion en haut de l’arborescence sur la gauche.
- Sélectionnez le menu «fichier».
- Choisissez «Ajouter la base de données».
- Entrez le nom de la base de données dans la boîte de dialogue qui s’affiche.
- Cliquez sur OK.
- Construire une collection contenant 5 000 DSE normalisé des extraits.
- Cliquez sur le nom de la base de données dans l’arborescence sur la gauche.
- Sélectionnez le menu «base de données».
- Choisir «AddCollection».
- Entrez le nom de la collection dans la boîte de dialogue qui s’affiche.
- Cliquez sur « créer».
- Cliquez sur le nom de la collection.
- Sélectionnez le menu «Import».
- Choisissez le bouton radio ''JSON - coquille mongo / / mongoexport ».
- Cliquez sur «suivant».
- Appuyez sur le bouton «Ajouter des fichiers de Source».
- Naviguer sur l’ordinateur à l’aide de la boîte de dialogue.
- Ouvrir le répertoire contenant 5 000 JSON extraire les fichiers.
- Sélectionnez tous les fichiers dans le répertoire.
- Appuyez sur «ouvrir». La liste des fichiers JSON doit apparaître dans la boîte de dialogue Importer.
- Appuyez sur «suivant» ; un aperçu de la nouvelle collection dans la base de données apparaît sur la gauche.
- Appuyez sur «suivant».
- Appuyez sur «Start Import». L’état d’avancement de l’importation s’affiche vers le bas sur la gauche, indiquant le nombre de fichiers importés et le temps écoulé.
- Répétez les étapes 5 et 6 à constituer une collection de 10 000 DSE normalisé des extraits.
- Répétez les étapes 5 et 6 à constituer une collection de 20 000 DSE normalisé des extraits.
3. construire un NoSQL existent SGBD pour magasin trois Double taille normalisée DSE extraits de bases de données
- Lancer la base de données existe .
- Icône de la base de données, ouvrez le Client d’administration de Java.
- Entrez le mot de passe admin.
- Appuyez sur le bouton «Connect».
- Construire une collection contenant 5 000 DSE normalisé des extraits.
- Dans la barre d’outils, sélectionnez le menu «créer une nouvelle Collection».
- Dans la boîte de dialogue qui s’affiche, tapez le nom de la nouvelle collection.
- Cliquez sur «accepter» ; la nouvelle collection s’affiche.
- Sélectionnez le nom de la collection.
- Dans la barre d’outils, sélectionnez le menu «stocker des fichiers dans la base de données».
- Naviguer sur l’ordinateur à l’aide de la boîte de dialogue.
- Sélectionnez le répertoire contenant 5 000 fichiers d’extrait XML normalisés.
- Cliquez sur le bouton «Sélectionner les fichiers ou répertoires pour stocker». Notez qu’une boîte de dialogue apparaît affichant la progression, les fichiers sont stockés et le pourcentage de la base de données créée.
- Répétez l’étape 5 pour construire une collection contenant 10 000 DSE normalisé des extraits.
- Répétez l’étape 5 pour construire une collection contenant les DSE standardisé 20 000 extraits.
4. concevoir et exécuter dans les bases de données relationnelles MySQL 3 6 requêtes de complexité croissante
- Concevoir six requêtes de complexité croissante selon les archétypes utilisés par les extraits de DSE.
- Programmer un script SQL avec la première requête sur la base de données MySQL. Le SQL doit s’adapter à la structure particulière de la base de données MySQL en raison de la normalisation des extraits (archétypes). La base de données mappe l’ensemble de la structure des extraits. En conséquence, la requête SQL est assez complexe.
- Identifier les attributs des bases de données seraient d’accélérer le temps de réponse des requêtes si un index a été construit sur eux, puis construisez ces indices, bien que la plupart des indices sont générés automatiquement par le SGBD.
- Si une requête a besoin d’un index non-automatiquement construit, générer manuellement.
- Se connecter au serveur MySQL (supplémentaire Figure 1).
- Sélectionnez et cliquez sur le nom de base de données sur la gauche.
- Sélectionnez et cliquez sur la table relationnelle où réside le champ indexé.
- Cliquez sur l’onglet «Structure».
- Sélectionnez et cliquez sur la colonne où l’index sera construit.
- Cliquez sur «index». Notez que la phrase SQL construire l’index s’affiche et un message indiquant que la phrase a été construite avec succès apparaît.
- Exécutez la première requête.
- Sélectionnez et cliquez sur le nom de base de données sur la gauche.
- Cliquez sur l’onglet «SQL».
- Écrire ou coller le code SQL de la première requête (voir supplémentaires Figure 2).
- Appuyez sur «Continuer». Notez que le premier écran de la liste des résultats apparaît, ainsi qu’un message avec la durée d’exécution de la requête.
- Répéter l’exécution 5 fois et calculer le temps moyen de réponse.
- Répétez l’étape 5 avec requêtes 2 à 6.
- Voir l’ensemble du processus trois fois, avec les bases de données de 5 000, 10 000 et 20 000 extraits.
5. concevoir et exécuter dans les bases de données NoSQL MongoDB 3 6 requêtes de complexité croissante
- Lancer l’interface graphique de MongoDB (voir Table des matières).
- Lancer le serveur MongoDB 2.6 l’exécution du programme de mongod depuis une fenêtre du système DOS (voir supplémentaire Figure 3).
- Suivez l’étape 2.4 pour connecter l’interface graphique de MongoDB au serveur localhost via port 27017.
- Sélectionnez et développez la base de données MongoDB sur le côté gauche.
- Sélectionnez la collection.
- Cliquez sur le menu «Collection» dans la barre d’outils.
- Exécutez la première requête de MongoDB.
- Double-cliquez sur le bouton «Requêteur».
- Double-cliquez sur le «champ de requête» du générateur de requêtes à la droite.
- Écrire le champ de la requête de MongoDB dans le champ zone de texte du panneau requête (voir supplémentaires Figure 4).
- Écrire la valeur de la requête de MongoDB dans la zone de texte valeur du panneau requête.
Remarque : Cette requête devrait être quelque chose comme {ns3:EHRExtract.allCompositions.content.items.parts.parts.name.ns2:originalText «. valeur » : « Descripcion »}. Le champ et la valeur sont cités et séparées par un point-virgule. - Double-cliquez sur le champ de Projection du générateur de requêtes
- Écrire la première projection dans la zone de texte de projection (voir supplémentaire Figure 5).
- Double-cliquez sur le champ de projection pour ajouter un nouveau textbox de projection.
- Écrire la deuxième projection dans la zone de texte de projection.
Remarque : Une projection permet de sélectionner une partie du document récupéré par la requête. Ceux-ci devraient être quelque chose comme {ns3:EHRExtract «. allCompositions.content.items.parts.parts.value.value » : 1} et {"ns3 : EHRExtract.all Compositions.content.items.parts.parts.value.nullFlavor » : 1} - Cliquez sur le bouton play bleu pour exécuter la requête.
- Visualiser le code de requête dans l’onglet Code de requête.
- Afficher les détails du résultat dans l’onglet expliquer : nombre de résultats, temps d’exécution en millisecondes.
- Découvre, développez, puis examinez les résultats dans l’onglet résultats.
- Si un traitement supplémentaire de la requête est requis, écrire un programme Java avec le driver MongoDB Java avec la requête et une méthode pour traiter les résultats.
- Répéter l’exécution 5 fois et calculer le temps moyen de réponse.
- Faire étape 5,7 pour les 2 autres par le biais de 6 requêtes.
- Répéter l’ensemble du processus dans les 5 000, 10 000 et 20 000 extraits de bases de données MongoDB.
6. concevoir et exécuter en 3 NoSQL existent des requêtes de bases de données 6 augmentations-complexité
- Lancer existent SGBD.
- Ouvrez le Client d’administration de Java.
- Appuyez sur le bouton «se connecter à la base de données».
- Sélectionnez la base de données et cliquez dessus.
- Cliquez sur le menu «consulter la base de données à l’aide de XPath» ; la boîte de dialogue consulter s’affiche.
- Exécution de la première requête XPath (voir supplémentaires Figure 6).
- Écrire ou coller le code XPath de la première requête dans la partie supérieure de la boîte de dialogue.
- Cliquez sur le menu «exécuter» dans la barre d’outils de la boîte de dialogue.
- Afficher les résultats XML à l’aide de l’onglet «XML» dans la partie inférieure de la boîte de dialogue.
- Afficher le nombre de résultats et de compilation et d’exécution au bas de la boîte de dialogue.
- Répéter l’exécution 5 fois et calculer le temps moyen de réponse.
- Répétez l’étape 6 pour les requêtes de 2 à 6.
- Faire le processus entier trois fois, pour les 5 000, 10 000 et 20 000 extraits existent des bases de données.
7. concevoir et exécuter une expérience d’accès concurrentiel en utilisant le MySQL et MongoDB 5 000 extraits de bases de données
Remarque : La base de données eXist a été retiré de l’expérience à ce stade en raison de la pire performance dans les expériences précédentes.
- Sélectionnez les requêtes avec les trois réponses de temps plus courtes dans les expériences précédentes en utilisant les bases de données de 5 000 extraits (généralement sous plusieurs secondes).
- Identifier et construire manuellement des index de l’attribut approprié pour ces requêtes, si nécessaire.
- Programmer des applications multithreads Java deux, un pour MySQL et l’autre pour MongoDB ; chaque application aura trois threads de priorité différents, un pour chaque requête sélectionnée à l’étape 1.
- Exécuter et calculer la CPU (unité centrale de traitement) utiliser la distribution pour chaque thread (requête).
- Exécuter chaque application multithread, en cliquant sur le bouton Exécuter cinq fois au cours de chaque travée de 10 min et calculer la plus exécutée (priorité) interroger un débit moyen et la moyenne de temps de réponse des trois requêtes.
- Afficher les requêtes dans l’exécution, aux priorités et temps d’exécution.
- Calculer le débit moyen et le temps de réponse moyen de chacune des trois requêtes.
Representative Results
Six différentes requêtes effectuées sur réalistes extraits standardisés de DSE contenant des informations sur les problèmes des patients, y compris leur nom, la date initiale et finale et la gravité, sont indiquées dans le tableau 1.
Temps de réponse moyen des six requêtes dans les trois bases de doubler de taille dans chaque SGBD sont indiquées dans les tableaux 2-4. Les figures 1 à 6 montrent les mêmes résultats sous forme graphique (Remarquez que les axes verticaux utilisent des échelles très différentes tout au long de ces chiffres).
Le comportement linéaire fort de complexité algorithmique est évident tout au long de toutes les requêtes des bases de données NoSQL, mais avec la mise en garde appropriée en raison de la taille relativement petite des 3 ensembles de données utilisés. Toutefois, la base de données relationnelle de l’ORM montre un comportement linéaire peu clair. La base de données MongoDB a une pente beaucoup plus plate que la base de données eXist.
On trouvera dans le tableau 5résultats par l’amélioration des systèmes relationnels discutés dans l’introduction, publiée dans la littérature. MongoDB résultats du tableau 3 avec des requêtes semblables et les tailles de base de données des résultats de bras du tableau 5 en interpolant équivaut à deux systèmes de base de données au 1er trimestre, mais favorise MongoDB en Q3.
On trouvera dans le tableau 5 et le tableau6, les résultats des expériences d’accès concurrentiel. MongoDB bat MySQL les deux au rythme de débit et de la réponse. En fait, MongoDB se comporte mieux dans la concurrence qu’en vase clos et se présente comme une base de données impressionnante dans une exécution simultanée.
Figure 1 : Complexité algorithmique des ORM MySQL, MongoDB, et il existe des SGBD pour les requêtes T1 et T4. Ce chiffre de7 à l’aide de la licence Creative Commons (http://creativecommons.org/ licenses/by/4.0/) a été modifié et montre des temps de réponse en quelques secondes pour 5 000, 10 000 et 20 000 entreprises DSE extraits de bases de données pour chaque SGBD et requêtes T1 et T4. S’il vous plaît cliquez ici pour visionner une version agrandie de cette figure.
Figure 2 : Complexité algorithmique du SGBD MySQL ORM pour requête Q2. Cette figure montre des temps de réponse en quelques secondes pour 5 000, 10 000 et 20 000 entreprises DSE extraits ORM MySQL base de données de requête Q2. S’il vous plaît cliquez ici pour visionner une version agrandie de cette figure.
Figure 3 : Complexité algorithmique de MongoDB et il existe des SGBD pour les requêtes Q2 et Q5. Ce chiffre a été modifié par7 à l’aide de la licence Creative Commons (http://creativecommons.org/licenses/ par / 4,0) et indique les temps de réponse en secondes pour 5 000, DSE 10 000 et 20 000 taille extraits de bases de données pour chaque SGBD et requêtes Q2 et Q5. S’il vous plaît cliquez ici pour visionner une version agrandie de cette figure.
Figure 4 : Complexité algorithmique du SGBD MySQL ORM pour les requêtes Q3 et Q5. Montre des temps de réponse en quelques secondes pour 5 000, 10 000 et 20 000 entreprises DSE extraits de bases de données pour chaque SGBD et requêtes Q3 et Q5. S’il vous plaît cliquez ici pour visionner une version agrandie de cette figure.
Figure 5: complexité algorithmique d’eXist et MongoDB DBMS pour requête Q3. Ce chiffre de7 à l’aide de la licence Creative Commons (http://creativecommons.org/licenses//4.0 /) a été modifié et indique le temps de réponse en secondes pour 5 000, que DSE 10 000 et 20 000 entreprises extraits de bases de données pour chaque requête Q3 et SGBD. S’il vous plaît cliquez ici pour visionner une version agrandie de cette figure.
Figure 6 : Complexité algorithmique de MySQL ORM, existent et MongoDB DBMS pour interroger Q6. Ce chiffre de7 à l’aide de la licence Creative Commons (http://creativecommons.org/licenses//4.0 /) a été modifié et indique le temps de réponse en secondes pour 5 000, que DSE 10 000 et 20 000 entreprises extraits de bases de données pour chaque requête Q6 et SGBD. S’il vous plaît cliquez ici pour visionner une version agrandie de cette figure.
| Requête | |
| 1ER TRIMESTRE | Trouver tous les problèmes d’un seul patient |
| Q2 | Trouver tous les problèmes de tous les patients |
| Q3 | Trouver la date initiale, date de la résolution et la gravité |
| d’un seul problème d’un seul patient | |
| Q4 | Trouver la date initiale, date de la résolution et la gravité |
| de tous les problèmes de problème d’un seul patient | |
| Q5 | Trouver la date initiale, date de la résolution et la gravité |
| de tous les problèmes problème de tous les patients | |
| Q6 | Trouver tous les patients avec pharyngite « problème » |
| première date > = 16 octobre 2007 ", date de la résolution | |
| < = 5 juin 2008 "et la gravité « élevée » |
Tableau 1 : les six requêtes effectuées sur le relationnel et bases de données NoSQL DSE normalisé contenant des extraits sur les problèmes des patients. Ce tableau a été modifié par7 à l’aide de la licence Creative Commons (http://creativecommons.org/ licenses/by/4.0/) et montre les six requêtes de complexité de plus en plus effectuées sur les trois bases de données en croissance taille pour chaque SGBD exprimée en naturel langue.
| ORM/MySQL | 5000 docs | 10 000 documents | 20 000 documents |
| Q1 (s) | 25.0474 | 32.6868 | 170.7342 |
| T2 (s) | 0.0158 | 0,0147 | 0,0222 |
| 3ème trimestre (s) | 3.3849 | 6.4225 | 207.2348 |
| 4e trimestre (s) | 33.5457 | 114.6607 | 115.4169 |
| Q5 (s) | 9.6393 | 74.3767 | 29.0993 |
| Q6 (s) | 1.4382 | 2.4844 | 183.4979 |
| Taille de la base de données | 4.6 GO | 9.4 GO | 19.4 GB |
| Extraits totaux | 5000 | 10 000 | 20 000 |
Tableau 2 : moyenne des temps de réponse en quelques secondes des six requêtes sur bases de données doublement-taille du SGBD relationnel ORM MySQL. Ce tableau montre six temps de réponse pour chaque requête pour les trois taille doublement bases de données à l’aide du SGBD relationnel ORM MySQL et la taille en mémoire des trois bases de données.
| MongoDB | 5000 docs | 10 000 documents | 20 000 documents | pente (*10exp(-6)) |
| Q1 (s) | 0,046 | 0,057 | 0.1221 | 5.07 |
| T2 (s) | 34.5181 | 68.6945 | 136.2329 | 6,780.99 |
| 3ème trimestre (s) | 0,048 | 0,058 | 0.1201 | 4.81 |
| 4e trimestre (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 |
| Taille de la base de données | 1,95 GO | 3,95 GO | 7,95 GO | |
| Extraits totaux | 5000 | 10 000 | 20 000 |
Tableau 3 : moyenne des temps de réponse en quelques secondes des six requêtes sur bases de données doublement-taille du SGBD NoSQL MongoDB. Ce tableau a été modifié par7 à l’aide de la licence Creative Commons (http://creativecommons.org/ licenses/by/4.0/) et indique les temps de six réponse de chaque requête pour les trois taille doublement bases de données en utilisant le NoSQL MongoDB SGBD et la taille en mémoire les trois bases de données. On montre aussi la pente linéaire de chaque requête.
| Il existe | 5000 docs | 10 000 documents | 20 000 documents | pente (*10exp(-6)) |
| Q1 (s) | 0.6608 | 3.7834 | 7.3022 | 442.76 |
| T2 (s) | 60.7761 | 129.3645 | 287.362 | 15,105.73 |
| 3ème trimestre (s) | 0.6976 | 1,771 | 4.1172 | 227.96 |
| 4e trimestre (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 |
| Taille de la base de données | 1,25 GO | 2,54 GB | 5,12 GO | |
| Extraits totaux | 5000 | 10 000 | 20 000 |
Tableau 4 : moyenne des temps de réponse en quelques secondes des six requêtes sur bases de données doublement-taille de l’exister NoSQL DBMS. Ce tableau a été modifié par7 à l’aide de la licence Creative Commons (http://creativecommons.org/ licenses/by/4.0/) et indique les temps de six réponse de chaque requête pour les trois taille doublement bases de données en utilisant le NoSQL existent SGBD et la taille en mémoire de les trois bases de données. On montre aussi la pente linéaire de chaque requête.
| Papier de bras | BRAS (s) | Noeud + chemin (s) | |
| 1ER TRIMESTRE | Requête 2.1 | 0,191 | 24.866 |
| Q3 | Query 3.1 | 0,27 | 294.774 |
| Taille de la base de données | 2,90 GB | 43,87 GB | |
| Extraits totaux | 29 743 | 29 743 |
Tableau 5 : moyenne des temps de réponse en quelques secondes des requêtes semblables à Q1 et Q3 de l’amélioration des systèmes relationnels présenté dans 10 . Ce tableau a été modifié par7 à l’aide de la licence Creative Commons (http://creativecommons.org/ licenses/by/4.0/) et montre les deux requêtes similaires plus Q1 et Q3 présenté en10 correspondant à deux systèmes améliorés de base de données relationnelle et leurs temps de réponse. Les tailles de base de deux données sont également indiqués.
| ORM/MySQL | Débit | Temps de réponse |
| Q1 (s) | 4,711.60 | 0.0793 |
| 3ème trimestre (s) | 4,711.60 | 0.1558 |
| 4e trimestre (s) | 4,711.60 | 0.9674 |
Tableau 6 : temps de débit et de la réponse en quelques secondes des requêtes Q1, Q3 et Q4 d’ORM MySQL SGBD relationnel dans une exécution simultanée moyen. Ce tableau a été modifié par7 à l’aide de la licence Creative Commons (http://creativecommons.org/ licenses/by/4.0/) et présente le plus haut débit moyen des trois requêtes individuelles et leur temps de réponse moyen dans le simultané expérience de l’exécution en utilisant le système relationnel ORM MySQL.
| MongoDB | Débit | Temps de réponse |
| Q1 (s) | 178,672.60 | 0,003 |
| 3ème trimestre (s) | 178,672.60 | 0,0026 |
| 4e trimestre (s) | 178,672.60 | 0,0034 |
Tableau 7 : temps de débit et de la réponse en quelques secondes des requêtes Q1, Q3 et Q4 de MongoDB NoSQL DBMS en exécution simultanée moyen. Ce tableau a été modifié par7 à l’aide de la licence Creative Commons (http://creativecommons.org/ licenses/by/4.0/) et présente le plus haut débit moyen des trois requêtes individuelles et leur temps de réponse moyen dans le simultané expérience de l’exécution en utilisant le système de MongoDB NoSQL.
Supplémentaire Figure 1 : la capture d’écran montre l’écran du logiciel pour se connecter au serveur MySQL. S’il vous plaît cliquez ici pour télécharger ce chiffre.
Supplémentaire Figure 2 : la capture d’écran montre l’interface SQL au serveur MySQL où la première requête SQL a été écrit. S’il vous plaît cliquez ici pour télécharger ce chiffre.
Supplémentaire Figure 3 : The MongoDB 2.6 du serveur localhost est lancé à l’aide d’une fenêtre du système DOS en exécutant le serveur mongod. S’il vous plaît cliquez ici pour télécharger ce chiffre.
Supplémentaire Figure 4 : la capture d’écran montre la requête écrite dans les zones de texte du générateur de requêtes, comme illustré dans les étapes 5.7.1 par 5.7.4. La capture d’écran illustre étape 5.7.3. S’il vous plaît cliquez ici pour télécharger ce chiffre.
Supplémentaire Figure 5 : la capture d’écran montre l’étape 5.7.6. S’il vous plaît cliquez ici pour télécharger ce chiffre.
Supplémentaires Figure 6 : la capture d’écran illustre l’écriture de la requête XPath dans la partie supérieur de la boîte de dialogue. S’il vous plaît cliquez ici pour télécharger ce chiffre.
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
Les auteurs n’ont rien à divulguer. Les ensembles de données utilisés dans ces expériences ont été fournis par plusieurs hôpitaux espagnols sous licence pour ces expériences et par conséquent ne sont pas accessibles au public. Le schéma XML de RM EN/ISO 13606 était prévu par l’University College London Centre informatique de santé & éducation multi-disciplinaire (carillon).
Acknowledgments
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
| 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).
