İlişkisel (MySQL) ve NoSQL karmaşıklık artan sorguları yürütme (NoSQL ve mevcut) boyutu büyüyen ISO/EN 13606 standart EHR veritabanları
Summary
Bu çalışmada ilişkisel karşılaştırır ve ilişkisel olmayan (NoSQL) tıbbi bilgi sistemleri standart. Böyle veritabanı yönetimi sistemleri (DBMS) sorgulama yanıt süreleri hesaplama karmaşıklığı kullanarak iki katına boyutlu veritabanları hesaplanır. Bu sonuçlar her veritabanı yaklaşım sorunları ve farklı senaryolar uygunluğunu tartışma yardım.
Abstract
Bu araştırma, sorgulama Hesaplamalı karmaşıklığını ilişkisel değerlendirmek için bir protokol gösterir ve ilişkisel olmayan (NoSQL (sadece yapılandırılmış sorgu dili)) elektronik sağlık kaydı (EHR) tıbbi bilgi veritabanı sistemleri (DBMS) standart. Üç iki katına ölçekli veritabanı, veritabanları, 5000 depolama 10.000 ve 20.000 gerçekçi standart EHR özleri, üç farklı veritabanı yönetim sistemleri (DBMS) Yani bir dizi kullanır: ilişkisel MySQL nesne-ilişkisel eşlemeyi (ORM), NoSQL NoSQL belge tabanlı ve yerel Genişletilebilir Biçimlendirme Dili (XML) NoSQL adlı biri yok.
Ortalama yanıt süreleri altı karmaşıklık artan sorguları için hesaplanan ve sonuçlar NoSQL durumlarda doğrusal bir davranış gösterdi. NoSQL alanında NoSQL var daha bir çok düz doğrusal eğim sunar.
NoSQL sistemleri de özel olması nedeniyle standart tıbbi bilgi sistemleri tutarlılığı ve verimliliği NoSQL veritabanlarında depolanan verilerin etkilememelidir tıbbi bilgi güncelleştirme politikalarının korumak daha uygun olabilir.
Bu iletişim kuralı bir sınırlama güzel örneği ilişkisel eşleme (kol) ile aynı verileri gibi gelişmiş ilişkisel sistemlerinin doğrudan sonuçları olmaması. Ancak, katlama boyutu veritabanı sonuçları bu ilişkilendirme literatürde sundu ve yayımlanmış diğer sonuçları göstermektedir NoSQL sistemleri birçok belirli senaryolar ve çözülmesi gereken sorunları daha uygun olabilir. Örneğin, NoSQL klinik pratikte, ya da baskı ve görselleştirme veya amaç değil sadece olduğu durumlar kullanılan EHR özleri için tıbbi bilgileri sorgulama, aynı zamanda tam olarak orijinal biçiminde EHR geri yüklemek gibi görevleri belge tabanlı için uygun olabilir.
Introduction
NoSQL (sadece SQL) DBMS son zamanlarda alternatif için geleneksel ilişkisel DBMS (RDMBS) olarak ortaya çıktı. RDBMS veri veritabanı sistemlerinde yıllardır saklanan edildi şekilde hakim olmuş. İyi okudu ve anlaşılır ilişkisel cebir ve diferansiyel ve İntegral Hesap verimlilik ve RDBMS1tutarlılığını garanti. NoSQL sistemleri ilişkisel sistemleri karşılıklarını olmak değil, ama onlar avantajlı belirli senaryolarda ve çeşitli koşullar altında davranır.
Bu belirli senaryolar ve koşullar bazı tıbbi bilgi depolamak ve yönetmek için kullanılan elektronik sağlık kaydı (EHR) sistemleri veritabanı sebat tasarlarken oluşacak. Birlikte çalışabilir ve pratikte ISO/EN 13606, openEHR ve HL72,3,4gibi çeşitli uluslararası standartları sürdürülebilir olması için,5 kullanılan EHR özleri standartlaştırmak.
ISO/EN 13606 ve openEHR gibi birkaç standart bilgi ve bilgi referans modeli (RM) tarafından temsil soyutlama ve özel veri yapıları archetypesolarak adlandırılan iki farklı düzeylerde ayrılmış. Bu ayrılık kez çift modeli olarak adlandırılan ve EHR sistemleri tüm EHR sistem yeniden programlama olmadan ve sonuç olarak, için gelişmeye anlam olarak birlikte çalışabilir ve tıbbi bilgi verir Bakımı ve sürdürülebilir pratik6 . Ancak, standart EHR sistemlerinde uygulanan çift model belirli bir yapı kuruluşu bilgi izler ve bu sistem veritabanı kalıcı düzeyde tasarlanmış7şekilde derin sonuçları vardır gerektirir.
Nesne ilişkisel eşleme (ORM)8 ilişkisel veritabanı paradigması kullanarak bir EHR sistemi uygulamak için bir metodoloji’dir. ORM etraflıca bir ilişkisel veritabanı için sistem tarafından kullanılan standart EHR özleri XML (eXtensible Markup Language) dosyalarının yapısını eşler. ORM etraflıca standart EHR özleri XML dosyalarının yapısını takip birçok ilişkisel tablolar oluşturur. Bu ilişkisel tablolar birçok yabancı anahtarları ile ilişkilidir ve elde edilen sistemi çok etkili olmayabilir.
ORM için çeşitli ilişkisel iyileştirmeler önerilmiştir. openEHR’ın düğüm + yolu9 tarafından bütün ayıklayın XML dosyası biçimlendiricisi alt ağaçlar BLOB (ikili büyük nesne) içine ilişkisel tablolar sayısını azaltır. Ancak, bu basitleştirme karmaşık alma mantığı, karmaşık sorgular zarar neden olur. Güzel örneği ilişkisel eşleme (kol)10 archetypes, archetypes ve ilişkisel tablolar arasındaki eşlemeleri dayalı yeni bir ilişkisel şema oluşturma tarafından yönlendirilen bir veritabanı modeli oluşturur. Sonuç olarak, bazı tıbbi olmayan bilgileri EHR ekstresinin şey bitti.
Birçok belge tabanlı NoSQL veritabanı tüm belgeleri bir orijinal XML ya da JSON (JavaScript Object Notation) saygı tüm BLOB’lar depolamak biçimi. Böylelikle hiçbir ilişkisel tablolar oluşturulur. Bu NoSQL veritabanları hiçbir şema var ve birleşimler veya (asit) özellikleri11, Yani, atom oranı, tutarlılık, yalıtım ya da dayanıklılık desteklemez. Sonuç olarak, onlar aynı unsurları bir belge öğesi başvuruda bulunuyorsa veya bir yönlendirme bağlantısı kullanan diğer tür belgeleri çok verimsiz olabilir. Tutarlılık sağlamak için başvurulan belgelerin tamamını olduğundan, ardışık olarak işlenmek üzere bu olur. Ancak, ilişkisel olmayan bir veritabanı DBMS tarafından gerçekleştirilen ana görevi bir belge tabanlı görev ise hala uygun olabilir. Bunun nedeni veri bu da EHR tıbbi belgeleri (tartışma bölümüne bakın) tarafından başarılı Özel kalıcılık politikaları nedeniyle olmasına rağmen daha yakından bir belge tabanlı NoSQL veritabanı kullanarak anlayışına doğru yaklaşıldığıdır bir formda kalabilir.
Bu yöntemlerin amacı sebat katman üç farklı DBMS’ler kullanarak standart bir EHR sisteminin uygulanması karşılaştırmak için çeşitli deneyler vitrin etmektir: bir ilişkisel (MySQL) ve iki NoSQL (NoSQL belge tabanlı ve yerel XML var). Onların hesaplama karmaşıklık oldu hesaplanan ve üç farklı artan boyutu veritabanı ve altı farklı karmaşıklık artan sorgularını kullanarak karşılaştırıldığında. Üç veritabanı sunucularının yüklendiği ve nerede sorgular yürütülen aynı bilgisayara yerel olarak yapılandırılmış. Teknik ayrıntılar için Malzemeler tablo görmek.
Eşzamanlılık deneyler de ilişkisel MySQL ve NoSQL NoSQL DBMS’ler performansını karşılaştırmak üzere yapılmıştır. Açıklanan ORM iyileştirmeler (düğüm + yolu ve kol) da edebiyat10ilgili uygun sonuçları kullanılarak karşılaştırılmıştır.
Veritabanı yönetim sistemleri sürekli hızlanan bir hızla gelişmektedir. Sadece mevcut paradigma ilişkisel model yaşındayken hiç kimse bu üstel gelişme hakkında düşünürdüm. Bir örnek almak için örneğin nerede bir model tepki süresi gelişmiş ilişkisel veritabanları ACID özelliklerini koruyarak uygulamak için önerilmiş12, bakın.
Protocol
Representative Results
Discussion
Bu iletişim kuralı yanıt süreleri yavaş, muhtemelen yüksek bir sayıda ilişkisel tablolar çok pahalı birleştirme işlemlerini gerçekleştirme ve nedeniyle nedeniyle olduğundan saf ilişkisel ORM sistemleri tek-hasta sorgularında (S1, S3 ve S4) pratik görünmüyor olduğunu gösterir veritabanı belirli tür tarafından kullanılan depolama sistemi. İlişkisel sistemleri her belgenin tüm veritabanını boyunca yayılır tablo temelli bir moda kullanırken NoSQL veritabanları belge tabanlı bir biçimde veri depolar. NoSQL sistemleri doğrusal bir yamaç, DBMS var daha önemli ölçüde daha hızlı gerçekleştirme NoSQL ile göster. Eşzamanlılık içinde NoSQL de ilişkisel MySQL ORM7daha iyi davranır.
Bu iletişim kuralı için sonuçları7 ORM MySQL DBMS ile ilgili olarak sunulan bir sorun gidermesi Protokolü sunar. MySQL sistemi en son sürümüne güncellendi ve sonuçları biraz değiştirilmiş. Buna ek olarak, belge tabanlı NoSQL sistemlerde kritik bir noktaya NoSQL EHR ekstresi güncelleştirildiğinde, değil yazılır çünkü tıbbi bilgiler7 depolamak, ama bir bütün yeni verilerle yeni ayıkladığınızda onlar tutarlılığı korumak gibi olduğunu oluşturulan ve sisteminde depolanan ve özgün özü korunur. Bazı tıp uygulayıcıları Tıbbi kararlar özgün verilere dayanarak yapılmış olabilir çünkü bu tıbbi bilgi, sıkı bir gereksinimdir.
Gelişmiş ilişkisel kol sistemi büyük ölçüde ilişkisel tablolar sayısı azalır ve ilişkisel performansını artırır. Ancak, ilişkisel şemayı değiştiren beri özler tarafından tutulan tıbbi bilgilerin sorgulanmasını ama özleri tam orijinal formlarında kurtarılamaz.
Çok büyük ikincil veritabanlarında kullanın (araştırma), all-hasta sorguları (Q2 ve Q5) ORM içinde NoSQL sistemlerinde uslu hangi veritabanı sistemi daha uygun olduğu için açık değil, ama bu sistemleri Basitleştirilmiş daha iyi performans için ilişkisel 12sistemlerinde. Klinik pratikte arasında ve ikincil özel sorgu kullanma olan davranış bu deneyler tarafından vermiştir sonuçlarına göre tespit edilemez Q6 göz önünde bulundurun.
Ancak, bir yöntem gelişmiş ilişkisel kol sistemiyle NoSQL NoSQL tek-hasta, tıbbi uygulama sorguları ile ilgili iletişim kuralında kullanılan tam olarak aynı verilerle karşılaştırarak doğrudan deneyler inavailability kısıtlamasıdır. Tablo 3 ve Tablo 5 tek-hasta sorguları ile ilgili protokol içinde en iyi duruma getirilmiş kol dahil olmak üzere deneme gerçekleştirildi kadar enterpolasyonla sonuçları saklanır. Bu deneyler gelecekteki uygulamalar için yola çıkıyoruz. Tam state-of–art üç teknolojileri karşılaştırmak iletişim kuralına bir kritik adım ücretsiz veritabanı, son yıl, benzer yazılım sürümleri seçimdir.
Bu doğrudan ilişkisel karşılaştırmak için ilk deneme ve gerçek, gerçekçi, standart tıbbi bilgileri kullanarak NoSQL sistemleri biridir. Ancak, kullanılacak belirli bir sistem çok gerçek senaryo ve sorun çözüldü8olarak bağlıdır.
Disclosures
The authors have nothing to disclose.
Acknowledgements
Yazarlar Dr Dipak Kalra, standart ISO/EN 13606 ve ekibi için ISO/EN 13606 W3C XML şema kullanmak izin onların tür University College London’dan tanımlanan EHRCom görev gücü’nün lideri teşekkür etmek istiyorum.
Bu eser Instituto de tarafından desteklenen Salud Carlos III [grant numaraları PI15/00321, PI15/00003, PI1500831, PI15CIII/00010 ve 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).
