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
1. Üç Kişilik ölçekli standart EHR özleri veritabanı depolamak için ilişkisel bir MySQL DBMS inşa
- İthalat W3C (World Wide Web Consortium) XML ISO/EN13606 RM ve ISO21090 veri türleri için bir 'Java IDE' (Integrated Development Environment) karşılık gelen şema.
Not: ISO International Standards Organization için duruyor. EN Avrupa Norm için gösterir. - JAXB (Java XML Binding) IDE içinde eklenti yürütmek; Bu öğeleri EHR özleri XML dosyaları yapısı için karşılık gelen Java sınıfları oluşturur.
- JPA etiketleri ile üretilen Java sınıflarını manuel olarak etiketleme. Bu Etiketler cardinalities ve diğer ilişkiler MySQL veritabanı ilişkisel tablolar arasında bakın.
- JPA (kalıcılığı API Java) kütüphanelerin IDE içine alabilir ve etiketli Java sınıfları dışında bir MySQL veritabanı oluşturur yöntemi uygulamak.
- Üç dizinler 5.000, 10.000 ve 20.000 gerçekçi EHR özleri ile XML dosyaları oluşturun.
- Bir XML ayıklamak 5000 özleri dizinin tüm özleri üzerinde MySQL DBMS yüklemek için JPA yöntemi uygulamak.
- 1.6 iki kez, 10.000 özleri directory ile bir kez ve bir kez 20.000 özleri directory ile adımları yineleyin.
2. bir NoSQL NoSQL DBMS üç kişilik ölçekli standart EHR özleri veritabanı depolamak için build
- Sürecinin her 5.000, 10.000 ve 20.000 gerçekçi EHR özleri içeren XML dosyalarını json.org.XML gibi JSON dosyaları XML dosyaları dönüştürmek için bir standart program içeren üç dizinler. 5.000, 10.000 ve 20.000 JSON dosyalarla üç dizini üretilen.
- Başlatmak NoSQL GUI (grafik kullanıcı arayüzü, Tablo malzemelerigörmek).
- Mongod programın bir DOS (Disk işletim sistemi) sistemi penceresinden yürütme NoSQL 2.6 sunucu başlatın.
- NoSQL GUI kullanarak bağlantı noktası 27017 localhost sunucuya bağlanın.
- "Bağlan" menüsünü seçin.
- Bağlantı için bir ad yazın (örneğin ' ilk').
- Localhost:27017 DB sunucu metin kutusuna yazın.
- "Bağlan" düğmesine basın; bir ağaç geçerli veritabanları ile sol tarafta görüntülenir.
- Özler 5000 standart EHR içeren bir veritabanı oluşturmak.
- Soldaki ağaç üstündeki bağlantısının adını tıklatın.
- "Dosya" menüsünü seçin.
- "Veritabanı Ekle" seçin.
- Görüntülenen iletişim kutusunda veritabanının adını girin.
- Tamam'ı tıklatın.
- 5000 standart EHR içeren bir koleksiyon özleri oluşturmak.
- Soldaki ağaçta veritabanının adını tıklatın.
- Menü "veritabanı".
- "AddCollection" seçin.
- Koleksiyon adı görüntülenen iletişim kutusunda girin.
- " Oluştur" u tıklayın.
- Koleksiyon adını tıklatın.
- "Alma" menüsünü seçin.
- Radyo düğmesini seçin ''JSON - mongo kabuk / / mongoexport ".
- "İleri" düğmesini tıklatın.
- "Kaynak dosyaları ekle" düğmesine basın.
- İletişim kutusunu kullanarak bilgisayarda gidin.
- Açık 5000 JSON içeren dizin dosyaları ayıklayın.
- Dizindeki tüm dosyaları seçin.
- "Aç" tuşuna basın. JSON dosya içe aktarma iletişim kutusunda görünmelidir.
- Basın "sonraki"; Yeni koleksiyon veritabanındaki bir önizlemesi sol tarafta görünür.
- "İleri" tuşuna basın.
- "Almayı başlat" tuşuna basın. Alma işleminin ilerleme aşağı içe aktarılan dosyaları ve geçen süreyi sayısını gösteren solda görünür.
- 5 ve 6 özleri 10.000 standart EHR bir koleksiyon oluşturmak için adımları yineleyin.
- 5 ve 6 özleri 20.000 standart EHR bir koleksiyon oluşturmak için adımları yineleyin.
3. kurmak bir NoSQL mevcut stok üç çift boyutlu standart EHR ayıklar veritabanlarına DBMS
- Varolan veritabanı başlatmak.
- Veritabanının simgesini kullanarak, Java Admin istemcisini açın.
- Yönetici şifresini girin.
- "Bağlan" düğmesine basın.
- 5000 standart EHR içeren bir koleksiyon özleri oluşturmak.
- Araç çubuğunda, menü "Oluştur yeni bir koleksiyon" seçin.
- Görüntülenen iletişim kutusunda, yeni koleksiyonun adını yazın.
- Tıklatın "kabul"; Yeni koleksiyon-ecek gözükmek.
- Koleksiyon adını seçin.
- Araç çubuğunda, "veritabanı dosyaları saklamak" menüsünü seçin.
- İletişim kutusunu kullanarak bilgisayarda gidin.
- 5000 standart XML özü dosyalarını içeren dizini seçin.
- "Dosya veya dizinler depolamak için seçmek" düğmesini tıklatın. Bir iletişim kutusu saklanan dosyaları ilerlemesini göstermek ve oluşturduğunuz veritabanını yüzdesi göründüğünü unutmayın.
- Özler 10.000 standart EHR içeren bir koleksiyon oluşturmak için 5 arasındaki adımları yineleyin.
- Özler 20.000 standart EHR içeren bir koleksiyon oluşturmak için 5 arasındaki adımları yineleyin.
4. tasarım ve 3 ilişkisel MySQL veritabanı 6 karmaşıklık artan sorguları yürütmek
- Altı karmaşıklık artan sorguları EHR özler tarafından kullanılan archetypes göre dizayn.
- Programı ilk sorgu MySQL veritabanı ile bir SQL komut dosyası. SQL MySQL veritabanı özleri standardizasyon (archetypes) nedeniyle özel yapısına uyum gerekir. Veritabanı özler tüm yapısını eşler. Sonuç olarak, SQL sorgusu oldukça karmaşık olduğunu.
- Olsa da çoğu dizinler otomatik olarak DBMS tarafından oluşturulan dizin üzerinde oluşturuldu ve sorgu yanıt süresini hızlandırmak sonra böyle dizinler oluşturmak istiyorum veritabanlarının özniteliklerini tanımlamak.
- Bir sorgu otomatik olarak sigara yapılı bir dizin ihtiyacı varsa, el ile oluşturun.
- (Ek şekil 1) MySQL sunucusuna bağlayın.
- Seçin ve veritabanı adı sol tıklatın.
- Seçin ve ilişkili tabloda yer aldığı dizine alınmış alanı tıklatın.
- "Yapı" sekmesini tıklayın.
- Seçin ve dizin nerede kurulacak sütun'u tıklatın.
- "Dizin"'ı tıklatın. Not Dizin oluşturma SQL cümlesi görünür ve cümle başarıyla inşa etti belirten bir ileti görüntülenir.
- İlk sorguyu yürütün.
- Seçin ve veritabanı adı sol tıklatın.
- "SQL" sekmesini tıklayın.
- İlk sorguyu SQL kodu yapıştırın veya yazın (bkz. ek Şekil 2).
- "Devam" tuşuna basın. Not sonuç listesindeki ilk ekran, sorgu yürütme süresi ile bir ileti ile birlikte görünür.
- Yürütme 5 kez tekrarlayın ve ortalama yanıt süresi hesaplamak.
- 5 ile sorgular 2 ile 6 arasındaki adımları yineleyin.
- Tüm süreç üç kez, 5.000, 10.000 ve 20.000 özleri veritabanları ile yapmak.
5. tasarım ve 3 NoSQL NoSQL veritabanlarında 6 karmaşıklık artan sorguları yürütmek
- NoSQL GUI başlatın ( Tablo malzemelerigörmek).
- Mongod programın bir DOS sistem penceresinden yürütme NoSQL 2.6 sunucu başlatma (bkz. ek şekil 3).
- Takip adım 2.4 NoSQL GUI kullanarak bağlantı noktası 27017 localhost sunucusuna bağlanmak için.
- Seçin ve sol tarafında NoSQL veritabanını genişletin.
- Koleksiyonu seçin.
- Araç çubuğundaki "koleksiyon" menüsünde'ı tıklatın.
- İlk NoSQL sorguyu yürütün.
- "Sorgu Oluşturucusu'nu" düğmesini çift tıklayın.
- Sorgu alanı"sağ Sorgu Oluşturucusu'nu çift tıklatın.
- NoSQL sorgu alan sorgu paneli (bkz: ek şekil 4) alanı metin kutusuna yazın.
- NoSQL sorgu değeri sorgu paneli değer metin kutusuna yazın.
Not: Bu sorgu {"ns3:EHRExtract.allCompositions.content.items.parts.parts.name.ns2:originalText. gibi bir şey olmalıdır değer":"Descripcion"}. Alan ve değer alıntı ve noktalı virgülle ayrılmış. - Sorgu Oluşturucusu'nun projeksiyon alanı çift tıklatın
- İlk projeksiyon projeksiyon metin kutusuna yazmak (bkz ek Şekil 5).
- Yeni projeksiyon metin kutusu eklemek için projeksiyon alanı çift tıklatın.
- İkinci projeksiyon projeksiyon metin kutusuna yazın.
Not: Bir projeksiyon sorgu tarafından alınan belgenin bir parçasını seçer. Bunlar {"ns3:EHRExtract. gibi bir şey olmalıdır allCompositions.content.items.parts.parts.value.value": 1} ve {" ns3: EHRExtract.all Compositions.content.items.parts.parts.value.nullFlavor ": 1} - Sorguyu yürütmek için mavi yürüt düğmesini tıklatın.
- Sorgu kodu sekmesinde sorgu kodu görselleştirin.
- Sonuç açıklama sekmesini görüntülemek: sonuç sayısı, yürütme süresi (milisaniye cinsinden).
- Görüntülemek genişletin ve sonuç sekmesinde sonuçları inceleyin.
- Sorgunun işlenmesi gerekiyorsa, bir Java programı sonuçları işlemek sorgu ve yöntemi ile NoSQL Java sürücüsüyle yazmak.
- Yürütme 5 kez tekrarlayın ve ortalama yanıt süresi hesaplamak.
- 5,7 kalan 2'den 6 sorguları için adım.
- Tüm süreç 5.000, 10.000 ve 20.000 NoSQL veritabanları ayıklar yineleyin.
6. tasarım ve çalıştırmak 3'te NoSQL mevcut veritabanları 6 artan karmaşıklık sorgular
- Mevcut DBMS başlatın.
- Java Admin istemcisini açın.
- "Veritabanına bağlan" düğmesine basın.
- Veritabanını seçin ve tıklayın.
- Tıkırtı üstünde yemek listesi "XPath kullanarak veritabanı başvurun"; konsültasyon iletişim kutusu görüntülenir.
- İlk XPath sorgusu yürütmek (bkz. ek şekil 6).
- İletişim kutusunun üst kısmındaki ilk sorgunun XPath kodu yapıştırın veya yazın.
- İletişim kutusunun araç çubuğunda "Execute" menüsünde'ı tıklatın.
- İletişim kutusunun alt kısmında "XML" sekmesini kullanarak XML sonuçlarını görüntüleyin.
- Sonuçları ve derleme ve iletişim kutusunun alt tarafındaki yürütme saat sayısını görüntüleyin.
- Yürütme 5 kez tekrarlayın ve ortalama yanıt süresi hesaplamak.
- Sorgu 2'den 6 için 6 arasındaki adımları yineleyin.
- 5.000, 10.000 ve 20.000 özleri veritabanları için tüm süreç üç kez yapmak.
7. tasarım ve MySQL ve NoSQL 5.000 ayıklar veritabanlarını kullanarak bir eşzamanlılık deneme çalıştırmak
Not: Mevcut veritabanı deneme bu dönemde önceki deneylerde daha kötü performansı nedeniyle kaldırıldı.
- Üç kısa zaman yanıt sorgularla (genellikle birkaç saniye altında) 5.000 özleri veritabanı kullanarak önceki deneyler seçin.
- Tanımlamak ve el ile gerekirse bu sorguları için uygun öznitelik dizinler oluşturmak.
- Program iki Java çok iş parçacıklı uygulamalar, MySQL için bir ve diğer NoSQL için; her uygulama üç farklı öncelikli konu, 1. adımda seçtiğiniz her sorgu için bir tane olacak.
- Yürütmek ve CPU (merkezi işlem birimi) dağıtım kullanmak için her iş parçacığı (sorgu) hesaplamak.
- Beş kez her 10dk span sırasında yürütmek düğmesini tıklatarak çoklu iş parçacığı kullanan her uygulama için yürütmek ve en yürütülen (en yüksek öncelik) hesaplamak ortalama işlem hacmi ve ortalama süre yanıt üç sorgular sorgu.
- Sorguları yürütme, öncelikleri ve yürütme süresi ile görüntüleyin.
- Hesaplama ortalama işlem hacmi ve ortalama yanıt süresi her üç sorgu.
Representative Results
Hastaların, onların adları, ilk ve son tarihleri ve önem derecesi gibi sorunlar hakkında bilgi içeren gerçekçi standart EHR özü üzerinde gerçekleştirilen altı farklı sorgular Tablo 1' de gösterilmiştir.
Ortalama yanıt süreleri altı sorguların her DBMS üç katlama-boyut veritabanında Tablo 2-4' te gösterilmiştir. Rakamlar 1-6 göster aynı sonuçları grafik olarak (dikey eksen boyunca bu rakamlar çok farklı ölçekler kullanır dikkat edin).
Hesaplama karmaşıklık güçlü doğrusal davranışını kullanılan 3 veri kümeleri nispeten küçük boyutu nedeniyle uygun dikkatli rağmen NoSQL veritabanları, tüm sorguları belirgindir. Ancak, ilişkisel ORM veritabanı belirsiz bir doğrusal davranışı gösterir. NoSQL veritabanı bir düz kadar yamaç var veritabanına daha vardır.
Literatürde Yayınlandı giriş ele gelişmiş ilişkisel sistemleri tarafından sonuçları Tablo 5' te bulunabilir. Benzer sorguları ve veritabanı boyutu Tablo 5 kol sonuçlarının NoSQL sonuçlar Tablo 3 enterpolasyonla her iki veritabanı sistemleri Q1 eşittir ama NoSQL Q3 içinde yanadır.
Eşzamanlılık deneylerin sonuçlarını Tablo 5 ve tablo6' da bulunabilir. NoSQL MySQL her iki işlem hacmi ve yanıt zaman içinde daha iyi. Aslında, NoSQL daha iyi yalıtım eşzamanlılık davranır ve eşzamanlı yürütme etkileyici bir veritabanında gibi duruyor.
Resim 1 : ORM MySQL, NoSQL, algoritmik karmaşıklık ve sorguları için Q1 ve Q4 DBMS var. Bu rakam7 Creative Commons lisansı (http://creativecommons.org/ licenses/by/4.0/) kullanarak değiştirildi ve yanıt süreleri saniye 5.000, 10.000 ve 20.000 ölçekli EHR her DBMS ve sorgu Q1 ve Q4 için veritabanları ayıklar gösterir. Bu rakam daha büyük bir versiyonunu görüntülemek için buraya tıklayınız.
Resim 2 : ORM MySQL DBMS sorgu Q2 için algoritmik karmaşıklık. Bu şekilde yanıt süreleri saniye 5.000, 10.000 ve 20.000 ölçekli EHR ORM MySQL veritabanı sorgu Q2 için ayıklar gösterilir. Bu rakam daha büyük bir versiyonunu görüntülemek için buraya tıklayınız.
Şekil 3 : NoSQL algoritmik karmaşıklık ve sorgu Q2 ve Q5 DBMS var. Bu rakam7 Creative Commons lisansı kullanarak değiştirildi (http://creativecommons.org/licenses/ tarafından / 4.0) ve gösterir yanıt süreleri saniye 5.000, 10.000 ve 20.000 ölçekli EHR her DBMS ve sorgu Q2 ve S5 için veritabanları ayıklar. Bu rakam daha büyük bir versiyonunu görüntülemek için buraya tıklayınız.
Şekil 4 : ORM MySQL DBMS algoritmik karmaşıklık sorgu Q3 ve S5 için. Yanıt süreleri saniye 5.000, 10.000 ve 20.000 ölçekli EHR her DBMS ve sorgu Q3 ve S5 için veritabanları ayıklar gösterir. Bu rakam daha büyük bir versiyonunu görüntülemek için buraya tıklayınız.
Şekil 5: var ve NoSQL DBMS için sorgu Q3 algoritmik karmaşıklık. Bu rakam7 Creative Commons lisansı (http://creativecommons.org/licenses/ tarafından/4.0 /) kullanarak değiştirildi ve yanıt süreleri saniye 5.000, 10.000 ve 20.000 ölçekli EHR her DBMS ve sorgu Q3 için veritabanları ayıklar gösterir. Bu rakam daha büyük bir versiyonunu görüntülemek için buraya tıklayınız.
Şekil 6 : ORM MySQL, algoritmik karmaşıklık var ve NoSQL DBMS için sorgu S6. Bu rakam7 Creative Commons lisansı (http://creativecommons.org/licenses/ tarafından/4.0 /) kullanarak değiştirildi ve yanıt süreleri saniye 5.000, 10.000 ve 20.000 ölçekli EHR her DBMS ve sorgu S6 için veritabanları ayıklar gösterir. Bu rakam daha büyük bir versiyonunu görüntülemek için buraya tıklayınız.
| Sorgu | |
| Q1 | Tek bir hastanın tüm sorunları bulma |
| Q2 | Tüm hastaların tüm sorunları bulma |
| Q3 | Başlangıç tarihi, çözünürlük Tarih ve önem bulmak |
| tek bir hastanın tek bir sorunu | |
| Q4 | Başlangıç tarihi, çözünürlük Tarih ve önem bulmak |
| tek bir hasta bütün sorunları problemini | |
| Q5 | Başlangıç tarihi, çözünürlük Tarih ve önem bulmak |
| tüm hastaların tüm sorunları sorunu | |
| S6 | Sorun 'farenjit' olan tüm hastalarda bulmak |
| ilk tarihi > ' 16/10/2007 =', çözümleme tarihi | |
| < = ' 06/05/2008 ' ve 'yüksek' |
Tablo 1: altı sorgular ilişkisel üzerinde gerçekleştirilen ve NoSQL veritabanlarını içeren standart EHR ayıklar hakkında hastaların sorunları. Bu tablo7 Creative Commons lisansı (http://creativecommons.org/ licenses/by/4.0/) kullanarak değiştirildi ve doğal olarak ifade edilen her DBMS için üç boyutu büyüyen veritabanı üzerinde gerçekleştirilen altı karmaşıklık büyüyen sorguları gösterir dili.
| ORM/MySQL | 5000 Dokümanlar | 10.000 Dokümanlar | 20.000 Dokümanlar |
| Q1 (s) | 25.0474 | 32.6868 | 170.7342 |
| Q2 (s) | 0.0158 | 0.0147 | 0,0222 |
| Q3 (s) | 3.3849 | 6.4225 | 207.2348 |
| Q4 (s) | 33.5457 | 114.6607 | 115.4169 |
| Q5 (s) | 9.6393 | 74.3767 | 29.0993 |
| S6 (s) | 1.4382 | 2.4844 | 183.4979 |
| Veritabanı boyutu | 4.6 GB | 9.4 GB | 19,4 GB |
| Toplam özler | 5000 | 10.000 | 20.000 |
Tablo 2: ortalama iki katına boyutlu veritabanları ORM MySQL ilişkisel DBMS altı sorgulamaları saniye içinde yanıt kez. Bu tablo ORM MySQL ilişkisel DBMS ve üç veritabanı bellek boyutunu kullanarak üç iki katına boyutlu veritabanları için her sorgu için 6 yanıt sürelerini gösterir.
| NoSQL | 5000 Dokümanlar | 10.000 Dokümanlar | 20.000 Dokümanlar | yamaç (*10exp(-6)) |
| Q1 (s) | 0.046 | 0.057 | 0.1221 | 5,07 |
| Q2 (s) | 34.5181 | 68.6945 | 136.2329 | 6,780.99 |
| Q3 (s) | 0.048 | 0.058 | 0.1201 | 4,81 |
| Q4 (s) | 0.052 | 0,061 | o.1241 | 4,81 |
| Q5 (s) | 38.0202 | 75.4376 | 149.933 | 7460.85 |
| S6 (s) | 9.5153 | 18.5566 | 36.7805 | 1,817.68 |
| Veritabanı boyutu | 1,95 GB | 3,95 GB | 7.95GB | |
| Toplam özler | 5000 | 10.000 | 20.000 |
Tablo 3: ortalama iki katına boyutlu veritabanları NoSQL NoSQL DBMS altı sorgulamaları saniye içinde yanıt kez. Bu tablo7 Creative Commons lisansı (http://creativecommons.org/ licenses/by/4.0/) kullanarak değiştirildi ve her sorgu altı yanıt süreleri NoSQL NoSQL DBMS ve bellek boyutu kullanarak üç iki katına boyutlu veritabanları için gösterir Üç veritabanları. Her sorgu doğrusal eğimi de gösterilir.
| biri yok | 5000 Dokümanlar | 10.000 Dokümanlar | 20.000 Dokümanlar | yamaç (*10exp(-6)) |
| Q1 (s) | 0.6608 | 3.7834 | 7.3022 | 442.76 |
| Q2 (s) | 60.7761 | 129.3645 | 287.362 | 15,105.73 |
| Q3 (s) | 0.6976 | 1.771 | 4.1172 | 227.96 |
| Q4 (s) | 0.6445 | 3.7604 | 7.3216 | 445.17 |
| Q5 (s) | 145.3373 | 291.2502 | 597.7216 | 30,158.93 |
| S6 (s) | 68.3798 | 138.9987 | 475.2663 | 27,125.82 |
| Veritabanı boyutu | 1,25 GB | 2.54GB | 5.12GB | |
| Toplam özler | 5000 | 10.000 | 20.000 |
Tablo 4: ortalama iki katına boyutlu veritabanları EXIST NoSQL DBMS altı sorgulamaları saniye içinde yanıt kez. Bu tablo7 Creative Commons lisansı (http://creativecommons.org/ licenses/by/4.0/) kullanarak değiştirildi ve DBMS ve bellek boyutunu her sorgu altı yanıt süreleri NoSQL kullanarak üç iki katına boyutlu veritabanları için mevcut gösterir Üç veritabanı. Her sorgu doğrusal eğimi de gösterilir.
| KOL kağıt | KOL (s) | Düğüm + yolu (s) | |
| Q1 | Sorgu 2.1 | 0.191 | 24.866 |
| Q3 | Sorgu 3.1 | 0,27 | 294.774 |
| Veritabanı boyutu | 2.90GB | 43.87GB | |
| Toplam özler | 29,743 | 29,743 |
Tablo 5: ortalama yanıt süreleri saniye sorgu Q1 ve Q3 sunulan gelişmiş ilişkisel sistemlerinin benzer 10 . Bu tablo7 Creative Commons lisansı (http://creativecommons.org/ licenses/by/4.0/) kullanarak değiştirildi ve iki çoğu benzer sorgu Q1 ve iki gelişmiş ilişkisel veritabanı sistemleri için karşılık gelen10 sundu Q3 gösterir ve onların yanıt süreleri. İki veritabanı boyutları da gösterilmiştir.
| ORM/MySQL | Üretilen iş | Tepki süresi |
| Q1 (s) | 4,711.60 | 0.0793 |
| Q3 (s) | 4,711.60 | 0.1558 |
| Q4 (s) | 4,711.60 | 0.9674 |
Tablo 6: ortalama işlem hacmi ve yanıt süresi saniye sorgu Q1, S3 ve S4 ORM MySQL ilişkisel eşzamanlı yürütme DBMS'de. Bu tablo7 Creative Commons lisansı (http://creativecommons.org/ licenses/by/4.0/) kullanarak değişiklik yapılmış ve en yüksek ortalama akış verimi, üç tek-hasta sorgu ve onların ortalama yanıt süreleri eşzamanlı gösterir ORM MySQL ilişkisel sistemini kullanarak yürütme deney.
| NoSQL | Üretilen iş | Tepki süresi |
| Q1 (s) | 178,672.60 | 0,003 |
| Q3 (s) | 178,672.60 | 0.0026 |
| Q4 (s) | 178,672.60 | 0.0034 |
Tablo 7: ortalama işlem hacmi ve yanıt süresi saniye sorgu Q1, S3 ve S4 NoSQL NoSQL DBMS eşzamanlı yürütme. Bu tablo7 Creative Commons lisansı (http://creativecommons.org/ licenses/by/4.0/) kullanarak değişiklik yapılmış ve en yüksek ortalama akış verimi, üç tek-hasta sorgu ve onların ortalama yanıt süreleri eşzamanlı gösterir NoSQL NoSQL sistemini kullanarak yürütme deney.
Ek şekil 1: MySQL sunucusuna bağlanmak için yazılım ekran ekran gösterir. Bu rakam indirmek için buraya tıklayınız.
Ek Şekil 2: ekran SQL arabirimi gösterir MySQL sunucusuna nerede ilk SQL sorgusu yazıyor. Bu rakam indirmek için buraya tıklayınız.
Ek şekil 3: NoSQL 2.6 localhost sunucu sunucu mongod yürüterek bir DOS sistem penceresini kullanarak başlatılır. Bu rakam indirmek için buraya tıklayınız.
Ek şekil 4: ekran 5.7.1 5.7.4 aracılığıyla adımda gösterildiği gibi Sorgu Oluşturucusu'nu metin kutuları içinde yazılı sorgu gösterir. Ekran adımı 5.7.3 göstermektedir. Bu rakam indirmek için buraya tıklayınız.
Ek Şekil 5: ekran gösterir adım 5.7.6. Bu rakam indirmek için buraya tıklayınız.
Ek şekil 6: ekran görüntüsü iletişim theupper kısmında XPath sorgusu yazma gösterilmiştir. Bu rakam indirmek için buraya tıklayınız.
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
Yazarlar ifşa gerek yok. Bu deneylerde kullanılan veri kümeleri bu deneyler için lisansı altında birkaç İspanyol hastaneler tarafından sağlanan ve sonuç olarak halka açık değildir. ISO/EN 13606 RM XML şeması University College London Merkezi tarafından Sağlık Bilişimi & Multiprofessional eğitim (çan) için sağlanan.
Acknowledgments
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
| Name | Company | Catalog Number | Comments |
| MySQL 5.7.20 | MySQL experiments | ||
| Red Hat Enterprise Linux Server release 7.4 (Maipo), 2.60GHz, RAM 16GB | |||
| MongoDB 2.6 | MongoDB experiments | ||
| Windows 7, 2.66GHz, RAM 12GB | |||
| eXist 3.0RC1 | eXist experiments | ||
| Windows 7, 2.66GHz, RAM 12GB | |||
| Studio 3T 5.5.1 | 3T Software Labs Gmbh | MongoDB GUI |
References
- Codd, E. F. A relational model for large shared data banks. Comm ACM. 13 (6), 377-387 (1970).
- Kalra, D., Lloyd, D. ISO 13606 electronic health record communication part 1: reference model. , ISO. Geneva. ISO 13606-1 (2008).
- Kalra, D., et al. Electronic health record communication part 2: archetype interchange specification. , ISO. Geneva. ISO 13606-2 (2008).
- Kalra, D., Beale, T., Heard, S. The openEHR foundation. Stud. Health Technol. Inform. 115, 153-173 (2005).
- Health Level seven. Health Level Seven International. , Available from: http://www.hl7.org (2017).
- Beale, T. Archetypes: constraint-based domain models for future proof information systems. OOPSLA, Workshop Behav Semant. , (2002).
- Sánchez-de-Madariaga, R., et al. Examining database persistence of ISO/EN 13606 standardized electronic health record extracts: relational vs. NoSQL approaches. BMC Medical Informatics and Decision Making. 32 (2), 493-503 (2017).
- Ireland, C., Bowers, D., Newton, M., Waugh, K. Understanding object-relational mapping: a framework based approach. Int. J. Adv. Softw. 2, 202-216 (2009).
- Node+Path Persistence. , Available from: https://openehr.atlassian.net/wiki/spaces/dev/pages/6553626/Node+Path+Persistence (2017).
- Wang, L., Min, L., Wang, R., et al. Archetype relational mapping - a practical openEHR persistence solution. BMC Medical Informatics and Decision Making. 15, 88 (2015).
- Kaur, K., Rani, R. Managing data in healthcare information systems: many models, one solution. Computer. March. , 52-59 (2015).
- Sabo, C., Pop, P. C., Valean, H., Danciulescu, D. An innovative approach to manage heterogeneous information using relational database systems. Advances in Intelligent Systems and Computing. 557, Springer. (2017).
