Summary
Questo studio confronta relazionali e non relazionali (NoSQL) standardizzato di sistemi di informazione medica. La complessità computazionale dei tempi di risposta di una query su tali sistemi di gestione di database (DBMS) viene calcolata utilizzando il database di dimensioni raddoppio. Questi risultati aiutano la discussione dell'adeguatezza di ogni approccio database per diversi scenari e problemi.
Abstract
Questa ricerca dimostra un protocollo per valutare la complessità computazionale di una query relazionale e non relazionali (NoSQL (non solo Structured Query Language)) standardizzati sistemi di electronic health record (EHR) informazioni mediche database (DBMS). Utilizza un set di tre dimensioni raddoppio database, cioè database memorizzazione 5000, 10.000 e 20.000 realistico EHR estratti, standardizzati in tre sistemi di gestione di diversi database (DBMS): relazionale MySQL object-relational mapping (ORM), Basato su documento NoSQL MongoDB e nativo extensible markup language (XML) NoSQL esiste.
I tempi di risposta medio a sei domande di crescente complessità sono stati computati, e i risultati hanno mostrato un comportamento lineare nei casi di NoSQL. Nel campo NoSQL MongoDB presenta una molto più piatta pendenza lineare di esistere.
Sistemi di NoSQL possono anche essere più opportuno mantenere i sistemi di informazione medica standardizzata a causa della natura speciale di criteri di aggiornamento delle informazioni mediche, che non dovrebbe pregiudicare la coerenza e l'efficienza dei dati memorizzati in database NoSQL.
Una limitazione di questo protocollo è la mancanza di risultati diretti di miglioramento dei sistemi relazionali come mapping relazionale archetipo (braccio) con gli stessi dati. Tuttavia, l'interpolazione dei risultati raddoppiamento della dimensione del database a quelli presentati nella letteratura e altri risultati pubblicati suggerisce che i sistemi di NoSQL potrebbero essere più appropriati in molti scenari specifici e problemi da risolvere. Ad esempio, NoSQL potrebbe essere appropriato per le attività basate su documenti come EHR estratti utilizzati nella pratica clinica, o edizione e visualizzazione o situazioni in cui l'obiettivo è non solo alla ricerca di informazioni mediche, ma anche per ripristinare la CCE in esattamente la sua forma originale.
Introduction
NoSQL (non solo SQL) DBMS recentemente sono emerso come alternativa al DBMS relazionali tradizionali (RDMBS). RDBMS hanno dominato il modo dati sono stati memorizzati in sistemi di database per decenni. Calcolo infinitesimale e algebra relazionale ben studiato e capito hanno garantito l'efficienza e la coerenza di RDBMS1. Sistemi di NoSQL non diventerà sostituti per sistemi relazionali, ma si potrebbe comportano vantaggiosamente in determinati scenari e condizioni diverse.
Alcuni di questi scenari particolari e condizioni potrebbe verificarsi quando si progetta la persistenza di database dei sistemi di Electronic Health Record (EHR) utilizzati per gestire e archiviare informazioni mediche. Al fine di essere interoperabile e sostenibile nella pratica, vari standard internazionali quali ISO/EN 13606, openEHR e HL72,3,4,5 sono stati usati per standardizzare gli estratti EHR.
Diversi standard quali ISO/EN 13606 e openEHR sono separati informazioni e conoscenze in due diversi livelli di astrazione, rappresentato da modello di riferimento (RM) e strutture di dati speciale chiamate archetipi. Questa separazione è spesso chiamata il modello dual e consente i sistemi CCE essere conoscenza semanticamente interoperabile e medica di evolversi senza riprogrammare l'intero sistema EHR e, di conseguenza, essere gestibile e sostenibile in pratica6 . Tuttavia, il modello dual implementato in sistemi standardizzati di EHR richiede che l'organizzazione delle informazioni segue una struttura specifica, e questo ha conseguenze profonde nel modo che il livello di persistenza di database del sistema è progettato7.
Object Relational Mapping (ORM)8 è un'unica metodologia per implementare un sistema di CCE utilizzando il paradigma di database relazionale. ORM mappe esaustivamente la struttura del standardizzato EHR estrazione di file XML (eXtensible Markup Language) utilizzato dal sistema per un database relazionale. ORM costruisce molte tabelle relazionali esaustivamente seguendo la struttura dei file XML di estratti EHR standardizzati. Queste tabelle relazionali sono correlate tramite molte chiavi esterne e il sistema risultante potrebbe non essere molto efficiente.
Sono stati proposti diversi miglioramenti relazionali di ORM. + Percorso del nodo9 di openEHR riduce il numero di tabelle relazionali di sottoalberi serializzazione dell'estratto intero file XML in BLOB (binary large objects). Tuttavia, questa semplificazione causa logica di recupero complesso, danneggiando query complesse. Archetipo relazionale Mapping (braccio)10 genera un modello di database guidato da archetipi, costruzione di un nuovo schema relazionale basato sul mapping tra archetipi e tabelle relazionali. Di conseguenza, alcune delle informazioni non-medici dell'estratto EHR è persa.
Molti database NoSQL documentali memorizzare interi documenti come intero blob rispettando un originale XML o JSON (JavaScript Object Notation) formato. Ciò significa che nessun tabelle relazionali vengono costruite. Questi database NoSQL non hanno nessun schema e non supportano join o (acido) proprietà11, vale a dire, atomicità, consistenza, isolamento o durata. Di conseguenza, possono essere molto inefficiente se un elemento di un documento fa riferimento a elementi dello stesso o di altri documenti che utilizzano un collegamento di riferimento indiretto. Ciò accade perché, al fine di mantenere la coerenza, la totalità dei documenti cui si fa riferimento devono essere elaborati in sequenza. Tuttavia, un database non relazionali può essere ancora appropriato se l'attività principale eseguita dal DBMS è un'attività basata su documento. Infatti, dati possono rimanere in una forma più strettamente approssimata rappresentazione vera, utilizzando un database NoSQL basato su documento, anche se questo è anche a causa delle politiche di persistenza speciale compiute da documenti medici EHR (Vedi sezione discussione).
Lo scopo di questi metodi è quello di mostrare diversi esperimenti per confrontare l'implementazione dello strato di persistenza di un sistema standardizzato di EHR utilizzando tre diversi DBMS: uno relazionali (MySQL) e due NoSQL (MongoDB basati su documenti e nativo XML esistono). Loro complessità computazionale è stato calcolato e confrontato utilizzando tre diversi database di dimensioni crescenti e sei diverse query di crescente complessità. I tre database server sono stati installati e configurati localmente sullo stesso computer dove sono state eseguite le query. Vedi la Tabella materiali per dettagli tecnici.
Inoltre sono stati condotti esperimenti di concorrenza al fine di confrontare le prestazioni di MySQL e NoSQL MongoDB DBMS relazionali. I miglioramenti descritti di ORM (percorso + nodo e braccio) sono stati confrontati anche con rilevanti risultati appropriati dalla letteratura10.
Sistemi di gestione di database sono in continua evoluzione ad un ritmo accelerato. Nessuno penserebbe di questo sviluppo esponenziale quando il paradigma unico esistente era il modello relazionale. Per fare un esempio, vedere ad esempio12, dove è stato proposto un modello per implementare tempi di risposta migliorati database relazionali conservando le proprietà ACID.
Protocol
1. costruire un DBMS relazionale MySQL per memorizzare tre doppie dimensioni standardizzate EHR estratti database
- Importare il W3C (World Wide Web Consortium) XML Schema corrispondente ISO/EN13606 RM e i tipi di dati ISO21090 in un 'Java IDE' (Integrated Development Environment).
Nota: ISO è acronimo di International Standards Organization. IT sta per European Norm. - Eseguire il JAXB (Java XML Binding) plug-nell'IDE; Questo produce classi Java corrispondenti alla struttura degli elementi del file XML estratti EHR.
- Tag manualmente le classi Java producerat con etichette JPA. Queste etichette si riferiscono le cardinalità e altre relazioni tra le tabelle relazionali del database MySQL.
- Importare le librerie di JPA (Java Persistence API) nell'IDE ed eseguire il metodo che crea un database MySQL fuori le classi Java taggati.
- Creare tre cartelle con 5.000, 10.000 e 20.000 EHR realistico estrae i file XML.
- Eseguire il metodo JPA per caricare un estratto XML nel DBMS MySQL su tutti gli estratti della directory 5.000 estratti.
- Ripetere il passaggio 1.6 due volte, una volta con la directory di 10.000 estratti e una volta con la directory di 20.000 estratti.
2. costruire un DBMS NoSQL MongoDB per memorizzare tre doppie dimensioni standardizzate EHR estratti database
- Ogni processo delle tre directory contenente 5.000, 10.000 e 20.000 realistico EHR estratti XML file con un programma standard per convertire i file XML in file JSON, ad esempio json.org.XML. Tre cartelle con file JSON 5.000, 10.000 e 20.000 dovrebbero essere prodotto.
- Lanciare un MongoDB GUI (Graphic User Interface, Vedi Tabella materiali).
- Avviare il MongoDB 2.6 server l'esecuzione del programma di mongod da una finestra di sistema DOS (Disk Operating System).
- Collegare la GUI di MongoDB al server localhost utilizzando la porta 27017.
- Selezionare il menu "Connetti".
- Scrivere un nome per la connessione (ad esempio ' prima').
- Scrivere localhost:27017 nella casella di testo Server DB.
- Premere il pulsante "Connetti"; un albero con i database correnti deve essere visualizzato sulla sinistra.
- Costruire un database contenente 5.000 EHR standardizzati estratti.
- Clicca sul nome della connessione nella parte superiore dell'albero sulla sinistra.
- Selezionare il menu "File".
- Scegliere "Aggiungi Database".
- Immettere il nome del database nella finestra di dialogo che appare.
- Fare clic su OK.
- Costruire una collezione contenente 5.000 EHR standardizzati estratti.
- Clicca sul nome del database nella struttura a sinistra.
- Selezionare il menu "Database".
- Scegliere "AddCollection".
- Immettere il nome della raccolta nella finestra di dialogo che appare.
- Fare clic su " Crea".
- Clicca sul nome della raccolta.
- Selezionare il menu "Import".
- Scegliere il pulsante di opzione 'JSON - shell mongo / / mongoexport ".
- Fare clic su "prossimo".
- Premere il pulsante "Aggiungi file di origine".
- Navigare sul computer utilizzando la finestra di dialogo.
- Apri la directory contenente 5.000 JSON estrarre file.
- Selezionare tutti i file nella directory.
- Premere "Apri". L'elenco dei file JSON dovrebbe apparire nella finestra di importazione.
- Premere "Avanti"; a sinistra viene visualizzata un'anteprima della nuova collezione nel database.
- Fare clic su "prossimo".
- Premere il tasto "Avvia importazione". L'avanzamento dell'importazione appare giù sulla sinistra, che indica il numero di file importati ed il tempo trascorso.
- Ripetere i passaggi 5 e 6 per creare una raccolta di 10.000 EHR standardizzati estratti.
- Ripetere i passaggi 5 e 6 per creare una raccolta di 20.000 EHR standardizzati estratti.
3. compilazione un NoSQL esiste DBMS tre doppie dimensioni standardizzate EHR estrae database di archivio
- Avviare il database esiste .
- Utilizzando l'icona del database, aprire il Client di amministrazione di Java.
- Immettere la password di admin.
- Premere il pulsante "Connetti".
- Costruire una collezione contenente 5.000 EHR standardizzati estratti.
- Nella barra degli strumenti, selezionare il menu "Crea una nuova collezione".
- Nella finestra di dialogo che appare, digitare il nome della nuova collezione.
- Fare clic su "accetta"; verrà visualizzata la nuova collezione.
- Selezionare il nome della raccolta.
- Nella barra degli strumenti, selezionare il menu "file di archivio nel database".
- Navigare sul computer utilizzando la finestra di dialogo.
- Selezionare la directory contenente 5.000 file di Estratto standardizzati di XML.
- Fare clic sul pulsante "Seleziona il file o la directory per archiviare". Si noti che verrà visualizzata una finestra di dialogo che mostra lo stato di avanzamento, i file memorizzati e la percentuale del database creato.
- Ripetere il passaggio 5 per costruire un insieme contenente 10.000 EHR standardizzati estratti.
- Ripetere il passaggio 5 per costruire un insieme contenente 20.000 EHR standardizzati estratti.
4. progettare ed eseguire nei database relazionali MySQL 3 6 Queries di crescente complessità
- Progettazione di query di crescente complessità sei secondo gli archetipi utilizzati dagli estratti EHR.
- Programma uno script SQL con la prima query su database MySQL. L'istruzione SQL deve adattarsi alla speciale struttura del database MySQL a causa di estratti di standardizzazione (archetipi). Il database di mappe: l'intera struttura degli estratti. Di conseguenza, la query SQL è piuttosto complessa.
- Identificare gli attributi dei database che dovrebbe accelerare i tempi di risposta delle query, se un indice è stato costruito su di loro, quindi costruire tali indici, anche se la maggior parte degli indici vengono compilata automaticamente dal DBMS.
- Se una query ha bisogno di un indice non automaticamente generato, è possibile compilarlo manualmente.
- Connettersi al server MySQL (complementare figura 1).
- Selezionare e fare clic sul nome del database sulla sinistra.
- Selezionare e fare clic sulla tabella relazionale dove risiede il campo indicizzato.
- Fare clic sulla scheda "struttura".
- Selezionare e fare clic sulla colonna dove sorgerà l'indice.
- Fare clic su "Indice". Si noti che viene visualizzata la frase SQL creando un indice, e appare un messaggio che indica che la frase è stata costruita con successo.
- Eseguire la prima query.
- Selezionare e fare clic sul nome del database sulla sinistra.
- Fare clic sulla scheda "SQL".
- Scrivere o incollare il codice SQL della query prima (Vedi complementare figura 2).
- Premere "continuare". Si noti che viene visualizzata la prima schermata della lista dei risultati, insieme a un messaggio con il tempo di esecuzione della query.
- Ripetere 5 volte, l'esecuzione e calcolare il tempo medio di risposta.
- Ripetere il passaggio 5 con query 2 a 6.
- Fare tre volte, l'intero processo con i database di estratti di 5.000, 10.000 e 20.000.
5. progettare ed eseguire nei database NoSQL MongoDB 3 6 Queries di crescente complessità
- Lanciare la GUI di MongoDB (Vedi Tabella materiali).
- Avviare il server MongoDB 2.6 l'esecuzione del programma di mongod da una finestra di sistema DOS (vedere complementare figura 3).
- Seguire il passaggio 2.4 a cui connettersi il server localhost porta 27017 la GUI di MongoDB.
- Selezionare ed espandere il database MongoDB sul lato sinistro.
- Selezionare la raccolta.
- Fare clic sul menu "collezione" nella barra degli strumenti.
- Eseguire la prima query MongoDB.
- Fare doppio clic sul pulsante "Query Builder".
- Fare doppio clic sul "campo di Query" del generatore di Query a destra.
- Scrivere il campo della query MongoDB in campo casella di testo del pannello delle query (Vedi complementare figura 4).
- Scrivi il valore della query MongoDB in casella di testo valore di pannello delle query.
Nota: Questa query deve essere qualcosa di simile a {ns3:EHRExtract.allCompositions.content.items.parts.parts.name.ns2:originalText". valore":"Descripcion"}. Il campo e il valore sono tra virgolette e separati da punto e virgola. - Fare doppio clic sul campo di proiezione del generatore di Query
- Scrivere la prima proiezione in textbox proiezione (Vedi complementare figura 5).
- Fare doppio clic sul campo per aggiungere un nuovo controllo textbox proiezione proiezione.
- Scrivere la seconda proiezione nella casella di proiezione.
Nota: Una proiezione consente di selezionare una parte del documento estratto dalla query. Questi dovrebbero essere qualcosa di simile a {ns3:EHRExtract". allCompositions.content.items.parts.parts.value.value": 1} e {" ns3: EHRExtract.all Compositions.content.items.parts.parts.value.nullFlavor ": 1} - Fare clic sul pulsante play blu per eseguire la query.
- Visualizzare il codice della query nella scheda Query codice.
- Visualizzare i dettagli del risultato nella scheda Descrizione: numero di risultati, tempo di esecuzione in millisecondi.
- Mostra, espandere ed esaminare i risultati nella scheda risultati.
- Se è necessaria ulteriore elaborazione della query, è possibile scrivere un programma Java con il driver MongoDB Java con la query e un metodo per elaborare i risultati.
- Ripetere 5 volte, l'esecuzione e calcolare il tempo medio di risposta.
- Passo 5.7 per i restanti 2 attraverso 6 queries.
- Ripetere l'intero processo nel 5.000, 10.000 e 20.000 estratti database MongoDB.
6. progettare ed eseguire in 3 NoSQL esistono database 6 crescente complessità query
- Lanciare l' esistere DBMS.
- Aprire il Client di amministrazione di Java.
- Premere il pulsante "connettersi al database".
- Selezionare il database e fare clic su di esso.
- Fare clic sul menu "consultare il database utilizzando XPath"; viene visualizzata la finestra di finestra di dialogo consult.
- Eseguire la prima query XPath (Vedi complementare figura 6).
- Scrivere o incollare il codice di XPath della prima query nella parte superiore della finestra di dialogo.
- Fare clic sul menu "Esegui" nella barra degli strumenti della finestra di dialogo.
- Mostra risultati XML utilizzando la scheda "XML" nella parte inferiore della finestra di dialogo.
- Mostra il numero di risultati e compilazione e tempo di esecuzione nella parte inferiore della finestra di dialogo.
- Ripetere 5 volte, l'esecuzione e calcolare il tempo medio di risposta.
- Ripetere il passaggio 6 per query 2 a 6.
- Fare l'intero processo tre volte, per gli estratti di 5.000, 10.000 e 20.000 esistono database.
7. progettare ed eseguire un esperimento di concorrenza utilizzando il MySQL e database di estratti di MongoDB 5.000
Nota: Il database di esistere è stato rimosso dall'esperimento in questo frangente a causa di peggio prestazioni negli esperimenti precedenti.
- Selezionare la query con le tre risposte di tempo più breve in precedenti esperimenti utilizzando i database di 5.000 estratti (in genere in alcuni secondi).
- Identificare e creare manualmente gli indici di attributo appropriato per tali query, se necessario.
- Programma due applicazioni multithread di Java, uno per MySQL e l'altra per MongoDB; ogni applicazione avrà tre thread con priorità diverse, una per ogni query selezionata nel passaggio 1.
- Eseguire e calcolare la CPU (Central Processing Unit) che utilizzano la distribuzione per ciascun thread (query).
- Eseguire ogni applicazione multithread, facendo clic sul pulsante Esegui cinque volte durante ogni intervallo di 10 min e calcolare il più eseguita (priorità massima) query produttività media e la risposta di tempo medio di tre query.
- Visualizzare le query in esecuzione, con priorità e tempi di esecuzione.
- Calcolare la velocità effettiva media e tempo di risposta medio di ognuna delle tre query.
Representative Results
Sei diverse query eseguite su realistici estratti standardizzati di EHR contenente informazioni sui problemi dei pazienti, compreso i loro nomi, le date iniziale e finale e gravità, sono riportate nella tabella 1.
Tempi di risposta medi delle sei query nei tre raddoppiamento della dimensione del database in ogni DBMS sono mostrati nelle tabelle 2-4. Figure 1-6 Visualizza graficamente gli stessi risultati (si noti che gli assi verticali utilizzano scale molto diverse nel corso di queste figure).
Il comportamento lineare forte di complessità computazionale è evidente in tutto tutte le query dei database NoSQL, sebbene con un'appropriata cautela a causa delle dimensioni relativamente piccole dei 3 set di dati utilizzati. Tuttavia, il database relazionale di ORM Mostra un chiaro comportamento lineare. Il database MongoDB ha una pendenza molto più piatta rispetto al database di esistere.
Risultati per il miglioramento dei sistemi relazionali discusso nell'introduzione pubblicato nella letteratura possono essere trovati nella tabella 5. Interpolando MongoDB risultati dalla tabella 3 con query simili e dimensioni del database di braccio risultati dalla tabella 5 è uguale a due sistemi di database in Q1, ma favorisce MongoDB in Q3.
I risultati degli esperimenti della concorrenza possono essere trovati nella tabella 5 e tabella6. MongoDB batte MySQL sia nella velocità effettiva e tempo di risposta. Infatti, MongoDB si comporta meglio in concorrenza più in isolamento e si pone come un impressionante database in esecuzione simultanea.
Figura 1 : Complessità algoritmica di ORM MySQL, MongoDB, ed esistono DBMS per query Q1 e Q4. Questa figura è stata modificata da7 con licenza Creative Commons (http://creativecommons.org/ licenses/by/4.0/) e indica i tempi di risposta in secondi per 5.000, 10.000 e 20.000 imprese EHR estrae il database per ogni query Q1 e Q4 e DBMS. Clicca qui per visualizzare una versione più grande di questa figura.
Figura 2 : Complessità algoritmica del DBMS MySQL ORM per la query Q2. Questa figura mostra i tempi di risposta in pochi secondi per 5.000, 10.000 e 20.000 imprese EHR estrae ORM MySQL database per la query Q2. Clicca qui per visualizzare una versione più grande di questa figura.
Figura 3 : Complessità algoritmica di MongoDB e DBMS per query Q2 e Q5 esiste. Questa figura è stata modificata da7 con licenza Creative Commons (http://creativecommons.org/licenses/ di / 4.0) e indica i tempi di risposta in secondi per 5.000, 10.000 e 20.000 dimensioni EHR estrae il database per ogni query Q2 e Q5 e DBMS. Clicca qui per visualizzare una versione più grande di questa figura.
Figura 4 : Complessità algoritmica del DBMS MySQL ORM per query Q3 e Q5. Indica i tempi di risposta in secondi per 5.000, 10.000 e 20.000 imprese EHR estrae il database per ogni query Q3 e Q5 e DBMS. Clicca qui per visualizzare una versione più grande di questa figura.
Figura 5: complessità algoritmica di esistere e MongoDB DBMS per query Q3. Questa figura è stata modificata da7 con licenza Creative Commons (http://creativecommons.org/licenses//4.0 /) e indica i tempi di risposta in secondi per 5.000, 10.000 e 20.000 imprese EHR estrae il database per ogni query Q3 e DBMS. Clicca qui per visualizzare una versione più grande di questa figura.
Figura 6 : Complessità algoritmica di ORM MySQL, esiste e MongoDB DBMS per eseguire query Q6. Questa figura è stata modificata da7 con licenza Creative Commons (http://creativecommons.org/licenses//4.0 /) e indica i tempi di risposta in secondi per 5.000, 10.000 e 20.000 imprese EHR estrae il database per ogni query Q6 e DBMS. Clicca qui per visualizzare una versione più grande di questa figura.
| Query | |
| 1 ° TRIMESTRE | Trovare tutti i problemi di un singolo paziente |
| Q2 | Trovare tutti i problemi di tutti i pazienti |
| Q3 | Trovare la data iniziale, la data di risoluzione e la gravità |
| di un singolo problema di un singolo paziente | |
| Q4 | Trovare la data iniziale, la data di risoluzione e la gravità |
| di tutti i problemi problema di un singolo paziente | |
| Q5 | Trovare la data iniziale, la data di risoluzione e la gravità |
| di tutti i problemi problema di tutti i pazienti | |
| Q6 | Trovare tutti i pazienti con 'faringite' problema, |
| Data iniziale > = 16 ottobre 2007 ', data di risoluzione | |
| < = 5 giugno 2008 ' e gravità 'alta' |
Tabella 1: le sei query eseguite su relazionale e database NoSQL EHR standardizzati contenenti estratti sui problemi dei pazienti. Questa tabella è stata modificata da7 con licenza Creative Commons (http://creativecommons.org/ licenses/by/4.0/) e Mostra le sei crescente complessità query eseguite sui tre crescente dimensione del database per ogni DBMS espresso in naturale lingua.
| ORM/MySQL | 5000 documenti | 10.000 documenti | 20.000 documenti |
| 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 |
| Q6 (s) | 1.4382 | 2.4844 | 183.4979 |
| Dimensione del database | 4.6 GB | 9.4 GB | 19,4 GB |
| Estratti totali | 5000 | 10.000 | 20.000 |
Tabella 2: media tempi di risposta in pochi secondi delle sei query il raddoppiamento della dimensione del database del DBMS relazionali MySQL ORM. Questa tabella Mostra sei tempi di risposta per ogni query per i tre database di raddoppio dimensioni utilizzando il DBMS relazionale MySQL ORM e le dimensioni in memoria dei tre database.
| MongoDB | 5000 documenti | 10.000 documenti | 20.000 documenti | pendenza (*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 |
| Q6 (s) | 9.5153 | 18.5566 | 36.7805 | 1,817.68 |
| Dimensione del database | 1,95 GB | 3,95 GB | 7,95 GB | |
| Estratti totali | 5000 | 10.000 | 20.000 |
Tabella 3: media tempi di risposta in pochi secondi delle sei query il raddoppiamento della dimensione del database del DBMS NoSQL MongoDB. Questa tabella è stata modificata da7 con licenza Creative Commons (http://creativecommons.org/ licenses/by/4.0/) e indica i tempi di sei risposta di ogni query per i tre database di raddoppio dimensioni utilizzando il DBMS di MongoDB NoSQL e le dimensioni in memoria dei tre database. Viene mostrata anche la pendenza lineare di ogni query.
| Esistono | 5000 documenti | 10.000 documenti | 20.000 documenti | pendenza (*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 |
| Q6 (s) | 68.3798 | 138.9987 | 475.2663 | 27,125.82 |
| Dimensione del database | 1.25GB | 2,54 GB | 5,12 GB | |
| Estratti totali | 5000 | 10.000 | 20.000 |
Tabella 4: media tempi di risposta in pochi secondi delle sei query il raddoppiamento della dimensione del database del esistono NoSQL DBMS. Questa tabella è stata modificata da7 con licenza Creative Commons (http://creativecommons.org/ licenses/by/4.0/) e Mostra i tempi di sei risposta di ogni query per i tre database raddoppio dimensioni utilizzando il NoSQL esistono DBMS e la dimensione in memoria di i tre database. Viene mostrata anche la pendenza lineare di ogni query.
| Carta di braccio | BRACCIO (s) | Percorso del nodo + (s) | |
| 1 ° TRIMESTRE | Query 2.1 | 0.191 | 24.866 |
| Q3 | Query 3.1 | 0,27 | 294.774 |
| Dimensione del database | 2,90 GB | 43,87 GB | |
| Estratti totali | 29.743 | 29.743 |
Tabella 5: media tempi di risposta in pochi secondi di query simili a Q1 e Q3 dei sistemi relazionali migliorati presentata 10 . Questa tabella è stata modificata da7 con licenza Creative Commons (http://creativecommons.org/ licenses/by/4.0/) e Mostra le due query più simili a Q1 e Q3 presentati in10 corrispondenti ai due sistemi di database relazionali migliorato e loro tempi di risposta. Sono indicate anche le dimensioni dei due database.
| ORM/MySQL | Velocità effettiva | Tempo di risposta |
| Q1 (s) | 4,711.60 | 0.0793 |
| Q3 (s) | 4,711.60 | 0.1558 |
| Q4 (s) | 4,711.60 | 0.9674 |
Tabella 6: velocità effettiva e la risposta il tempo medio in secondi di query Q1, Q3 e Q4 di ORM MySQL DBMS relazionale in esecuzione simultanea. Questa tabella è stata modificata da7 con licenza Creative Commons (http://creativecommons.org/ licenses/by/4.0/) e Mostra la massima produttività media di tre query di singolo paziente e loro tempi di risposta medi nei concorrenti esperimento di esecuzione utilizzando il sistema relazionale MySQL ORM.
| MongoDB | Velocità effettiva | Tempo di risposta |
| Q1 (s) | 178,672.60 | 0,003 |
| Q3 (s) | 178,672.60 | 0,0026 |
| Q4 (s) | 178,672.60 | 0,0034 |
Tabella 7: velocità effettiva e la risposta il tempo medio in secondi di query Q1, Q3 e Q4 di MongoDB NoSQL DBMS in esecuzione simultanea. Questa tabella è stata modificata da7 con licenza Creative Commons (http://creativecommons.org/ licenses/by/4.0/) e Mostra la massima produttività media di tre query di singolo paziente e loro tempi di risposta medi nei concorrenti esperimento di esecuzione utilizzando il sistema di MongoDB NoSQL.
Complementare figura 1: la schermata mostra la schermata del software per la connessione al server MySQL. Per favore clicca qui per scaricare questa figura.
Complementare figura 2: la schermata mostra l'interfaccia SQL al server MySQL dove è stata scritta la prima query SQL. Per favore clicca qui per scaricare questa figura.
Complementare figura 3: The MongoDB 2.6 localhost server viene avviato utilizzando una finestra di sistema DOS eseguendo il server mongod. Per favore clicca qui per scaricare questa figura.
Complementare figura 4: la schermata mostra la query scritta nelle caselle di testo del generatore di Query, come mostrato nei passaggi 5.7.1 attraverso 5.7.4. La schermata illustra passo 5.7.3. Per favore clicca qui per scaricare questa figura.
Complementare figura 5: la schermata mostra il passo 5.7.6. Per favore clicca qui per scaricare questa figura.
Complementare figura 6: la schermata illustra la scrittura della query XPath nella parte superiore della finestra di dialogo. Per favore clicca qui per scaricare questa figura.
Discussion
Questo protocollo viene illustrato che Puri sistemi relazionali di ORM non sembrano pratici per le query di singolo paziente (Q1, Q3 e Q4) poiché i tempi di risposta sono più lenti, probabilmente a causa di un numero elevato di tabelle relazionali eseguire molte operazioni di join costosi e a causa della sistema di archiviazione utilizzato dal tipo specifico del database. Database NoSQL memorizzare dati in un modo basato su documento, mentre sistemi relazionali utilizzano una moda basato su tabelle che si diffonde ogni documento in tutta l'intero database. NoSQL sistemi mostrano una pendenza lineare, con MongoDB esecuzione notevolmente più veloce di quanto esiste DBMS. In concorrenza, MongoDB inoltre si comporta molto meglio di relazionale MySQL ORM7.
Questo protocollo presenta un protocollo di risoluzione dei problemi per i risultati presentati in7 per quanto riguarda il DBMS MySQL ORM. Il sistema di MySQL è stato aggiornato all'ultima versione e i risultati sono stati leggermente modificati. Inoltre, un punto critico nei sistemi basati su documento di NoSQL come MongoDB è che può preservare la consistenza, quando la conservazione di informazioni mediche7 perché quando viene aggiornato un estratto EHR, non viene sovrascritto, ma un intero nuovo estratto con i nuovi dati è generati e memorizzati nel sistema, e l'estratto originale viene mantenuto. Questo è un requisito indispensabile di informazioni mediche, perché alcuni medici possono hanno preso importanti decisioni mediche basate sui dati originali.
Il sistema braccio relazionale migliorato drasticamente riduce il numero di tabelle relazionali e migliora le prestazioni relazionale. Tuttavia, poiché consente di modificare lo schema relazionale, informazioni mediche in possesso gli estratti possono essere interrogati, ma gli estratti non possono essere recuperati nella loro forma originale esatta.
Per utilizzano i database molto grandi nel secondario (ricerca), non è chiaro quale sistema di database è più appropriato, poiché le query di tutti-paziente (Q2 e Q5) si comportano meglio in ORM rispetto a sistemi di NoSQL, ma questi sistemi eseguono meglio la procedura semplificata relazionale sistemi a 12. Consideriamo una query speciale tra pratica clinica e secondaria utilizzare quale comportamento non può essere determinato dai risultati ottenuti con questi esperimenti Q6.
Tuttavia, una limitazione del metodo è la inavailability di esperimenti diretti confrontando il migliorato sistema di braccio relazionale con NoSQL MongoDB per quanto riguarda il singolo paziente, medico pratica query con esattamente gli stessi dati che utilizzati nel protocollo. Abbiamo mantenuto i risultati interpolando tabella 3 e tabella 5 per quanto riguarda le query singolo paziente fino a quando è stato effettuato l'esperimento tra cui braccio ottimizzato nel protocollo. Lasciamo questi esperimenti per future applicazioni. Un passo critico all'interno del protocollo è la selezione di database gratuito, versioni software simili degli ultimi anni, così che possiamo paragonare l'esatto stato-of-the-art delle tre tecnologie.
Questo è uno dei primi tentativi di confrontare direttamente relazionali e NoSQL sistemi utilizzando informazioni mediche effettive, realistiche, standardizzate. Tuttavia, il sistema specifico da utilizzare dipende molto lo scenario reale e problema essere risolto8.
Disclosures
Gli autori non hanno nulla a rivelare. Il set di dati utilizzati in questi esperimenti sono stati forniti da diversi ospedali spagnoli sotto licenza per questi esperimenti e di conseguenza non sono pubblicamente disponibili. Lo schema ISO/EN 13606 RM XML fornito da University College Londra centro per Health Informatics & multiprofessionali educazione (carillon).
Acknowledgments
Gli autori vorrei ringraziare Dr Dipak Kalra, capo della task force EHRCom definita la ISO/EN 13606 standard e il suo team dell'University College di Londra per la gentile concessione di utilizzare ISO/EN 13606 W3C XML Schema.
Questo lavoro è stato supportato da Instituto de Salud Carlos III [grant numeri PI15/00321, PI15/00003, PI1500831, PI15CIII/00010 e 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).
