L'esecuzione di query di complessità crescente in relazionali (MySQL) e NoSQL (MongoDB ed esiste) crescente dimensione ISO/EN 13606 EHR standardizzato database
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
Representative Results
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
The authors have nothing to disclose.
Acknowledgements
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
| 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. , (2008).
- Kalra, D., et al. . Electronic health record communication part 2: archetype interchange specification. , (2008).
- Kalra, D., Beale, T., Heard, S. The openEHR foundation. Stud. Health Technol. Inform. 115, 153-173 (2005).
- 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, (2017).
