Name: Lesecuzione di query di complessità crescente in relazionali (MySQL) e NoSQL (MongoDB ed esiste) crescente dimensione ISO/EN 13606 EHR standardizzato database (Video) | JoVE Journal
Uploaded: 2018-03-19T14:30:00.000+00:00
Duration: 7 min 26 s
Description: Scopri come confrontare la complessità computazionale di database relazionali (MySQL) e NoSQL (MongoDB) misurando i tempi di risposta a query di crescente complessità. Questo metodo aiuta a selezionare il sistema più adatto per applicazioni specifiche.

ai_agent_IP

ai_agent

maintenance

instantTrialDurationMinutes

isBiopharma

enableNewMyJoveSectionDesign

educationFeatures

seoMetaApi

ai_copilot_institution_blacklist

ai_chat_institution_blacklist

freeAccessWindow

ssoRoleCapture

scheduledMaintenanceBanner

joveLabsFeatures

disable_autoplay_for_bots

extended_trial_duration

5 minutes

playerTrialDesktop

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].

1. costruire un DBMS relazionale MySQL per memorizzare tre doppie dimensioni standardizzate EHR estratti database
<ol><li>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.</li>
	<li>Eseguire il JAXB (Java XML Binding) plug-nell'IDE; Questo produce classi Java corrispondenti alla struttura degli elementi del file XML estratti EHR.</li>
	<li>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.</li>
	<li>Importare le librerie di JPA (Java Persistence API) nell'IDE ed eseguire il metodo che crea un database MySQL fuori le classi Java taggati.</li>
	<li>Creare tre cartelle con 5.000, 10.000 e 20.000 EHR realistico estrae i file XML.</li>
	<li>Eseguire il metodo JPA per caricare un estratto XML nel DBMS MySQL su tutti gli estratti della directory 5.000 estratti.</li>
	<li>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.</li>
</ol>2. costruire un DBMS NoSQL MongoDB per memorizzare tre doppie dimensioni standardizzate EHR estratti database
<ol><li>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.</li>
	<li>Lanciare un MongoDB GUI (Graphic User Interface, Vedi Tabella materiali).</li>
	<li>Avviare il MongoDB 2.6 server l'esecuzione del programma di mongod da una finestra di sistema DOS (Disk Operating System).</li>
	<li>Collegare la GUI di MongoDB al server localhost utilizzando la porta 27017.<ol>
<li>Selezionare il menu "Connetti".</li>
		<li>Scrivere un nome per la connessione (ad esempio ' prima').</li>
		<li>Scrivere localhost:27017 nella casella di testo Server DB.</li>
		<li>Premere il pulsante "Connetti"; un albero con i database correnti deve essere visualizzato sulla sinistra.</li>
	</ol>
</li>
	<li>Costruire un database contenente 5.000 EHR standardizzati estratti.<ol>
<li>Clicca sul nome della connessione nella parte superiore dell'albero sulla sinistra.</li>
		<li>Selezionare il menu "File".</li>
		<li>Scegliere "Aggiungi Database".</li>
		<li>Immettere il nome del database nella finestra di dialogo che appare.</li>
		<li>Fare clic su OK.</li>
	</ol>
</li>
	<li>Costruire una collezione contenente 5.000 EHR standardizzati estratti.<ol>
<li>Clicca sul nome del database nella struttura a sinistra.</li>
		<li>Selezionare il menu "Database".</li>
		<li>Scegliere "AddCollection".</li>
		<li>Immettere il nome della raccolta nella finestra di dialogo che appare.</li>
		<li>Fare clic su " Crea".</li>
		<li>Clicca sul nome della raccolta.</li>
		<li>Selezionare il menu "Import".</li>
		<li>Scegliere il pulsante di opzione 'JSON - shell mongo / / mongoexport ".</li>
		<li>Fare clic su "prossimo".</li>
		<li>Premere il pulsante "Aggiungi file di origine".</li>
		<li>Navigare sul computer utilizzando la finestra di dialogo.</li>
		<li>Apri la directory contenente 5.000 JSON estrarre file.</li>
		<li>Selezionare tutti i file nella directory.</li>
		<li>Premere "Apri". L'elenco dei file JSON dovrebbe apparire nella finestra di importazione.</li>
		<li>Premere "Avanti"; a sinistra viene visualizzata un'anteprima della nuova collezione nel database.</li>
		<li>Fare clic su "prossimo".</li>
		<li>Premere il tasto "Avvia importazione". L'avanzamento dell'importazione appare giù sulla sinistra, che indica il numero di file importati ed il tempo trascorso.</li>
	</ol>
</li>
	<li>Ripetere i passaggi 5 e 6 per creare una raccolta di 10.000 EHR standardizzati estratti.</li>
	<li>Ripetere i passaggi 5 e 6 per creare una raccolta di 20.000 EHR standardizzati estratti.</li>
</ol>3. compilazione un NoSQL esiste DBMS tre doppie dimensioni standardizzate EHR estrae database di archivio
<ol><li>Avviare il database esiste .</li>
	<li>Utilizzando l'icona del database, aprire il Client di amministrazione di Java.</li>
	<li>Immettere la password di admin.</li>
	<li>Premere il pulsante "Connetti".</li>
	<li>Costruire una collezione contenente 5.000 EHR standardizzati estratti.<ol>
<li>Nella barra degli strumenti, selezionare il menu "Crea una nuova collezione".</li>
		<li>Nella finestra di dialogo che appare, digitare il nome della nuova collezione.</li>
		<li>Fare clic su "accetta"; verrà visualizzata la nuova collezione.</li>
		<li>Selezionare il nome della raccolta.</li>
		<li>Nella barra degli strumenti, selezionare il menu "file di archivio nel database".</li>
		<li>Navigare sul computer utilizzando la finestra di dialogo.</li>
		<li>Selezionare la directory contenente 5.000 file di Estratto standardizzati di XML.</li>
		<li>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.</li>
	</ol>
</li>
	<li>Ripetere il passaggio 5 per costruire un insieme contenente 10.000 EHR standardizzati estratti.</li>
	<li>Ripetere il passaggio 5 per costruire un insieme contenente 20.000 EHR standardizzati estratti.</li>
</ol>4. progettare ed eseguire nei database relazionali MySQL 3 6 Queries di crescente complessità
<ol><li>Progettazione di query di crescente complessità sei secondo gli archetipi utilizzati dagli estratti EHR.</li>
	<li>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.</li>
	<li>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.</li>
	<li>Se una query ha bisogno di un indice non automaticamente generato, è possibile compilarlo manualmente.<ol>
<li>Connettersi al server MySQL (complementare figura 1).</li>
		<li>Selezionare e fare clic sul nome del database sulla sinistra.</li>
		<li>Selezionare e fare clic sulla tabella relazionale dove risiede il campo indicizzato.</li>
		<li>Fare clic sulla scheda "struttura".</li>
		<li>Selezionare e fare clic sulla colonna dove sorgerà l'indice.</li>
		<li>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.</li>
	</ol>
</li>
	<li>Eseguire la prima query.<ol>
<li>Selezionare e fare clic sul nome del database sulla sinistra.</li>
		<li>Fare clic sulla scheda "SQL".</li>
		<li>Scrivere o incollare il codice SQL della query prima (Vedi complementare figura 2).</li>
		<li>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.</li>
		<li>Ripetere 5 volte, l'esecuzione e calcolare il tempo medio di risposta.</li>
	</ol>
</li>
	<li>Ripetere il passaggio 5 con query 2 a 6.</li>
	<li>Fare tre volte, l'intero processo con i database di estratti di 5.000, 10.000 e 20.000.</li>
</ol>5. progettare ed eseguire nei database NoSQL MongoDB 3 6 Queries di crescente complessità
<ol><li>Lanciare la GUI di MongoDB (Vedi Tabella materiali).</li>
	<li>Avviare il server MongoDB 2.6 l'esecuzione del programma di mongod da una finestra di sistema DOS (vedere complementare figura 3).</li>
	<li>Seguire il passaggio 2.4 a cui connettersi il server localhost porta 27017 la GUI di MongoDB.</li>
	<li>Selezionare ed espandere il database MongoDB sul lato sinistro.</li>
	<li>Selezionare la raccolta.</li>
	<li>Fare clic sul menu "collezione" nella barra degli strumenti.</li>
	<li>Eseguire la prima query MongoDB.<ol>
<li>Fare doppio clic sul pulsante "Query Builder".</li>
		<li>Fare doppio clic sul "campo di Query" del generatore di Query a destra.</li>
		<li>Scrivere il campo della query MongoDB in campo casella di testo del pannello delle query (Vedi complementare figura 4).</li>
		<li>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.</li>
		<li>Fare doppio clic sul campo di proiezione del generatore di Query</li>
		<li>Scrivere la prima proiezione in textbox proiezione (Vedi complementare figura 5).</li>
		<li>Fare doppio clic sul campo per aggiungere un nuovo controllo textbox proiezione proiezione.</li>
		<li>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}</li>
		<li>Fare clic sul pulsante play blu per eseguire la query.</li>
		<li>Visualizzare il codice della query nella scheda Query codice.</li>
		<li>Visualizzare i dettagli del risultato nella scheda Descrizione: numero di risultati, tempo di esecuzione in millisecondi.</li>
		<li>Mostra, espandere ed esaminare i risultati nella scheda risultati.</li>
		<li>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.</li>
		<li>Ripetere 5 volte, l'esecuzione e calcolare il tempo medio di risposta.</li>
	</ol>
</li>
	<li>Passo 5.7 per i restanti 2 attraverso 6 queries.</li>
	<li>Ripetere l'intero processo nel 5.000, 10.000 e 20.000 estratti database MongoDB.</li>
</ol>6. progettare ed eseguire in 3 NoSQL esistono database 6 crescente complessità query
<ol><li>Lanciare l' esistere DBMS.</li>
	<li>Aprire il Client di amministrazione di Java.</li>
	<li>Premere il pulsante "connettersi al database".</li>
	<li>Selezionare il database e fare clic su di esso.</li>
	<li>Fare clic sul menu "consultare il database utilizzando XPath"; viene visualizzata la finestra di finestra di dialogo consult.</li>
	<li>Eseguire la prima query XPath (Vedi complementare figura 6).<ol>
<li>Scrivere o incollare il codice di XPath della prima query nella parte superiore della finestra di dialogo.</li>
		<li>Fare clic sul menu "Esegui" nella barra degli strumenti della finestra di dialogo.</li>
		<li>Mostra risultati XML utilizzando la scheda "XML" nella parte inferiore della finestra di dialogo.</li>
		<li>Mostra il numero di risultati e compilazione e tempo di esecuzione nella parte inferiore della finestra di dialogo.</li>
		<li>Ripetere 5 volte, l'esecuzione e calcolare il tempo medio di risposta.</li>
	</ol>
</li>
	<li>Ripetere il passaggio 6 per query 2 a 6.</li>
	<li>Fare l'intero processo tre volte, per gli estratti di 5.000, 10.000 e 20.000 esistono database.</li>
</ol>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.
<ol><li>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).</li>
	<li>Identificare e creare manualmente gli indici di attributo appropriato per tali query, se necessario.</li>
	<li>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.</li>
	<li>Eseguire e calcolare la CPU (Central Processing Unit) che utilizzano la distribuzione per ciascun thread (query).</li>
	<li>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.</li>
	<li>Visualizzare le query in esecuzione, con priorità e tempi di esecuzione.</li>
	<li>Calcolare la velocità effettiva media e tempo di risposta medio di ognuna delle tre query.</li>
</ol>

<ol><li>Codd, E. F. <a target="_blank" href="https://cs.uwaterloo.ca/~david/cs848s14/codd-relational.pdf">A relational model for large shared data banks.</a> Comm ACM. 13 (6), 377-387 (1970).</li>
<li>Kalra, D., Lloyd, D. <a target="_blank" href="http://scholar.google.com/scholar?hl=en&safe=off&q=author%3aKalra%2C+D+%22ISO+13606+electronic+health+record+communication+part+1%3A+reference+model%22">ISO 13606 electronic health record communication part 1: reference model</a>. , ISO. Geneva. ISO 13606-1 (2008).</li>
<li>Kalra, D., et al. <a target="_blank" href="http://scholar.google.com/scholar?hl=en&safe=off&q=author%3aKalra%2C+D+%22Electronic+health+record+communication+part+2%3A+archetype+interchange+specification%22">Electronic health record communication part 2: archetype interchange specification</a>. , ISO. Geneva. ISO 13606-2 (2008).</li>
<li>Kalra, D., Beale, T., Heard, S. <a target="_blank" href="https://www.ncbi.nlm.nih.gov/pubmed/16160223">The openEHR foundation.</a> Stud. Health Technol. Inform. 115, 153-173 (2005).</li>
<li>Health Level seven. Health Level Seven International. , Available from:
 <a target="_blank" href="http://www.hl7.org">http://www.hl7.org</a> (2017).</li>
<li>Beale, T. <a target="_blank" href="https://www.researchgate.net/publication/237033734_Archetypes_Constraint-based_Domain_Models_for_Future-proof_Information_Systems">Archetypes: constraint-based domain models for future proof information systems.</a> OOPSLA, Workshop Behav Semant. , (2002).</li>
<li>Sánchez-de-Madariaga, R., et al. <a target="_blank" href="http://www.ncbi.nlm.nih.gov/pubmed?term=((Examining+database+persistence+of+ISO%2FEN+13606+standardized+electronic+health+record+extracts%3A+relational+vs.+NoSQL+approaches%5BTitle%5D)+AND+%22BMC+Medical+Informatics+and+Decision+Making%22%5BJournal%5D)">Examining database persistence of ISO/EN 13606 standardized electronic health record extracts: relational vs. NoSQL approaches.</a> BMC Medical Informatics and Decision Making. 32 (2), 493-503 (2017).</li>
<li>Ireland, C., Bowers, D., Newton, M., Waugh, K. <a target="_blank" href="https://www.researchgate.net/publication/42800142_Understanding_object-relational_mapping_A_framework_based_approach">Understanding object-relational mapping: a framework based approach.</a> Int. J. Adv. Softw. 2, 202-216 (2009).</li>
<li>Node+Path Persistence. , Available from:
 <a target="_blank" href="https://openehr.atlassian.net/wiki/spaces/dev/pages/6553626/Node+Path+Persistence">https://openehr.atlassian.net/wiki/spaces/dev/pages/6553626/Node+Path+Persistence</a> (2017).</li>
<li>Wang, L., Min, L., Wang, R., et al. <a target="_blank" href="http://www.ncbi.nlm.nih.gov/pubmed?term=((Archetype+relational+mapping+-+a+practical+openEHR+persistence+solution%5BTitle%5D)+AND+%22BMC+Medical+Informatics+and+Decision+Making%22%5BJournal%5D)">Archetype relational mapping - a practical openEHR persistence solution.</a> BMC Medical Informatics and Decision Making. 15, 88(2015).</li>
<li>Kaur, K., Rani, R. <a target="_blank" href="http://ieeexplore.ieee.org/document/7063177/">Managing data in healthcare information systems: many models, one solution.</a> Computer. March. , 52-59 (2015).</li>
<li>Sabo, C., Pop, P. C., Valean, H., Danciulescu, D. <a target="_blank" href="https://link.springer.com/chapter/10.1007/978-3-319-53480-0_1">An innovative approach to manage heterogeneous information using relational database systems.</a> Advances in Intelligent Systems and Computing. 557, Springer. (2017).</li>
</ol>

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).

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.

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.

<table><tbody><tr><td>MySQL 5.7.20</td><td></td><td></td><td>MySQL sperimenta</td></tr><tr><td>Red Hat Enterprise Linux Server versione 7.4 (Maipo), 2,60 GHz, RAM 16 GB</td><td></td><td></td><td></td></tr><tr><td>MongoDB 2.6</td><td></td><td></td><td>MongoDB sperimenta</td></tr><tr><td>Windows 7, 2,66 GHz, RAM 12 GB</td><td></td><td></td><td></td></tr><tr><td>eXist 3.0RC1</td><td></td><td></td><td>eXist sperimenta</td></tr><tr><td>Windows 7, 2,66 GHz, RAM 12 GB</td><td></td><td></td><td></td></tr><tr><td>Studio 3T 5.5.1</td><td>3T Software Labs Gmbh</td><td></td><td>MongoDB GUI</td></tr></tbody></table>

l'esecuzione di query di complessità crescente in relazionali (mysql) e nosql (mongodb ed esiste) crescente dimensione iso/en 13606 ehr standardizzato database

Executing Complexity-Increasing Queries in Relational (MySQL) and NoSQL (MongoDB and EXist) Size-Growing ISO/EN 13606 Standardized EHR Databases

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.

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.
<img alt="Figure 1" class="xfigimg" src="/files/ftp_upload/57439/57439fig1.jpg"> 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. <a href="//cloudflare.jove.com/files/ftp_upload/57439/57439fig1large.jpg" target="_blank">Clicca qui per visualizzare una versione più grande di questa figura.</a>
<img alt="Figure 2" class="xfigimg" src="/files/ftp_upload/57439/57439fig2.jpg"> 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. <a href="//cloudflare.jove.com/files/ftp_upload/57439/57439fig2large.jpg" target="_blank">Clicca qui per visualizzare una versione più grande di questa figura.</a>
<img alt="Figure 3" class="xfigimg" src="/files/ftp_upload/57439/57439fig3.jpg"> 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. <a href="//cloudflare.jove.com/files/ftp_upload/57439/57439fig3large.jpg" target="_blank">Clicca qui per visualizzare una versione più grande di questa figura.</a>
<img alt="Figure 4" class="xfigimg" src="/files/ftp_upload/57439/57439fig4.jpg"> 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. <a href="//cloudflare.jove.com/files/ftp_upload/57439/57439fig4large.jpg" target="_blank">Clicca qui per visualizzare una versione più grande di questa figura.</a>
<img alt="Figure 5" class="xfigimg" src="/files/ftp_upload/57439/57439fig5.jpg"> 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. <a href="//cloudflare.jove.com/files/ftp_upload/57439/57439fig5large.jpg" target="_blank">Clicca qui per visualizzare una versione più grande di questa figura.</a>
<img alt="Figure 6" class="xfigimg" src="/files/ftp_upload/57439/57439fig6.jpg"> 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. <a href="//cloudflare.jove.com/files/ftp_upload/57439/57439fig6large.jpg" target="_blank">Clicca qui per visualizzare una versione più grande di questa figura.</a>
<table border="1" fo:keep-together.within-page="1" fo:keep-with-next.within-page="always"><tbody>
<tr>
<td></td>
			<td>Query</td>
		</tr>
<tr>
<td>1 ° TRIMESTRE</td>
			<td>Trovare tutti i problemi di un singolo paziente</td>
		</tr>
<tr>
<td>Q2</td>
			<td>Trovare tutti i problemi di tutti i pazienti</td>
		</tr>
<tr>
<td>Q3</td>
			<td>Trovare la data iniziale, la data di risoluzione e la gravità</td>
		</tr>
<tr>
<td></td>
			<td>di un singolo problema di un singolo paziente</td>
		</tr>
<tr>
<td>Q4</td>
			<td>Trovare la data iniziale, la data di risoluzione e la gravità</td>
		</tr>
<tr>
<td></td>
			<td>di tutti i problemi problema di un singolo paziente</td>
		</tr>
<tr>
<td>Q5</td>
			<td>Trovare la data iniziale, la data di risoluzione e la gravità</td>
		</tr>
<tr>
<td></td>
			<td>di tutti i problemi problema di tutti i pazienti</td>
		</tr>
<tr>
<td>Q6</td>
			<td>Trovare tutti i pazienti con 'faringite' problema,</td>
		</tr>
<tr>
<td></td>
			<td>Data iniziale &gt; = 16 ottobre 2007 ', data di risoluzione</td>
		</tr>
<tr>
<td></td>
			<td>&lt; = 5 giugno 2008 ' e gravità 'alta'</td>
		</tr>
</tbody></table>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.
<table border="1" fo:keep-together.within-page="1" fo:keep-with-next.within-page="always"><tbody>
<tr>
<td>ORM/MySQL</td>
			<td>5000 documenti</td>
			<td>10.000 documenti</td>
			<td>20.000 documenti</td>
		</tr>
<tr>
<td>Q1 (s)</td>
			<td>25.0474</td>
			<td>32.6868</td>
			<td>170.7342</td>
		</tr>
<tr>
<td>Q2 (s)</td>
			<td>0.0158</td>
			<td>0.0147</td>
			<td>0,0222</td>
		</tr>
<tr>
<td>Q3 (s)</td>
			<td>3.3849</td>
			<td>6.4225</td>
			<td>207.2348</td>
		</tr>
<tr>
<td>Q4 (s)</td>
			<td>33.5457</td>
			<td>114.6607</td>
			<td>115.4169</td>
		</tr>
<tr>
<td>Q5 (s)</td>
			<td>9.6393</td>
			<td>74.3767</td>
			<td>29.0993</td>
		</tr>
<tr>
<td>Q6 (s)</td>
			<td>1.4382</td>
			<td>2.4844</td>
			<td>183.4979</td>
		</tr>
<tr>
<td>Dimensione del database</td>
			<td>4.6 GB</td>
			<td>9.4 GB</td>
			<td>19,4 GB</td>
		</tr>
<tr>
<td>Estratti totali</td>
			<td>5000</td>
			<td>10.000</td>
			<td>20.000</td>
		</tr>
</tbody></table>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.
<table border="1" fo:keep-together.within-page="1" fo:keep-with-next.within-page="always"><tbody>
<tr>
<td>MongoDB</td>
			<td>5000 documenti</td>
			<td>10.000 documenti</td>
			<td>20.000 documenti</td>
			<td>pendenza (*10exp(-6))</td>
		</tr>
<tr>
<td>Q1 (s)</td>
			<td>0,046</td>
			<td>0,057</td>
			<td>0.1221</td>
			<td>5,07</td>
		</tr>
<tr>
<td>Q2 (s)</td>
			<td>34.5181</td>
			<td>68.6945</td>
			<td>136.2329</td>
			<td>6,780.99</td>
		</tr>
<tr>
<td>Q3 (s)</td>
			<td>0,048</td>
			<td>0,058</td>
			<td>0.1201</td>
			<td>4.81</td>
		</tr>
<tr>
<td>Q4 (s)</td>
			<td>0,052</td>
			<td>0,061</td>
			<td>o.1241</td>
			<td>4.81</td>
		</tr>
<tr>
<td>Q5 (s)</td>
			<td>38.0202</td>
			<td>75.4376</td>
			<td>149.933</td>
			<td>7460.85</td>
		</tr>
<tr>
<td>Q6 (s)</td>
			<td>9.5153</td>
			<td>18.5566</td>
			<td>36.7805</td>
			<td>1,817.68</td>
		</tr>
<tr>
<td>Dimensione del database</td>
			<td>1,95 GB</td>
			<td>3,95 GB</td>
			<td>7,95 GB</td>
			<td></td>
		</tr>
<tr>
<td>Estratti totali</td>
			<td>5000</td>
			<td>10.000</td>
			<td>20.000</td>
			<td></td>
		</tr>
</tbody></table>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.
<table border="1" fo:keep-together.within-page="1" fo:keep-with-next.within-page="always"><tbody>
<tr>
<td>Esistono</td>
			<td>5000 documenti</td>
			<td>10.000 documenti</td>
			<td>20.000 documenti</td>
			<td>pendenza (*10exp(-6))</td>
		</tr>
<tr>
<td>Q1 (s)</td>
			<td>0.6608</td>
			<td>3.7834</td>
			<td>7.3022</td>
			<td>442.76</td>
		</tr>
<tr>
<td>Q2 (s)</td>
			<td>60.7761</td>
			<td>129.3645</td>
			<td>287.362</td>
			<td>15,105.73</td>
		</tr>
<tr>
<td>Q3 (s)</td>
			<td>0.6976</td>
			<td>1,771</td>
			<td>4.1172</td>
			<td>227.96</td>
		</tr>
<tr>
<td>Q4 (s)</td>
			<td>0.6445</td>
			<td>3.7604</td>
			<td>7.3216</td>
			<td>445.17</td>
		</tr>
<tr>
<td>Q5 (s)</td>
			<td>145.3373</td>
			<td>291.2502</td>
			<td>597.7216</td>
			<td>30,158.93</td>
		</tr>
<tr>
<td>Q6 (s)</td>
			<td>68.3798</td>
			<td>138.9987</td>
			<td>475.2663</td>
			<td>27,125.82</td>
		</tr>
<tr>
<td>Dimensione del database</td>
			<td>1.25GB</td>
			<td>2,54 GB</td>
			<td>5,12 GB</td>
			<td></td>
		</tr>
<tr>
<td>Estratti totali</td>
			<td>5000</td>
			<td>10.000</td>
			<td>20.000</td>
			<td></td>
		</tr>
</tbody></table>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.
<table border="1" fo:keep-together.within-page="1" fo:keep-with-next.within-page="always"><tbody>
<tr>
<td></td>
			<td>Carta di braccio</td>
			<td>BRACCIO (s)</td>
			<td>Percorso del nodo + (s)</td>
		</tr>
<tr>
<td>1 ° TRIMESTRE</td>
			<td>Query 2.1</td>
			<td>0.191</td>
			<td>24.866</td>
		</tr>
<tr>
<td>Q3</td>
			<td>Query 3.1</td>
			<td>0,27</td>
			<td>294.774</td>
		</tr>
<tr>
<td></td>
			<td>Dimensione del database</td>
			<td>2,90 GB</td>
			<td>43,87 GB</td>
		</tr>
<tr>
<td></td>
			<td>Estratti totali</td>
			<td>29.743</td>
			<td>29.743</td>
		</tr>
</tbody></table>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.
<table border="1" fo:keep-together.within-page="1" fo:keep-with-next.within-page="always"><tbody>
<tr>
<td>ORM/MySQL</td>
			<td>Velocità effettiva</td>
			<td>Tempo di risposta</td>
		</tr>
<tr>
<td>Q1 (s)</td>
			<td>4,711.60</td>
			<td>0.0793</td>
		</tr>
<tr>
<td>Q3 (s)</td>
			<td>4,711.60</td>
			<td>0.1558</td>
		</tr>
<tr>
<td>Q4 (s)</td>
			<td>4,711.60</td>
			<td>0.9674</td>
		</tr>
</tbody></table>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.
<table border="1" fo:keep-together.within-page="1" fo:keep-with-next.within-page="always"><tbody>
<tr>
<td>MongoDB</td>
			<td>Velocità effettiva</td>
			<td>Tempo di risposta</td>
		</tr>
<tr>
<td>Q1 (s)</td>
			<td>178,672.60</td>
			<td>0,003</td>
		</tr>
<tr>
<td>Q3 (s)</td>
			<td>178,672.60</td>
			<td>0,0026</td>
		</tr>
<tr>
<td>Q4 (s)</td>
			<td>178,672.60</td>
			<td>0,0034</td>
		</tr>
</tbody></table>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. <a href="//cloudflare.jove.com/files/ftp_upload/57439/Supplementary_Figure_1.png" target="_blank">Per favore clicca qui per scaricare questa figura.</a>
Complementare figura 2: la schermata mostra l'interfaccia SQL al server MySQL dove è stata scritta la prima query SQL. <a href="//cloudflare.jove.com/files/ftp_upload/57439/Supplementary_Figure_2.png" target="_blank">Per favore clicca qui per scaricare questa figura.</a>
Complementare figura 3: The MongoDB 2.6 localhost server viene avviato utilizzando una finestra di sistema DOS eseguendo il server mongod. <a href="//cloudflare.jove.com/files/ftp_upload/57439/Supplementary_Figure_3.png" target="_blank">Per favore clicca qui per scaricare questa figura.</a>
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. <a href="//cloudflare.jove.com/files/ftp_upload/57439/Supplementary_Figure_4.png" target="_blank">Per favore clicca qui per scaricare questa figura.</a>
Complementare figura 5: la schermata mostra il passo 5.7.6. <a href="//cloudflare.jove.com/files/ftp_upload/57439/Supplementary_Figure_5.png" target="_blank">Per favore clicca qui per scaricare questa figura.</a>
Complementare figura 6: la schermata illustra la scrittura della query XPath nella parte superiore della finestra di dialogo. <a href="//cloudflare.jove.com/files/ftp_upload/57439/Supplementary_Figure_6.png" target="_blank">Per favore clicca qui per scaricare questa figura.</a>

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.

L'esecuzione di query di complessità crescente in relazionali (MySQL) e NoSQL (MongoDB ed esiste) crescente dimensione ISO/EN 13606 EHR standardizzato database

This research shows a protocol to assess the computational complexity of querying relational and non-relational (NoSQL (not only Structured Query ...

L'obiettivo generale di questo esperimento è quello di confrontare la complessità computazionale di sistemi di query relazionali e non solo strutturati o di database NoSQL, misurata dai loro tempi di risposta a query di complessità crescente. Questo metodo può aiutare a rispondere a domande chiave nel campo dei sistemi di gestione di database, ad esempio quali tipi di query sono più appropriati per quale tipo di sistemi di database. Il vantaggio principale di questa tecnica è che confronta i tempi di risposta alle query per database doppi di ogni tipo, insieme alla complessità computazionale da calcolare, e quindi questo metodo può fornire informazioni su MySQL, MongoDB e sui sistemi di database in eccesso.Può anche essere applicato ad altri sistemi XML nativi e basati su documenti relazionali come SQL Server e Base X. Abbiamo sentito per la prima volta che hanno usato questo metodo quando dobbiamo selezionare un sistema persistente per un sistema di cartelle cliniche elettroniche. Per progettare ed eseguire query ad aumento della complessità con indici non creati automaticamente in un database MySQL relazionale. Connettiti al server MySQL e seleziona il nome del database.Selezionare la tabella relazionale all'interno del campo dell'indice e aprire la scheda della struttura. Selezionare la colonna in cui verrà creato l'indice e fare clic su indice. Apparirà la frase SQL che costruisce l'indice, seguita da un messaggio che indica che la frase è stata costruita con successo.Per eseguire la prima query, selezionare il nome del database e aprire la scheda SQL. Immettere il codice SQL della prima query e fare clic su Continua. Apparirà la prima schermata dell'elenco dei risultati con il messaggio relativo al tempo di esecuzione della query.Per progettare ed eseguire query che aumentano la complessità e un database Mongo non relazionale, non solo o NoSQL avvia l'interfase utente grafica del database Mongo e il server del database Mongo 2.6 che esegue il programma Mongo da una finestra di sistema DOS. Collegare l'interfase utente grafica del database Mongo al server host locale tramite la porta 27017 e selezionare il menu di connessione. Immettere un nome per la connessione e immettere la posizione dell'host locale nella casella di testo del server di database, quindi fare clic su Connetti.Dovrebbe apparire un albero con i database correnti. Espandere il database Mongo. Seleziona la collezione di interesse e apri il menu della raccolta.Per eseguire la prima query del database Mongo, fare doppio clic sul generatore di query e sui pulsanti del campo di query. Immettere i campi della query del database Mongo nella casella di testo dei campi del pannello della query e il valore della query nella casella di testo del valore del pannello della query. Fare doppio clic sul campo di proiezione del generatore di query e inserire la prima proiezione nella casella di testo di proiezione.Fare doppio clic sul campo di proiezione per aggiungere una nuova casella di testo di proiezione e inserire la seconda proiezione, quindi fare clic, giocare per eseguire la query e visualizzare il codice di query nella scheda del codice di query. I dettagli del risultato saranno visualizzabili nella scheda Spiega e risultati. Per progettare ed eseguire query di complessità crescente in un database NoSQL EXist, avviare il database EXist e aprire il client di amministrazione java.Fare clic su, connettersi al database e selezionare il database. Fare clic su, consultare il database utilizzando il percorso X. Apparirà la finestra di dialogo di consultazione.Quindi esegui la prima query del percorso X. In questa tabella vengono mostrate sei diverse query eseguite su estratti di cartelle cliniche elettroniche standardizzate realistiche contenenti informazioni sui problemi dei pazienti, inclusi i loro nomi, le date iniziali e finali e la gravità. Il tempo medio di risposta delle sei query e dei tre database di dimensioni raddoppiate in ciascun sistema di gestione di database, dimostrano un lungo comportamento lineare di complessità computazionale in tutte le query dei database non relazionali che non viene osservato nell'analisi dei database di mappatura relazionale degli oggetti relazionali.L'interpolazione dei risultati del database Mongo con query e dimensioni simili dei risultati del mapping relazionale dell'archetipo genera risultati uguali in entrambi i sistemi di database per la prima query, ma con risultati più favorevoli determinati utilizzando il database Mongo per la terza query. Negli esperimenti di concorrenza, il database Mongo è preferibile al database MySQl sia in termini di velocità effettiva che di tempi di risposta, con il database Mongo che si comporta meglio in concorrenza rispetto a un isolamento e si pone come un database impressionante in esecuzione simultanea. Beh, ho pensato che questo è importante ricordare di mantenere tutti i server localmente nelle stesse macchine in cui il client esegue le query.Seguendo questa procedura, è possibile eseguire altri metodi, come l'utilizzo di altri tipi di sistemi di database, per rispondere a ulteriori domande, ad esempio se un tipo di database può esistere e vincere sia nelle query di un singolo paziente che in quelle di un singolo paziente? Dopo il suo sviluppo, questa tecnica ha aperto la strada ai ricercatori nel campo della complessità algoritmica per esplorare le prestazioni comparative dei database in diversi tipi di sistemi di database. Dopo aver visto questo video, dovresti avere una buona comprensione di come eseguire query di complessità crescente in database di sistemi di database di tipi molto diversi.

executing-complexity-increasing-queries-relational-mysql-nosql

Research

Ricerca

JoVE Journal

Medicine

Medicina

Vi presentiamo un protocollo e codice di programmazione associato, nonché esempi di metadati per supportare un'identificazione automatizzata basata su cloud dell'associazione di categoria di frasi che rappresentano concetti unici nel dominio selezionato conoscenza utente nella letteratura biomedica. L'associazione di frase-categoria quantificata dal presente protocollo può facilitare un'analisi approfondita del dominio di conoscenza selezionato.

Frase di Cloud-Based Mining e analisi dell'associazione di categoria-frase definita dall'utente in pubblicazioni biomediche

Molti ricercatori generano dati "di medie dimensioni", a bassa velocità e multidimensionali, che possono essere gestiti in modo più efficiente con i database anziché con i fogli di calcolo. In questo argomento viene fornita una panoramica concettuale dei database, inclusa la visualizzazione di dati multidimensionali, il collegamento di tabelle in strutture di database relazionali, il mapping di pipeline di dati semiautomatizzate e l'utilizzo del database per chiarire il significato dei dati.

Database per gestire in modo efficiente dati di medie dimensioni, a bassa velocità e multidimensionali nell'ingegneria dei tessuti

TBase combina una cartella clinica elettronica con un database di ricerca innovativo per i riceventi di trapianto di rene. TBase è costruito su una piattaforma di database in memoria, collegata a diversi sistemi ospedalieri e utilizzata per cure ambulatoriali regolari. Integra automaticamente tutti i dati clinici rilevanti, compresi i dati specifici del trapianto, creando un database di ricerca unico.

TBase - una cartella clinica elettronica integrata e un database di ricerca per i riceventi di trapianto di rene

gP2S è un'applicazione web per il monitoraggio degli esperimenti crioEM. Vengono descritte le sue caratteristiche principali, così come i passaggi necessari per installare e configurare l'applicazione. Una volta configurata, l'applicazione consente di registrare con precisione i metadati associati a macchie negative ed esperimenti crioEM.

gP2S, un sistema di gestione delle informazioni per gli esperimenti CryoEM

Ileo postoperatorio (POI) è una complicanza della chirurgia addominale che porta a un aumento della morbilità e degenza prolungata. Poiché le strategie profilattiche o terapeutiche mancano intensificazione della ricerca è necessaria. Pertanto abbiamo stabilito un modello di topo standardizzata e possibile esaminare la fisiopatologia di POI e di studiare i potenziali opzioni terapeutiche.

Valutazione funzionale della motilità intestinale e Wall infiammazione intestinale nei roditori: Analisi in un modello standardizzato di manipolazione intestinale

Lesione Explorer (LE) è una elaborazione delle immagini gasdotto semi-automatico sviluppato per ottenere tessuto cerebrale regionale e subcorticali volumetria iperintensità della lesione da MRI strutturale della malattia di Alzheimer e normale anziani. Per garantire un elevato livello di precisione e affidabilità, il seguente è un protocollo standardizzato di video-guidata per procedure manuali di LE.

Lesione Explorer: un video-guida, standardizzato protocollo preciso e affidabile Volumetrics MRI-derivati ​​nella malattia di Alzheimer e normale Anziani

Descriviamo un portatile naturalmente standardizzato coperta, che può essere utilizzato per valutare evitare di ostacolo in persone che hanno una visione ultrabassa. Il percorso è relativamente poco costoso, semplice da amministrare, e ha dimostrato di essere affidabile e riproducibile.

Un percorso ad ostacoli standardizzato per la valutazione della funzione visiva in Ultra Low Vision e Visione Artificiale

Questo protocollo descrive una tecnica di osteosintesi che utilizza un chiodo di bloccaggio intramidollare per la fissazione standardizzata delle osteotomie del femore, che può essere utilizzato per analizzare la guarigione ossea normale e difettosa nei topi.

Un chiodo endomidollare di bloccaggio per standardizzata Fissazione del femore osteotomie per analizzare normale e difettoso guarigione ossea nei topi

Qui, presentiamo un protocollo standardizzato per misurare la differenza di potenziale nasale (NPD). Regolatore di conduttanza del transmembrane di fibrosi cistica (CFTR) ed epiteliale del sodio (ENaC) canale funzione vengono valutati dal cambiamento nella tensione attraverso l'epitelio nasale dopo superfusione di soluzioni che modificano l'attività del canale ionico, fornendo un misura di risultato.

Misurazione standardizzato di differenza di potenziale Transepithelial membrana nasale (NPD)

Le banche dati della letteratura sono comunemente utilizzate per valutare le pubblicazioni in un determinato argomento, disciplina, paese o regione del mondo, una pratica nota come analisi bibliometrica. Il protocollo corrente descrive in dettaglio come utilizzare i database PubMed, Scopus e Web of Science per eseguire analisi bibliometriche.

Confronto dell'analisi bibliometrica con PubMed, Scopus e Web of Science Databases

Scopri come confrontare la complessità computazionale di database relazionali (MySQL) e NoSQL (MongoDB) misurando i tempi di risposta a query di crescente complessità. Questo metodo aiuta a selezionare il sistema più adatto per applicazioni specifiche.

Lesecuzione di query di complessità crescente in relazionali (MySQL) e NoSQL (MongoDB ed esiste) crescente dimensione ISO/EN 13606 EHR standardizzato database (Video) | JoVE Journal

L'esecuzione di query di complessità crescente in relazionali (MySQL) e NoSQL (MongoDB ed esiste) crescente dimensione ISO/EN 13606 EHR standardizzato database

Esplora altri video