Toenemende complexiteit query's uitvoeren in relationele (MySQL) en NoSQL (MongoDB en bestaan) grootte groeiende ISO/nl 13606 gestandaardiseerde EMD Databases
Summary
Deze studie vergelijkt relationele en niet-relationele (NoSQL) gestandaardiseerd medische informatiesystemen. De computationele complexiteit van de responstijden van het opvragen van dergelijke databasebeheersystemen (DBMS) wordt berekend met behulp van verdubbeling middelgrote databases. Deze resultaten helpen de discussie van de geschiktheid van elke database benadering van verschillende scenario’s en problemen.
Abstract
Dit onderzoek toont een protocol bij het beoordelen van de computationele complexiteit van het opvragen van relationele en niet-relationele (NoSQL (niet alleen Structured Query Language)) gestandaardiseerd elektronische medische record (EMD) medische informatie databasesystemen (DBMS). Het maakt gebruik van een set van drie verdubbeling middelgrote databases, d.w.z. databases opslaan van 5000, 10.000 en 20.000 realistische gestandaardiseerde extracten van EMD, in drie verschillende databasebeheersystemen (DBMS): relationele MySQL object-relationele mapping (ORM), document-gebaseerd NoSQL MongoDB, als inheemse extensible markup language (XML) NoSQL bestaan.
De gemiddelde responstijden voor zes toenemende complexiteit query’s werden berekend, en de resultaten toonden een lineaire gedrag in de NoSQL gevallen. In het veld NoSQL presenteert MongoDB een veel vlakker lineaire helling dan bestaan.
NoSQL systemen wellicht ook meer geschikt om gestandaardiseerde medische informatiesystemen vanwege de speciale aard van het bijgewerkte beleid van medische informatie, die mag geen afbreuk doen aan de consistentie en efficiëntie van de gegevens die zijn opgeslagen in databases van NoSQL.
Een beperking van dit protocol is het gebrek aan directe resultaten van de verbeterde relationele systemen zoals archetype relationele mapping (ARM) met dezelfde gegevens. Echter de interpolatie van verdubbeling-grootte databaseresultaten die gepresenteerd in de literatuur en andere gepubliceerde resultaten blijkt dat NoSQL systemen zou meer passend is in vele specifieke scenario’s en problemen op te lossen. Bijvoorbeeld, kan NoSQL dienstig voor documentgebaseerde taken zoals het EMD extracten gebruikt in de klinische praktijk, of edition en visualisatie of situaties waarin het doel is niet alleen voor query medische informatie, maar ook voor het EMD in precies de oorspronkelijke vorm te herstellen.
Introduction
NoSQL (niet alleen SQL) DBMS hebben onlangs naar voren gekomen als een alternatief voor de traditionele relationele DBMS (RDMBS). RDBMS hebben gedomineerd de manier gegevens werden opgeslagen in databasesystemen voor decennia. Goed bestudeerde en begrepen relationele algebra en calculus hebben gegarandeerd de efficiëntie en consistentie van RDBMS1. NoSQL systemen zal niet worden substituten voor relationele systemen, maar ze kunnen voordelig gedragen in bepaalde scenario’s en onder verschillende voorwaarden.
Sommige van deze bepaalde scenario’s en omstandigheden zou optreden bij het ontwerpen van het voortbestaan van de database van Electronic Health Record (EMD) systemen gebruikt voor het beheer en de opslag van medische informatie. Om interoperabele en duurzame in de praktijk verschillende internationale normen zoals ISO/nl 13606, openEHR en HL72,3,4werden,5 gebruikt op de standaardisering van EMD-extracten.
Diverse standaarden zoals ISO/nl-13606 en openEHR hebben gescheiden informatie en kennis in twee verschillende niveaus van abstractie, vertegenwoordigd door de Reference Model (RM) en speciale datastructuren archetypengenoemd. Deze scheiding wordt vaak de dubbele model genoemd en hierdoor EMD-systemen als semantisch interoperabele en medische kennis evolueren zonder de hele EMD-systeem te herprogrammeren en, bijgevolg, naar onderhoudbaar en duurzame in de praktijk6 . De dubbele model ten uitvoer gelegd in gestandaardiseerde EMD-systemen vereist echter dat de organisatie van informatie een specifieke structuur volgt, en dit heeft ingrijpende gevolgen in de manier waarop die de databaseniveau persistentie van het systeem ontworpen7 is.
Object Relational Mapping (ORM)8 is een methodologie om een EMD-systeem met behulp van de relationele database paradigma. ORM kaarten uitvoerig de structuur van de gestandaardiseerde EMD extracten van XML (eXtensible Markup Language) bestanden die worden gebruikt door het systeem voor een relationele database. ORM construeert vele relationele tabellen die uitputtend na de structuur van de gestandaardiseerde extracten van EMD XML-bestanden. Deze relationele tabellen zijn gerelateerd door vele refererende sleutels en het resulterende systeem kan niet zeer efficiënt zijn.
De relationele verbeteringen in ORM hebben voorgesteld. het openEHR knooppunt + pad9 vermindert het aantal relationele tabellen door serializing substructuren van het hele extract xmldossier in BLOB’s (binary large objects). Deze vereenvoudiging veroorzaakt echter complexe ophalen logica, beschadiging van complexe query’s. Archetype relationele Mapping (ARM)10 genereert een databasemodel gedreven door archetypen, bouwen van een nieuwe relationele schema op basis van toewijzingen tussen archetypen en relationele tabellen. Enkele van de niet-medische informatie van het EMD-extract is dus verloren.
Veel documenten gebaseerde NoSQL databases hele documenten opslaan als hele BLOBs met inachtneming van een oorspronkelijke XML of JSON (JavaScript Object Notation) formaat. Dit betekent dat geen relationele tabellen worden geconstrueerd. Deze databases NoSQL geen schema hebben en ze ondersteunen geen ofwel joins of (zuur) eigenschappen11, dat wil zeggen, atomiciteit, consistentie, isolatie of duurzaamheid. Dientengevolge, kunnen zij zeer inefficiënt als een element van een document wordt verwezen naar elementen van dezelfde of andere dergelijke documenten met behulp van een indirecte koppeling. Dit gebeurt omdat, om redenen van consistentie, het geheel van de documenten waarnaar wordt verwezen moeten worden opeenvolgend verwerkt. Een niet-relationele database kan echter nog steeds geschikt als de belangrijkste taak van het DBMS een document-gebaseerde taak is. Dit is omdat de gegevens in een formulier mogen blijven meer nauw tot onderlinge aanpassing van de ware vertegenwoordiging met behulp van een document-based database voor NoSQL, al is dit ook te wijten aan het beleid van de speciale persistentie bereikt door EMD medische documenten (zie sectie discussie).
Het doel van deze methoden is om te demonstreren van verschillende experimenten te vergelijken van de uitvoering van de laag van de persistentie van een gestandaardiseerde EMD-systeem met behulp van drie verschillende databasebeheersystemen (DBMS): een relationele (MySQL) en twee NoSQL (documentgebaseerde MongoDB en native XML bestaan). Hun computationele complexiteit is berekend en vergeleken met behulp van drie verschillende toenemende grootte databases en zes verschillende complexiteit toenemende query’s. De drie databaseservers zijn geïnstalleerd en lokaal geconfigureerd in dezelfde computer waar de query’s zijn uitgevoerd. Zie de Tabel van materialen voor de technische details.
Concurrency experimenten zijn ook uitgevoerd om het vergelijken van de prestaties van relationele MySQL en NoSQL MongoDB databasebeheersystemen (DBMS). Ook zijn de beschreven ORM-verbeteringen (knooppunt + pad en ARM) vergeleken met behulp van relevante passende resultaten uit de literatuur10.
Database managementsystemen evolueren voortdurend in een versneld tempo. Niemand zou denken over deze exponentiële ontwikkeling toen de enige bestaande paradigma het relationele model was. Neem een voorbeeld, zie bijvoorbeeld12, waar een model werd voorgesteld om de verbeterde relationele databases responstijd behoud van de ACID-eigenschappen.
Protocol
Representative Results
Discussion
Dit protocol laat zien dat zuivere relationele ORM systemen niet praktisch voor single-patiënt query’s (Q1, Q3 en Q4 lijken) aangezien responstijden zijn langzamer, waarschijnlijk als gevolg van een hoog aantal relationele tabellen veel dure join-bewerkingen uitvoeren, en vanwege de opslagsysteem dat wordt gebruikt door de specifieke aard van de database. NoSQL databases slaan gegevens op documenten gebaseerde wijze, terwijl relationele systemen gebruiken een tabel is gebaseerd mode die zich elk document in de hele database verspreidt. NoSQL systemen tonen een lineaire helling, met MongoDB uitvoeren aanzienlijk sneller dan bestaan DBMS. In concurrency, MongoDB ook gedraagt zich veel beter dan relationele MySQL ORM7.
Dit protocol biedt een probleemoplossing protocol voor de resultaten gepresenteerd in7 met betrekking tot de ORM MySQL DBMS. De MySQL-systeem is bijgewerkt naar de nieuwste versie en de resultaten zijn enigszins gewijzigd. Daarnaast is een kritisch punt in document gebaseerde NoSQL systemen zoals MongoDB is dat ze consistentie behouden kunnen bij het opslaan van medische informatie7 omdat wanneer een EMD uittreksel wordt bijgewerkt, wordt het niet overschreven, maar een geheel nieuw pak uit met de nieuwe gegevens gegenereerd en opgeslagen in het systeem, en het oorspronkelijke extract wordt gehandhaafd. Dit is een strikte vereiste van medische informatie, omdat sommige artsen mogelijk hebben gemaakt van belangrijke medische beslissingen op basis van de oorspronkelijke gegevens.
De verbeterde relationele armsysteem drastisch vermindert het aantal relationele tabellen en relationele prestaties verbetert. Aangezien het wijzigt het relationele schema, medische informatie, gehouden door de extracten kan worden opgevraagd, maar extracten kunnen niet worden hersteld in hun exacte originele vormen.
Voor zeer grote databases in secundaire gebruiken (onderzoek), het is niet duidelijk welke database-systeem is meer nodig, aangezien de all-patiënt-query’s (Q2 en Q5) beter in ORM dan in NoSQL systemen gedragen, maar deze systemen beter dan de vereenvoudigde presteren relationele systemen in 12. Wij beschouwen de Q6 een speciale query tussen de klinische praktijk en secundaire gebruiken wier gedrag kan niet worden bepaald door de resultaten van deze experimenten.
Een beperking van de methode is echter de inavailability van directe experimenten het verbeterde relationele armsysteem met NoSQL MongoDB met betrekking tot één-patiënt, medische praktijk query’s vergelijken met precies dezelfde gegevens die in het protocol worden gebruikt. Wij onderhouden de resultaten interpoleren van tabel 3 en tabel 5 met betrekking tot één-patiënt query’s totdat het experiment met inbegrip van geoptimaliseerde ARM in het protocol was uitgevoerd. Laten we deze experimenten voor toekomstige toepassingen. Een kritieke stap in het protocol is de selectie van gratis database, soortgelijke softwareversies van de afgelopen jaren, zodat we de exacte state-of-the-art van de drie technologieën kan vergelijken.
Dit is een van de eerste pogingen om rechtstreeks vergelijken relationele en NoSQL systemen die gebruikmaken van de eigenlijke, realistische en gestandaardiseerde medische informatie. Het specifieke systeem worden gebruikt hangt echter wel veel van op de werkelijke scenario en het probleem als opgelost8.
Disclosures
The authors have nothing to disclose.
Acknowledgements
De auteurs bedank Dr Dipak Kalra, leider van de EHRCom task force, die de standaard ISO/nl-13606 en zijn team van University College London voor hun vriendelijke toestemming voor het gebruik van de ISO/nl 13606 W3C XML-Schema gedefinieerd.
Dit werk werd gesteund door het Instituto de Salud Carlos III [subsidie nummers PI15/00321 en PI15/00003, PI1500831, PI15CIII/00010, 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).
