Summary
Denne studien sammenligner relasjonelle og ikke-relasjonelle (NoSQL) standardisert medisinske informasjonssystemer. Beregningsorientert kompleksiteten i responstider i spørring slik databasebehandlingssystemer (DBMS) er beregnet benytter doble store databaser. Disse resultatene hjelpe diskusjon om hensiktsmessigheten av hver database tilnærming til ulike scenarier og problemer.
Abstract
Denne forskningen viser en protokoll for å vurdere beregningsorientert kompleksiteten av relasjonelle og ikke-relasjonelle (NoSQL (ikke bare Structured Query Language)) standardisert elektroniske helse post (EHR) medisinsk informasjon databasesystemer (DBMS). Den bruker et sett med tre doble store databaser, dvs databaser lagre 5000, 10 000 og 20 000 realistisk standardisert EHR ekstrakter, i tre ulike database management systems (DBMS): relasjonelle MySQL objekt-relasjonelle kartlegging (ORM), dokumentbaserte NoSQL MongoDB og innfødt extensible markup language (XML) NoSQL finnes.
De gjennomsnittlige responstid til seks kompleksitet økende spørringer var beregnet, og resultatene viste en lineær atferd i NoSQL tilfeller. I feltet NoSQL presenterer MongoDB en mye flatere lineær helning enn eksisterer.
NoSQL systemer kan også være mer hensiktsmessig å opprettholde standardisert medisinske informasjonssystemer på grunn av spesielle natur av oppdatering av medisinsk informasjon, som ikke bør påvirke konsekvent og effektiv data lagret i NoSQL databaser.
En begrensning av denne protokollen er mangelen på direkte resultat av forbedret relasjonelle systemer som arketypen relasjonelle kartlegging (ARM) med de samme dataene. Men interpolering av dobling størrelse databaseresultatene de presentert i litteratur og andre publiserte resultatene tyder på at NoSQL systemer kan være mer passende i mange bestemte scenarier og problemer løses. For eksempel kan NoSQL være passende for dokumentbaserte oppgaver som EHR ekstrakter brukt i klinisk praksis, eller edition og visualisering eller situasjoner der målet er ikke bare å søke medisinsk informasjon, men også gjenopprette EHR i nøyaktig sin opprinnelige form.
Introduction
NoSQL (ikke bare SQL) DBMS har nylig dukket opp som et alternativ til tradisjonelle relasjonelle DBMS (RDMBS). RDBMS har dominert måten dataene var lagret i databasesystemer i flere tiår. Godt studert og forstått relasjonelle algebra og kalkulus har garantert effektivitet og konsistensen av RDBMS1. NoSQL systemer blir ikke erstatter for relasjonsdatabase-systemer, men de kan oppføre seg advantageously i visse scenarier og flere vilkår.
Noen av disse spesielle scenarier ville skje når du utformer databasen utholdenhet av elektroniske helse post (EHR) brukes til å behandle og lagre medisinsk informasjon. For å være interoperable og utholdende i praksis, flere internasjonale standarder som ISO/EN 13606, openEHR og HL72,3,4har,5 blitt brukt til å standardisere EHR ekstrakter.
Flere standarder som ISO/EN 13606 og openEHR har delt informasjon og kunnskap inn i to ulike nivåer av abstraksjon, representert ved referanse modell (RM) og spesielle datastrukturer kalt arketyper. Dette skillet kalles ofte dobbel-modell og det tillater EHR systemer å være semantisk interoperable og medisinsk kunnskap utvikles uten omprogrammering hele EHR systemet og følgelig å vedlikeholde og bærekraftig i praksis6 . Dobbel modellen implementert i standardiserte EHR systemer krever imidlertid at organiseringen av informasjon følger en bestemt struktur, og dette har dyptgripende konsekvenser i databasen utholdenhet nivået av systemet er designet7.
Objektet relasjonelle kartlegging (ORM)8 er en metodologi for å implementere et EHR system bruker relasjonsdatabase paradigmet. ORM kart grundig strukturen i standardiserte EHR ekstrakter XML (eXtensible Markup Language) filer som brukes av systemet for en relasjonsdatabase. ORM lager mange relasjonstabeller grundig følger kontoplanens standardisert EHR ekstrakter XML-filer. Disse relasjonstabeller relatert gjennom mange sekundærnøkler og resulterende systemet kan være svært effektiv.
Foreslått flere relasjonelle forbedringer ORM. Openehr's nodebanen +9 reduserer antall relasjonstabeller ved sender som serie undertrær av hele ekstraktet XML-fil i BLOBer (binary large objects). Men forårsaker denne forenklingen komplekse henting logikk, skade komplekse spørringer. Arketypen relasjonelle kartlegging (ARM)10 genererer en databasemodell drevet av arketyper, bygge et nytt relasjonelle skjema basert på tilordningene mellom arketyper og relasjonstabeller. Derfor noen av de ikke-medisinsk informasjon av EHR ekstraktet er tapt.
Mange dokumentbaserte NoSQL databaser lagrer hele dokumenter som hele BLOBs respektere en opprinnelige XML eller JSON (JavaScript Object Notation) format. Dette betyr at ingen relasjonstabeller er konstruert. Disse NoSQL databaser har ingen skjema, og de støtter ikke enten sammenføyninger eller (ACID) egenskaper11 dvs, udelbarhet, konsekvens, isolasjon og holdbarhet. Som et resultat, kan de være svært ineffektiv hvis et element i et dokument refererer til elementer av denne eller andre slike dokumenter bruker en indirekte kobling. Dette skjer fordi, for å beholde konsekvensen, hele refererte dokumenter må behandles sekvensielt. En ikke-relasjonelt database kan imidlertid være fortsatt riktig hvis oppgave utført av DBMS er en dokumentbaserte aktivitet. Dette skyldes at data kan bli værende i en form mer tett tilnærming sin sanne representasjon bruker en dokumentbaserte NoSQL database, men dette skyldes også spesielle utholdenhet policyene ved EHR medisinsk dokumenter (se drøftingen).
Formålet med metodene er å presentere flere eksperimenter for å sammenligne gjennomføringen av utholdenhet laget av et standardisert EHR system bruker tre ulike DBMSer: en relasjonsdatabase (MySQL) og to NoSQL (dokumentbaserte MongoDB og opprinnelige XML finnes). Beregningsorientert kompleksitet er beregnet og sammenlignet med tre forskjellige økende størrelse databaser og seks ulike kompleksitet økende spørringer. Tre databaseservere er installert og konfigurert lokalt i samme datamaskin der spørringer utført. Se Tabellen for materiale for tekniske detaljer.
Samtidighet eksperimenter har også blitt gjennomført for å sammenligne resultatene for relasjonelle MySQL og NoSQL MongoDB DBMSer. Beskrevet ORM forbedringer (Node + banen og ARM) har også blitt sammenlignet med relevante riktige resultater fra litteratur10.
Databasebehandlingssystemer er kontinuerlig utvikling i et akselererende tempo. Ingen ville tro om denne eksplosive utviklingen når det eksisterende paradigmet som bare var den relasjonelle modellen. Ta et eksempel, se for eksempel12, der en modell ble foreslått å implementere svartiden forbedret relasjonsdatabaser beholde egenskapene ACID.
Protocol
1. bygge et tilhørende MySQL DBMS for å lagre tre dobbel størrelse standardisert EHR ekstrakter databaser
- Importere W3C (World Wide Web Consortium) XML-skjemaet tilsvarer ISO/EN13606 Ressursbehandlingen og datatypene som ISO21090 i en 'Java IDE' (integrert utviklingsmiljø).
Merk: ISO står for International Standards Organization. NO står for europeiske normen. - Kjøre den JAXB (Java XML bindende) plug-in i IDE; Dette gir Java-klasser som tilsvarer strukturen til elementene i EHR ekstrakter XML-filer.
- Tag manuelt Java-klasser med JPA etiketter. Disse etikettene se på cardinalities og andre relasjoner mellom tabellene relasjonelle av MySQL-databasen.
- Importere bibliotekene i JPA (Java utholdenhet API) til IDE og utføre metoden som bygger en MySQL database av merket Java-klasser.
- Opprette tre mapper med 5000, 10 000 og 20 000 realistisk EHR ekstrakter XML-filer.
- Utføre JPA metoden for å laste inn et XML-utdrag i MySQL DBMS på alle ekstrakter av 5000 ekstrakter katalogen.
- Gjenta trinn 1.6 to ganger, én gang med mappen 10.000 ekstrakter og med 20.000 ekstrakter katalogen.
2. bygge et NoSQL MongoDB DBMS for å lagre tre dobbel størrelse standardisert EHR ekstrakter databaser
- Prosessen hver med tre mappene som inneholder 5 000, 10 000 og 20 000 realistisk EHR ekstrakter XML-filer med et standard program for å konvertere XML-filer til JSON filer, for eksempel json.org.XML. Tre kataloger med 5000, 10 000 og 20 000 JSON-filer skal produseres.
- Starte en MongoDB GUI (grafisk bruker grenseflate, se Tabellen for materiale).
- Starte MongoDB 2.6 serveren kjøre programmet mongod fra en DOS (Disk Operating System) system-vinduet.
- Koble MongoDB GUI til localhost server bruker port 27017.
- Velg "Koble"-menyen.
- Skrive inn et navn for tilkoblingen (for eksempel "første").
- Skriv localhost:27017 i boksen DB Server.
- Trykk "Koble"; et tre med gjeldende databaser skal vises til venstre.
- Bygge en database som inneholder 5000 standardisert EHR ekstrakter.
- Klikk på navnet på tilkoblingen på toppen av treet til venstre.
- Velg "fil"-menyen.
- Velg "Legg til Database".
- Angi navnet på databasen i dialogboksen som vises.
- Klikk på OK.
- Bygge en samling som inneholder 5000 standardisert EHR ekstrakter.
- Klikk på navnet på databasen i treet til venstre.
- Velg "Database"-menyen.
- Velg "AddCollection".
- Angi navnet på samlingen i dialogboksen som vises.
- Klikk " Opprett".
- Klikk på navnet på samlingen.
- Velg "Import"-menyen.
- Velg alternativknappen ''JSON - mongo shell / / mongoexport ".
- Klikk "neste".
- Trykk på "Legg til kildefilene".
- Naviger på datamaskinen bruker dialogboksen.
- Åpne mappen som inneholder 5000 JSON pakke ut filer.
- Merk alle filene i mappen.
- Trykk "Åpne". Listen over JSON filer skal vises i dialogboksen Import.
- Trykk "neste"; en forhåndsvisning av den nye samlingen i databasen vises til venstre.
- Trykk "neste".
- Trykk "Start Import". Fremdriften i importen vises nede til venstre, som angir antall filer importeres og medgått tid.
- Gjenta trinn 5 og 6 for å bygge en samling av 10 000 standardisert EHR ekstrakter.
- Gjenta trinn 5 og 6 for å bygge en samling av 20.000 standardisert EHR ekstrakter.
3. Bygg en NoSQL finnes DBMS til Store tre dobbel størrelse standardisert EHR ekstrakter databaser
- Starte databasen finnes .
- Bruk ikonet for databasen, åpne Java Admin klienten.
- Angi administratorpassord.
- Trykk på "Connect"-knappen.
- Bygge en samling som inneholder 5000 standardisert EHR ekstrakter.
- Velg "Opprett en ny samling"-menyen på verktøylinjen.
- I dialogboksen som vises, skriver du inn navnet på den nye kolleksjonen.
- Klikk "godta"; den nye kolleksjonen vises.
- Velg navnet på samlingen.
- Velg "lagre filer i databasen"-menyen på verktøylinjen.
- Naviger på datamaskinen bruker dialogboksen.
- Velg mappen som inneholder 5000 standardiserte XML-trekke ut filer.
- Klikk "Velg filer eller mapper til å lagre". Merk at en dialogboks viser fremdriften, filene blir lagret, og andelen av databasen opprettet.
- Gjenta trinn 5 for å bygge en samling som inneholder 10.000 standardisert EHR ekstrakter.
- Gjenta trinn 5 for å bygge en samling som inneholder 20.000 standardisert EHR ekstrakter.
4. design og utføre i 3 relasjonelle MySQL databaser 6 kompleksitet økende spørringer
- Utforme seks kompleksitet økende spørringer etter erketypene brukes av EHR ekstrakter.
- Programmet et SQL-skript med den første spørringen på MySQL database. SQL må tilpasse seg spesiell strukturen til MySQL-databasen på grunn av ekstrakter standardisering (arketyper). Databasen kart hele strukturen av ekstrakter. Som et resultat, er SQL-spørringen ganske komplisert.
- Identifisere attributtene av databasene ville fremskynde responstid for spørringene hvis en indeks ble bygget på dem, så lage slike indekser, selv om de fleste indekser bygges automatisk ved DBMSEN.
- Hvis en spørring må en ikke-automatisk innebygd indeks, bygge den manuelt.
- Koble til MySQL-serveren (supplerende figur 1).
- Velg og klikk på navnet på venstre.
- Velg og klikk på tilhørende bordet der det indekserte feltet ligger.
- Klikk på kategorien "struktur".
- Velg og klikk på kolonnen der indeksen skal bygges.
- Klikk på "indeks". Merk at SQL setningen bygge indeksen vises, og en melding om at setningen har blitt bygget vellykket vises.
- Utføre den første spørringen.
- Velg og klikk på navnet på venstre.
- Klikk på kategorien "SQL".
- Skrive eller lime inn SQL-koden for den første spørringen (se utfyllende figur 2).
- Trykk "Fortsett". Merk at den første skjermen for resultatlisten vises, sammen med en melding med kjøringstid for spørringen.
- Gjenta kjøring 5 ganger og beregne gjennomsnittlig responstid.
- Gjenta trinn 5 med spørringer 2 til 6.
- Gjør hele prosessen tre ganger, med 5000, 10 000 og 20 000 ekstrakter databaser.
5. design og utføre i 3 NoSQL MongoDB databaser 6 kompleksitet økende spørringer
- Starte MongoDB GUI (se Tabell for materiale).
- Starte MongoDB 2.6 serveren kjøre programmet mongod fra en DOS system-vinduet (se utfyllende figur 3).
- Følg trinn 2.4 koble MongoDB GUI til localhost server bruker port 27017.
- Velg og Utvid MongoDB databasen på venstre side.
- Velg samlingen.
- Klikk på "samling"-menyen på verktøylinjen.
- Utfør første MongoDB spørringen.
- Dobbeltklikk knappen "Spørreverktøyet".
- Dobbeltklikk på "spørringsfelt" av spørringsverktøyet til høyre.
- Skrive feltet MongoDB spørringen i boksen felt i spørringen panelet (se utfyllende figur 4).
- Skriv verdien av MongoDB spørringen i boksen verdi i spørring-panelet.
Merk: Denne spørringen bør være noe som {"ns3:EHRExtract.allCompositions.content.items.parts.parts.name.ns2:originalText. verdien":"Descripcion"}. Feltet og verdien er sitert og atskilt med semikolon. - Dobbeltklikk projeksjon av spørringsutformingen
- Skrive første projeksjon i projeksjon tekstboksen (se utfyllende figur 5).
- Dobbeltklikk projeksjon legge til en ny tekstboks for projeksjon.
- Skrive andre projeksjon i tekstboksen for projeksjon.
Merk: En projeksjon velger en del av dokumentet hentet av spørringen. Dette bør være noe som {"ns3:EHRExtract. allCompositions.content.items.parts.parts.value.value": 1} og {" ns3: EHRExtract.all Compositions.content.items.parts.parts.value.nullFlavor ": 1} - Klikk på den blå play-knappen for å kjøre spørringen.
- Visualisere spørringen koden i kategorien spørring koden.
- Vis detaljer om resultatet i kategorien forklaring: antall resultater, effektuering tid i millisekunder.
- Vise, utvide og undersøke resultatene i kategorien resultat.
- Hvis det er nødvendig å videre behandling av spørringen, skriv et Java-program med MongoDB Java driveren med spørringen og en metode på resultatene.
- Gjenta kjøring 5 ganger og beregne gjennomsnittlig responstid.
- Gjøre trinn 5.7 for de resterende 2 gjennom 6 spørringer.
- Gjenta hele prosessen i 5000, 10 000 og 20 000 ekstrakter MongoDB databaser.
6. utforme og utføre i 3 NoSQL finnes databaser 6 økende komplekse spørringer
- Starte finnes DBMS.
- Åpne Java Admin klienten.
- Trykk "Koble til databasen".
- Velg databasen og klikk på den.
- Klikk på menyen "konsultere bruker XPath databasen"; dialogboksen consult vises.
- Utfører første XPath-spørring (se utfyllende figur 6).
- Skriv eller lim inn XPath koden for den første spørringen øverst i dialogboksen.
- Klikk på "Kjør"-menyen i verktøylinjen i dialogboksen.
- Vis XML-resultater i "XML"-kategorien i den nedre delen av dialogboksen.
- Vis antall resultater og samling og utførelsestid nederst i dialogboksen.
- Gjenta kjøring 5 ganger og beregne gjennomsnittlig responstid.
- Gjenta trinn 6 for spørringer 2 til 6.
- Gjøre hele prosessen tre ganger, for 5000, 10 000 og 20 000 ekstrakter finnes databaser.
7. utforme og gjennomføre et samtidighet eksperiment med MySQL og MongoDB 5000 ekstrakter databaser
Merk: Eksisterer databasen ble fjernet fra eksperimentet på dette tidspunktet på grunn av verre ytelse i forrige eksperimenter.
- Velg søkene med tre korteste tid svarene i forrige eksperimenter med 5000 ekstrakter databaser (vanligvis under flere sekunder).
- Identifisere og bygge riktig attributt indekser for dem forespørsler, om nødvendig.
- Multithread programmet to Java-programmer, for MySQL og den andre for MongoDB; hvert program vil ha tre forskjellige prioriterte tråder, én for hver spørring som er valgt i trinn 1.
- Kjøre og beregne den CPU (Central Processing Unit) bruke fordeling for hver tråd (spørring).
- Kjører hver multithread programmet, klikke på Utfør fem ganger under hvert 10 minutters span, og beregne det mest utført (høyeste prioritet) gjennomsnittlig overføringshastighet og gjennomsnittlig tid svaret av disse spørringene.
- Vis spørringene i kjøring, prioriteringer og effektuering tid.
- Beregne gjennomsnittlig overføringshastighet og gjennomsnittlig responstid for hver av disse spørringene.
Representative Results
Seks ulike spørringer utført på realistisk standardisert EHR ekstrakter som inneholder informasjon om problemer av pasienter, inkludert navn, innledende og avsluttende datoer og alvorlighetsgrad, vises i tabell 1.
Gjennomsnittlig responstid seks spørringene i tre doble størrelse databaser i hver DBMS vises i tabellene 2-4. Tallene 1-6 viser de samme resultatene grafisk (merker at loddrette akser bruker svært forskjellige skalaer gjennom disse tallene).
Den sterke lineær atferden av beregningsorientert kompleksitet er tydelig gjennom alle spørringer til NoSQL databaser, men med passende forsiktighet på grunn av den relativt lille størrelsen på 3 datasett brukes. ORM relasjonsdatabasen viser imidlertid en uklart lineær atferd. MongoDB databasen har en mye flatere helning enn eksisterer databasen.
Resultater av forbedrede relasjonelle systemer diskuteres i innledningen publisert i litteraturen kan finnes i tabell 5. Interpolere MongoDB resultater fra tabell 3 med lignende spørringer og database størrelser ARM resultater fra tabell 5 tilsvarer både databasesystemer i Q1, men favoriserer MongoDB i Q3.
Resultatene av samtidighet eksperimenter kan finnes i tabell 5 og tabell6. MongoDB slår MySQL både i gjennomstrømming og responstid. Faktisk MongoDB fungerer bedre i samtidighet enn isolert, og står som en imponerende database i samtidige utførelse.
Figur 1 : Algoritmisk kompleksitet av ORM MySQL, MongoDB, og det finnes DBMS for spørringer Q1 og Q4. Dette tallet har blitt endret fra7 med Creative Commons-lisens (http://creativecommons.org/ licenses/by/4.0/) og viser responstid i sekunder for 5000, 10 000 og 20 000 størrelse EHR ekstrakter databaser for hver DBMS og spørringer Q1 og Q4. Klikk her for å se en større versjon av dette tallet.
Figur 2 : Algoritmisk kompleksitet ORM MySQL database for spørringen Q2. Denne illustrasjonen viser responstid i sekunder for 5000, 10 000 og 20 000 størrelse EHR ekstrakter ORM MySQL database for spørring Q2. Klikk her for å se en større versjon av dette tallet.
Figur 3 : Algoritmisk kompleksitet MongoDB og finnes DBMS for spørringer Q2 og Q5. Dette tallet har blitt endret fra7 med Creative Commons-lisens (http://creativecommons.org/licenses/ ved / 4.0) og viser responstid i sekunder for 5000, 10 000 og 20 000 størrelse EHR ekstrakter databaser for hver DBMS og spørringer Q2 og Q5. Klikk her for å se en større versjon av dette tallet.
Figur 4 : Algoritmisk kompleksitet av ORM MySQL DBMS for spørringer Q3 og Q5. Viser responstid i sekunder for 5000, 10 000 og 20 000 størrelse EHR ekstrakter databaser for hver DBMS og spørringer Q3 og Q5. Klikk her for å se en større versjon av dette tallet.
Figur 5: algoritmisk kompleksitet eksisterer og MongoDB DBMS for spørring Q3. Dette tallet har blitt endret fra7 med Creative Commons-lisens (http://creativecommons.org/licenses//4.0 /) og viser responstid i sekunder for 5000, 10 000 og 20 000 størrelse EHR ekstrakter databaser for hver DBMS og spørring Q3. Klikk her for å se en større versjon av dette tallet.
Figur 6 : Algoritmisk kompleksitet av ORM MySQL, finnes og MongoDB DBMS for spørre spørsmål 6. Dette tallet har blitt endret fra7 med Creative Commons-lisens (http://creativecommons.org/licenses//4.0 /) og viser responstid i sekunder for 5000, 10 000 og 20 000 størrelse EHR ekstrakter databaser for hver DBMS og spørring Sp. 6. Klikk her for å se en større versjon av dette tallet.
| Spørring | |
| Q1 | Finn alle problemer i en enkelt pasient |
| Q2 | Finn alle problemer av alle pasienter |
| Q3 | Første dato, oppløsning dato og alvorlighetsgrad |
| ett problem av en enkelt pasient | |
| Q4 | Første dato, oppløsning dato og alvorlighetsgrad |
| alle problemer problem av en enkelt pasient | |
| S5 | Første dato, oppløsning dato og alvorlighetsgrad |
| alle problemer problemet av alle pasienter | |
| SP. 6 | Finne alle pasienter med problemet 'faryngitt', |
| første dato > = 16/10/2007 ', oppløsning dato | |
| < = ' 06/05/2008 ' og alvorlighetsgrad "høy" |
Tabell 1: seks spørringene på den relasjonelle og NoSQL databaser inneholder standardisert EHR utdrag om problemer av pasienter. Denne tabellen er endret fra7 med Creative Commons-lisens (http://creativecommons.org/ licenses/by/4.0/) og viser seks kompleksitet voksende spørringer utført på tre størrelse voksende databasene for hver DBMSEN uttrykt i naturlig språk.
| ORM/MySQL | 5000 dokumenter | 10 000 dokumenter | 20.000 dokumenter |
| 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 |
| Sp. 6 (s) | 1.4382 | 2.4844 | 183.4979 |
| Databasestørrelsen | 4.6 GB | 9,4 GB | 19.4 GB |
| Totalt ekstrakter | 5000 | 10.000 | 20.000 |
Tabell 2: gjennomsnittlig responstid i sekunder for seks spørringene dobling størrelse databaser av ORM MySQL relasjonsdatabase DBMSEN. Denne tabellen viser seks svartid for hver spørring for tre doble størrelse databasene med ORM MySQL relasjonsdatabase DBMS og i minnet størrelse av tre databaser.
| MongoDB | 5000 dokumenter | 10 000 dokumenter | 20.000 dokumenter | stigningstallet (*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 |
| Sp. 6 (s) | 9.5153 | 18.5566 | 36.7805 | 1,817.68 |
| Databasestørrelsen | 1.95GB | 3,95 GB | 7.95GB | |
| Totalt ekstrakter | 5000 | 10.000 | 20.000 |
Tabell 3: gjennomsnittlig responstid i sekunder for seks spørringene dobling størrelse databaser av MongoDB NoSQL DBMSEN. Denne tabellen er endret fra7 med Creative Commons-lisens (http://creativecommons.org/ licenses/by/4.0/) og viser seks responstider i hver spørring for de tre doble store databasene med NoSQL MongoDB DBMS og i minnet størrelse av tre databaser. Lineær skråningen av hver spørring vises også.
| Finnes | 5000 dokumenter | 10 000 dokumenter | 20.000 dokumenter | stigningstallet (*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 |
| Sp. 6 (s) | 68.3798 | 138.9987 | 475.2663 | 27,125.82 |
| Databasestørrelsen | 1.25GB | 2,54 GB | 5,12 GB | |
| Totalt ekstrakter | 5000 | 10.000 | 20.000 |
Tabell 4: gjennomsnittlig responstid i sekunder for seks spørringene dobling størrelse databaser av eksisterer NoSQL DBMS. Denne tabellen er endret fra7 med Creative Commons-lisens (http://creativecommons.org/ licenses/by/4.0/) og viser seks responstider i hver spørring for tre doble størrelse databasene ved hjelp av NoSQL finnes DBMS og i minnet størrelse på tre databasene. Lineær skråningen av hver spørring vises også.
| ARM papir | ARM (s) | Noden + banen (s) | |
| Q1 | Spørringen 2.1 | 0.191 | 24.866 |
| Q3 | Spørringen 3.1 | 0,27 | 294.774 |
| Databasestørrelsen | 2,90 GB | 43.87GB | |
| Totalt ekstrakter | 29,743 | 29,743 |
Tabell 5: gjennomsnittlig responstid i sekunder for spørringer Q1 og Q3 av forbedrede relasjonelle systemer i 10 . Denne tabellen er endret fra7 med Creative Commons-lisens (http://creativecommons.org/ licenses/by/4.0/) og viser de fleste-lignende uttrykkene Q1 og Q3 presentert i10 tilsvarer to forbedret relasjonsdatabase-systemer og deres responstid. To størrelsene vises også.
| ORM/MySQL | Gjennomstrømming | Responstid |
| Q1 (s) | 4,711.60 | 0.0793 |
| Q3 (s) | 4,711.60 | 0.1558 |
| Q4 (s) | 4,711.60 | 0.9674 |
Tabell 6: gjennomsnittlig gjennomstrømning og svar tiden i sekunder for spørringer Q1, Q3 og Q4 ORM MySQL relasjonsdatabase DBMS i samtidige utførelse. Denne tabellen er endret fra7 med Creative Commons-lisens (http://creativecommons.org/ licenses/by/4.0/) og viser den høyeste gjennomsnittlig overføringshastighet på tre single-pasient spørringene og deres gjennomsnittlige responstid i samtidig kjøring av eksperiment bruker ORM MySQL relasjonsdatabase system.
| MongoDB | Gjennomstrømming | Responstid |
| Q1 (s) | 178,672.60 | 0.003 |
| Q3 (s) | 178,672.60 | 0.0026 |
| Q4 (s) | 178,672.60 | 0.0034 |
Tabell 7: gjennomsnittlig gjennomstrømning og svar tiden i sekunder for spørringer Q1, Q3 og Q4 av MongoDB NoSQL DBMS i samtidige utførelse. Denne tabellen er endret fra7 med Creative Commons-lisens (http://creativecommons.org/ licenses/by/4.0/) og viser den høyeste gjennomsnittlig overføringshastighet på tre single-pasient spørringene og deres gjennomsnittlige responstid i samtidig kjøring av eksperimentere med MongoDB NoSQL systemet.
Supplerende figur 1: bildet viser programvare skjermen for å koble til MySQL-serveren. Klikk her for å laste ned dette tallet.
Supplerende figur 2: skjermbilde viser SQL-grensesnitt til MySQL-serveren der den første SQL-spørringen har blitt skrevet. Klikk her for å laste ned dette tallet.
Supplerende figur 3: The MongoDB 2.6 localhost server startes med DOS system-vinduet ved å kjøre serveren mongod. Klikk her for å laste ned dette tallet.
Supplerende figur 4: skjermbilde viser spørringer som er skrevet i tekstboksene i spørreverktøyet som vist i trinn 5.7.1 gjennom 5.7.4. Skjermbilde illustrerer trinn 5.7.3. Klikk her for å laste ned dette tallet.
Supplerende figur 5: skjermbilde viser trinn 5.7.6. Klikk her for å laste ned dette tallet.
Supplerende figur 6: skjermbilde illustrerer skrivingen av XPath-spørring i theupper delen av dialogboksen. Klikk her for å laste ned dette tallet.
Discussion
Denne protokollen viser at ren relasjonelle ORM systemer ikke synes praktisk for single-pasient spørringer (Q1, Kv3 og Kv4) siden responstid er tregere, sannsynligvis på grunn av et høyt antall relasjonstabeller utfører mange dyre sammenføyningsoperasjoner, og grunn den lagringssystem som brukes av den bestemte typen database. NoSQL databaser lagrer data i en dokumentbaserte mote, mens relasjonsdatabase-systemer bruker en tabellbasert mote som sprer hvert dokument i hele databasen. NoSQL systemer viser en lineær skråning, med MongoDB utføre betydelig raskere enn finnes DBMS. I samtidighet fungerer MongoDB også mye bedre enn relasjonelle MySQL ORM7.
Denne protokollen presenterer en feilsøking protokoll for resultatene som presenteres i7 om ORM MySQL DBMSEN. MySQL systemet er oppdatert til nyeste versjon og resultatene er litt endret. I tillegg er et kritisk punkt i dokumentbaserte NoSQL systemer som MongoDB er at de kan beholde konsistensen når lagre medisinsk informasjon7 fordi når et EHR utdrag er oppdatert, ikke er det overskrevet, men en helt ny pakke med nye data generert og lagres i systemet, og den opprinnelige ekstrakt opprettholdes. Dette er et strenge krav av medisinsk informasjon, fordi noen leger har gjort viktige medisinsk beslutninger basert på de opprinnelige dataene.
Forbedret relasjonelle ARMEN systemet drastisk reduserer antallet relasjonstabeller og relasjonelle ytelsen forbedres. Men siden den endrer det tilhørende skjemaet, medisinsk informasjon holdt av ekstrakter kan spørres, men ekstrakter kan ikke gjenopprettes i sine eksakte opprinnelige former.
For svært store databaser i sekundære bruker (forskning), det er ikke klart hvilke databasesystem er mer hensiktsmessig, siden alle-pasient spørringene (Q2 og Q5) oppføre seg bedre i ORM enn i NoSQL systemer, men systemene utfører bedre enn den forenklede relasjonelle systemer i 12. Vi vurdere spørsmål 6 en spesiell spørring mellom klinisk praksis og sekundær bruk hvis adferd kan ikke bestemmes av resultatene som gis av disse eksperimentene.
Imidlertid er en begrensning av metoden inavailability direkte eksperimenter sammenligne forbedret relasjonelle ARMEN systemet med NoSQL MongoDB om single-pasienten, medisinske praksis spørringer med nøyaktig de samme dataene brukes i protokollen. Vi beholdt resultatene interpolere tabell 3 og tabell 5 om single-pasient spørringer før eksperimentet inkludert optimalisert ARM i protokollen ble utført. Vi la disse eksperimentene for framtidige applikasjoner. En kritisk trinn i protokollen er utvalget av gratis database, lignende programvareversjoner fra de siste årene, slik at vi kan sammenligne den nøyaktig state-of-the-art av tre teknologier.
Dette er en av de første forsøkene på å direkte sammenligne relasjonelle og NoSQL-systemer som bruker faktiske, realistisk, standardisert medisinsk informasjon. Imidlertid avhenger det aktuelle systemet som skal brukes mye på faktiske scenario og problem løst8.
Disclosures
Forfatterne ikke avsløre. Datasett i disse eksperimentene ble gitt av flere spanske sykehus lisens for disse eksperimentene, og derfor er ikke offentlig tilgjengelig. ISO/EN 13606 RM XML-skjemaet ble levert av University College London sentrum helse informatikk & Multiprofessional utdanning (KLOKKESPILL).
Acknowledgments
Forfatterne vil gjerne takke Dr. Dipak Kalra, leder av EHRCom task force som definert i ISO/EN 13606 standard og hans team fra University College London for tillatelse til å bruke ISO/EN 13606 W3C XML-skjemaet.
Dette arbeidet ble støttet av Instituto de Salud Carlos III [gi nummer 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).
