Method Article

Toenemende complexiteit query's uitvoeren in relationele (MySQL) en NoSQL (MongoDB en bestaan) grootte groeiende ISO/nl 13606 gestandaardiseerde EMD Databases

DOI:

10.3791/57439

⸱

March 19th, 2018

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

In This Article

Summary

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

Deze studie vergelijkt relationele en niet-relationele (NoSQL) gestandaardiseerd medische informatiesystemen. De computationele complexiteit van de responstijden van het opvragen van dergelijke databasebeheersystemen (DBMS) wordt berekend met behulp van verdubbeling middelgrote databases. Deze resultaten helpen de discussie van de geschiktheid van elke database benadering van verschillende scenario's en problemen.

Abstract

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

Dit onderzoek toont een protocol bij het beoordelen van de computationele complexiteit van het opvragen van relationele en niet-relationele (NoSQL (niet alleen Structured Query Language)) gestandaardiseerd elektronische medische record (EMD) medische informatie databasesystemen (DBMS). Het maakt gebruik van een set van drie verdubbeling middelgrote databases, d.w.z. databases opslaan van 5000, 10.000 en 20.000 realistische gestandaardiseerde extracten van EMD, in drie verschillende databasebeheersystemen (DBMS): relationele MySQL object-relationele mapping (ORM), document-gebaseerd NoSQL MongoDB, als inheemse extensible markup language (XML) NoSQL bestaan.

De gemiddelde responstijden voor zes toenemende complexiteit query's werden berekend, en de resultaten toonden een lineaire gedrag in de NoSQL gevallen. In het veld NoSQL presenteert MongoDB een veel vlakker lineaire helling dan bestaan.

NoSQL systemen wellicht ook meer geschikt om gestandaardiseerde medische informatiesystemen vanwege de speciale aard van het bijgewerkte beleid van medische informatie, die mag geen afbreuk doen aan de consistentie en efficiëntie van de gegevens die zijn opgeslagen in databases van NoSQL.

Een beperking van dit protocol is het gebrek aan directe resultaten van de verbeterde relationele systemen zoals archetype relationele mapping (ARM) met dezelfde gegevens. Echter de interpolatie van verdubbeling-grootte databaseresultaten die gepresenteerd in de literatuur en andere gepubliceerde resultaten blijkt dat NoSQL systemen zou meer passend is in vele specifieke scenario's en problemen op te lossen. Bijvoorbeeld, kan NoSQL dienstig voor documentgebaseerde taken zoals het EMD extracten gebruikt in de klinische praktijk, of edition en visualisatie of situaties waarin het doel is niet alleen voor query medische informatie, maar ook voor het EMD in precies de oorspronkelijke vorm te herstellen.

Introduction

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

NoSQL (niet alleen SQL) DBMS hebben onlangs naar voren gekomen als een alternatief voor de traditionele relationele DBMS (RDMBS). RDBMS hebben gedomineerd de manier gegevens werden opgeslagen in databasesystemen voor decennia. Goed bestudeerde en begrepen relationele algebra en calculus hebben gegarandeerd de efficiëntie en consistentie van RDBMS1. NoSQL systemen zal niet worden substituten voor relationele systemen, maar ze kunnen voordelig gedragen in bepaalde scenario's en onder verschillende voorwaarden.

Sommige van deze bepaalde scenario's en omstandigheden zou optreden bij het ontwerpen van het voortbestaan van de database van Electronic Health Record (EMD) systemen gebruikt voor het beheer en de opslag van medische informatie. Om interoperabele en duurzame in de praktijk verschillende internationale normen zoals ISO/nl 13606, openEHR en HL72,3,4werden,5 gebruikt op de standaardisering van EMD-extracten.

Diverse standaarden zoals ISO/nl-13606 en openEHR hebben gescheiden informatie en kennis in twee verschillende niveaus van abstractie, vertegenwoordigd door de Reference Model (RM) en speciale datastructuren archetypengenoemd. Deze scheiding wordt vaak de dubbele model genoemd en hierdoor EMD-systemen als semantisch interoperabele en medische kennis evolueren zonder de hele EMD-systeem te herprogrammeren en, bijgevolg, naar onderhoudbaar en duurzame in de praktijk6 . De dubbele model ten uitvoer gelegd in gestandaardiseerde EMD-systemen vereist echter dat de organisatie van informatie een specifieke structuur volgt, en dit heeft ingrijpende gevolgen in de manier waarop die de databaseniveau persistentie van het systeem ontworpen7 is.

Object Relational Mapping (ORM)8 is een methodologie om een EMD-systeem met behulp van de relationele database paradigma. ORM kaarten uitvoerig de structuur van de gestandaardiseerde EMD extracten van XML (eXtensible Markup Language) bestanden die worden gebruikt door het systeem voor een relationele database. ORM construeert vele relationele tabellen die uitputtend na de structuur van de gestandaardiseerde extracten van EMD XML-bestanden. Deze relationele tabellen zijn gerelateerd door vele refererende sleutels en het resulterende systeem kan niet zeer efficiënt zijn.

De relationele verbeteringen in ORM hebben voorgesteld. het openEHR knooppunt + pad9 vermindert het aantal relationele tabellen door serializing substructuren van het hele extract xmldossier in BLOB's (binary large objects). Deze vereenvoudiging veroorzaakt echter complexe ophalen logica, beschadiging van complexe query's. Archetype relationele Mapping (ARM)10 genereert een databasemodel gedreven door archetypen, bouwen van een nieuwe relationele schema op basis van toewijzingen tussen archetypen en relationele tabellen. Enkele van de niet-medische informatie van het EMD-extract is dus verloren.

Veel documenten gebaseerde NoSQL databases hele documenten opslaan als hele BLOBs met inachtneming van een oorspronkelijke XML of JSON (JavaScript Object Notation) formaat. Dit betekent dat geen relationele tabellen worden geconstrueerd. Deze databases NoSQL geen schema hebben en ze ondersteunen geen ofwel joins of (zuur) eigenschappen11, dat wil zeggen, atomiciteit, consistentie, isolatie of duurzaamheid. Dientengevolge, kunnen zij zeer inefficiënt als een element van een document wordt verwezen naar elementen van dezelfde of andere dergelijke documenten met behulp van een indirecte koppeling. Dit gebeurt omdat, om redenen van consistentie, het geheel van de documenten waarnaar wordt verwezen moeten worden opeenvolgend verwerkt. Een niet-relationele database kan echter nog steeds geschikt als de belangrijkste taak van het DBMS een document-gebaseerde taak is. Dit is omdat de gegevens in een formulier mogen blijven meer nauw tot onderlinge aanpassing van de ware vertegenwoordiging met behulp van een document-based database voor NoSQL, al is dit ook te wijten aan het beleid van de speciale persistentie bereikt door EMD medische documenten (zie sectie discussie).

Het doel van deze methoden is om te demonstreren van verschillende experimenten te vergelijken van de uitvoering van de laag van de persistentie van een gestandaardiseerde EMD-systeem met behulp van drie verschillende databasebeheersystemen (DBMS): een relationele (MySQL) en twee NoSQL (documentgebaseerde MongoDB en native XML bestaan). Hun computationele complexiteit is berekend en vergeleken met behulp van drie verschillende toenemende grootte databases en zes verschillende complexiteit toenemende query's. De drie databaseservers zijn geïnstalleerd en lokaal geconfigureerd in dezelfde computer waar de query's zijn uitgevoerd. Zie de Tabel van materialen voor de technische details.

Concurrency experimenten zijn ook uitgevoerd om het vergelijken van de prestaties van relationele MySQL en NoSQL MongoDB databasebeheersystemen (DBMS). Ook zijn de beschreven ORM-verbeteringen (knooppunt + pad en ARM) vergeleken met behulp van relevante passende resultaten uit de literatuur10.

Database managementsystemen evolueren voortdurend in een versneld tempo. Niemand zou denken over deze exponentiële ontwikkeling toen de enige bestaande paradigma het relationele model was. Neem een voorbeeld, zie bijvoorbeeld12, waar een model werd voorgesteld om de verbeterde relationele databases responstijd behoud van de ACID-eigenschappen.

Protocol

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

1. bouw een relationele DBMS MySQL om informatiearchiefdatabases drie dubbele grootte gestandaardiseerde EMD extracten

  1. Importeren van de W3C (World Wide Web Consortium) XML-Schema overeenkomt met de ISO/EN13606 RM en de gegevenstypen van ISO21090 in een 'Java IDE' (Integrated Development Environment).
    Opmerking: ISO staat voor International Standards Organization. NL staat voor Europese Norm.
  2. Uitvoeren van de JAXB (Java XML-bindende) plug-in in de IDE; Dit levert de Java klassen overeenkomt met de structuur van de elementen van het EMD XML-bestanden worden uitgepakt.
  3. De Java-klassen geproduceerd met PPV labels handmatig labelen. Deze labels verwijzen naar de kardinaliteiten en andere relaties tussen de relationele tabellen van de MySQL-database.
  4. De bibliotheken van de PPV (Java Persistentie API) importeren in de IDE en uitvoeren van de methode die een MySQL -database uit de tagged Java-klassen bouwt.
  5. Drie mappen maken met 5.000, 10.000 en 20.000 realistische EMD XML-bestanden worden uitgepakt.
  6. De methode van de PPV te laden van een XML-fragment in het DBMS MySQL op alle extracten van de 5.000 extracten directory uitgevoerd.
  7. Herhaal stap 1.6 tweemaal, eenmaal met de 10.000 extracten-map en een keer met de extracten van 20.000 directory.

2. bouw een NoSQL MongoDB-DBMS om te slaan drie dubbele grootte gestandaardiseerde EMD extracten Databases

  1. Proces elk van de drie lijsten met 5.000, 10.000 en 20.000 realistische EMD XML-bestanden worden uitgepakt met een standaardprogramma XML-bestanden omzetten in JSON bestanden, zoals json.org.XML. Drie mappen met 5.000, 10.000 en 20.000 JSON bestanden moeten worden geproduceerd.
  2. Lanceren van een MongoDB-GUI (Graphic User Interface, Zie Tabel van materialen).
  3. Start de MongoDB 2.6 server uitvoeren van het mongod -programma van een venster van DOS (Disk Operating System) systeem.
  4. De GUI MongoDB verbinden met de localhost-server via poort 27017.
    1. Selecteer het menu "Connect".
    2. Schrijf een naam voor de verbinding (bijvoorbeeld ' eerste').
    3. Localhost:27017 in de textbox DB Server schrijven.
    4. Druk op de knop "verbinden"; een boom met de huidige databases wordt weergegeven aan de linkerkant.
  5. Het bouwen van een database met 5.000 gestandaardiseerde EMD extracten.
    1. Klik op de naam van de verbinding bij de bovenkant van de boom aan de linkerkant.
    2. Selecteer het menu "bestand".
    3. Kies 'Database toevoegen'.
    4. Voer de naam van de database in het dialoogvenster dat verschijnt.
    5. Klik op OK.
  6. Het bouwen van een collectie met 5.000 gestandaardiseerde EMD extracten.
    1. Klik op de naam van de database in de boom aan de linkerkant.
    2. Selecteer menu "Database".
    3. Kies "AddCollection".
    4. Voer de naam van de collectie in het dialoogvenster dat verschijnt.
    5. Klik op ' Maakaan '.
    6. Klik op de naam van de collectie.
    7. Selecteer het menu "importeren".
    8. Selecteer keuzerondje ''JSON - mongo shell / / mongoexport ".
    9. Klik op "volgende".
    10. Druk op de knop "Add Source Files".
    11. Navigeren op de computer met behulp van het dialoogvenster.
    12. Open de map met 5.000 JSON bestanden uitpakken.
    13. Selecteer alle bestanden in de directory.
    14. Druk op "Open". De lijst van JSON bestanden moet worden weergegeven in het dialoogvenster importeren.
    15. Druk op "volgende"; een preview van de nieuwe collectie in de database wordt weergegeven aan de linkerkant.
    16. Druk op "volgende".
    17. Druk op "Start importeren". De voortgang van het importeren wordt weergegeven naar beneden aan de linkerkant, met vermelding van het aantal geïmporteerde bestanden en de verstreken tijd.
  7. Herhaal stap 5 en 6 om te bouwen van een verzameling van 10.000 gestandaardiseerde EMD-extracten.
  8. Herhaal stap 5 en 6 om te bouwen van een verzameling van 20.000 gestandaardiseerde EMD-extracten.

3. bouw een NoSQL bestaan DBMS tot winkel drie dubbele Sized gestandaardiseerd EMD extracten Databases

  1. Start de database bestaat .
  2. Met behulp van het pictogram van de database, opent u de administratie Client van Java.
  3. Het admin wachtwoord.
  4. Druk op de knop "Connect".
  5. Het bouwen van een collectie met 5.000 gestandaardiseerde EMD extracten.
    1. Selecteer in de werkbalk het menu "maken een nieuwe collectie".
    2. Typ in het dialoogvenster dat verschijnt, de naam van de nieuwe collectie.
    3. Klik op "accepteren"; de nieuwe collectie verschijnt.
    4. Selecteer de naam van de collectie.
    5. Selecteer het menu 'Store files in de database' in de werkbalk.
    6. Navigeren op de computer met behulp van het dialoogvenster.
    7. Selecteer de map met 5.000 gestandaardiseerde XML-bestanden uitpakken.
    8. Klik op de knop "Selecteer de bestanden of mappen op te slaan". Merk op dat een dialoogvenster wordt weergegeven waarin de vooruitgang, de bestanden worden opgeslagen, en het percentage van de database gemaakt.
  6. Herhaal stap 5 om te bouwen van een collectie met 10.000 gestandaardiseerde EMD-extracten.
  7. Herhaal stap 5 om te bouwen van een collectie met 20.000 gestandaardiseerde EMD-extracten.

4. ontwerpen en 6 toenemende complexiteit Queries uitvoeren in de 3 relationele MySQL Databases

  1. Het ontwerp van zes toenemende complexiteit query's volgens de archetypen gebruikt door de EMD-extracten.
  2. Programmeren van een SQL-script met de eerste query op de MySQL database. De SQL-code moet aanpassen aan de speciale structuur van de MySQL database als gevolg van extracten normalisatie (archetypen). De database wijst de hele structuur van de extracten. Dientengevolge, is de SQL-query nogal complex.
  3. Bepaal de kenmerken van de databases die zou versnellen de responstijd van de query's als een index werd gebouwd op hen, dan bouwen deze indexen, hoewel meeste indexen automatisch door het DBMS worden gebouwd.
  4. Als een query een niet-automatisch ingebouwde index moet, moet u het handmatig bouwen.
    1. Verbinding met de mysqlserver (aanvullende figuur 1).
    2. Selecteer en klik op de naam van de database aan de linkerkant.
    3. Selecteer en klik op de relationele tabel waar het geïndexeerde veld zich bevindt.
    4. Klik op het tabblad "structuur".
    5. Selecteer en klik op de kolom waar de index zal worden gebouwd.
    6. Klik op "index". Merk op dat de SQL-zin bouwen de index weergegeven en verschijnt er een bericht waarin staat dat de zin met succes is gebouwd.
  5. De eerste query uitvoert.
    1. Selecteer en klik op de naam van de database aan de linkerkant.
    2. Klik op het tabblad "SQL".
    3. Schrijven of de SQL-code van de eerste query plakken (Zie aanvullende figuur 2).
    4. Druk op "Doorgaan". Merk op dat het eerste scherm van de lijst met zoekresultaten, samen met een bericht met de uitvoeringstermijn van de query verschijnt.
    5. Herhaal de uitvoering 5 keer en berekenen van de gemiddelde responstijd.
  6. Herhaal stap 5 met queries 2 t/m 6.
  7. Niet het hele proces drie keer, met de 5.000, 10.000 en 20.000 extracten-databases.

5. ontwerpen en 6 toenemende complexiteit Queries uitvoeren in de 3 NoSQL MongoDB-Databases

  1. Starten van de GUI MongoDB (Zie Tabel van materialen).
  2. Starten van de server van de MongoDB 2.6 uitvoeren van het programma van de mongod van een DOS-venster systeem (Zie aanvullende figuur 3).
  3. Volg stap 2.4 de MongoDB GUI verbinden met de localhost-server via poort 27017.
  4. Selecteer en vouw de database MongoDB aan de linkerkant.
  5. Selecteer de collectie.
  6. Klik op de "collectie" menu in de werkbalk.
  7. De eerste MongoDB-query uitvoert.
    1. Dubbelklik op de knop "Query Builder".
    2. Dubbelklik op het "queryveld" van de opbouwfunctie voor Query's aan de rechterkant.
    3. Schrijf het veld van de MongoDB-query in het tekstvak van het veld voor de query panel (Zie aanvullende figuur 4).
    4. Schrijf de waarde van de MongoDB-query in het tekstvak van de waarde van het query-paneel.
      Opmerking: Deze query moet iets als {"ns3:EHRExtract.allCompositions.content.items.parts.parts.name.ns2:originalText. waarde":"Descripción"}. Het veld zijn de waarde geciteerd en gescheiden door puntkomma's.
    5. Dubbelklik op het gebied van de projectie van de opbouwfunctie voor Query 's
    6. Schrijf de eerste projectie in de textbox projectie (Zie aanvullende figuur 5).
    7. Dubbelklik op de projectie gebied toe te voegen een nieuwe projectie textbox.
    8. Schrijf de tweede projectie in de textbox projectie.
      Opmerking: Een projectie selecteert een deel van het document opgehaald met de query. Dit moet iets als {"ns3:EHRExtract. allCompositions.content.items.parts.parts.value.value": 1} en {" ns3: EHRExtract.all Compositions.content.items.parts.parts.value.nullFlavor ": 1}
    9. Klik op de blauwe afspeelknop de query uit te voeren.
    10. Visualiseren van de code van de query in het tabblad Query Code.
    11. De details van het resultaat bekijken in het tabblad uitleg: aantal resultaten, uitvoering tijd in milliseconden.
    12. Bekijken, uit te breiden, en bekijkt u de resultaten in het tabblad resultaat.
    13. Als verdere verwerking van de query vereist is, een Java-programma te schrijven met de bestuurder van de MongoDB Java met de query en een methode voor het verwerken van de resultaten.
    14. Herhaal de uitvoering 5 keer en berekenen van de gemiddelde responstijd.
  8. Stap 5.7 voor de resterende 2 t/m 6 queries.
  9. Herhaal het hele proces in de 5.000, 10.000 en 20.000 extracten MongoDB databases.

6. ontwerpen en uitvoeren in de 3 NoSQL bestaan Databases 6 vergroting-complexiteit query's

  1. Start de bestaan DBMS.
  2. Open de administratie Client van Java.
  3. Druk op de knop "verbinden met de database".
  4. Selecteer de database en klik op het.
  5. Klik op het menu "raadplegen van de database met behulp van XPath"; het consult-dialoogvenster wordt weergegeven.
  6. De eerste XPath-query uitvoeren (Zie aanvullende figuur 6).
    1. Schrijven of de XPath-code van de eerste query plakken in het bovenste gedeelte van het dialoogvenster.
    2. Klik op het menu "uitvoeren" in de knoppenbalk van het dialoogvenster.
    3. Via het tabblad 'XML' in het onderste gedeelte van het dialoogvenster XML-resultaten weergeven.
    4. Aantal resultaten en compilatie en uitvoeringstijd onderin het dialoogvenster bekijken.
    5. Herhaal de uitvoering 5 keer en berekenen van de gemiddelde responstijd.
  7. Herhaal stap 6 voor query's 2 tot en met 6.
  8. Niet het hele proces drie keer, want de extracten van 5.000, 10.000 en 20.000 databases bestaan.

7. het ontwerpen en uitvoeren van een Experiment van de Concurrency met behulp van de MySQL en MongoDB 5.000 extracten Databases

Opmerking: De eXist database is verwijderd uit het experiment op dit moment als gevolg van erger prestaties in de eerdere experimenten.

  1. Selecteer de query's met de drie kortste tijd antwoorden in het eerdere experimenten met behulp van de 5.000 extracten databases (doorgaans onder enkele seconden).
  2. Identificeren en handmatig bouwen passende kenmerk indexen voor die query's, indien nodig.
  3. Programma twee Java multithread-toepassingen, één voor MySQL en de andere voor MongoDB; elke aanvraag zal hebben drie verschillende prioritaire onderwerpen, één voor elke query die in stap 1 hebt geselecteerd.
  4. Uitvoeren en berekenen de CPU (Central Processing Unit) gebruik verdeling voor elke thread (query).
  5. Elke multithread-toepassing te klikken op de knop uitvoeren vijf keer tijdens elke 10-min span, uitvoeren en berekenen van de meest uitgevoerde (hoogste prioriteit) gemiddelde doorvoer en de reactie van de gemiddelde tijd van de drie queries opvragen.
  6. De query's in uitvoering, met de prioriteiten en uitvoertijd weergeven.
  7. Berekenen gemiddelde doorvoer en gemiddelde responstijd van elk van de drie queries.

Results

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

Zes verschillende query's uitgevoerd op realistische gestandaardiseerde extracten van EMD met informatie over de problemen van patiënten, met inbegrip van hun namen, de eerste en de laatste datums en de ernst, zijn vermeld in tabel 1.

Gemiddelde responstijden van de zes zoekopdrachten in de drie databases verdubbeling-grootte in elk DBMS staan in de tabellen 2-4. Cijfers 1-6 de dezelfde resultaten grafisch tonen (merk op dat de verticale assen zeer verschillende schalen in deze cijfers gebruiken).

Het sterke lineair gedrag van computationele complexiteit is duidelijk tijdens alle query's van de NoSQL databases, hoewel met passende voorzichtigheid als gevolg van de relatief geringe omvang van de 3 datasets gebruikt. De relationele database van ORM blijkt echter een onduidelijk lineaire gedrag. De database MongoDB heeft een veel vlakker helling dan de eXist database.

Resultaten door de verbeterde relationele systemen besproken in de inleiding gepubliceerd in de literatuur kunnen worden gevonden in tabel 5. Interpoleren MongoDB resultaten uit tabel 3 met soortgelijke vragen en database maten van ARM resultaten van tabel 5 is gelijk aan beide databasesystemen in Q1, maar gunsten MongoDB in Q3.

De resultaten van de experimenten concurrency kunnen worden gevonden in tabel 5 en tabel6. MongoDB verslaat MySQL, beide in doorvoer en responstijd. In feite, MongoDB gedraagt zich beter in concurrency dan los, en staat als een indrukwekkende database bij gelijktijdige uitvoering.

figure-results-1
Figuur 1 : Algoritmische complexiteit van ORM MySQL, MongoDB, en bestaan van DBMS voor query's Q1 en Q4. Dit cijfer is gewijzigd van7 met behulp van Creative Commons-licentie (http://creativecommons.org/ licenses/by/4.0/) en toont reactietijd in seconden voor 5.000, 10.000 en 20.000 middelgrote EMD extracten databases voor elk DBMS en query's Q1 en Q4. Klik hier voor een grotere versie van dit cijfer.

figure-results-2
Figuur 2 : Algoritmische complexiteit van ORM MySQL DBMS voor query Q2. Deze figuur toont reactietijd in seconden voor 5.000, 10.000 en 20.000 middelgrote EMD extracten ORM MySQL database voor query Q2. Klik hier voor een grotere versie van dit cijfer.

figure-results-3
Figuur 3 : Algoritmische complexiteit van MongoDB en DBMS bestaan voor query Q2 en Q5. Dit cijfer is gewijzigd van7 met behulp van Creative Commons-licentie (http://creativecommons.org/licenses/ door / 4.0) en toont reactietijd in seconden voor 5.000, 10.000 en 20.000 middelgrote EMD extracten databases voor elk DBMS en query's Q2 en Q5. Klik hier voor een grotere versie van dit cijfer.

figure-results-4
Figuur 4 : Algoritmische complexiteit van ORM MySQL DBMS voor query's Q3 en Q5. Toont reactietijd in seconden voor 5.000, 10.000 en 20.000 middelgrote EMD extracten databases voor elk DBMS en query's Q3 en Q5. Klik hier voor een grotere versie van dit cijfer.

figure-results-5
Figuur 5: algoritmische complexiteit van eXist en MongoDB DBMS voor query Q3. Dit cijfer is gewijzigd van7 met behulp van Creative Commons-licentie (http://creativecommons.org/licenses/ door/4.0 /) en toont reactietijd in seconden voor 5.000, 10.000 en 20.000 middelgrote EMD extracten databases voor elk DBMS en de query Q3. Klik hier voor een grotere versie van dit cijfer.

figure-results-6
Figuur 6 : Algoritmische complexiteit van ORM MySQL, bestaan en MongoDB DBMS voor query V6. Dit cijfer is gewijzigd van7 met behulp van Creative Commons-licentie (http://creativecommons.org/licenses/ door/4.0 /) en toont reactietijd in seconden voor 5.000, 10.000 en 20.000 middelgrote EMD extracten databases voor elk DBMS en de query V6. Klik hier voor een grotere versie van dit cijfer.

Query
Q1Alle problemen van een enkele patiënt te vinden
Q2Alle problemen van alle patiënten te vinden
Q3Zoeken oorspronkelijke datum, resolutie datum en ernst
van een enkel probleem van een enkele patiënt
Q4Zoeken oorspronkelijke datum, resolutie datum en ernst
van alle problemen-probleem van een enkele patiënt
Q5Zoeken oorspronkelijke datum, resolutie datum en ernst
van alle problemen probleem van alle patiënten
Q6Vinden van alle patiënten met probleem 'faryngitis',
eerste datum > ' 16/10/2007 =', resolutie datum
< = ' 06/05/2008 ' en ernst 'hoog'

Tabel 1: de zes query's uitgevoerd op de relationele en NoSQL databases met gestandaardiseerde EMD extracten over problemen van patiënten. Deze tabel is gewijzigd van7 met behulp van Creative Commons-licentie (http://creativecommons.org/ licenses/by/4.0/) en geeft de zes complexiteit groeiende query's uitgevoerd op de drie grootte groeiende databases voor elk DBMS uitgedrukt in natuurlijke taal.

ORM/MySQL5000 docs10.000 docs20.000 docs
Q1 (s)25.047432,6868170.7342
Q2 (s)0.01580.01470.0222
Q3 (s)3.38496.4225207.2348
Q4 (s)33.5457114.6607115.4169
Q5 (s)9.639374.376729.0993
Q6 (s)1.43822.4844183.4979
Databaseomvang4.6 GB9.4 GB19.4 GB
Totale extracten500010.00020.000

Tabel 2: gemiddelde reactietijd in seconden van de zes vragen over verdubbeling-grootte databases van de ORM MySQL relationele DBMS. Deze tabel toont zes responstijden voor elke query voor de drie verdubbeling middelgrote databases met behulp van de ORM MySQL relationele DBMS en de grootte in het geheugen van de drie databases.

MongoDB5000 docs10.000 docs20.000 docshelling (*10exp(-6))
Q1 (s)0.0460,0570.12215.07
Q2 (s)34.518168.6945136.23296,780.99
Q3 (s)0.0480.0580.12014.81
Q4 (s)0.0520.061o.12414.81
Q5 (s)38.020275.4376149.9337460.85
Q6 (s)9.515318.556636.78051,817.68
Databaseomvang1,95 GB3.95GB7,95 GB
Totale extracten500010.00020.000

Tabel 3: gemiddelde reactietijd in seconden van de zes vragen over verdubbeling-grootte databases van de MongoDB NoSQL DBMS. Deze tabel is gewijzigd van7 met behulp van Creative Commons-licentie (http://creativecommons.org/ licenses/by/4.0/) en toont de zes reactietijden van elke query voor de drie verdubbeling middelgrote databases met behulp van de NoSQL MongoDB DBMS en de grootte in het geheugen van de drie databases. De lineaire helling van elke query wordt ook weergegeven.

Bestaan5000 docs10.000 docs20.000 docshelling (*10exp(-6))
Q1 (s)0.66083.78347.3022442.76
Q2 (s)60.7761129.3645287.36215,105.73
Q3 (s)0.69761.7714.1172227.96
Q4 (s)0.64453.76047.3216445.17
Q5 (s)145.3373291.2502597.721630,158.93
Q6 (s)68.3798138.9987475.266327,125.82
Databaseomvang1,25 GB2.54GB5,12 GB
Totale extracten500010.00020.000

Tabel 4: gemiddelde reactietijd in seconden van de zes vragen over verdubbeling-grootte databases van de eXist NoSQL DBMS. Deze tabel is gewijzigd van7 met behulp van Creative Commons-licentie (http://creativecommons.org/ licenses/by/4.0/) en toont de zes reactietijden van elke query voor de drie verdubbeling middelgrote databases die gebruikmaken van de NoSQL bestaan DBMS en de grootte in het geheugen van de drie databases. De lineaire helling van elke query wordt ook weergegeven.

ARM papierARM (s)Knooppunt + pad (s)
Q1Query 2.10.19124.866
Q3Query 3.10.27294.774
Databaseomvang2.90GB43.87GB
Totale extracten29,74329,743

Tabel 5: gemiddelde reactietijd in seconden van query's vergelijkbaar met Q1 en Q3 van de verbeterde relationele systemen aangeboden 10 . Deze tabel is gewijzigd van7 met behulp van Creative Commons-licentie (http://creativecommons.org/ licenses/by/4.0/) en toont de twee meeste-soortgelijke vragen aan Q1 en Q3 gepresenteerd in10 overeenkomt met twee verbeterde relationele databasesystemen en hun responstijden. De twee database maten worden ook weergegeven.

ORM/MySQLDoorvoerReactietijd
Q1 (s)4,711.600.0793
Q3 (s)4,711.600.1558
Q4 (s)4,711.600.9674

Tabel 6: gemiddelde doorvoer en reactie tijd in seconden van query's Q1, Q3 en Q4 van ORM MySQL relationele DBMS in gelijktijdige uitvoering. Deze tabel is gewijzigd van7 met behulp van Creative Commons-licentie (http://creativecommons.org/ licenses/by/4.0/) en toont de hoogste gemiddelde doorvoer van de drie single-patiënt queries en hun gemiddelde responstijden in de concurrent uitvoering experiment met behulp van de ORM MySQL relationele systeem.

MongoDBDoorvoerReactietijd
Q1 (s)178,672.600.003
Q3 (s)178,672.600.0026
Q4 (s)178,672.600.0034

Tabel 7: gemiddelde doorvoer en reactie tijd in seconden van query's Q1, Q3 en Q4 van MongoDB NoSQL DBMS in gelijktijdige uitvoering. Deze tabel is gewijzigd van7 met behulp van Creative Commons-licentie (http://creativecommons.org/ licenses/by/4.0/) en toont de hoogste gemiddelde doorvoer van de drie single-patiënt queries en hun gemiddelde responstijden in de concurrent uitvoering experiment met behulp van de MongoDB NoSQL systeem.

Aanvullende figuur 1: de schermafdruk toont het scherm van de software om te verbinden met de server MySQL. Klik hier voor het downloaden van dit cijfer.

Aanvullende figuur 2: de schermafdruk toont de SQL-interface naar de mysqlserver waar de eerste SQL-query is geschreven. Klik hier voor het downloaden van dit cijfer.

Aanvullende figuur 3: The MongoDB 2.6 localhost server wordt gestart met behulp van een DOS-venster systeem door het uitvoeren van de server mongod. Klik hier voor het downloaden van dit cijfer.

Aanvullende figuur 4: de schermafdruk toont de query in de tekstvakken van de opbouwfunctie voor Query's worden geschreven in stappen 5.7.1 via 5.7.4. Screenshot toont stap 5.7.3-fouten te vermijden. Klik hier voor het downloaden van dit cijfer.

Aanvullende figuur 5: de schermafdruk toont de stap 5.7.6. Klik hier voor het downloaden van dit cijfer.

Aanvullende figuur 6: de screenshot illustreert het schrijven van de XPath-query in theupper deel van het dialoogvenster. Klik hier voor het downloaden van dit cijfer.

Discussion

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

Dit protocol laat zien dat zuivere relationele ORM systemen niet praktisch voor single-patiënt query's (Q1, Q3 en Q4 lijken) aangezien responstijden zijn langzamer, waarschijnlijk als gevolg van een hoog aantal relationele tabellen veel dure join-bewerkingen uitvoeren, en vanwege de opslagsysteem dat wordt gebruikt door de specifieke aard van de database. NoSQL databases slaan gegevens op documenten gebaseerde wijze, terwijl relationele systemen gebruiken een tabel is gebaseerd mode die zich elk document in de hele database verspreidt. NoSQL systemen tonen een lineaire helling, met MongoDB uitvoeren aanzienlijk sneller dan bestaan DBMS. In concurrency, MongoDB ook gedraagt zich veel beter dan relationele MySQL ORM7.

Dit protocol biedt een probleemoplossing protocol voor de resultaten gepresenteerd in7 met betrekking tot de ORM MySQL DBMS. De MySQL-systeem is bijgewerkt naar de nieuwste versie en de resultaten zijn enigszins gewijzigd. Daarnaast is een kritisch punt in document gebaseerde NoSQL systemen zoals MongoDB is dat ze consistentie behouden kunnen bij het opslaan van medische informatie7 omdat wanneer een EMD uittreksel wordt bijgewerkt, wordt het niet overschreven, maar een geheel nieuw pak uit met de nieuwe gegevens gegenereerd en opgeslagen in het systeem, en het oorspronkelijke extract wordt gehandhaafd. Dit is een strikte vereiste van medische informatie, omdat sommige artsen mogelijk hebben gemaakt van belangrijke medische beslissingen op basis van de oorspronkelijke gegevens.

De verbeterde relationele armsysteem drastisch vermindert het aantal relationele tabellen en relationele prestaties verbetert. Aangezien het wijzigt het relationele schema, medische informatie, gehouden door de extracten kan worden opgevraagd, maar extracten kunnen niet worden hersteld in hun exacte originele vormen.

Voor zeer grote databases in secundaire gebruiken (onderzoek), het is niet duidelijk welke database-systeem is meer nodig, aangezien de all-patiënt-query's (Q2 en Q5) beter in ORM dan in NoSQL systemen gedragen, maar deze systemen beter dan de vereenvoudigde presteren relationele systemen in 12. Wij beschouwen de Q6 een speciale query tussen de klinische praktijk en secundaire gebruiken wier gedrag kan niet worden bepaald door de resultaten van deze experimenten.

Een beperking van de methode is echter de inavailability van directe experimenten het verbeterde relationele armsysteem met NoSQL MongoDB met betrekking tot één-patiënt, medische praktijk query's vergelijken met precies dezelfde gegevens die in het protocol worden gebruikt. Wij onderhouden de resultaten interpoleren van tabel 3 en tabel 5 met betrekking tot één-patiënt query's totdat het experiment met inbegrip van geoptimaliseerde ARM in het protocol was uitgevoerd. Laten we deze experimenten voor toekomstige toepassingen. Een kritieke stap in het protocol is de selectie van gratis database, soortgelijke softwareversies van de afgelopen jaren, zodat we de exacte state-of-the-art van de drie technologieën kan vergelijken.

Dit is een van de eerste pogingen om rechtstreeks vergelijken relationele en NoSQL systemen die gebruikmaken van de eigenlijke, realistische en gestandaardiseerde medische informatie. Het specifieke systeem worden gebruikt hangt echter wel veel van op de werkelijke scenario en het probleem als opgelost8.

Disclosures

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

De auteurs hebben niets te onthullen. De datasets gebruikt in deze experimenten werden verstrekt door verschillende Spaanse ziekenhuizen onder licentie voor deze experimenten en bijgevolg zijn niet publiekelijk beschikbaar. Het ISO/nl 13606 RM XML-schema werd verstrekt door het University College London Centre for Health Informatics & gezondheidsdimensie onderwijs (klokkenspel).

Acknowledgements

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

De auteurs bedank Dr Dipak Kalra, leider van de EHRCom task force, die de standaard ISO/nl-13606 en zijn team van University College London voor hun vriendelijke toestemming voor het gebruik van de ISO/nl 13606 W3C XML-Schema gedefinieerd.

Dit werk werd gesteund door het Instituto de Salud Carlos III [subsidie nummers PI15/00321 en PI15/00003, PI1500831, PI15CIII/00010, RD16CIII].

Materials

List of materials used in this article
NameCompanyCatalog NumberComments
MySQL 5.7.20MySQL experiments
Red Hat Enterprise Linux Server release 7.4 (Maipo), 2.60GHz, RAM 16GB
MongoDB 2.6MongoDB experiments
Windows 7, 2.66GHz, RAM 12GB 
eXist 3.0RC1eXist experiments
Windows 7, 2.66GHz, RAM 12GB 
Studio 3T 5.5.13T Software Labs GmbhMongoDB GUI

References

$$\rightleftharpoonup{xx}$$ $$\longleftharp{xx}$$, $$\longrightharp{xx}$$,
  1. 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).
  2. 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).
  3. 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).
  4. 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).
  5. http://www.hl7.org (2017).">Health Level seven. Health Level Seven International. , Available from: http://www.hl7.org (2017).
  6. 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).
  7. 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).
  8. 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).
  9. 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).
  10. 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).
  11. 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).
  12. 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

Tags

Complexity Increasing QueriesRelational Database SystemsNoSQL Database SystemsMySQL MongoDB EXistElectronic Health RecordsDatabase Management SystemsComputational Complexity AnalysisResponse Time MeasurementDoubling Size DatabasesStandardized EHR Databases

Related Articles