Summary
Denne undersøgelse sammenligner relationelle og ikke-relationelle (NoSQL) standardiseret medicinske informationssystemer. Svartider for forespørgsler sådanne database management systemer (DBMS) beregningsmæssige kompleksitet er beregnet ved hjælp af fordobling sized databaser. Disse resultater hjælper diskussionen om hensigtsmæssigheden af hver database tilgang til forskellige scenarier og problemer.
Abstract
Denne forskning viser en protokol til at vurdere de beregningsmæssige kompleksitet af forespørge relationelle og ikke-relationelle (NoSQL (ikke kun Structured Query Language)) standardiserede elektroniske patientjournaler post (EPJ) medicinske oplysninger databasesystemer (DBMS). Det bruger et sæt af tre fordobling sized databaser, dvs databaser lagring 5000, 10.000 og 20.000 realistisk standardiseret EPJ ekstrakter, i tre forskellige database management systems (DBMS): relationel MySQL objekt-relationelle kortlægning (ORM), dokument-baserede NoSQL MongoDB, og indfødte extensible markup language (XML) NoSQL findes.
De gennemsnitlige svartider på seks kompleksitet-stigende forespørgsler var beregnet, og resultaterne viste en lineær opførsel i sagerne NoSQL. I feltet NoSQL præsenterer MongoDB en meget fladere lineær hældning end eXist.
NoSQL systemer kan også være mere hensigtsmæssigt at opretholde standardiserede medicinske informationssystemer på grund af den særlige karakter af lægelige oplysninger, som ikke bør påvirke sammenhængen i og effektiviteten af data, der lagres i NoSQL databaser opdatering politik.
En begrænsning af denne protokol er manglen direkte resultater af forbedrede relationelle systemer såsom arketype relationelle kortlægning (ARM) med de samme data. Men interpolation af fordobling størrelse databaseresultater til dem, der præsenteres i litteratur og andre offentliggjorte resultater tyder på, at NoSQL systemer kan være mere hensigtsmæssigt i mange specifikke scenarier og problemer skal løses. For eksempel, kan NoSQL være relevante for dokument-baserede opgaver som EPJ ekstrakter anvendes i klinisk praksis, eller oplag og visualisering eller situationer, hvor formålet er ikke kun til forespørgsel medicinske oplysninger, men også at genoprette EPJ i præcis den oprindelige form.
Introduction
NoSQL (ikke kun SQL) DBMS har for nylig vist sig som et alternativ til traditionelle relationelle DBMS (RDMBS). RDBMS har domineret den måde data blev gemt i databasesystemer i årtier. Godt undersøgt og forstået relationel algebra og kalkyle har garanteret effektivitet og konsekvens af RDBMS1. NoSQL systemer bliver ikke erstatninger for relationelle systemer, men de kunne opføre sig med fordel i visse scenarier og flere betingelser.
Nogle af disse særlige situationer og betingelser vil opstå, når designe database persistens af elektroniske sundhed post (EPJ) systemer anvendes til at administrere og lagre medicinske oplysninger. For at være interoperable og bæredygtig i praksis, flere internationale standarder såsom ISO/da 13606, openEHR og HL72,3,4er,5 blevet brugt til at standardisere EPJ ekstrakter.
Flere standarder såsom ISO/da 13606 og openEHR har adskilt information og viden ind i to forskellige niveauer af abstraktion, repræsenteret af Reference Model (RM) og specielle datastrukturer, der kaldes arketyper. Denne adskillelse kaldes ofte dual model og det tillader EPJ-systemer skal semantisk interoperable og medicinsk viden til at udvikle sig uden omprogrammering hele EPJ systemet og dermed i at vedligeholde og bæredygtig i praksis6 . Dobbelt modellen gennemføres i standardiserede EPJ-systemer kræver dog, at tilrettelæggelse af oplysningskampagner følger en bestemt struktur, og det har vidtrækkende konsekvenser i den måde database persistens niveau af systemet er designet7.
Objektet relationelle kortlægning (ORM)8 er en metode til at gennemføre et EPJ-system ved hjælp af relationelle database paradigme. ORM kort udtømmende strukturen af standardiserede EPJ uddrag XML (eXtensible Markup Language) filer bruges af systemet til en relationel database. ORM konstruerer mange relationelle tabeller udtømmende efter strukturen af standardiserede EPJ uddrag XML-filer. Disse relationelle tabeller er relateret gennem mange fremmede nøgler og den deraf følgende system kan ikke være meget effektiv.
Flere relationelle forbedringer til ORM er blevet foreslået. Openehr's Node + sti9 reducerer antallet af relationelle tabeller ved serialisering undertræer af den hele uddrag XML-filen til BLOB'er (binary store objekter). Men denne forenkling forårsager komplekse hentning logik, beskadige komplekse forespørgsler. Arketype relationelle kortlægning (ARM)10 genererer en databasemodel, drevet af arketyper, bygge en ny relationel skema baseret på tilknytninger mellem arketyper og relationelle tabeller. Nogle af de ikke-medicinske oplysninger i EPJ-ekstrakt er derfor tabt.
Mange dokumentbaserede NoSQL databaser gemme hele dokumenter som hele klatter respektere en oprindelige XML- eller JSON (JavaScript Object Notation) format. Det betyder, at ingen relationelle tabeller er konstrueret. Disse NoSQL databaser har ingen skema og de understøtter ikke enten joinforbindelser eller (syre) egenskaber11, dvs, atomicitet, konsistens, isolation eller holdbarhed. Som et resultat, kan de være meget ineffektivt, hvis et element i et dokument refererer til elementer i det samme eller andre sådanne dokumenter udnytter en indirection link. Dette sker fordi, for at opretholde sammenhæng, helhed af de dokumenter, der refereres til skal behandles sekventielt. En ikke-relationelle database kan dog stadig relevante, hvis vigtigste opgave udført af DBMS er en dokumentbaseret opgave. Det skyldes, at data kan forblive i en formular mere tæt tilnærmelse dens sande repræsentation ved hjælp af en dokumentbaseret NoSQL-database, men det er også på grund af de særlige persistens politikker udført af EPJ medicinske dokumenter (Se diskussion sektion).
Formålet med metoderne er at fremvise flere eksperimenter for at sammenligne gennemførelsen af persistens lag af en standardiseret EPJ systemet ved hjælp af tre forskellige DBMS'er: en relationel (MySQL) og to NoSQL (dokument-baserede MongoDB og indfødte XML findes). Deres beregningsmæssige kompleksitet er blevet beregnet og sammenlignet ved hjælp af tre forskellige stigende størrelse databaser og seks forskellige kompleksitet-stigende forespørgsler. De tre databaseservere er installeret og konfigureret lokalt på den samme computer, hvor forespørgslerne, der er blevet udført. Se Tabel af materialer for tekniske detaljer.
Samtidighed eksperimenter er også blevet gennemført for at sammenligne effektiviteten af relationelle MySQL og NoSQL MongoDB DBMS'er. De beskrevne ORM forbedringer (Node + sti og ARM) er også blevet sammenlignet ved hjælp af relevante relevante resultater fra litteratur10.
Database management systemer udvikler sig løbende i en accelererende tempo. Ingen ville tænke over denne eksponentielle udvikling, da den eneste eksisterende paradigme var den relationelle model. For at tage et eksempel, se for eksempel12, hvor en model blev foreslået at gennemføre svartid forbedret relationelle databaser bevarer ACID-egenskaberne.
Protocol
1. bygge en relationel MySQL DBMS for at gemme tre dobbelt størrelse standardiseret EPJ ekstrakter databaser
- Import af W3C (World Wide Web Consortium) XML-skemaet svarer til ISO/EN13606 RM og ISO21090 datatyper i en 'Java IDE' (Integrated Development Environment).
Bemærk: ISO står for International Standards Organization. DA står for europæisk Norm. - Effektuere den JAXB (Java XML-bindende) plug-in i IDE; Dette producerer Java klasser svarende til strukturen i elementerne i EPJ uddrag XML-filer.
- Tag manuelt de Java klasser produceret med blandede etiketter. Disse etiketter henvise til cardinalities og andre forbindelser mellem de relationelle tabeller af MySQL-database.
- Importere biblioteker i den Blandede Parlamentariske Forsamling (Java persistens API) til IDE og effektuere den metode, der bygger en MySQL database ud af mærket Java klasser.
- Opret tre mapper med 5.000, 10.000 og 20.000 realistisk EPJ uddrag XML-filer.
- Effektuere den blandede metode for at indlæse en XML-ekstrakt i MySQL DBMS på alle uddrag af mappen 5.000 ekstrakter.
- Gentag trin 1,6 to gange, én gang med 10.000 ekstrakter register og en gang med mappen 20.000 ekstrakter.
2. bygge en NoSQL MongoDB DBMS for at gemme tre dobbelt størrelse standardiseret EPJ ekstrakter databaser
- Proces hver af de tre mapper, som indeholder 5.000, 10.000 og 20.000 realistisk EPJ uddrag XML-filer med en standard program til at konvertere XML-filer til JSON, såsom json.org.XML. Tre mapper med 5.000, 10.000 og 20.000 JSON filer bør udarbejdes.
- Lancere en MongoDB GUI (Graphic User Interface, se Tabel af materialer).
- Lancere MongoDB 2.6 server udfører programmet mongod fra et DOS (Disk Operating System) system vindue.
- Tilsluttes localhost server bruger port 27017 MongoDB GUI.
- Vælg menuen "Opret forbindelse".
- Skriv et navn for forbindelsen (for eksempel ' første').
- Skrive localhost:27017 i DB Server lærebog.
- Tryk på knappen "Connect"; et træ med de nuværende databaser skal vises til venstre.
- Opbygge en database, der indeholder 5.000 standardiseret EPJ ekstrakter.
- Klik på navnet på forbindelsen på toppen af træet til venstre.
- Vælg "fil" menu.
- Vælg "Tilføj Database".
- Angiv navnet på databasen i den viste dialog.
- Klik på OK.
- Bygge en samling, der indeholder 5.000 standardiseret EPJ ekstrakter.
- Klik på navnet på databasen i træ til venstre.
- Vælg menuen "Database".
- Vælg "AddCollection".
- Angiv navnet på samlingen i den viste dialog.
- Klik på " Opret".
- Klik på navnet på samlingen.
- Vælg menuen "Import".
- Vælg alternativknappen ''JSON - mongo shell / / mongoexport ".
- Klik på "næste".
- Tryk på knappen "Tilføj filer".
- Navigere på computeren ved hjælp af dialogboksen.
- Åbn den mappe, der indeholder 5.000 JSON uddrag filer.
- Marker alle filerne i mappen.
- Tryk på "åben". Listen over JSON filer skal vises i dialogboksen Importer.
- Tryk på "næste"; et eksempel på den nye kollektion i databasen vises til venstre.
- Tryk på "næste".
- Tryk på "Start Import". Udviklingen i importen vises ned til venstre, med angivelse af antallet af importerede filer og den forløbne tid.
- Gentag trin 5 og 6 for at opbygge en samling af 10.000 standardiseret EPJ ekstrakter.
- Gentag trin 5 og 6 for at opbygge en samling af 20.000 standardiseret EPJ ekstrakter.
3. Byg en NoSQL findes DBMS til butikken tre dobbelt størrelse standardiseret EPJ ekstrakter databaser
- Lancere databasen findes .
- Bruger databasens ikon, åbne Java Admin klienten.
- Indtast admin password.
- Tryk på knappen "Connect".
- Bygge en samling, der indeholder 5.000 standardiseret EPJ ekstrakter.
- Vælg menuen "Opret en ny samling" i værktøjslinjen.
- I den dialogboks, der vises, skal du skrive navnet på den nye kollektion.
- Klik på "Accepter"; den nye kollektion vises.
- Vælg navnet på samlingen.
- Vælg menuen "gemme filer i databasen" i værktøjslinjen.
- Navigere på computeren ved hjælp af dialogboksen.
- Vælg den mappe, der indeholder 5.000 standardiseret XML uddrag filer.
- Klik på knappen "Vælg de filer eller mapper til at gemme". Bemærk, at en dialogboks viser fremskridt, de filer, og procentdelen af den database, der oprettes.
- Gentag trin 5 for at opbygge en samling, der indeholder 10.000 standardiseret EPJ ekstrakter.
- Gentag trin 5 for at opbygge en samling, der indeholder 20.000 standardiseret EPJ ekstrakter.
4. design og udføre i de 3 relationelle MySQL databaser 6 kompleksitet-stigende forespørgsler
- Design seks kompleksitet-stigende forespørgsler efter arketyper bruges af EPJ ekstrakter.
- Programmet et SQL-script med den første forespørgsel på MySQL-database. SQL-Sætningen skal tilpasse sig til den særlige opbygning af MySQL-databasen på grund af ekstrakter standardisering (arketyper). Databasen kort hele strukturen af ekstrakterne. SQL-forespørgslen er temmelig komplekse.
- Identificere attributter af de databaser, der ville fremskynde responstid på forespørgslerne, hvis et indeks, der blev bygget på dem og derefter konstruere sådanne indekser, selv om de fleste indekser er bygget automatisk af DBMS.
- Hvis en forespørgsel har brug for en ikke-automatisk indbygget indeks, bygge det manuelt.
- Forbinde til MySQL server (tillægs figur 1).
- Vælg og klik på databasenavnet til venstre.
- Vælg og klik på tabellen relationelle hvor det indekserede felt er bosat.
- Klik på fanen "struktur".
- Vælg og klik på den kolonne, hvor indekset vil blive bygget.
- Klik på "index". Bemærk, at SQL-sætningen bygge indekset vises, og en meddelelse om, at sætningen er blevet oprettet vises.
- Effektuere den første forespørgsel.
- Vælg og klik på databasenavnet til venstre.
- Klik på fanen "SQL".
- Skriv eller Indsæt SQL-koden i den første forespørgsel (Se tillægs figur 2).
- Tryk på "Fortsæt". Bemærk, at det første skærmbillede i resultatlisten vises sammen med en besked med forespørgslen udførelsestid.
- Gentag udførelse 5 gange og beregne den gennemsnitlige svartid.
- Gentag trin 5 med forespørgsler 2 til 6.
- Gøre hele processen tre gange, med de 5.000, 10.000 og 20.000 ekstrakter databaser.
5. design og udføre i de 3 NoSQL MongoDB databaser 6 kompleksitet-stigende forespørgsler
- Lancere MongoDB GUI (Se Tabel af materialer).
- Lancere MongoDB 2.6 serveren udfører programmet mongod fra en DOS-systemet vinduet (Se supplerende figur 3).
- Følg trin 2.4 tilsluttes MongoDB GUI til localhost server bruger port 27017.
- Vælg og Udvid MongoDB database på venstre side.
- Vælg samlingen.
- Klik på menuen "samling" i værktøjslinjen.
- Effektuere den første MongoDB forespørgsel.
- Dobbeltklik på knappen "Query Builder".
- Dobbeltklik på "forespørgselsfelt" af Forespørgselsgenerator til højre.
- Skrive inden for MongoDB forespørgsel i feltet tekstboks i panelet forespørgsel (Se supplerende figur 4).
- Skriv værdien for MongoDB forespørgslen i værdi-tekstfelt i panelet forespørgsel.
Bemærk: Denne forespørgsel skal være noget som {"ns3:EHRExtract.allCompositions.content.items.parts.parts.name.ns2:originalText. værdi":"Descripcion"}. Feltet er værdien citeret og adskilt af semikolon. - Dobbeltklik på feltet projektion i forespørgselsgeneratoren
- Skrive den første projektion i projektion lærebog (Se supplerende figur 5).
- Dobbeltklik på feltet projektion til at tilføje en ny projektion tekstboks.
- Skrive den anden projektion i projektion lærebog.
Bemærk: En projektion vælger en del af dokumentet hentes af forespørgslen. Disse bør være noget lignende {"ns3:EHRExtract. allCompositions.content.items.parts.parts.value.value": 1} og {" ns3: EHRExtract.all Compositions.content.items.parts.parts.value.nullFlavor ": 1} - Klik på blå play-knappen til at udføre forespørgslen.
- Visualisere koden forespørgsel under fanen forespørgsel kode.
- Få vist detaljer om resultatet i fanen Forklaring: antallet af resultater, gennemførelsestid i millisekunder.
- Se, udvide, og undersøge resultaterne under fanen resultat.
- Hvis der kræves yderligere forarbejdning af forespørgslen, skal du skrive et Java-program med MongoDB Java driver med forespørgslen og en metode til at behandle resultaterne.
- Gentag udførelse 5 gange og beregne den gennemsnitlige svartid.
- Gøre trin 5.7 for de resterende 2 igennem 6 forespørgsler.
- Gentag hele processen i 5.000, 10.000 og 20.000 uddrag MongoDB databaser.
6. udforme og udføre i 3 NoSQL findes databaser 6 stigende kompleksitet forespørgsler
- Lancere findes DBMS.
- Åbn Java Admin klienten.
- Tryk på knappen "oprette forbindelse til databasen".
- Vælg databasen og klikke på den.
- Klik på menuen "kontakt database ved hjælp af XPath"; consult dialogboks ser ud.
- Udføre den første XPath-forespørgsel (Se supplerende figur 6).
- Skriv eller Indsæt XPath koden for den første forespørgsel i den øverste del af dialogboksen.
- Klik på menuen "Execute" på værktøjslinjen i dialogboksen.
- Se XML-resultater ved hjælp af fanen "XML" i den nederste del af dialogboksen.
- Se antallet af resultater og udarbejdelsen og gennemførelsestid nederst i dialogboksen.
- Gentag udførelse 5 gange og beregne den gennemsnitlige svartid.
- Gentag trin 6 for forespørgsler 2 til 6.
- Gøre hele processen tre gange, for 5.000, 10.000 og 20.000 uddrag findes databaser.
7. design og Udfør en samtidighed eksperiment ved hjælp af MySQL og MongoDB 5.000 ekstrakter databaser
Bemærk: eXist database er blevet fjernet fra forsøget på nuværende tidspunkt på grund af værre ydeevne i de tidligere forsøg.
- Vælg forespørgsler med de tre korteste tid svar i de tidligere eksperimenter ved hjælp af 5.000 ekstrakter databaserne (typisk under flere sekunder).
- Identificere og manuelt opbygge passende attribut indekser for disse forespørgsler, hvis det er nødvendigt.
- Programmet to Java multithread ansøgninger, én for MySQL og den anden for MongoDB; hver applikation vil have tre forskellige prioriterede emner, en for hver forespørgsel, der er valgt i trin 1.
- Udføre og beregne den CPU (Central Processing Unit) bruge fordeling for hver tråd (forespørgsel).
- Udføre hver multithread ansøgning, at klikke på knappen execute fem gange i løbet af hver 10-min span, og beregne den mest udført (højeste prioritet) forespørge gennemsnitshastigheden og den gennemsnitlige tid reaktion på de tre forespørgsler.
- Se forespørgslerne i udførelsen, prioriteringer og gennemførelsestid.
- Beregne gennemsnitshastigheden og gennemsnitlige svartid for hver af de tre forespørgsler.
Representative Results
Seks forskellige forespørgsler udføres på realistisk standardiseret EPJ ekstrakter som indeholder oplysninger om problemerne af patienter, herunder deres navne, indledende og afsluttende datoer og sværhedsgraden, er vist i tabel 1.
Gennemsnitlige responstider de seks forespørgsler i de tre fordobling størrelse databaser i hver DBMS er vist i tabel 2-4. Tallene 1-6 viser de samme resultater grafisk (Bemærk at de lodrette akser bruger meget forskellige skalaer i hele disse tal).
Den stærke lineære opførsel af beregningsmæssige kompleksitet fremgår hele alle forespørgsler af NoSQL-databaser, men med passende forsigtighed på grund af den relativt lille størrelse af de 3 datasæt anvendes. ORM relationsdatabase viser imidlertid en uklar lineær opførsel. MongoDB database har en meget fladere hældning end den eksisterende database.
Resultaterne af de forbedrede relationelle systemer drøftet i indledningen offentliggjort i litteraturen kan findes i tabel 5. Interpolering MongoDB resultaterne fra tabel 3 med lignende forespørgsler og database størrelser af ARM resultater fra tabel 5 er lig med begge databasesystemer i Q1, men favoriserer MongoDB i Q3.
Resultaterne af concurrency eksperimenter kan findes i tabel 5 og tabel6. MongoDB beats MySQL både i overførselshastighed og responstid. Faktisk MongoDB opfører sig bedre i concurrency end i isolation, og står som et imponerende database i samtidige gennemførelsen.
Figur 1 : Algoritmisk kompleksitet af ORM MySQL, MongoDB, og findes DBMS for forespørgsler Q1 og Q4. Dette tal er blevet ændret fra7 bruger Creative Commons licens (http://creativecommons.org/ licenses/by/4.0/) og viser svartider i sekunder for 5.000, 10.000 og 20.000 mellemstore EPJ ekstrakter databaser for hver DBMS og forespørgsler Q1 og Q4. Venligst klik her for at se en større version af dette tal.
Figur 2 : Algoritmisk kompleksitet af ORM MySQL DBMS for forespørgslen Q2. Denne figur viser svartider i sekunder for 5.000, 10.000 og 20.000 mellemstore EPJ ekstrakter ORM MySQL database for forespørgslen Q2. Venligst klik her for at se en større version af dette tal.
Figur 3 : Algoritmisk kompleksitet af MongoDB findes DBMS for forespørgsler Q2 og Q5 og. Dette tal er blevet ændret fra7 bruger Creative Commons licens (http://creativecommons.org/licenses/ af / 4.0) og viser svartider i sekunder for 5.000, 10.000 og 20.000 mellemstore EPJ ekstrakter databaser for hver DBMS og forespørgsler Q2 og Q5. Venligst klik her for at se en større version af dette tal.
Figur 4 : Algoritmisk kompleksitet af ORM MySQL DBMS for forespørgsler Q3 og Q5. Viser svartider i sekunder for 5.000, 10.000 og 20.000 mellemstore EPJ ekstrakter databaser for hver DBMS og forespørgsler Q3 og Q5. Venligst klik her for at se en større version af dette tal.
Figur 5: algoritmisk kompleksitet eksisterer og MongoDB DBMS for forespørgslen Q3. Dette tal er blevet ændret fra7 bruger Creative Commons licens (http://creativecommons.org/licenses//4.0 /) og viser svartider i sekunder for 5.000, 10.000 og 20.000 mellemstore EPJ ekstrakter databaser for hver DBMS og forespørgsel Q3. Venligst klik her for at se en større version af dette tal.
Figur 6 : Algoritmisk kompleksitet af ORM MySQL, findes og MongoDB DBMS for forespørgslen SP6. Dette tal er blevet ændret fra7 bruger Creative Commons licens (http://creativecommons.org/licenses//4.0 /) og viser svartider i sekunder for 5.000, 10.000 og 20.000 mellemstore EPJ ekstrakter databaser for hver DBMS og forespørgsel SP6. Venligst klik her for at se en større version af dette tal.
| Forespørgsel | |
| Q1 | Find alle problemer med en enkelt patient |
| Q2 | Find alle problemer af alle patienter |
| Q3 | Find første dato, beslutning dato og sværhedsgraden |
| af et enkelt problem af en enkelt patient | |
| Q4 | Find første dato, beslutning dato og sværhedsgraden |
| af alle problemer problem af en enkelt patient | |
| Q5 | Find første dato, beslutning dato og sværhedsgraden |
| af alle problemer problem af alle patienter | |
| SPGS. 6 | Find alle patienter med problemet 'pharyngitis', |
| første dato > = ' 16/10/2007 ', opløsning dato | |
| < = ' 06/05/2008 ' og sværhedsgraden 'høj' |
Tabel 1: seks forespørgsler udføres på den relationelle og NoSQL databaser indeholdende standardiseret EPJ uddrag om problemerne med patienter. Denne tabel er ændret fra7 bruger Creative Commons licens (http://creativecommons.org/ licenses/by/4.0/) og viser de seks kompleksitet-stigende forespørgsler udføres på de tre størrelse voksende databaser for hver DBMS udtrykt i naturlige sprog.
| 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 |
| SP6 (s) | 1.4382 | 2.4844 | 183.4979 |
| Databasestørrelse | 4.6 GB | 9,4 GB | 19.4 GB |
| Samlede ekstrakter | 5000 | 10.000 | 20.000 |
Tabel 2: gennemsnitlig svartider i sekunder af seks forespørgsler på fordobling størrelse databaser af ORM MySQL relationelle DBMS. Denne tabel viser seks svartider for hver forespørgsel til de tre fordobling sized databaser ved hjælp af ORM MySQL relationelle DBMS og i hukommelse størrelse af de tre databaser.
| MongoDB | 5000 docs | 10.000 docs | 20.000 docs | hældning (*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 |
| SP6 (s) | 9.5153 | 18.5566 | 36.7805 | 1,817.68 |
| Databasestørrelse | 1,95 GB | 3,95 GB | 7,95 GB | |
| Samlede ekstrakter | 5000 | 10.000 | 20.000 |
Tabel 3: gennemsnitlig svartider i sekunder af seks forespørgsler på fordobling størrelse databaser for MongoDB NoSQL DBMS. Denne tabel er ændret fra7 bruger Creative Commons licens (http://creativecommons.org/ licenses/by/4.0/) og viser seks svartiderne for hver forespørgsel, for de tre fordobling sized databaser ved hjælp af NoSQL MongoDB DBMS og i memory size af de tre databaser. Den lineære hældningen for hver forespørgsel, vises også.
| Findes | 5000 docs | 10.000 docs | 20.000 docs | hældning (*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 |
| SP6 (s) | 68.3798 | 138.9987 | 475.2663 | 27,125.82 |
| Databasestørrelse | 1,25 GB | 2,54 GB | 5.12GB | |
| Samlede ekstrakter | 5000 | 10.000 | 20.000 |
Tabel 4: gennemsnitlig svartider i sekunder af seks forespørgsler på fordobling størrelse databaser af eXist NoSQL DBMS. Denne tabel er ændret fra7 bruger Creative Commons licens (http://creativecommons.org/ licenses/by/4.0/) og viser seks svartiderne for hver forespørgsel, for de tre fordobling sized databaser ved hjælp af NoSQL findes DBMS og i hukommelse størrelse de tre databaser. Den lineære hældningen for hver forespørgsel, vises også.
| ARM papir | ARM (s) | Node + sti (s) | |
| Q1 | Forespørgsel 2.1 | 0.191 | 24.866 |
| Q3 | Forespørgsel 3.1 | 0,27 | 294.774 |
| Databasestørrelse | 2,90 GB | 43.87GB | |
| Samlede ekstrakter | 29,743 | 29,743 |
Tabel 5: gennemsnitlig svartider i sekunder af forespørgsler svarer til Q1 og Q3 af de forbedrede relationelle systemer præsenteret i 10 . Denne tabel er ændret fra7 bruger Creative Commons licens (http://creativecommons.org/ licenses/by/4.0/) og viser de to mest-lignende forespørgsler til Q1 og Q3 præsenteret i10 svarer til to forbedret relationelle databasesystemer og deres svartider. To database størrelserne er også vist.
| ORM/MySQL | Overførselshastighed | Svartid |
| Q1 (s) | 4,711.60 | 0.0793 |
| Q3 (s) | 4,711.60 | 0.1558 |
| Q4 (s) | 4,711.60 | 0.9674 |
Tabel 6: gennemsnitlig overførselshastighed og svar tid i sekunder for forespørgsler Q1, Q3 og Q4 af ORM MySQL relationelle DBMS i samtidige gennemførelsen. Denne tabel er ændret fra7 bruger Creative Commons licens (http://creativecommons.org/ licenses/by/4.0/) og viser den højeste gennemsnitlige gennemløb af de tre én patient forespørgsler og deres gennemsnitlige svartider i samtidigt udførelse eksperiment ved hjælp af ORM MySQL relationelle system.
| MongoDB | Overførselshastighed | Svartid |
| Q1 (s) | 178,672.60 | 0,003 |
| Q3 (s) | 178,672.60 | 0.0026 |
| Q4 (s) | 178,672.60 | 0.0034 |
Tabel 7: gennemsnitlig overførselshastighed og svar tid i sekunder for forespørgsler Q1, Q3 og Q4 af MongoDB NoSQL DBMS i samtidige gennemførelsen. Denne tabel er ændret fra7 bruger Creative Commons licens (http://creativecommons.org/ licenses/by/4.0/) og viser den højeste gennemsnitlige gennemløb af de tre én patient forespørgsler og deres gennemsnitlige svartider i samtidigt udførelse eksperiment ved hjælp af MongoDB NoSQL system.
Tillægs figur 1: screenshot viser skærmbilledet software til at forbinde til MySQL server. Venligst klik her for at downloade denne figur.
Tillægs figur 2: skærmbilledet viser SQL interface til MySQL-serveren, hvor den første SQL forespørgsel er blevet skrevet. Venligst klik her for at downloade denne figur.
Supplerende figur 3: The MongoDB 2.6 localhost server startes ved hjælp af et DOS system vindue ved at udføre server mongod. Venligst klik her for at downloade denne figur.
Supplerende figur 4: screenshot viser forespørgslen skrevet i tekstboksene i forespørgselsgeneratoren, som vist i trin 5.7.1 gennem 5.7.4. Skærmbilledet viser trin 5.7.3. Venligst klik her for at downloade denne figur.
Supplerende figur 5: screenshot viser trin 5.7.6. Venligst klik her for at downloade denne figur.
Supplerende figur 6: screenshot illustrerer skrivning af XPath-forespørgsel i theupper del af dialogboksen. Venligst klik her for at downloade denne figur.
Discussion
Denne protokol viser, at ren relationelle ORM systemer ikke synes praktisk for én patient forespørgsler (Q1, Q3 og Q4) da svartider er langsommere, sandsynligvis på grund af et højt antal relationstabeller udfører mange dyre joinhandlinger, og skyldes den storagesystem brugt af den særlige form for database. NoSQL databaser gemme data i et dokument-baserede mode, mens relationelle systemer bruger en tabelbaseret mode, der spreder sig hvert dokument overalt i hele databasen. NoSQL systemer viser en lineær skråning med MongoDB udfører betydeligt hurtigere end findes DBMS. I concurrency fungerer MongoDB også meget bedre end relationelle MySQL ORM7.
Denne protokol udgør en fejlfinding protokol for resultaterne præsenteres i7 vedrørende ORM MySQL DBMS. MySQL system er blevet opdateret til den nyeste version og resultaterne har været ændret en smule. Desuden er et kritisk punkt i dokument-baserede NoSQL systemer såsom MongoDB er, at de kan bevare konsistens, når opbevaring medicinsk information7 fordi når EPJ uddrag opdateres, ikke overskrives det, men en hel ny uddrag med de nye data oprettet og gemt i systemet, og den oprindelige ekstrakt er opretholdt. Dette er en strengt krav om lægelige oplysninger, fordi nogle læger kan have gjort vigtige medicinske beslutninger baseret på de oprindelige data.
Forbedret relationelle ARM systemet drastisk formindsker antallet af relationelle tabeller og forbedrer relationelle ydeevne. Men da det ændrer den relationelle skema, medicinske oplysninger afholdt af ekstrakter kan forespørges, men ekstrakter kan ikke være genoprettet i deres nøjagtige oprindelige former.
For meget store databaser i sekundær brug (forskning), det er ikke klart, hvilken databasesystem er mere passende, da de alle-patient forespørgsler (Q2 og Q5) opføre sig bedre i ORM end i NoSQL systemer, men disse systemer klarer sig bedre end den forenklede relationelle systemer i 12. Vi overveje SP6 en speciel forespørgsel i mellem klinisk praksis og sekundær brug hvis adfærd ikke kan bestemmes af de resultater af disse eksperimenter.
Dog er en begrænsning af metoden inavailability direkte forsøg sammenligner den forbedrede relationelle ARM system med NoSQL MongoDB med hensyn til én patient, medicinsk praksis forespørgsler med præcis de samme data, der bruges i protokollen. Vi fastholdt resultater interpolering tabel 3 og tabel 5 vedrørende én patient forespørgsler indtil forsøget, herunder optimeret ARM i protokollen blev udført. Vi forlader disse eksperimenter for fremtidige ansøgninger. Et kritisk trin i protokollen er Udvalget af gratis database, lignende softwareversioner fra de seneste år, således at vi kan sammenligne de nøjagtige state-of-the-art af de tre teknologier.
Dette er en af de første forsøg på at direkte sammenligne relationelle og NoSQL systemer ved hjælp af egentlige, realistiske, standardiseret medicinsk information. Det særlige system skal anvendes afhænger imidlertid meget faktiske scenario og problemet at være løst8.
Disclosures
Forfatterne har ikke noget at oplyse. De datasæt, der anvendes i disse eksperimenter blev leveret af flere spanske hospitaler under licens til disse eksperimenter og derfor er ikke offentligt tilgængelige. ISO/da 13606 RM XML-skemaet blev leveret af University College London Centre for Health Informatics & Multiprofessional uddannelse (CHIME).
Acknowledgments
Forfatterne vil gerne takke Dr. Dipak Kalra, leder af EHRCom taskforce, som defineret i ISO/da 13606 standard og hans team fra University College London for deres slags tilladelse til at bruge ISO/da 13606 W3C XML-skema.
Dette arbejde blev støttet af Instituto de Salud Carlos III [grant tal PI15/00321, PI15/00003, PI1500831, PI15CIII/00010 og 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).
