Erhöhung der Komplexität Abfragen in relationalen (MySQL) und NoSQL (MongoDB und existieren) Größe wachsenden ISO/EN 13606 standardisierte EHR Datenbanken

Ricardo Sánchez-de-Madariaga; Adolfo Muñoz; Antonio L Castro; Oscar Moreno; Mario Pascual

doi:10.3791/57439

Method Article

Erhöhung der Komplexität Abfragen in relationalen (MySQL) und NoSQL (MongoDB und existieren) Größe wachsenden ISO/EN 13606 standardisierte EHR Datenbanken

DOI:

10.3791/57439

⸱

March 19th, 2018

Ricardo Sánchez-de-Madariaga¹ , Adolfo Muñoz¹ , Antonio L Castro¹ , Oscar Moreno¹ , Mario Pascual¹

¹Telemedicine and Information Society Department, Health Institute "Carlos III"

Summary

$$\rightleftharpoonup{xx}$$ $$\longleftharp{xx}$$, $$\longrightharp{xx}$$,

Diese Studie vergleicht relationale und nicht relationale (NoSQL) standardisierten medizinischen Informationssystemen. Der Rechenaufwand der Antwortzeiten von Abfragen von solchen Datenbankmanagementsysteme (DBMS) wird anhand der Verdoppelung mittlere Datenbanken berechnet. Diese Ergebnisse helfen, die Diskussion über die Angemessenheit der einzelnen Datenbank-Ansätze für verschiedene Szenarien und Probleme.

Abstract

$$\rightleftharpoonup{xx}$$ $$\longleftharp{xx}$$, $$\longrightharp{xx}$$,

Diese Forschung zeigt ein Protokoll zur Bewertung der Rechenkomplexität Abfragen relationale und nicht relationale (NoSQL (nicht nur Structured Query Language)) standardisierte elektronische Aufzeichnung (EHR) medizinische Informationen Datenbanksysteme (DBMS). Es verwendet einen Satz von drei Verdoppelung große Datenbanken, d.h. Datenbanken speichern von 5000, 10.000 und 20.000 realistische standardisiert EHR Extrakte, in drei verschiedenen Datenbankmanagementsysteme (DBMS): relationale MySQL Objekt-relationale Mapping (ORM) dokumentbasierte NoSQL MongoDB und native extensible Markup Language (XML) NoSQL vorhanden sind.

Die durchschnittlichen Antwortzeiten auf sechs Komplexität steigt Abfragen wurden berechnet, und die Ergebnisse zeigten ein lineares Verhalten in der NoSQL-Fällen. Im Feld NoSQL präsentiert MongoDB eine viel flachere lineare Steigung als eXist.

NoSQL-Systeme möglicherweise auch besser geeignet zu standardisierten medizinischen Informationssystemen aufgrund des besonderen Charakters der Update-Richtlinien von medizinischen Informationen, was die Konsistenz und Effizienz der NoSQL-Datenbanken gespeicherten Daten nicht beeinflussen sollte.

Eine Einschränkung dieses Protokolls ist die fehlende direkte Ergebnisse der verbesserten relationalen Systemen wie Archetyp relational Mapping (ARM) mit den gleichen Daten. Jedoch die Interpolation der Verdoppelung Größe Datenbankergebnisse zu denen in der Literatur vorgestellt und andere veröffentlichten Ergebnisse legt nahe, dass NoSQL-Systeme in vielen Szenarien und zu lösenden Probleme besser geeignet sein könnte. Z. B. NoSQL eignet sich möglicherweise für Dokumenten-basierte Aufgaben wie EHR Extrakte verwendet in klinische Praxis, Ausgabe und Visualisierung oder Situationen, wo das Ziel ist nicht nur, medizinische Abfrageinformationen, sondern auch um die EHR in genau ihrer ursprünglichen Form wiederherzustellen.

Introduction

$$\rightleftharpoonup{xx}$$ $$\longleftharp{xx}$$, $$\longrightharp{xx}$$,

NoSQL (nicht nur SQL) DBMS sind vor kurzem als Alternative zu herkömmlichen relationalen DBMS (RDBMS) entstanden. RDBMS haben die Art und Weise beherrscht seit Jahrzehnten in Datenbanksystemen gespeichert wurden. Gut untersucht und verstanden relationale Algebra und Analysis haben die Effizienz und Konsistenz der RDBMS¹garantiert. NoSQL-Systeme werden nicht Ersatz für relationale Systeme, aber sie könnte vorteilhaft Verhalten in bestimmten Situationen und unter verschiedenen Bedingungen.

Einige dieser bestimmten Szenarien und Bedingungen treten beim Entwerfen der Datenbank-Persistenz von Electronic Health Record (EHR) Systeme zur Verwaltung und Speicherung von medizinischen Informationen. Um interoperable und nachhaltig in der Praxis mehrere internationale Standards wie ISO/EN 13606, OpenEHR und HL7²^,³^,⁴wurden^,⁵ verwendet, um EHR Extrakte zu standardisieren.

Verschiedene Standards wie ISO/EN 13606 und OpenEHR haben Informationen und wissen in zwei verschiedenen Ebenen der Abstraktion, vertreten durch Referenz-Modell (RM) und spezielle Datenstrukturen genannt Archetypengetrennt. Diese Trennung ist oft das duale Modell genannt und EPA-Systemen semantisch interoperabel und medizinischem Wissen ohne Neuprogrammierung des Gesamtsystems EHR und infolgedessen zu entwickeln sein ermöglicht werden, wartbar und nachhaltig in der Praxis⁶. Das duale Modell umgesetzt in standardisierten EPA-Systemen erfordert jedoch, dass die Organisation von Informationen einer bestimmten Struktur folgt, und dies hat tiefgreifende Auswirkungen auf die Weise ist der Datenbankebene Persistenz des Systems gestaltete⁷.

Objekt-relationale Mapping (ORM)-⁸ ist eine Methodik zur Umsetzung eines EPA-Systems mit dem relationalen Datenbank-Paradigma. ORM Karten ausführlich die Struktur der standardisierten EHR Extrakte XML (eXtensible Markup Language) Dateien vom System für eine relationale Datenbank verwendet. ORM baut viele relationale Tabellen umfassend entsprechend der Struktur der standardisierten EHR Auszüge XML-Dateien. Diese relationalen Tabellen sind durch viele Fremdschlüssel verknüpft und das resultierende System möglicherweise nicht sehr effizient.

Mehreren relationalen Verbesserungen in ORM sind vorgeschlagen worden. OpenEHR der Knoten + Pfad⁹ reduziert die Anzahl der relationalen Tabellen von serialisieren Teilstrukturen der Gesamtextrakt XML-Datei in BLOBs (binary Großobjekte). Allerdings verursacht diese Vereinfachung komplexer Abruf Logik, komplexe Abfragen zu beschädigen. Archetyp Relational Mapping (ARM)¹⁰ generiert ein Datenbankmodell angetrieben von Archetypen, Bau eines neuen relationalen Schemas basierend auf Zuordnungen zwischen Archetypen und relationalen Tabellen. Einige der nicht-medizinischen Informationen der EHR-Extrakt deshalb verloren.

Viele dokumentbasierte NoSQL-Datenbanken speichern Sie ganze Dokumente als gesamte BLOBs unter Beachtung einer ursprünglichen XML oder JSON (JavaScript Objekt Notation) Format. Dies bedeutet, dass keine relationalen Tabellen aufgebaut sind. Diese NoSQL-Datenbanken haben kein Schema, und sie unterstützen keine Verknüpfungen oder (Säure) Eigenschaften¹¹, d. h., Unteilbarkeit, Konsistenz, Isolation oder Haltbarkeit. Dadurch können sie sehr ineffizient sein, wenn ein Element eines Dokuments verweist auf Elemente des gleichen oder anderen Schriftstücke unter Verwendung einen Dereferenzierung Link. Dies geschieht, weil, um Konsistenz zu gewährleisten, müssen die Gesamtheit der referenzierten Dokumente sequentiell abgearbeitet werden. Eine nicht-relationale Datenbank kann jedoch noch angemessen, wenn die Hauptaufgabe, durchgeführt durch das DBMS eine dokumentbasierte Aufgabe ist. Und zwar deshalb, weil Daten in Form mehr eng Annäherung sein getreues Abbild dokumentenbasierte NoSQL-Datenbank verwenden bleiben können, obwohl dies auch aufgrund der speziellen Ausdauer-Politik erreicht, indem EHR medizinische Unterlagen (siehe Diskussion).

Diese Methoden soll mehrere Experimente durchführen, um die Umsetzung der Persistenzschicht eine standardisierte EHR-System mit drei verschiedenen DBMS vergleichen zu präsentieren: eine relationale (MySQL) und zwei NoSQL (dokumentbasierte MongoDB und native XML vorhanden sein). Ihre Rechenkomplexität wurde berechnet und verglichen mit drei verschiedenen zunehmende Größe Datenbanken und sechs verschiedene größer werdende Komplexität Abfragen. Die drei Datenbankserver wurden installiert und lokal auf demselben Computer wo die Abfragen ausgeführt wurden konfiguriert. Tabelle der Materialien für technische Details anzeigen.

Parallelität Experimente wurden auch durchgeführt, um die Leistung der relationalen MySQL und NoSQL MongoDB DBMS zu vergleichen. Die beschriebenen ORM-Verbesserungen (Knoten + Pfad und ARM) wurden auch mit entsprechenden entsprechende Ergebnisse aus der Literatur¹⁰verglichen.

Datenbank-Management-Systeme werden kontinuierlich weiterentwickelt, mit einer rasanten Geschwindigkeit. Niemand würde diese exponentielle Entwicklung denken, wenn das einzige vorhandene Paradigma das relationale Modell war. Um ein Beispiel zu nennen, siehe z. B.¹², wo wurde ein Modell vorgeschlagen, Reaktionszeit verbesserte relationale Datenbanken Beibehaltung der ACID-Eigenschaften zu implementieren.

Protocol

$$\rightleftharpoonup{xx}$$ $$\longleftharp{xx}$$, $$\longrightharp{xx}$$,

1. erstellen Sie eine relationale MySQL-DBMS um drei doppelte Größe EHR standardisierte Extrakte Datenbanken speichern

Importieren des W3C (World Wide Web Consortium) XML-Schema entspricht der ISO/EN13606 RM und ISO21090 Datentypen in einer "Java IDE" (Integrated Development Environment).
Hinweis: ISO steht für International Standards Organization. EN steht für Europäische Norm.
Die JAXB (Java XML Binding)-Plug-in in der IDE ausgeführt; Dies führt zu Java-Klassen entsprechend der Struktur der Elemente der EHR Auszüge XML-Dateien.
Kennzeichnen Sie manuell die Java-Klassen mit JPA Etiketten produziert. Diese Bezeichnungen beziehen sich auf die Kardinalitäten und andere Beziehungen zwischen den relationalen Tabellen der MySQL-Datenbank.
Importieren Sie die Bibliotheken der JPA (Java Persistence API) in der IDE und führen Sie die Methode, die eine MySQL -Datenbank aus den tagged Java-Klassen aufbaut.
Erstellen Sie drei Verzeichnisse mit 5.000, 10.000 und 20.000 realistische EHR XML-Dateien extrahiert.
Führen Sie die PPV-Methode um ein XML-Extrakt in MySQL DBMS auf den Extrakten des Verzeichnisses 5.000 Extrakte zu laden.
Wiederholen Sie Schritt 1.6 zweimal, einmal mit 10.000 Extrakte Verzeichnis und einmal mit dem 20.000 Extrakte-Verzeichnis.

2. bauen Sie ein NoSQL MongoDB DBMS um drei doppelte Größe EHR standardisierte Extrakte Datenbanken speichern

Jeder Prozess der drei Verzeichnisse mit 5.000, 10.000 und 20.000 realistische EHR Auszüge XML-Dateien mit einem standard-Programm zum XML-Dateien konvertieren in JSON-Dateien, wie z. B. json.org.XML. Drei Verzeichnisse mit 5.000, 10.000 und 20.000 JSON-Dateien sollte hergestellt werden.
Starten einer MongoDB-GUI (grafische Benutzeroberfläche, siehe Tabelle der Materialien).
Starten Sie den MongoDB 2.6 Server Ausführung des Mongod Programms aus einem DOS (Disk Operating System)-System-Fenster.
Verbinden Sie die MongoDB-GUI mit dem "localhost" Server über Port 27017.
1. Wählen Sie im Menü "verbinden".
2. Geben Sie einen Namen für die Verbindung (zum Beispiel "first").
3. Schreiben Sie Localhost:27017 in der DB-Server-Textfeld.
4. Drücken Sie die Schaltfläche "verbinden"; ein Baum mit aktuellen Datenbanken sollte auf der linken Seite angezeigt werden.
Erstellen Sie eine Datenbank mit 5.000 standardisierte EHR Extrakte.
1. Klicken Sie auf den Namen der Verbindung an der Spitze des Baumes auf der linken Seite.
2. Wählen Sie im Menü "Datei".
3. Wählen Sie "Datenbank hinzufügen".
4. Geben Sie den Namen der Datenbank im Dialogfeld, das angezeigt wird.
5. Klicken Sie auf OK.
Erstellen Sie eine Auflistung mit 5.000 standardisierte EHR Extrakte.
1. Klicken Sie auf den Namen der Datenbank in der Baumstruktur auf der linken Seite.
2. Wählen Sie Menü "Datenbank".
3. Wählen Sie "AddCollection".
4. Geben Sie den Namen der Sammlung in das Dialogfeld, das angezeigt wird.
5. Klicken Sie auf " Erstellen".
6. Klicken Sie auf den Namen der Sammlung.
7. Wählen Sie im Menü "Importieren".
8. Wählen Sie die Optionsschaltfläche ''JSON - Mongo Schale / / Mongoexport ".
9. Klicken Sie auf "nächste".
10. Drücken Sie den Button "Source-Dateien hinzufügen".
11. Navigieren Sie auf dem Computer mithilfe des Dialogfelds.
12. Offen das Verzeichnis mit 5.000 JSON-Dateien extrahieren.
13. Wählen Sie alle Dateien im Verzeichnis.
14. Klicken Sie auf "Öffnen". Die Liste der JSON-Dateien sollten im Import-Dialog angezeigt.
15. Klicken Sie auf "nächste"; auf der linken Seite erscheint eine Vorschau der neuen Kollektion in der Datenbank.
16. Klicken Sie auf "nächste".
17. Drücken Sie auf "Import starten". Der Fortschritt des Importvorgangs erscheint unten auf der linken Seite, die Anzahl der importierten Dateien und die verstrichene Zeit angibt.
Wiederholen Sie die Schritte 5 und 6, eine Sammlung von 10.000 standardisierte EHR Extrakte zu bauen.
Wiederholen Sie die Schritte 5 und 6, eine Sammlung von 20.000 standardisierte EHR Extrakte zu bauen.

3. Aufbau einer NoSQL existieren DBMS zu drei doppelte Größe standardisiert EHR extrahiert Datenbanken

Starten Sie die Datenbank bestehen .
Öffnen Sie mit dem Datenbank-Symbol der Java-Admin-Client.
Geben Sie das Administratorkennwort ein.
Drücken Sie die Schaltfläche "verbinden".
Erstellen Sie eine Auflistung mit 5.000 standardisierte EHR Extrakte.
1. Wählen Sie in der Symbolleiste das Menü "Erstellen einer neuen Sammlung".
2. Geben Sie im Dialogfeld, das angezeigt wird den Namen der neuen Kollektion.
3. Klicken Sie auf "akzeptieren"; die neue Kollektion erscheint.
4. Wählen Sie den Namen der Sammlung.
5. Wählen Sie in der Symbolleiste das Menü "Dateien speichern in der Datenbank".
6. Navigieren Sie auf dem Computer mithilfe des Dialogfeldes.
7. Wählen Sie das Verzeichnis mit 5.000 standardisierten XML-Extrakt Dateien.
8. Klicken Sie auf "Wählen Sie die Dateien oder Verzeichnisse speichern". Beachten Sie, dass ein Dialogfenster zeigt den Fortschritt der Dateien und der Prozentsatz der Datenbank erstellt.
Wiederholen Sie Schritt 5, um eine Auflistung mit 10.000 EHR standardisierte Extrakte bauen.
Wiederholen Sie Schritt 5, um eine Auflistung mit 20.000 EHR standardisierte Extrakte bauen.

4. design und 6 Komplexität steigt Abfragen ausführen, in den 3 relationale MySQL-Datenbanken

Entwerfen Sie sechs Komplexität steigt Abfragen nach den Archetypen von der EHR-Extrakte verwendet.
Ein SQL-Skript mit der ersten Abfrage auf die MySQL-Datenbank zu programmieren. Die SQL-Anweisung muss auf die spezielle Struktur der MySQL Datenbank aufgrund der Extrakte Standardisierung (Archetypen) einstellen. Die Datenbank bildet die gesamte Struktur der Extrakte. Infolgedessen ist die SQL-Abfrage ziemlich komplex.
Identifizieren Sie die Attribute der Datenbanken, die würde die Reaktionszeit der Abfragen beschleunigen, wenn ein Index auf sie gebaut wurde, dann solche Indizes zu konstruieren, obwohl die meisten Indizes automatisch durch das DBMS erstellt werden.
Wenn eine Abfrage nicht automatisch erstellten Indexdatei benötigt, es manuell zu erstellen.
1. Verbinden Sie mit dem MySQL-Server (zusätzliche Abbildung1).
2. Wählen Sie und klicken Sie auf den Namen der Datenbank auf der linken Seite.
3. Wählen Sie und klicken Sie auf die relationale Tabelle indizierte Feld Speicherort.
4. Klicken Sie auf die Registerkarte "Struktur".
5. Wählen Sie und klicken Sie auf die Spalte wo der Index erstellt wird.
6. Klicken Sie auf "Index". Beachten Sie, dass der SQL-Satz erstellen des Index angezeigt wird, erscheint eine Meldung, dass der Satz erfolgreich erstellt wurde.
Die erste Abfrage ausführen.
1. Wählen Sie und klicken Sie auf den Namen der Datenbank auf der linken Seite.
2. Klicken Sie auf die Registerkarte "SQL".
3. Schreiben Sie oder fügen Sie den SQL-Code der ersten Abfrage (siehe ergänzende Abbildung2).
4. Drücken Sie "weiter". Beachten Sie, dass das erste Bild der Ergebnisliste, zusammen mit einer Nachricht mit der Ausführungszeit der Abfrage erscheint.
5. Wiederholen Sie die Ausführung 5 Mal und berechnen Sie die durchschnittliche Antwortzeit.
Wiederholen Sie Schritt 5 mit 2 bis 6 Abfragen.
Den gesamten Prozess dreimal mit der 5.000, 10.000 und 20.000 Datenbanken extrahiert.

5. entwerfen und in den 3 NoSQL MongoDB-Datenbanken 6 Komplexität steigt Abfragen ausführen

Die MongoDB-GUI zu starten (siehe Tabelle der Materialien).
Starten Sie den MongoDB 2.6 Server Ausführung des Mongod -Programms von einem DOS-System-Fenster (siehe ergänzende Abbildung 3).
Folgen Sie Schritt 2.4, MongoDB GUI Verbindung zum "localhost" Server Port 27017 verwendet.
Wählen Sie und erweitern Sie die MongoDB-Datenbank auf der linken Seite.
Wählen Sie die Sammlung.
Klicken Sie auf das Menü "Sammlung" in der Symbolleiste.
Die ersten MongoDB-Abfrage ausführen.
1. Doppelklicken Sie auf die Schaltfläche "Abfrage-Generator".
2. Doppelklicken Sie auf das "Abfragefeld" von den Abfrage-Generator auf der rechten Seite.
3. Schreiben Sie das Feld der MongoDB-Abfrage in das Textfeld Feld ein, von den Abfrageeditor (siehe ergänzende Abbildung 4).
4. Schreiben Sie den Wert der MongoDB-Abfrage in das Textfeld Wert der Abfrageeditor.
  Hinweis: Diese Abfrage sollte sein etwas wie {"ns3:EHRExtract.allCompositions.content.items.parts.parts.name.ns2:originalText. Wert":"Descripcion"}. Das Feld der Wert zitiert und durch Semikolon voneinander getrennt.
5. Doppelklicken Sie auf das Projektionsfeld des Abfrage-Generator
6. Schreiben Sie die erste Projektion in der Projektion Textbox (siehe ergänzende Abbildung 5).
7. Doppelklicken Sie auf das Projektionsfeld, eine neue Projektion Textfeld hinzuzufügen.
8. Schreiben Sie die zweite Projektion in der Projektion Textbox.
  Hinweis: Eine Projektion wählt einen Teil des Dokuments durch die Abfrage abgerufen. Diese sollte etwas wie {"Ns3:EHRExtract. allCompositions.content.items.parts.parts.value.value": 1} und {" ns3: EHRExtract.all Compositions.content.items.parts.parts.value.nullFlavor ": 1}
9. Klicken Sie auf den blauen Play-Button zum Ausführen der Abfrage.
10. Visualisieren Sie den Abfragecode in der Registerkarte "Abfragecode".
11. Zeigen Sie die Details des Ergebnisses in der Registerkarte Erklärung: Anzahl der Ergebnisse, Ausführungszeit in Millisekunden.
12. Zeigen Sie an, erweitern Sie und prüfen Sie die Ergebnisse in der Registerkarte "Ergebnis".
13. Wenn weitere Verarbeitung der Abfrage erforderlich ist, schreiben Sie eine Java-Programm mit dem MongoDB-Java-Treiber mit der Abfrage und eine Methode, die Ergebnisse zu verarbeiten.
14. Wiederholen Sie die Ausführung 5 Mal und berechnen Sie die durchschnittliche Antwortzeit.
Treten Sie 5.7 für die verbleibenden 2 bis 6 Abfragen.
Wiederholen Sie der gesamte Prozess in die 5.000, 10.000 und 20.000 MongoDB Datenbanken extrahiert.

(6) entwerfen und ausführen in den 3 NoSQL existieren Datenbanken 6 zunehmende Komplexität Abfragen

Starten Sie die existieren DBMS.
Öffnen Sie die Java-Admin-Client.
Drücken Sie die Taste "verbinden mit der Datenbank".
Wählen Sie die Datenbank, und klicken Sie darauf.
Klicken Sie auf das Menü "Datenbank mit XPath"; Sie gelangen auf das Dialogfenster Consult.
Die ersten XPath-Abfrage ausführen (siehe ergänzende Abbildung 6).
1. Schreiben Sie oder fügen Sie den XPath-Code der ersten Abfrage im oberen Teil des Dialogfelds.
2. Klicken Sie auf das Menü "Ausführen" in der Symbolleiste des Dialogfensters.
3. XML-Ergebnisse mithilfe der Registerkarte "XML" im unteren Teil des Dialogfelds angezeigt.
4. Anzahl der Ergebnisse und Erstellung und Ausführungszeit am unteren Rand das Dialogfeld anzeigen.
5. Wiederholen Sie die Ausführung 5 Mal und berechnen Sie die durchschnittliche Antwortzeit.
Wiederholen Sie Schritt 6 für 2 bis 6 Abfragen.
Tun Sie den gesamten Prozess dreimal für die 5.000, 10.000 und 20.000 Extrakte Datenbanken vorhanden sind.

(7) entwerfen und Ausführen einer Parallelität Experiment mit MySQL und MongoDB 5.000 extrahiert Datenbanken

Hinweis: Die eXist-Datenbank wurde aus dem Experiment zu diesem Zeitpunkt wegen schlechter Leistung in den vorhergehenden Experimenten entfernt.

Wählen Sie die Abfragen mit den drei kürzester Zeit Antworten in den vorherigen Experimenten mit 5.000 Extrakte Datenbanken (in der Regel unter mehrere Sekunden).
Identifizieren und entsprechende Attributindizes für Abfragen, bei Bedarf manuell zu erstellen.
Programm zwei Java multithread-Anwendungen, eine für MySQL und die andere für MongoDB; jede Anwendung wird drei Threads mit verschiedenen Priorität, eine für jede Abfrage, die in Schritt 1 ausgewählt haben.
Führen und die CPU (Central Processing Unit) Verteilung verwenden für jeden Thread (Abfrage) zu berechnen.
Führen Sie jede multithread-Anwendung, klicken Sie auf die Schaltfläche "ausführen" fünfmal während jeder Spanne 10-min und berechnen die meisten hingerichteten (höchste Priorität) durchschnittliche Durchsatz und die durchschnittliche Reaktionszeit der drei Abfragen Abfragen.
Die Abfragen in der Ausführung, mit Prioritäten und Ausführungszeit anzeigen
Durchschnittlichen Durchsatz und die durchschnittliche Antwortzeit eines jeden der drei Abfragen zu berechnen.

Results

$$\rightleftharpoonup{xx}$$ $$\longleftharp{xx}$$, $$\longrightharp{xx}$$,

Sechs verschiedene Abfragen durchgeführt auf realistische standardisierte EHR-Extrakte, die Informationen über die Probleme des Patienten, einschließlich Namen, erste und letzte Termine und Schweregrad, sind in Tabelle 1dargestellt.

Durchschnittliche Reaktionszeiten der sechs Abfragen in den drei verdoppelt Größe Datenbanken in jeder DBMS sind in Tabellen 2-4gezeigt. Zahlen 1 bis 6 zeigen die gleichen Ergebnisse grafisch (beachten Sie, dass die vertikalen Achsen sehr unterschiedliche Maßstäben in diese Zahlen).

Das starke lineare Verhalten der Rechenaufwand ist offensichtlich in alle Abfragen der NoSQL-Datenbanken, obwohl mit entsprechender Vorsicht aufgrund der relativ geringen Größe der 3 Datensätze verwendet. Die relationale Datenbank ORM zeigt jedoch ein unklares lineares Verhalten. MongoDB-Datenbank hat eine viel flachere Steigung als die eXist-Datenbank.

Ergebnisse durch die verbesserte relationale Systeme diskutiert in der Einleitung, veröffentlicht in der Literatur finden Sie in Tabelle 5. Interpolation MongoDB Ergebnisse aus Tabelle 3 mit ähnlichen Abfragen und Datenbankgrößen ARM Ergebnisse aus Tabelle 5 ist gleich beide Datenbanksysteme im 1. Quartal, sondern begünstigt MongoDB in Q3.

Die Ergebnisse der Experimente Parallelität finden Sie in Tabelle 5 und Tabelle6. MongoDB schlägt MySQL sowohl im Durchsatz und die Antwortzeit. In der Tat MongoDB verhält sich besser in Parallelität als isoliert und steht als beeindruckende Datenbank bei gleichzeitiger Ausführung.

figure-results-1
Abbildung 1 : Algorithmische Komplexität der ORM MySQL, MongoDB, und es gibt DBMS für Abfragen Q1 und Q4. Diese Zahl von⁷ mit Creative Commons-Lizenz (http://creativecommons.org/ licenses/by/4.0/) verändert wurde und zeigt Reaktionszeiten in Sekunden für 5.000, 10.000 und 20.000 Größe EHR Datenbanken für jedes DBMS und Abfragen Q1 und Q4 extrahiert. Bitte klicken Sie hier für eine größere Version dieser Figur.

figure-results-2
Abbildung 2 : Algorithmische Komplexität der ORM MySQL DBMS für Abfrage Q2. Diese Abbildung zeigt Reaktionszeiten in Sekunden für 5.000, 10.000 und 20.000 Größe EHR ORM MySQL-Datenbank für die Abfrage Q2 extrahiert. Bitte klicken Sie hier für eine größere Version dieser Figur.

figure-results-3
Abbildung 3 : Algorithmische Komplexität von MongoDB und DBMS für Abfragen Q2 und Q5 gibt es. Diese Zahl von⁷ mit Creative Commons-Lizenz geändert wurde (http://creativecommons.org/licenses/ durch / 4.0) und zeigt Reaktionszeiten in Sekunden für 5.000, 10.000 und 20.000 Größe EHR Extrakte Datenbanken für jedes DBMS und Abfragen Q2 und Q5. Bitte klicken Sie hier für eine größere Version dieser Figur.

figure-results-4
Abbildung 4 : Algorithmische Komplexität der ORM MySQL DBMS für Abfragen Q3 und Q5. Zeigt Reaktionszeiten in Sekunden für 5.000, 10.000 und 20.000 Größe EHR Datenbanken für jedes DBMS und Abfragen Q3 und Q5 extrahiert. Bitte klicken Sie hier für eine größere Version dieser Figur.

figure-results-5
Abbildung 5: algorithmische Komplexität der eXist und MongoDB DBMS für Abfrage Q3. Diese Zahl von⁷ mit Creative Commons-Lizenz (http://creativecommons.org/licenses/ durch/4.0 /) verändert wurde und zeigt Reaktionszeiten in Sekunden für 5.000, 10.000 und 20.000 Größe EHR Datenbanken für jedes DBMS und Abfrage Q3 extrahiert. Bitte klicken Sie hier für eine größere Version dieser Figur.

figure-results-6
Abbildung 6 : Algorithmische Komplexität der ORM MySQL vorhanden und MongoDB DBMS für Abfragen Q6. Diese Zahl von⁷ mit Creative Commons-Lizenz (http://creativecommons.org/licenses/ durch/4.0 /) verändert wurde und zeigt Reaktionszeiten in Sekunden für 5.000, 10.000 und 20.000 Größe EHR Datenbanken für jedes DBMS und Abfrage Q6 extrahiert. Bitte klicken Sie hier für eine größere Version dieser Figur.

	Abfrage
Q1	Alle Probleme des einzelnen Patienten zu finden
Q2	Finden Sie alle Probleme aller Patienten
Q3	Anfangsdatum, Lösungsdatum und Schweregrad zu finden
	ein einzelnes Problem eines einzelnen Patienten
Q4	Anfangsdatum, Lösungsdatum und Schweregrad zu finden
	alle Probleme Problem eines einzelnen Patienten
Q5	Anfangsdatum, Lösungsdatum und Schweregrad zu finden
	alle Probleme Problem aller Patienten
Q6	Alle Patienten mit Problem "Pharyngitis", zu finden
	Datum erste > = 16. Oktober 2007 ", Lösungsdatum
	< = 5. Juni 2008 "und Schweregrad"hoch"

Tabelle 1: die sechs Abfragen durchgeführt auf der relationalen und NoSQL-Datenbanken mit standardisierten EHR Auszüge über die Probleme der Patienten. Diese Tabelle wurde aus⁷ mit Creative Commons-Lizenz (http://creativecommons.org/ licenses/by/4.0/) geändert und zeigt die sechs Komplexität wächst Abfragen auf die drei Größe wachsenden Datenbanken für jedes DBMS, ausgedrückt in natürlichen durchgeführt Sprache.

ORM/MySQL	5000 Dokumente	10.000 Dokumente	20.000 Dokumente
1. Quartal (s)	25.0474	32.6868	170.7342
2. Quartal (s)	0,0158	0.0147	0.0222
3. Quartal (s)	3.3849	6.4225	207.2348
4. Quartal (s)	33.5457	114.6607	115.4169
Q5 (s)	9.6393	74.3767	29.0993
Q6 (s)	1.4382	2.4844	183.4979
Datenbankgröße	4,6 GB	9,4 GB	19.4 GB
Gesamtextrakte	5000	10.000	20.000

Tabelle 2: durchschnittliche Reaktionszeiten in Sekunden der sechs Abfragen auf Verdoppelung Größe Datenbanken der ORM MySQL relationalen DBMS. Diese Tabelle zeigt sechs Reaktionszeiten für jede Abfrage für die drei Verdoppelung große Datenbanken mit der ORM MySQL relationalen DBMS und die Speichergröße der drei Datenbanken.

MongoDB	5000 Dokumente	10.000 Dokumente	20.000 Dokumente	*Neigung (10exp(-6))**
1. Quartal (s)	0.046	0.057	0.1221	5.07
2. Quartal (s)	34.5181	68.6945	136.2329	6,780.99
3. Quartal (s)	0,048	0.058	0.1201	4.81
4. Quartal (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
Datenbankgröße	1,95 GB	3,95 GB	7,95 GB
Gesamtextrakte	5000	10.000	20.000

Tabelle 3: durchschnittliche Reaktionszeiten in Sekunden der sechs Abfragen auf Verdoppelung Größe Datenbanken MongoDB NoSQL DBMS. Diese Tabelle wurde von⁷ mit Creative Commons-Lizenz (http://creativecommons.org/ licenses/by/4.0/) geändert und zeigt die sechs Reaktionszeiten der einzelnen Abfragen für die drei Verdoppelung große Datenbanken mit NoSQL MongoDB DBMS und die Speichergröße die drei Datenbanken. Die lineare Steigung der einzelnen Abfragen wird ebenfalls angezeigt.

gibt es	5000 Dokumente	10.000 Dokumente	20.000 Dokumente	*Neigung (10exp(-6))**
1. Quartal (s)	0.6608	3.7834	7.3022	442.76
2. Quartal (s)	60.7761	129.3645	287.362	15,105.73
3. Quartal (s)	0.6976	1,771	4.1172	227.96
4. Quartal (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
Datenbankgröße	1,25 GB	2,54 GB	5,12 GB
Gesamtextrakte	5000	10.000	20.000

Tabelle 4: durchschnittliche Reaktionszeiten in Sekunden der sechs Abfragen auf Verdoppelung Größe Datenbanken der gibt NoSQL DBMS. Diese Tabelle aus⁷ mit Creative Commons-Lizenz (http://creativecommons.org/ licenses/by/4.0/) verändert wurde und zeigt, dass die sechs Reaktionszeiten der einzelnen Abfragen für die drei Verdoppelung mittlere Datenbanken unter Verwendung der NoSQL DBMS und die Speichergröße des vorhanden die drei Datenbanken. Die lineare Steigung der einzelnen Abfragen wird ebenfalls angezeigt.

	ARM-Papier	ARM (s)	Knoten + Pfad (s)
Q1	Abfrage 2.1	0.191	24.866
Q3	Abfrage 3.1	0,27	294.774
	Datenbankgröße	2,90 GB	43,87 GB
	Gesamtextrakte	29.743	29.743

Tabelle 5: durchschnittliche Reaktionszeiten in Sekunden von Abfragen ähnlich Q1 und Q3 der bessere relationale Systeme präsentiert ¹⁰ . Diese Tabelle aus⁷ mit Creative Commons-Lizenz (http://creativecommons.org/ licenses/by/4.0/) verändert wurde und zeigt die beiden die meisten ähnlichen Abfragen zu Q1 und Q3 präsentiert in¹⁰ entspricht zwei verbesserte relationale Datenbanksysteme und ihre Reaktionszeiten. Die zwei Datenbankgrößen werden auch angezeigt.

ORM/MySQL	Durchsatz	Reaktionszeit
1. Quartal (s)	4,711.60	0.0793
3. Quartal (s)	4,711.60	0.1558
4. Quartal (s)	4,711.60	0.9674

Tabelle 6: durchschnittliche Durchsatz und Reaktion Zeit in Sekunden von Abfragen Q1, Q3 und Q4 der ORM MySQL relationalen DBMS in gleichzeitige Ausführung. Diese Tabelle wurde aus⁷ mit Creative Commons-Lizenz (http://creativecommons.org/ licenses/by/4.0/) geändert und zeigt den höchsten durchschnittlichen Durchsatz die drei Single-Patienten Abfragen und ihre durchschnittliche Reaktionszeiten in der gleichzeitigen Ausführung-Experiment mit dem ORM MySQL relationale System.

MongoDB	Durchsatz	Reaktionszeit
1. Quartal (s)	178,672.60	0,003
3. Quartal (s)	178,672.60	0.0026
4. Quartal (s)	178,672.60	0.0034

Tabelle 7: durchschnittliche Durchsatz und Reaktion Zeit in Sekunden der Abfragen Q1, Q3 und Q4 MongoDB NoSQL DBMS in gleichzeitige Ausführung. Diese Tabelle wurde aus⁷ mit Creative Commons-Lizenz (http://creativecommons.org/ licenses/by/4.0/) geändert und zeigt den höchsten durchschnittlichen Durchsatz die drei Single-Patienten Abfragen und ihre durchschnittliche Reaktionszeiten in der gleichzeitigen Ausführung-Experiment mit dem MongoDB NoSQL-System.

Ergänzende Abbildung1: der Screenshot zeigt die Software-Bildschirm, um mit dem MySQL-Server verbinden. Klicken Sie bitte hier, um diese Zahl zu downloaden.

Ergänzende Abbildung2: der Screenshot zeigt die SQL-Schnittstelle an dem MySQL-Server, wo wurde die erste SQL-Abfrage geschrieben. Klicken Sie bitte hier, um diese Zahl zu downloaden.

Ergänzende Abbildung 3: The MongoDB 2.6 "localhost" Server gestartet wird, verwenden ein DOS-System-Fenster durch Ausführen von Server-Mongod. Klicken Sie bitte hier, um diese Zahl zu downloaden.

Ergänzende Abbildung 4: der Screenshot zeigt die Abfrage in die Textfelder des Abfrage-Generator geschrieben, wie in Schritten 5.7.1 durch 5.7.4 gezeigt. Der Screenshot zeigt Schritt 5.7.3. Klicken Sie bitte hier, um diese Zahl zu downloaden.

Ergänzende Abbildung 5: der Screenshot zeigt den Schritt 5.7.6. Klicken Sie bitte hier, um diese Zahl zu downloaden.

Ergänzende Abbildung 6: der Screenshot zeigt das Schreiben von der XPath-Abfrage im obere Teil des Dialogfelds. Klicken Sie bitte hier, um diese Zahl zu downloaden.

Discussion

$$\rightleftharpoonup{xx}$$ $$\longleftharp{xx}$$, $$\longrightharp{xx}$$,

Dieses Protokoll zeigt, dass rein relationale ORM-Systemen nicht praktisch für einzelne Patienten Abfragen (Q1, Q3 und Q4) scheinen, da die Reaktionszeiten sind langsamer, wahrscheinlich aufgrund einer hohen Anzahl von relationalen Tabellen viele teure Join-Operationen durchführen, und aufgrund der Storage-System durch die spezifische Art der Datenbank verwendet. NoSQL-Datenbanken speichern Daten in ein Dokument-basierte Mode, während relationale Systeme eine tabellenbasierten Mode verwenden, die jedes Dokument in der gesamten Datenbank verbreitet. NoSQL-Systeme zeigen eine lineare Steigung mit MongoDB Durchführung wesentlich schneller als DBMS vorhanden sind. Parallelität MongoDB verhält sich auch viel besser als relationale MySQL ORM⁷.

Dieses Protokoll stellt eine Problembehandlung Protokoll für die Ergebnisse, die in⁷ bezüglich der ORM-MySQL-DBMS. Das MySQL-System wurde auf die neueste Version aktualisiert und die Ergebnisse wurden geringfügig geändert. Darüber hinaus ist wie MongoDB ist, dass sie Konsistenz bewahren können, wenn medizinische Informationen⁷ speichern, denn wenn ein EHR Auszug aktualisiert wird, ist es nicht überschrieben, sondern eine ganze neue mit den neuen Daten zu extrahieren ein kritischer Punkt im Dokument-basierte NoSQL-Systeme erzeugt und im System gespeichert und der Stammwürze wird beibehalten. Dies ist eine strenge Anforderung von medizinischen Informationen, weil einige Ärzte wichtige medizinische Entscheidungen auf Basis der ursprünglichen Daten gebildet haben können.

Die verbesserte relationalen ARM System drastisch verringert sich die Anzahl der relationalen Tabellen und relationalen Leistung verbessert. Da es das relationale Schema ändert, medizinische Informationen im Besitz der Extrakte kann abgefragt werden, jedoch Auszüge nicht in ihrer genauen ursprünglichen Form wiederhergestellt werden.

Für sehr große Datenbanken in sekundären verwenden (Forschung), es nicht klar ist, welche Datenbank-System besser geeignet ist, da die All-Patient-Abfragen (Q2 und Q5) besser in ORM als NoSQL-Systeme Verhalten, aber diese Systeme eine bessere als die vereinfachte Leistung relationalen Systeme im ¹². Wir betrachten Q6 eine spezielle Abfrage zwischen klinischen Praxis und sekundäre verwenden, deren Verhalten durch die Ergebnisse dieser Experimente bestimmt werden kann.

Eine Einschränkung der Methode ist jedoch die Nichtverfügbarkeit von direkten Experimenten vergleichen das verbesserte relationalen ARM-System mit NoSQL MongoDB über einzelne Patienten, medizinische Praxis Abfragen mit exakt die gleichen Daten in das Protokoll verwendet. Wir erhalten die Ergebnisse, die Interpolation von Tabelle 3 und Tabelle 5 über einzelne Patienten Abfragen, bis das Experiment auch optimierte ARM in das Protokoll durchgeführt wurde. Wir verlassen diese Experimente für zukünftige Anwendungen. Ein wichtiger Schritt im Rahmen des Protokolls ist die Auswahl der kostenlosen Datenbank, ähnliche Software-Versionen der letzten Jahre, so dass wir die genaue State-of-the-Art der drei Technologien vergleichen kann.

Dies ist einer der ersten Versuche, relationale direkt zu vergleichen und NoSQL-Systeme mit tatsächlichen, realistisch, standardisierte medizinische Informationen. Jedoch hängt am jeweiligen System verwendet werden stark von der tatsächlichen Szenario und Problem gelöst⁸sein.

Disclosures

$$\rightleftharpoonup{xx}$$ $$\longleftharp{xx}$$, $$\longrightharp{xx}$$,

Die Autoren haben nichts preisgeben. In diesen Experimenten verwendeten Datensätze wurden durch mehrere spanische Krankenhäuser unter Lizenz für diese Experimente zur Verfügung gestellt und sind daher nicht öffentlich zugänglich. Das ISO/EN 13606 RM XML-Schema sorgte das University College London Centre for Health Informatics & multiprofessionelle Bildung (Glockenspiel).

Acknowledgements

$$\rightleftharpoonup{xx}$$ $$\longleftharp{xx}$$, $$\longrightharp{xx}$$,

Die Autoren möchten Dr Dipak Kalra, Leiter der Task Force EHRCom danken, die der standard ISO/EN-13606 und sein Team vom University College London für ihre freundliche Genehmigung verwenden Sie das ISO/EN 13606 W3C XML-Schema definiert.

Diese Arbeit wurde unterstützt von Instituto de Salud Carlos III [Grantnummern PI15/00321, PI15/00003, PI1500831, PI15CIII/00010 und RD16CIII].

Materials

List of materials used in this article
Name	Company	Comments
MySQL 5.7.20		MySQL Experimente
Red Hat Enterprise Linux Server Release 7.4 (Maipo), 2,60 GHz, RAM 16 GB
MongoDB 2.6		MongoDB Experimente
Windows 7, 2,66 GHz, RAM 12 GB
eXist 3.0RC1		eXist experimentiert
Windows 7, 2,66 GHz, RAM 12 GB
Studio 3T 5.5.1	3T Software Labs Gmbh	MongoDB GUI

References

$$\rightleftharpoonup{xx}$$ $$\longleftharp{xx}$$, $$\longrightharp{xx}$$,

A relational model for large shared data banks. Comm ACM. 13 (6), 377-387 (1970).">Codd, E. F. A relational model for large shared data banks. Comm ACM. 13 (6), 377-387 (1970).
ISO 13606 electronic health record communication part 1: reference model. , ISO. Geneva. ISO 13606-1 (2008).">Kalra, D., Lloyd, D. ISO 13606 electronic health record communication part 1: reference model. , ISO. Geneva. ISO 13606-1 (2008).
Electronic health record communication part 2: archetype interchange specification. , ISO. Geneva. ISO 13606-2 (2008).">Kalra, D., et al. Electronic health record communication part 2: archetype interchange specification. , ISO. Geneva. ISO 13606-2 (2008).
The openEHR foundation. Stud. Health Technol. Inform. 115, 153-173 (2005).">Kalra, D., Beale, T., Heard, S. The openEHR foundation. Stud. Health Technol. Inform. 115, 153-173 (2005).
http://www.hl7.org (2017).">Health Level seven. Health Level Seven International. , Available from: http://www.hl7.org (2017).
Archetypes: constraint-based domain models for future proof information systems. OOPSLA, Workshop Behav Semant. , (2002).">Beale, T. Archetypes: constraint-based domain models for future proof information systems. OOPSLA, Workshop Behav Semant. , (2002).
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).">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).
Understanding object-relational mapping: a framework based approach. Int. J. Adv. Softw. 2, 202-216 (2009).">Ireland, C., Bowers, D., Newton, M., Waugh, K. Understanding object-relational mapping: a framework based approach. Int. J. Adv. Softw. 2, 202-216 (2009).
https://openehr.atlassian.net/wiki/spaces/dev/pages/6553626/Node+Path+Persistence (2017).">Node+Path Persistence. , Available from: https://openehr.atlassian.net/wiki/spaces/dev/pages/6553626/Node+Path+Persistence (2017).
Archetype relational mapping - a practical openEHR persistence solution. BMC Medical Informatics and Decision Making. 15, 88(2015).">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).
Managing data in healthcare information systems: many models, one solution. Computer. March. , 52-59 (2015).">Kaur, K., Rani, R. Managing data in healthcare information systems: many models, one solution. Computer. March. , 52-59 (2015).
An innovative approach to manage heterogeneous information using relational database systems. Advances in Intelligent Systems and Computing. 557, Springer. (2017).">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).

Reprints and Permissions

Request permission to reuse the text or figures of this JoVE article

Request Permission

Erhöhung der Komplexität Abfragen in relationalen (MySQL) und NoSQL (MongoDB und existieren) Größe wachsenden ISO/EN 13606 standardisierte EHR Datenbanken

In This Article

Summary

Abstract

Introduction

Protocol

Results

Discussion

Disclosures

Acknowledgements

Materials

References

Reprints and Permissions

Tags

Related Articles