Summary
Denna studie jämför relationella och icke-relationsdata (NoSQL) standardiserade medicinska informationssystem. Svarstider för frågekörning sådan databashanteringssystem (DBMS) beräkningsmässig komplexitet beräknas använda fördubbling medelstora databaser. Dessa resultat hjälpa diskussioner om lämpligheten i varje databas förhållningssätt till olika scenarier och problem.
Abstract
Denna forskning visar ett protokoll för att bedöma computational komplexiteten i fråge relationella och icke-relationsdata (NoSQL (inte bara Structured Query Language)) standardiserade elektroniska post (EPJ) medicinsk databas hälsoinformationssystem (DBMS). Det använder en uppsättning av tre fördubbling medelstora databaser, dvs databaser lagra 5000, 10.000 och 20.000 realistiska standardiserade EHR extrakt, i tre olika databashanterare (DBMS): relationella MySQL objekt-relationella kartläggning (ORM), dokument-baserade NoSQL MongoDB, och infödda extensible markup language (XML) NoSQL finns.
Genomsnittliga svarstider på sex ökande komplexitet frågor beräknades och resultaten visade ett linjärt beteende i NoSQL-fall. I fältet NoSQL presenterar MongoDB en mycket plattare linjär lutning än finns.
NoSQL-system kan också vara lämpligare att upprätthålla standardiserade medicinska informationssystem på grund av den särskilda karaktären av medicinsk information, som inte bör påverka den samstämmighet och effektivitet av data som lagras i NoSQL-databaser uppdateras politik.
En begränsning i detta protokoll är avsaknaden av direkta resultat av förbättrad relationella system som arketyp relationella kartläggning (ARM) med samma data. Dock interpolering av fördubbling-storlek databasresultat som presenteras i litteraturen och andra offentliggjorda resultat antyder att NoSQL-system kan vara mer lämpligt i många specifika scenarier och problem som måste lösas. Till exempel kan NoSQL vara lämpligt för dokument-baserade aktiviteter såsom EHR extrakt som används i klinisk praxis eller edition och visualisering, eller situationer där syftet är inte bara att fråga efter medicinsk information, men också att återställa EHR i exakt dess ursprungliga form.
Introduction
NoSQL (inte bara SQL) DBMS har nyligen dykt upp som ett alternativ till traditionella relationell Databashanterare (RDMBS). RDBMS har dominerat det sättet som data lagrades i databassystem i årtionden. Väl studerat och förstås relational algebra och analys har garanterad effektivitet och konsekvens av RDBMS1. NoSQL-system kommer inte att bli substitut för relationella system, men de kunde bete sig med fördel i vissa scenarier och flera villkor.
Några av dessa särskilda situationer och villkor skulle uppstå när utforma databasen ihållande elektroniska hälsa rekord (EPJ) system används för att hantera och lagra medicinsk information. För att vara driftskompatibla och hållbar i praktiken flera internationella standarder såsom ISO/EN 13606, openEHR och HL72,3,4har,5 använts för att standardisera EHR extrakt.
Flera standarder som ISO/EN 13606 och openEHR har separerat information och kunskap in i två olika nivåer av abstraktion, representerade av referens modell (RM) och särskilda datastrukturer som kallas arketyper. Detta avskiljande kallas ofta den dubbla modell och det tillåter EPJ-system vara semantiskt interoperabla och medicinsk kunskap för att utvecklas utan omprogrammering hela EHR systemet och, följaktligen, att vara hanterbar och hållbar i praktiken6 . Den dubbla modellen genomförs i standardiserade EPJ-system kräver dock att organisationen av information följer en viss struktur, och detta har djupgående konsekvenser på det sätt som databasen persistens systemet är designade7.
Objekt-relationsmappning (ORM)8 är en metod att genomföra EPJ-systemet använder relationsdatabas paradigm. ORM kartor uttömmande strukturen av standardiserade EHR extrakt XML (eXtensible Markup Language) filer används av systemet för en relationsdatabas. ORM konstruerar många relationella bord uttömmande efter strukturen för standardiserade EHR extrakt XML-filerna. Dessa relationella tabeller är relaterade genom många främmande nycklar och resulterande systemet kan inte vara mycket effektiv.
Flera relationella förbättringar ORM har föreslagits. Openehr's nodsökvägen +9 minskar antalet relationella tabeller av serialisering underträd i hela extraktet XML-filen till BLOB (binära stora objekt). Men orsakar denna förenkling komplexa hämtning logik, skadar komplexa frågor. Arketyp Relational Mapping (ARM)10 genererar en databasmodell som drivs av arketyper, bygga en ny relations schema baserat på mappningar mellan arketyper och relationella tabeller. Vissa icke-medicinska uppgifter i EPJ extraktet är följaktligen förlorade.
Många dokument-baserade NoSQL-databaser lagra hela dokument som hela blobbar respektera en ursprungliga XML eller JSON (JavaScript Object Notation) format. Detta innebär att inga relationella bord är konstruerade. Dessa NoSQL-databaser har inget schema och de stöder inte antingen kopplingar eller (syra) boenden11, dvs, atomicity, konsekvens, isolering eller hållbarhet. Som ett resultat, kan de vara mycket ineffektiv om ett element i ett dokument refererar till element av samma eller andra sådana handlingar som utnyttjar en falskhet länk. Detta händer eftersom för att upprätthålla konsistens, helheten av de refererade dokumenten måste bearbetas sekventiellt. En icke-relationell databas kan dock fortfarande lämpligt om den viktigaste uppgiften som utförs av DBMS är en dokumentbaserade uppgift. Detta beror på att data kan finnas kvar i en form mer nära tillnärma sin sanna representation med hjälp av en dokument-baserade NoSQL-databas, men detta beror också på speciella persistens politik fulländat av EPJ medicinska handlingar (se diskussionsavsnittet).
Syftet med dessa metoder är att visa upp flera experiment för att jämföra genomförandet av persistens lagret av ett standardiserat EPJ-system som använder tre olika databashanteringssystem: en relationell (MySQL) och två NoSQL (finns dokumentbaserat MongoDB och native XML). Deras beräkningskomplexitet har varit beräknas och jämförs med hjälp av tre olika ökande storlek databaser och sex olika komplexitet större frågor. De tre database-servrarna har installerats och konfigurerats lokalt på samma dator där frågorna har utförts. Se Tabell för material för tekniska detaljer.
Samtidighet experiment har också utförts för att jämföra prestanda för relationell MySQL och NoSQL MongoDB databashanteringssystem. De beskrivna ORM förbättringarna (nodsökvägen + och ARM) har också jämförts med relevanta lämpliga resultat från litteratur10.
Databashanteringssystem utvecklas kontinuerligt i allt snabbare takt. Ingen skulle tro om denna exponentiell utveckling när det enda existerande paradigmet var relationsmodellen. För att ta ett exempel, se till exempel12, där en modell föreslogs att genomföra svarstid förbättrad relationsdatabaser behålla ACID-egenskaper.
Protocol
1. Bygg en relationell MySQL Databashanterare för att lagra tre dubbel storlek standardiserade EHR extrakt databaser
- Importera W3C (World Wide Web Consortium) XML-Schema motsvarar ISO/EN13606 RM och ISO21090 datatyper till en 'Java IDE' (Integrated Development Environment).
Obs: ISO står för International Standards Organization. SV står för europeisk Norm. - Köra den JAXB (Java XML bindande) plug-in i IDE; Detta ger Java-klasser som motsvarar strukturen i delarna av EPJ extrakt XML-filerna.
- Tagga manuellt de Java-klasser som produceras med JPA etiketter. Dessa etiketter hänvisa till cardinalities och andra relationer mellan tabellerna relationella av MySQL-databasen.
- Importera biblioteken i den gemensamma parlamentariska församlingen (Java Persistence API) till IDE och kör metoden som bygger en MySQL -databas av märkta Java-klasser.
- Skapa tre kataloger med 5000, 10.000 och 20.000 realistiska EHR extrakt XML-filer.
- Kör metoden JPA för att läsa in ett XML-extrakt i MySQL DBMS på alla extrakt av katalogen 5.000 extrakt.
- Upprepa steg 1,6 två gånger, en gång med katalogen 10.000 extrakt och en gång med katalogen 20.000 extrakt.
2. Bygg en NoSQL MongoDB DBMS för att lagra tre dubbel storlek standardiserade EHR extrakt databaser
- Processen varje tre kataloger som innehåller 5000, 10.000 och 20.000 realistiska EHR extrakt XML-filer med en standard program för att konvertera XML-filer till JSON-filer, till exempel json.org.XML. Tre kataloger med 5000, 10.000 och 20.000 JSON-filer bör produceras.
- Starta en MongoDB-GUI (grafisk förbrukaren gräns flat, se Tabell för material).
- Starta MongoDB 2.6 server köra programmet mongod från en DOS (Disk Operating System) system-fönstret.
- Anslut MongoDB GUI till localhost-servern använder port 27017.
- Välj ”Anslut”-menyn.
- Skriv ett namn för anslutningen (till exempel ' första').
- Skriva localhost:27017 i textrutan DB-Server.
- Tryck på knappen ”Anslut”; ett träd med de aktuella databaserna ska visas till vänster.
- Bygga upp en databas som innehåller 5 000 standardiserade EHR extrakt.
- Klicka på namnet på anslutningen högst upp i trädet till vänster.
- Välj ”fil” menyn.
- Välj ”Lägg till databas”.
- Ange namnet på databasen i dialogrutan som visas.
- Klicka på OK.
- Bygga upp en samling som innehåller 5 000 standardiserade EHR extrakt.
- Klicka på namnet på databasen i trädet till vänster.
- Välj menyn ”databas”.
- Välj ”AddCollection”.
- Ange namnet på samlingen i dialogrutan som visas.
- Klicka på ” skapa”.
- Klicka på namnet på samlingen.
- Välj menyn ”Import”.
- Välj alternativknappen ''JSON - mongo shell / / mongoexport ”.
- Klicka på ”Nästa”.
- Tryck på knappen ”Lägg till källa filer”.
- Navigera på datorn med hjälp av dialogrutan.
- Öppna den katalog som innehåller 5000 JSON extrahera filer.
- Markera alla filer i katalogen.
- Tryck på ”Öppna”. Listan över JSON-filer ska visas i dialogrutan Import.
- Tryck på ”Nästa”; en förhandsvisning av den nya kollektionen i databasen visas till vänster.
- Tryck på ”Nästa”.
- Tryck på ”Starta Import”. Förloppet för import visas nere till vänster, som indikerar antalet filer som importeras och förfluten tid.
- Upprepa steg 5 och 6 för att bygga upp en samling av 10 000 standardiserade EHR extrakt.
- Upprepa steg 5 och 6 för att bygga upp en samling av 20.000 standardiserade EHR extrakt.
3. bygga en NoSQL finns DBMS till butiken tre dubbel storlek standardiserade EHR extrakt databaser
- Starta databasen finns .
- Öppna Java Admin klienten databasens ikon.
- Ange administratörslösenordet.
- Tryck på knappen ”Anslut”.
- Bygga upp en samling som innehåller 5 000 standardiserade EHR extrakt.
- I verktygsfältet, Välj menyn ”skapa en ny samling”.
- I dialogrutan som visas, Skriv namnet på den nya samlingen.
- Klicka på ”acceptera”; den nya samlingen visas.
- Välj namnet på samlingen.
- Välj menyn ”lagra filer i databasen” i verktygsfältet.
- Navigera på datorn med hjälp av dialogrutan.
- Välj den katalog som innehåller 5 000 standardiserade XML-extrahera filer.
- Klicka på knappen ”Välj de filer eller kataloger för att lagra”. Observera att en dialogruta visas visar framsteg, filer lagras, och andelen av den databas som har skapats.
- Upprepa steg 5 för att bygga upp en samling som innehåller 10 000 standardiserade EHR extrakt.
- Upprepa steg 5 för att bygga upp en samling som innehåller 20.000 standardiserade EHR extrakt.
4. design och köra i 3 relationella MySQL databaser 6 ökande komplexitet frågor
- Design sex ökande komplexitet frågor enligt de arketyper som används av EPJ extrakt.
- Programmera en SQL-skriptet med den första frågan på MySQL-databasen. SQL måste anpassa sig till den speciella strukturen av MySQL-databasen på grund av extrakt standardisering (arketyper). Databasen kartor hela strukturen av extrakten. Som ett resultat, är SQL-frågan ganska komplicerat.
- Identifiera attributen för de databaser som skulle påskynda svarstiden för frågor om ett index byggdes på dem och sedan konstruera sådana index, men de flesta index byggs automatiskt av DBMS.
- Om en fråga behöver ett icke-automatiskt byggda index, bygga det manuellt.
- Ansluta till MySQL-servern (kompletterande Figur1).
- Välj och klicka på databasens namn till vänster.
- Välj och klicka på tabellen relationella där det indexerade fältet finns.
- Klicka på fliken ”struktur”.
- Välj och klicka på kolumnen där indexet kommer att byggas.
- Klicka på ”index”. Observera att SQL meningen bygga index visas och ett meddelande om att meningen har skapats visas.
- Utföra första frågan.
- Välj och klicka på databasens namn till vänster.
- Klicka på fliken ”SQL”.
- Skriva eller klistra in SQL-koden i den första frågan (se kompletterande diagram 2).
- Tryck på ”Fortsätt”. Observera att den första skärmen i resultatlistan visas, tillsammans med ett meddelande med körningstiden för frågan.
- Upprepa 5 gånger för utförandet och beräkna den genomsnittliga svarstiden.
- Upprepa steg 5 med frågor 2 till 6.
- Gör hela processen tre gånger, med 5000, 10.000 och 20.000 extrakt databaser.
5. design och köra i 3 NoSQL MongoDB databaser 6 ökande komplexitet frågor
- Starta MongoDB GUI (se Tabell för material).
- Starta MongoDB 2.6 servern köra programmet mongod från ett DOS-system fönster (se kompletterande diagram 3).
- Följ steg 2,4 ansluta MongoDB GUI till localhost servern använder port 27017.
- Välj och expandera databasen MongoDB på vänster sida.
- Välj samlingen.
- Klicka på menyn ”samling” i verktygsfältet.
- Utföra första MongoDB frågan.
- Dubbelklicka på ”Query Builder”-knappen.
- Dubbelklicka på ”Query fält” av frågeverktyget till höger.
- Skriva fältet för MongoDB frågan i textrutan fält på panelen frågan (se kompletterande diagram 4).
- Skriv värdet för MongoDB frågan i textrutan värde på panelen fråga.
Obs: Denna fråga bör vara något i stil med {”ns3:EHRExtract.allCompositions.content.items.parts.parts.name.ns2:originalText. värdet ”:” Descripcion ”}. Fältet och värdet är citerade och avgränsade med semikolon. - Dubbelklicka på fältet projektion av frågeverktyget
- Skriva den första projektionen i textrutan projektion (se kompletterande diagram 5).
- Dubbelklicka på fältet projektion vill lägga till en ny projektion textbox.
- Skriv den andra projektionen i textrutan projektion.
Obs: En projektion väljer en del av dokumentet Hämtad av frågan. Dessa bör vara något i stil med {”ns3:EHRExtract. allCompositions.content.items.parts.parts.value.value ”: 1} och {” ns3: EHRExtract.all Compositions.content.items.parts.parts.value.nullFlavor ”: 1} - Klicka på den blå play-knappen för att köra frågan.
- Visualisera fråga koden i fliken fråga kod.
- Visa information om resultatet i fliken förklaring: antal resultat, körningstid i millisekunder.
- Visa, expandera och granska resultaten på fliken resultat.
- Om ytterligare behandling av frågan krävs, Skriv ett Java-program med MongoDB Java föraren med frågan och en metod att bearbeta resultaten.
- Upprepa 5 gånger för utförandet och beräkna den genomsnittliga svarstiden.
- Gör steg 5.7 för de återstående 2 till 6 frågor.
- Upprepa hela processen i 5000, 10.000 och 20.000 utdrag MongoDB databaser.
6. design och köra i 3 NoSQL finns databaser 6 öka komplexa frågor
- Starta det finns DBMS.
- Öppna Java Admin klienten.
- Tryck på knappen ”ansluta till databasen”.
- Välj databasen och klicka på den.
- Klicka på menyn ”konsultera databasen med hjälp av XPath”; dialogrutan consult visas.
- Utföra första XPath-fråga (se kompletterande diagram 6).
- Skriv eller klistra in XPath kod av den första frågan i den övre delen av dialogrutan.
- Klicka på menyn ”Kör” i verktygsfältet i dialogrutan.
- Visa XML-resultat med hjälp av ”XML” fliken i den nedre delen av dialogrutan.
- Visa antal resultat och sammanställning och körningstid längst ned i dialogrutan.
- Upprepa 5 gånger för utförandet och beräkna den genomsnittliga svarstiden.
- Upprepa steg 6 för frågor 2 till 6.
- Gör hela processen tre gånger, för 5000, 10.000 och 20.000 extrakt finns databaser.
7. designa och utföra en samtidighet Experiment med hjälp av MySQL och MongoDB 5,000 extrakt databaser
Obs: Databasen finns har tagits från experiment vid denna tidpunkt på grund av sämre resultat i tidigare experiment.
- Välj frågor med tre kortaste tid svaren i tidigare experiment med 5.000 extrakt databaserna (vanligtvis under flera sekunder).
- Identifiera och manuellt bygga lämpliga attribut index för dessa frågor, om det behövs.
- Programmera två multitrådsprogrammering Java-program, ett för MySQL och den andra för MongoDB; varje program kommer att ha tre olika prioritet trådar, en för varje fråga som valts i steg 1.
- Utföra och beräkna den CPU (Central Processing Unit) använda distribution för varje tråd (fråga).
- Kör varje multithread ansökan, klicka på knappen execute fem gånger under varje 10-min span, och beräkna körda (högsta prioritet) fråga Genomsnittligt dataflöde och genomsnittlig tid svar på tre frågor.
- Se frågorna i utförandet, med prioriteringar och körningstid.
- Beräkna Genomsnittligt dataflöde och genomsnittlig svarstid för var och en av de tre frågorna.
Representative Results
Sex olika frågor utförs på realistiska standardiserade EHR extrakt som innehåller information om problem som patienter, inklusive deras namn, första och sista datum och svårighetsgrad, visas i tabell 1.
Genomsnittliga svarstider sex frågor i tre fördubbling-storlek databaser i varje DBMS visas i tabellerna 2-4. Siffror 1-6 visar samma resultat grafiskt (Observera att de lodräta axlarna använder mycket olika skalor i hela dessa siffror).
Det starka linjära uppförandet av beräkningskomplexitet är uppenbart i hela alla frågor till NoSQL-databaser, men med lämplig försiktighet på grund av den relativt lilla storleken på 3 datamängderna används. Relationsdatabasen ORM visar dock en oklar linjära uppförandet. MongoDB databasen har en mycket flackare lutning än databasen finns.
Resultat av förbättrad relationella system diskuteras i inledningen publicerat i litteraturen kan hittas i tabell 5. Interpolera MongoDB resultaten från tabell 3 med liknande frågor och databasstorlekar av ARM resultaten från tabell 5 är lika med båda databassystem i Q1, men gynnar MongoDB i Q3.
Resultaten av samtidighet experimenten kan hittas i tabell 5 och tabell6. MongoDB slår MySQL både i genomströmning och reaktionstid. I själva verket MongoDB beter sig bättre i samtidighet än isolerat, och står som ett imponerande databas i samtidiga utförande.
Figur 1 : Algoritmisk komplexitet ORM MySQL, MongoDB, och existerar DBMS för frågor Q1 och Q4. Denna siffra har ändrats från7 använder Creative Commons-licens (http://creativecommons.org/ licenses/by/4.0/) och visar svarstider i sekunder för 5000, 10.000 och 20.000 medelstora EHR extrakt databaser för varje DBMS och frågor Q1 och Q4. Klicka här för att se en större version av denna siffra.
Figur 2 : Algoritmisk komplexitet ORM MySQL Databashanterare för frågan Q2. Denna figur visar svarstider i sekunder för 5000, 10.000 och 20.000 medelstora EHR extrakt ORM MySQL databas för frågan Q2. Klicka här för att se en större version av denna siffra.
Figur 3 : Algoritmisk komplexitet MongoDB och finnas DBMS för frågor Q2 och Q5. Denna siffra har ändrats från7 använder Creative Commons-licens (http://creativecommons.org/licenses/ av / 4.0) och visar svarstider i sekunder för 5000, 10.000 och 20.000 medelstora EHR extrakt databaser för varje DBMS och frågor Q2 och Q5. Klicka här för att se en större version av denna siffra.
Figur 4 : Algoritmisk komplexitet ORM MySQL Databashanterare för frågor Q3 och Q5. Visar svarstider i sekunder för 5000, 10.000 och 20.000 medelstora EHR extrakt databaser för varje DBMS och frågor Q3 och Q5. Klicka här för att se en större version av denna siffra.
Figur 5: algoritmisk komplexitet existerar och MongoDB DBMS för frågan Q3. Denna siffra har ändrats från7 använder Creative Commons-licens (http://creativecommons.org/licenses//4.0 /) och visar svarstider i sekunder för 5000, 10.000 och 20.000 medelstora EHR extrakt databaser för varje DBMS och fråga Q3. Klicka här för att se en större version av denna siffra.
Figur 6 : Algoritmisk komplexitet ORM MySQL, existerar och MongoDB DBMS för fråga Q6. Denna siffra har ändrats från7 använder Creative Commons-licens (http://creativecommons.org/licenses//4.0 /) och visar svarstider i sekunder för 5000, 10.000 och 20.000 medelstora EHR extrakt databaser för varje DBMS och fråga Q6. Klicka här för att se en större version av denna siffra.
| Fråga | |
| Q1 | Hitta alla problem av en enda patient |
| Q2 | Hitta alla problem av alla patienter |
| Q3 | Hitta första datum, resolution datum och svårighetsgrad |
| av ett enda problem av en enda patient | |
| Q4 | Hitta första datum, resolution datum och svårighetsgrad |
| av alla problem problem av en enda patient | |
| Q5 | Hitta första datum, resolution datum och svårighetsgrad |
| av alla problem problem av alla patienter | |
| Q6 | Hitta alla patienter med problem 'faryngit', |
| inledande datum > = ' 16/10/2007 ', resolution datum | |
| < = ' 06/05/2008 ' och 'hög' |
Tabell 1: de sex frågorna som utförs på den relationella och NoSQL-databaser som innehåller standardiserade EHR extrakt om problem av patienter. Den här tabellen har ändrats från7 använder Creative Commons-licens (http://creativecommons.org/ licenses/by/4.0/) och visar de sex komplexitet växande frågor utförs på de tre storlek växande databaserna för varje DBMS uttryckt i naturlig språk.
| ORM/MySQL | 5000 docs | 10.000 docs | 20.000 docs |
| Q1 (s) | 25.0474 | 32.6868 | 170.7342 |
| Q2 (s) | 0,0158 | 0.0147 | 0.0222 |
| Q3 (s) | 3.3849 | 6.4225 | 207.2348 |
| Q4 (s) | 33.5457 | 114.6607 | 115.4169 |
| Q5 (s) | 9.6393 | 74.3767 | 29.0993 |
| F6 (s) | 1.4382 | 2.4844 | 183.4979 |
| Databasens storlek | 4.6 GB | 9,4 GB | 19,4 GB |
| Totala extrakt | 5000 | 10 000 | 20.000 |
Tabell 2: genomsnittlig svarstider i sekunder för sex frågorna på fördubbling-storlek databaser av ORM MySQL relationsdatabaser DBMS. Denna tabell visar sex svarstider för varje fråga för tre fördubbling medelstora databaser använder ORM MySQL relationsdatabaser DBMS och storleken i minnet av de tre databaserna.
| MongoDB | 5000 docs | 10.000 docs | 20.000 docs | lutning (*10exp(-6)) |
| Q1 (s) | 0.046 | 0.057 | 0.1221 | 5,07 |
| Q2 (s) | 34.5181 | 68.6945 | 136.2329 | 6,780.99 |
| Q3 (s) | 0,048 | 0,058 | 0.1201 | 4.81 |
| Q4 (s) | 0.052 | 0,061 | o.1241 | 4.81 |
| Q5 (s) | 38.0202 | 75.4376 | 149.933 | 7460.85 |
| F6 (s) | 9.5153 | 18.5566 | 36.7805 | 1,817.68 |
| Databasens storlek | 1,95 GB | 3.95GB | 7,95 GB | |
| Totala extrakt | 5000 | 10 000 | 20.000 |
Tabell 3: genomsnittliga svarstider i sekunder för sex frågorna på fördubbling-storlek databaser för MongoDB NoSQL DBMS. Den här tabellen har ändrats från7 använder Creative Commons-licens (http://creativecommons.org/ licenses/by/4.0/) och visar de sex svarstiderna på varje fråga för tre fördubbling medelstora databaser använder NoSQL MongoDB DBMS och storleken i minnet av de tre databaserna. Linjär lutningen på varje fråga visas också.
| Finns | 5000 docs | 10.000 docs | 20.000 docs | lutning (*10exp(-6)) |
| Q1 (s) | 0.6608 | 3.7834 | 7.3022 | 442.76 |
| Q2 (s) | 60.7761 | 129.3645 | 287.362 | 15,105.73 |
| Q3 (s) | 0.6976 | 1.771 | 4.1172 | 227.96 |
| Q4 (s) | 0.6445 | 3.7604 | 7.3216 | 445.17 |
| Q5 (s) | 145.3373 | 291.2502 | 597.7216 | 30,158.93 |
| F6 (s) | 68.3798 | 138.9987 | 475.2663 | 27,125.82 |
| Databasens storlek | 1.25GB | 2.54GB | 5.12GB | |
| Totala extrakt | 5000 | 10 000 | 20.000 |
Tabell 4: genomsnittliga svarstider i sekunder för sex frågorna på fördubbling-storlek databaser av finns NoSQL DBMS. Den här tabellen har ändrats från7 använder Creative Commons-licens (http://creativecommons.org/ licenses/by/4.0/) och visar de sex svarstiderna på varje fråga för tre fördubbling medelstora databaser använder NoSQL finns DBMS och i minnet storlek de tre databaserna. Linjär lutningen på varje fråga visas också.
| ARM papper | ARM (s) | Nod + Stig (s) | |
| Q1 | Fråga 2.1 | 0.191 | 24.866 |
| Q3 | Fråga 3.1 | 0,27 | 294.774 |
| Databasens storlek | 2.90GB | 43.87GB | |
| Totala extrakt | 29,743 | 29,743 |
Tabell 5: genomsnittliga svarstider i sekunder av frågor liknar Q1 och Q3 av förbättrad relationella system presenteras i 10 . Den här tabellen har ändrats från7 använder Creative Commons-licens (http://creativecommons.org/ licenses/by/4.0/) och visar de två mer-liknande frågorna till Q1 och Q3 presenteras i10 motsvarar två förbättrad relationsdatabassystem och deras svarstider. De två databasstorlekar visas också.
| ORM/MySQL | Genomströmning | Svarstiden |
| Q1 (s) | 4,711.60 | 0.0793 |
| Q3 (s) | 4,711.60 | 0.1558 |
| Q4 (s) | 4,711.60 | 0.9674 |
Tabell 6: genomsnittlig genomströmning och svar tid i sekunder av frågor Q1, Q3 och Q4 av ORM MySQL relationell Databashanterare i samtidiga utförande. Den här tabellen har ändrats från7 använder Creative Commons-licens (http://creativecommons.org/ licenses/by/4.0/) och visar det högsta Genomsnittligt dataflödet på tre single-patienten frågorna och deras genomsnittliga svarstider i samtidigt utförande experiment med ORM MySQL relationsdatabaser system.
| MongoDB | Genomströmning | Svarstiden |
| Q1 (s) | 178,672.60 | 0,003 |
| Q3 (s) | 178,672.60 | 0,0026 |
| Q4 (s) | 178,672.60 | 0.0034 |
Tabell 7: genomsnittlig genomströmning och svar tid i sekunder av frågor Q1, Q3 och Q4 av MongoDB NoSQL-DBMS i samtidiga utförande. Den här tabellen har ändrats från7 använder Creative Commons-licens (http://creativecommons.org/ licenses/by/4.0/) och visar det högsta Genomsnittligt dataflödet på tre single-patienten frågorna och deras genomsnittliga svarstider i samtidigt utförande experiment med hjälp av MongoDB NoSQL-systemet.
Kompletterande Figur1: Skärmbilden visar skärmen programvara för att ansluta till MySQL server. Vänligen klicka här för att ladda ner denna siffra.
Kompletterande figur 2: Skärmbilden visar det SQL-gränssnittet till MySQL-servern där första SQL-frågan har skrivits. Vänligen klicka här för att ladda ner denna siffra.
Kompletterande figur 3: The MongoDB 2.6 localhost server lanseras med en DOS system-fönstret genom att köra den server-mongod. Vänligen klicka här för att ladda ner denna siffra.
Kompletterande figur 4: Skärmbilden visar frågan skrivs i textrutor i Frågeverktyget som visas i steg 5.7.1 genom 5.7.4. Skärmdumpen visar steg 5.7.3. Vänligen klicka här för att ladda ner denna siffra.
Kompletterande figur 5: Skärmbilden visar steget 5.7.6. Vänligen klicka här för att ladda ner denna siffra.
Kompletterande figur 6: skärmdump illustrerar skrivandet av XPath-fråga i theupper delen av dialogrutan. Vänligen klicka här för att ladda ner denna siffra.
Discussion
Detta protokoll visar att ren relationella ORM system inte verkar praktiska för singel-patienten frågor (Q1, Q3 och Q4) eftersom svarstider är långsammare, förmodligen på grund av ett högt antal relationella tabeller utför många dyra join-operationer, och beror på den lagringssystem för av den specifika typ av databas. NoSQL-databaser lagra data i ett dokument-baserade mode, medan relationella system använder en tabell-baserade mode som sprider varje dokument i hela hela databasen. NoSQL-system visar en linjär lutning, med MongoDB utför betydligt snabbare än finns DBMS. I samtidighet fungerar MongoDB också mycket bättre än relationella MySQL ORM7.
Detta protokoll presenterar en felsökning protokoll för de resultat som presenteras i7 angående ORM MySQL DBMS. MySQL system har uppdaterats till den senaste versionen och resultaten har ändrats något. Dessutom är en kritisk punkt i dokument-baserade NoSQL-system såsom MongoDB är att de kan bevara enhetlighet när lagring medicinsk information7 eftersom när EHR utdrag uppdateras, det skrivs inte över, men en helt ny extraktet med nya data skapas och lagras i systemet, och den ursprungliga extraktet upprätthålls. Detta är ett strikt krav för medicinsk information, eftersom vissa medicinska utövare kan ha gjort viktiga medicinska beslut baserat på ursprungliga data.
Förbättrad relationella armsystemet drastiskt minskar antalet relationella tabeller och förbättrar relationella prestanda. Eftersom det ändrar schemat relationella, medicinsk information som innehas av extrakt kan tillfrågas, men extrakt kan inte återställas i sin exakta ursprungliga form.
För mycket stora databaser i sekundära använda (forskning), det är inte klart vilken databassystem är lämpligare, eftersom all-patienten frågor (Q2 och Q5) uppföra sig bättre i ORM än i NoSQL-system, men dessa system fungerar bättre än förenklade relationella system i 12. Vi anser Q6 en särskild fråga mellan klinisk praxis och sekundära använda vars beteende kan inte bestämmas av de resultat som framkommit genom dessa experiment.
En begränsning med metoden är dock inavailability direkta experiment jämföra förbättrad relationella armsystemet med NoSQL MongoDB angående singel-patient, medicinsk praxis frågor med exakt samma data används i protokollet. Vi bibehållit resultaten interpolera tabell 3 och tabell 5 angående singel-patienten frågor tills experimentet inklusive optimerad ARM i protokollet utfördes. Vi lämnar dessa experiment för framtida program. Ett kritiskt steg inom protokollet är urvalet av gratis databas, liknande programvaruversioner från senare år, så att vi kan jämföra den exakta state-of-the-art av tre tekniker.
Detta är en av de första försöken att direkt jämföra relationella och NoSQL-system som använder faktiska, realistiska, standardiserade medicinsk information. Det särskilda systemet som ska användas beror dock mycket på det faktiska fallet och problemet vara löst8.
Disclosures
Författarna har något att avslöja. De datamängder som används i dessa experiment tillhandahölls av flera spanska sjukhus under licens för dessa experiment och följaktligen är inte offentligt tillgängliga. ISO/EN 13606 RM XML-schemat lämnades av University College London centrum för hälsoinformatik & multiprofessionellt utbildning (CHIME).
Acknowledgments
Författarna vill tacka Dr Dipak Kalra, ledare för den EHRCom arbetsgrupp som definieras i ISO/EN 13606 standard och hans team från University College London för deras tillstånd att använda ISO/EN 13606 W3C XML-schemat.
Detta arbete stöds av Instituto de Salud Carlos III [grant nummer PI15/00321, PI15/00003, PI1500831, PI15CIII/00010 och 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).
