Method Article

Wykonywanie zapytań zwiększających złożoność w relacyjnych (MySQL) i NoSQL (MongoDB i EXist) bazach danych EHR zgodnych z normą ISO/EN 13606

DOI:

10.3791/57439

⸱

March 19th, 2018

 ,  ,  ,  , 
1Telemedicine and Information Society Department, Health Institute "Carlos III"

In This Article

Summary

$$\rightleftharpoonup{xx}$$ $$\longleftharp{xx}$$, $$\longrightharp{xx}$$,

To badanie porównuje relacyjne i nierelacyjne (NoSQL) standardowe systemy informacji medycznej. Złożoność obliczeniowa czasów odpowiedzi na zapytania dotyczące takich systemów zarządzania bazami danych (DBMS) jest obliczana przy użyciu baz danych o podwójnym rozmiarze. Wyniki te pomagają w omówieniu adekwatności każdego podejścia do bazy danych do różnych scenariuszy i problemów.

Abstract

$$\rightleftharpoonup{xx}$$ $$\longleftharp{xx}$$, $$\longrightharp{xx}$$,

To badanie pokazuje protokół do oceny złożoności obliczeniowej systemów baz danych informacji medycznych (DBMS) relacyjnych i nierelacyjnych (NoSQL (nie tylko Structured Query Language)) standaryzowanych systemów baz danych informacji medycznych (DBMS) relacyjnych i nierelacyjnych (NoSQL (nie tylko Structured Query Language)). Wykorzystuje zestaw trzech baz danych o podwójnej wielkości, tj. baz danych przechowujących 5000, 10 000 i 20 000 realistycznych, ustandaryzowanych ekstraktów EHR, w trzech różnych systemach zarządzania bazami danych (DBMS): relacyjnym mapowaniu obiektowo-relacyjnym MySQL (ORM), opartym na dokumentach NoSQL MongoDB i natywnym rozszerzalnym języku znaczników (XML) NoSQL eXist.

Obliczono średni czas odpowiedzi na sześć zapytań zwiększających złożoność, a wyniki wykazały liniowe zachowanie w przypadkach NoSQL. W polu NoSQL MongoDB prezentuje znacznie bardziej płaskie nachylenie liniowe niż eXist.

Systemy NoSQL mogą być również bardziej odpowiednie do utrzymywania standardowych systemów informacji medycznej ze względu na specjalny charakter polityk aktualizacji informacji medycznych, które nie powinny wpływać na spójność i wydajność danych przechowywanych w bazach danych NoSQL.

Jednym z ograniczeń tego protokołu jest brak bezpośrednich wyników ulepszonych systemów relacyjnych, takich jak mapowanie relacyjne archetypu (ARM) z tymi samymi danymi. Jednak interpolacja wyników bazy danych o podwojonym rozmiarze do tych przedstawionych w literaturze i innych opublikowanych wyników sugeruje, że systemy NoSQL mogą być bardziej odpowiednie w wielu konkretnych scenariuszach i problemach do rozwiązania. Na przykład NoSQL może być odpowiedni do zadań opartych na dokumentach, takich jak wyciągi z elektronicznej dokumentacji medycznej stosowane w praktyce klinicznej lub edycja i wizualizacja, lub w sytuacjach, w których celem jest nie tylko zapytanie o informacje medyczne, ale także przywrócenie elektronicznej dokumentacji medycznej w dokładnie jej pierwotnej formie.

Introduction

$$\rightleftharpoonup{xx}$$ $$\longleftharp{xx}$$, $$\longrightharp{xx}$$,

NoSQL (nie tylko SQL) DBMS pojawił się ostatnio jako alternatywa dla tradycyjnego relacyjnego DBMS (RDMBS). RDBMS od dziesięcioleci dominują w sposobie przechowywania danych w systemach baz danych. Dobrze zbadana i zrozumiana algebra relacyjna i rachunek różniczkowy zagwarantowały wydajność i spójność RDBMS1. Systemy NoSQL nie staną się substytutami systemów relacyjnych, ale mogą zachowywać się korzystnie w niektórych scenariuszach i pod kilkoma warunkami.

Niektóre z tych szczególnych scenariuszy i warunków wystąpiłyby podczas projektowania trwałości bazy danych systemów elektronicznej dokumentacji medycznej (EHR) używanych do zarządzania i przechowywania informacji medycznych. Aby zapewnić interoperacyjność i zrównoważony rozwój w praktyce, do standaryzacji ekstraktów EHR zastosowano kilka międzynarodowych standardów, takich jak ISO/EN 13606, openEHR i HL72,3,4,5.

Kilka standardów, takich jak ISO/EN 13606 i openEHR, rozdzieliło informacje i wiedzę na dwa różne poziomy abstrakcji, reprezentowane przez Model Referencyjny (RM) i specjalne struktury danych zwane archetypami. Ta separacja jest często nazywana modelem podwójnym i pozwala systemom EHR na semantyczną interoperacyjność, a wiedza medyczna na ewolucję bez przeprogramowywania całego systemu EHR, a w konsekwencji na utrzymanie i trwałość w praktyce6. Jednak podwójny model zaimplementowany w ustandaryzowanych systemach EHR wymaga, aby organizacja informacji była zgodna z określoną strukturą, a to ma poważne konsekwencje w sposobie, w jaki projektowany jest poziom trwałości bazy danych systemu7.

Object Relational Mapping (ORM)8 to jedna z metodologii implementacji systemu EHR wykorzystującego paradygmat relacyjnej bazy danych. ORM wyczerpująco odwzorowuje strukturę ustandaryzowanych plików EHR extracts XML (eXtensible Markup Language) używanych przez system do relacyjnej bazy danych. ORM konstruuje wiele tabel relacyjnych w sposób wyczerpujący zgodnie ze strukturą ustandaryzowanych plików XML wyodrębnianych przez EHR. Te tabele relacyjne są powiązane za pomocą wielu kluczy obcych, a wynikowy system może nie być zbyt wydajny.

Zaproponowano kilka ulepszeń relacyjnych dla ORM. openEHR's Node+Path9 zmniejsza liczbę tabel relacyjnych poprzez serializację poddrzew całego pliku XML do BLOB-ów (dużych obiektów binarnych). Jednak to uproszczenie powoduje złożoną logikę pobierania, uszkadzając złożone zapytania. Archetype Relational Mapping (ARM)10 generuje model bazy danych oparty na archetypach, budując nowy schemat relacyjny oparty na mapowaniach między archetypami i tabelami relacyjnymi. W związku z tym niektóre informacje niemedyczne zawarte w wyciągu z elektronicznej dokumentacji medycznej zostają utracone.

Wiele baz danych NoSQL opartych na dokumentach przechowuje całe dokumenty jako całe BLOBy, przestrzegając oryginalnego formatu XML lub JSON (JavaScript Object Notation). Oznacza to, że nie są konstruowane żadne tabele relacyjne. Te bazy danych NoSQL nie mają schematu i nie obsługują ani sprzężeń, ani właściwości (ACID)11, tj. niepodzielność, spójność, izolację lub trwałość. W rezultacie mogą być bardzo nieefektywne, jeśli element dokumentu odwołuje się do elementów tego samego lub innych takich dokumentów wykorzystujących link pośredni. Dzieje się tak dlatego, że w celu zachowania spójności całość dokumentów referencyjnych musi być przetwarzana sekwencyjnie. Jednak nierelacyjna baza danych może być nadal odpowiednia, jeśli główne zadanie wykonywane przez DBMS jest zadaniem opartym na dokumentach. Dzieje się tak, ponieważ dane mogą pozostać w formie bardziej zbliżonej do ich prawdziwej reprezentacji przy użyciu bazy danych NoSQL opartej na dokumentach, chociaż jest to również spowodowane specjalnymi zasadami trwałości realizowanymi przez dokumenty medyczne EHR (patrz sekcja dyskusji).

Celem tych metod jest pokazanie kilku eksperymentów w celu porównania implementacji warstwy trwałości standardowego systemu EHR przy użyciu trzech różnych DBMS: jednego relacyjnego (MySQL) i dwóch NoSQL (MongoDB opartego na dokumentach i natywnego XML eXist). Ich złożoność obliczeniowa została obliczona i porównana przy użyciu trzech różnych baz danych o rosnącym rozmiarze i sześciu różnych zapytań zwiększających złożoność. Trzy serwery baz danych zostały zainstalowane i skonfigurowane lokalnie na tym samym komputerze, na którym zostały wykonane zapytania. Szczegółowe informacje techniczne można znaleźć w tabeli materiałów.

Eksperymenty z współbieżnością zostały również przeprowadzone w celu porównania wydajności relacyjnych baz danych MySQL i NoSQL MongoDB. Opisane ulepszenia ORM (Node+Path i ARM) zostały również porównane przy użyciu odpowiednich wyników z literatury10.

Systemy zarządzania bazami danych stale ewoluują w coraz szybszym tempie. Nikt nie myślałby o tym wykładniczym rozwoju, gdyby jedynym istniejącym paradygmatem był model relacyjny. Dla przykładu, zobacz na przykład12, gdzie zaproponowano model do implementacji ulepszonych relacyjnych baz danych w czasie odpowiedzi, zachowujących właściwości ACID.

Protocol

$$\rightleftharpoonup{xx}$$ $$\longleftharp{xx}$$, $$\longrightharp{xx}$$,

1. Zbuduj relacyjny baz danych MySQL DBMS do przechowywania trzech dwuwymiarowych standardowych baz danych ekstraktów EHR

  1. Zaimportuj schemat XML W3C (World Wide Web Consortium) odpowiadający typom danych ISO/EN13606 RM i ISO21090 do "Java IDE" (zintegrowane środowisko programistyczne).
    UWAGA: ISO to skrót od International Standards Organization (Międzynarodowa Organizacja Normalizacyjna). EN to skrót od European Norm (norma europejska).
  2. Uruchom wtyczkę JAXB (Java XML Binding) w IDE; spowoduje to utworzenie klas Java odpowiadających strukturze elementów EHR i wyodrębnienie plików XML.
  3. Ręcznie oznacz klasy Java utworzone za pomocą etykiet JPA. Te etykiety odnoszą się do kardynalności i innych relacji między tabelami relacyjnymi bazy danych MySQL.
  4. Zaimportuj biblioteki JPA (Java Persistence API) do IDE i wykonaj metodę, która buduje bazę danych MySQL z oznaczonych klas Java.
  5. Utwórz trzy katalogi z 5 000, 10 000 i 20 000 realistycznych plików XML wyodrębnianych przez EHR.
  6. Wykonaj metodę JPA, aby załadować ekstrakt XML do MySQL DBMS we wszystkich ekstraktach z katalogu 5 000 ekstraktów.
  7. Powtórz krok 1.6 dwa razy, raz z katalogiem 10 000 ekstraktów i raz z katalogiem 20 000 ekstraktów.

2. Zbuduj bazę danych NoSQL MongoDB do przechowywania trzech dwuwymiarowych standardowych baz danych ekstraktów EHR

  1. Przetwarzanie każdego z trzech katalogów zawierających 5 000, 10 000 i 20 000 realistycznych plików EHR wyodrębnia pliki XML za pomocą standardowego programu do konwersji plików XML na pliki JSON, takie jak json.org.XML. Należy utworzyć trzy katalogi z plikami JSON 5 000, 10 000 i 20 000
    2. .
  2. Uruchom MongoDB GUI (graficzny interfejs użytkownika, patrz tabela materiałów).
  3. Uruchom serwer MongoDB 2.6 wykonując program mongod z okna systemu DOS (Disk Operating System).
  4. Połącz graficzny interfejs użytkownika bazy danych MongoDB z serwerem hosta lokalnego przy użyciu portu 27017.
    1. Wybierz menu "Połącz".
    2. Wpisz nazwę połączenia (na przykład "pierwszy").
    3. Wpisz localhost:27017 w polu tekstowym serwera bazy danych.
    4. Naciśnij przycisk "Połącz"; po lewej stronie powinno pojawić się drzewo z aktualnymi bazami danych.
  5. Zbuduj bazę danych zawierającą 5 000 standaryzowanych wyciągów z elektronicznej dokumentacji medycznej.
    1. Kliknij nazwę połączenia w górnej części drzewa po lewej stronie.
    2. Wybierz menu "Plik".
    3. Wybierz "Dodaj bazę danych".
    4. Wprowadź nazwę bazy danych w wyświetlonym oknie dialogowym.
    5. Kliknij przycisk OK.
  6. Zbuduj kolekcję zawierającą 5 000 standaryzowanych ekstraktów elektronicznej dokumentacji medycznej.
    1. Kliknij nazwę bazy danych w drzewie po lewej stronie.
    2. Wybierz menu "Baza danych".
    3. Wybierz "Dodaj Kolekcję".
    4. Wprowadź nazwę kolekcji w wyświetlonym oknie dialogowym.
    5. Kliknij " Utwórz".
    6. Kliknij na nazwę kolekcji.
    7. Wybierz menu "Importuj".
    8. Wybierz przycisk opcji ''JSON - mongo shell / / mongoexport'.
    9. Kliknij "Dalej".
    10. Naciśnij przycisk "Dodaj pliki źródłowe".
    11. Poruszaj się po komputerze za pomocą okna dialogowego.
    12. Otwórz katalog zawierający 5 000 plików wyodrębniania JSON.
    13. Zaznacz wszystkie pliki w katalogu.
    14. Naciśnij "Otwórz". Lista plików JSON powinna pojawić się w oknie dialogowym Importowanie.
    15. Naciśnij "Dalej"; po lewej stronie pojawi się podgląd nowej kolekcji w bazie danych.
    16. Naciśnij "Dalej".
    17. Naciśnij "Rozpocznij import". Postęp importu jest wyświetlany na dole po lewej stronie, wskazując liczbę zaimportowanych plików i czas, który upłynął.
  7. Powtórz kroki 5 i 6, aby utworzyć kolekcję 10 000 standardowych fragmentów elektronicznej dokumentacji medycznej.
  8. Powtórz kroki 5 i 6, aby utworzyć kolekcję 20 000 standardowych fragmentów elektronicznej dokumentacji medycznej.

3. Zbuduj bazę danych NoSQL eXist DBMS do przechowywania trzech dwuwymiarowych standardowych baz danych ekstraktów EHR

  1. Uruchom bazę danych eXist.
  2. Korzystając z ikony bazy danych, otwórz klienta Java Admin Client.
  3. Wprowadź hasło administratora.
  4. Naciśnij przycisk "Połącz".
  5. Zbuduj kolekcję zawierającą 5 000 standaryzowanych ekstraktów elektronicznej dokumentacji medycznej.
    1. Na pasku narzędzi wybierz menu "Utwórz nową kolekcję".
    2. W wyświetlonym oknie dialogowym wpisz nazwę nowej kolekcji.
    3. Kliknij "akceptuj"; pojawi się nowa kolekcja.
    4. Wybierz nazwę kolekcji.
    5. Na pasku narzędzi wybierz menu "Przechowuj pliki w bazie danych".
    6. Nawiguj po komputerze za pomocą okna dialogowego.
    7. Wybierz katalog zawierający 5 000 standardowych plików wyodrębniania XML.
    8. Kliknij przycisk "Wybierz pliki lub katalogi do przechowywania". Należy zauważyć, że zostanie wyświetlone okno dialogowe pokazujące postęp, przechowywane pliki i procent utworzonej bazy danych.
  6. Powtórz krok 5, aby utworzyć kolekcję zawierającą 10 000 standaryzowanych ekstraktów EHR.
  7. Powtórz krok 5, aby utworzyć kolekcję zawierającą 20 000 standaryzowanych ekstraktów EHR.

4. Projektuj i realizuj w 3 relacyjnych bazach danych MySQL 6 zapytań zwiększających złożoność

  1. Zaprojektuj sześć zapytań zwiększających złożoność zgodnie z archetypami używanymi przez ekstrakty EHR.
  2. Zaprogramuj skrypt SQL z pierwszym zapytaniem w bazie danych MySQL. SQL musi dostosować się do specjalnej struktury bazy danych MySQL ze względu na standaryzację ekstraktów (archetypy). Baza danych odwzorowuje całą strukturę ekstraktów. W rezultacie zapytanie SQL jest dość złożone.
  3. Zidentyfikuj atrybuty baz danych, które przyspieszyłyby czas odpowiedzi na zapytania, gdyby został na nich zbudowany indeks, a następnie skonstruuj takie indeksy, chociaż większość indeksów jest tworzona automatycznie przez system DBMS.
  4. Jeśli zapytanie wymaga indeksu, który nie jest tworzony automatycznie, skompiluj go ręcznie.
    1. Połącz się z serwerem MySQL (rysunek uzupełniający 1).
    2. Wybierz i kliknij nazwę bazy danych po lewej stronie.
    3. Wybierz i kliknij tabelę relacyjną, w której znajduje się indeksowane pole.
    4. Kliknij zakładkę "Struktura".
    5. Wybierz i kliknij kolumnę, w której zostanie zbudowany indeks.
    6. Kliknij "indeks". Zauważ, że pojawi się zdanie SQL budujące indeks i pojawi się komunikat informujący, że zdanie zostało pomyślnie zbudowane.
  5. Wykonaj pierwsze zapytanie.
    1. Wybierz i kliknij nazwę bazy danych po lewej stronie.
    2. Kliknij zakładkę "SQL".
    3. Wpisz lub wklej kod SQL pierwszego zapytania (patrz rysunek uzupełniający 2).
    4. Naciśnij "kontynuuj". Należy zauważyć, że zostanie wyświetlony pierwszy ekran listy wyników wraz z komunikatem z czasem wykonania zapytania.
    5. Powtórz wykonanie 5 razy i oblicz średni czas odpowiedzi.
  6. Powtórz krok 5 z zapytaniami od 2 do 6.
  7. Wykonaj cały proces trzy razy, korzystając z baz danych 5 000, 10 000 i 20 000 ekstraktów.

5. Projektowanie i wykonywanie w 3 bazach danych NoSQL MongoDB 6 Zapytania zwiększające złożoność

  1. Uruchom graficzny interfejs użytkownika MongoDB (patrz tabela materiałów).
  2. Uruchom serwer MongoDB 2.6 wykonując program mongod z okna systemu DOS (patrz Rysunek 3).
  3. Wykonaj krok 2.4, aby połączyć graficzny interfejs użytkownika bazy danych MongoDB z serwerem hosta lokalnego przy użyciu portu 27017.
  4. Wybierz i rozwiń bazę danych MongoDB po lewej stronie.
  5. Wybierz kolekcję.
  6. Kliknij menu "Kolekcja" na pasku narzędzi.
  7. Wykonaj pierwsze zapytanie bazy danych MongoDB.
    1. Kliknij dwukrotnie przycisk "Kreator zapytań".
    2. Kliknij dwukrotnie "Pole zapytania" w Kreatorze zapytań po prawej stronie.
    3. Wpisz pole zapytania MongoDB w polu tekstowym pola panelu zapytań (patrz rysunek uzupełniający 4).
    4. Wpisz wartość zapytania MongoDB w polu tekstowym wartości panelu zapytań.
      UWAGA: To zapytanie powinno wyglądać mniej więcej tak: {"ns3:EHRExtract.allCompositions.content.items.parts.parts.name.ns2:originalText. value": "Opis"}. Pole i wartość są ujęte w cudzysłowy i oddzielone średnikiem.
    5. Kliknij dwukrotnie pole Projekcja w Konstruktorze zapytań
    6. Wpisz pierwsze rzutowanie w polu tekstowym projekcji (patrz rysunek uzupełniający 5).
    7. Kliknij dwukrotnie pole projekcji, aby dodać nowe pole tekstowe projekcji.
    8. Wpisz drugą projekcję w polu tekstowym projekcji.
      UWAGA: Projekcja wybiera część dokumentu pobraną przez zapytanie. Powinny one wyglądać mniej więcej tak: {"ns3:EHRExtract. allCompositions.content.items.parts.parts.value.value": 1} i {"ns3: EHRExtract.all Compositions.content.items.parts.parts.value.nullFlavor" : 1}
    9. Kliknij niebieski przycisk odtwarzania, aby wykonać zapytanie.
    10. Wizualizacja kodu zapytania na karcie Kod zapytania.
    11. Wyświetl szczegóły wyniku w zakładce Wyjaśnienie: liczba wyników, czas wykonania w milisekundach.
    12. Wyświetl, rozwiń i sprawdź wyniki na karcie Wynik.
    13. Jeśli wymagane jest dalsze przetwarzanie zapytania, napisz program Java ze sterownikiem Java MongoDB z zapytaniem i metodą do przetwarzania wyników.
    14. Powtórz wykonanie 5 razy i oblicz średni czas odpowiedzi.
  8. Wykonaj krok 5.7 dla pozostałych zapytań od 2 do 6
    9. .
  9. Powtórz cały proces w 5 000, 10 000 i 20 000 wyodrębnionych bazach danych MongoDB.

6. Projektowanie i wykonywanie w 3 bazach danych NoSQL eXist 6 Zapytania o rosnącej złożoności

  1. Uruchom system zarządzania bazami danych eXist.
  2. Otwórz klienta Java Admin Client.
  3. Naciśnij przycisk "połącz z bazą danych".
  4. Wybierz bazę danych i kliknij na nią.
  5. Kliknij menu "Skonsultuj bazę danych za pomocą XPath"; pojawi się okno dialogowe konsultacji.
  6. Wykonaj pierwsze zapytanie XPath (patrz rysunek uzupełniający 6).
    1. Wpisz lub wklej kod XPath pierwszego zapytania w górnej części okna dialogowego.
    2. Kliknij menu "Wykonaj" na pasku narzędzi okna dialogowego.
    3. Wyświetl wyniki XML za pomocą zakładki "XML" w dolnej części okna dialogowego.
    4. Wyświetl liczbę wyników oraz czas kompilacji i wykonania w dolnej części okna dialogowego.
    5. Powtórz wykonanie 5 razy i oblicz średni czas odpowiedzi.
  7. Powtórz krok 6 dla zapytań od 2 do 6.
  8. Wykonaj cały proces trzy razy, dla 5 000, 10 000 i 20 000 wyodrębnionych baz danych eXist.

7. Zaprojektuj i wykonaj eksperyment współbieżności przy użyciu baz danych MySQL i MongoDB 5 000 ekstraktów

UWAGA: Baza danych eXist została usunięta z eksperymentu w tym momencie z powodu gorszych wyników w poprzednich eksperymentach.

  1. Wybierz zapytania z trzema odpowiedziami o najkrótszym czasie w poprzednich eksperymentach przy użyciu 5 000 wyodrębnionych baz danych (zwykle poniżej kilku sekund).
  2. W razie potrzeby zidentyfikuj i ręcznie utwórz odpowiednie indeksy atrybutów dla tych zapytań.
  3. Zaprogramuj dwie wielowątkowe aplikacje Java, jedną dla MySQL, a drugą dla MongoDB; każda aplikacja będzie miała trzy różne priorytety, po jednym dla każdego zapytania wybranego w kroku 1.
  4. Wykonaj i oblicz dystrybucję użycia procesora CPU (jednostki centralnej) dla każdego wątku (zapytania).
  5. Uruchom każdą aplikację wielowątkową, klikając przycisk wykonywania pięć razy w każdym 10-minutowym przedziale i oblicz najczęściej wykonywaną (o najwyższym priorytecie) średnią przepływność zapytania oraz średni czas odpowiedzi trzech zapytań.
  6. Wyświetlanie wykonywanych zapytań z priorytetami i czasem wykonywania.
  7. Obliczanie średniej przepływności i średniego czasu odpowiedzi dla każdego z trzech zapytań.

Results

$$\rightleftharpoonup{xx}$$ $$\longleftharp{xx}$$, $$\longrightharp{xx}$$,

Sześć różnych zapytań przeprowadzonych na realistycznych, standardowych wyciągach EHR zawierających informacje o problemach pacjentów, w tym ich imiona, początkowe i końcowe daty oraz nasilenie, przedstawiono w Tabeli 1.

Średni czas odpowiedzi dla sześciu zapytań w trzech podwajających się bazach danych w każdym DBMS są pokazane w tabelach 2-4. Rysunki 1-6 pokazują te same wyniki graficznie (zauważ, że osie pionowe używają bardzo różnych skal na tych rysunkach).

Silne liniowe zachowanie złożoności obliczeniowej jest widoczne we wszystkich zapytaniach baz danych NoSQL, chociaż z zachowaniem odpowiedniej ostrożności ze względu na stosunkowo mały rozmiar 3 używanych zestawów danych. Jednak relacyjna baza danych ORM wykazuje niejasne zachowanie liniowe. Baza danych MongoDB ma znacznie bardziej płaskie nachylenie niż baza danych eXist.

Wyniki ulepszonych systemów relacyjnych omówione we wstępie opublikowanym w literaturze można znaleźć w Tabeli 5. Interpolacja wyników bazy danych MongoDB z tabeli 3 z podobnymi zapytaniami i rozmiarami baz danych wyników ARM z tabeli 5 równa się obu systemom baz danych w Q1, ale faworyzuje MongoDB w Q3.

Wyniki eksperymentów z współbieżnością można znaleźć w Tabeli 5 i Tabeli6. MongoDB bije MySQL zarówno pod względem przepustowości, jak i czasu odpowiedzi. W rzeczywistości MongoDB zachowuje się lepiej w współbieżności niż w izolacji i stanowi imponującą bazę danych w współbieżnym wykonywaniu.

figure-results-1
Rysunek 1: Złożoność algorytmiczna ORM MySQL, MongoDB i eXist DBMS dla zapytań Q1 i Q4. Ten rysunek został zmodyfikowany z7 przy użyciu licencji Creative Commons (http://creativecommons.org/ licenses/by/4.0/) i pokazuje czasy odpowiedzi w sekundach dla EHR o rozmiarach 5 000, 10 000 i 20 000 EHR wyodrębnia bazy danych dla każdego DBMS i zapytania Q1 i Q4. Kliknij tutaj, aby zobaczyć większą wersję tego rysunku.

figure-results-2
Rysunek 2: Złożoność algorytmiczna ORM MySQL DBMS dla zapytania Q2. Ta ilustracja przedstawia czasy odpowiedzi w sekundach dla EHR o rozmiarach 5 000, 10 000 i 20 000 wyodrębnia bazę danych ORM MySQL dla zapytania Q2. Kliknij tutaj, aby zobaczyć większą wersję tego rysunku.

figure-results-3
Rysunek 3: Złożoność algorytmiczna MongoDB i eXist DBMS dla zapytań Q2 i Q5. Ten rysunek został zmodyfikowany z7 przy użyciu licencji Creative Commons (http://creativecommons.org/licenses/ by/4.0) i pokazuje czasy odpowiedzi w sekundach dla EHR o rozmiarach 5 000, 10 000 i 20 000 wyodrębnia bazy danych dla każdego DBMS i zapytania Q2 i Q5. Kliknij tutaj, aby zobaczyć większą wersję tego rysunku.

figure-results-4
Rysunek 4: Złożoność algorytmiczna ORM MySQL DBMS dla zapytań Q3 i Q5. Pokazuje czasy odpowiedzi w sekundach dla EHR o rozmiarach 5 000, 10 000 i 20 000 wyodrębnia bazy danych dla każdego systemu DBMS i zapytań Q3 i Q5. Kliknij tutaj, aby zobaczyć większą wersję tego rysunku.

figure-results-5
Rysunek 5: Złożoność algorytmiczna eXist i MongoDB DBMS dla zapytania Q3. Ten rysunek został zmodyfikowany z7 przy użyciu licencji Creative Commons (http://creativecommons.org/licenses/ by/4.0/ ) i pokazuje czasy odpowiedzi w sekundach dla 5 000, 10 000 i 20 000 rozmiarów EHR wyodrębnia bazy danych dla każdego DBMS i zapytania Q3. Kliknij tutaj, aby zobaczyć większą wersję tego rysunku.

figure-results-6
Rysunek 6: Złożoność algorytmiczna ORM MySQL, eXist i MongoDB DBMS dla zapytania Q6. Ten rysunek został zmodyfikowany z7 przy użyciu licencji Creative Commons (http://creativecommons.org/licenses/ by/4.0/) i pokazuje czasy odpowiedzi w sekundach dla EHR o rozmiarach 5 000, 10 000 i 20 000 EHR wyodrębnia bazy danych dla każdego DBMS i zapytania Q6. Kliknij tutaj, aby zobaczyć większą wersję tego rysunku.

zapytanie
Pytanie 1Znajdź wszystkie problemy jednego pacjenta
Pytanie 2Znajdź wszystkie problemy wszystkich pacjentów
Pytanie 3Znajdź datę początkową, datę rozwiązania i ważność
pojedynczego problemu jednego pacjenta
Pytanie 4Znajdź datę początkową, datę rozwiązania i ważność
wszystkich problemów dotyczy jednego pacjenta
Pytanie 5Znajdź datę początkową, datę rozwiązania i ważność
wszystkich problemów dotyczy wszystkich pacjentów
Pytanie 6Znajdź wszystkich pacjentów z problematycznym zapaleniem gardła,
Data początkowa >= "16/10/2007", data uchwały
<= "06/05/2008" i stopień ważności "wysoki"

Tabela 1: Sześć zapytań wykonanych na relacyjnych bazach danych i bazach danych NoSQL, zawierających ustandaryzowane wyciągi EHR dotyczące problemów pacjentów. Ta tabela została zmodyfikowana z7 przy użyciu licencji Creative Commons (http://creativecommons.org/ licenses/by/4.0/) i pokazuje sześć rosnących złożoności zapytań wykonanych na trzech rosnących bazach danych dla każdego DBMS wyrażonego w języku naturalnym.

TGL TGL pkt. TGL TGL TGL TGE TGL TGL szt. szt. szt.
ORM/MySQL5000 dokumentów10 000 dokumentów20 000 dokumentów
Pytanie 1 (s)25.0474Numer katalogowy: 32.6868Numer katalogowy: 170.7342
Pytanie 2 (s)0,01580,01470,0222
Pytanie 3 (s)3,3849Numer katalogowy: 6,4225Numer katalogowy 207.2348
Pytanie 4 (s)Numer katalogowy: 33.5457Numer katalogowy 114.6607Numer katalogowy: 115.4169
Pytanie 5 (s)9,639374.376729.0993
Pytanie 6 (s)1,4382Nr kat. 2,4844Numer katalogowy: 183.4979
Rozmiar bazy danych4,6 GB9,4 GB19,4 GB
Ekstrakty ogółem500010 00020 000

Tabela 2: Średni czas odpowiedzi w sekundach dla sześciu zapytań w podwajających się bazach danych relacyjnego DBMS MySQL. W tej tabeli przedstawiono sześć czasów odpowiedzi dla każdego zapytania dla trzech baz danych o podwojonym rozmiarze przy użyciu relacyjnego systemu DBMS ORM MySQL i rozmiaru w pamięci trzech baz danych.

pkt. pkt. pkt. TGL zł pkt. pkt. pkt. pkt. TGL Pręty TGL jedn. TGL zł szt. szt. szt.
Baza danych MongoDB5000 dokumentów10 000 dokumentów20 000 dokumentówNachylenie (*10exp(-6))
Pytanie 1 (s)0,0460,0570,12215.07
Pytanie 2 (s)Numer katalogowy: 34.5181Numer katalogowy: 68.6945Numer katalogowy: 136.23296 780,99
Pytanie 3 (s)0,0480,0580,1201 jezdnegoZ godziny 4,81
Pytanie 4 (s)0,0520,061O.1241Z godziny 4,81
Pytanie 5 (s)Numer katalogowy: 38.0202Numer katalogowy: 75.4376149.9337460.85
Pytanie 6 (s)9,5153Numer katalogowy: 18.5566Numer katalogowy: 36.78051 817,68
Rozmiar bazy danych1,95 GB3,95 GB7,95 GB
Ekstrakty ogółem500010 00020 000

Tabela 3: Średni czas odpowiedzi w sekundach dla sześciu zapytań w bazach danych MongoDB NoSQL DBMS. Ta tabela została zmodyfikowana z7 przy użyciu licencji Creative Commons (http://creativecommons.org/ licenses/by/4.0/) i pokazuje sześć czasów odpowiedzi każdego zapytania dla trzech baz danych o podwójnym rozmiarze przy użyciu bazy danych NoSQL MongoDB DBMS oraz rozmiar w pamięci trzech baz danych. Pokazane jest również nachylenie liniowe każdego zapytania.

pkt. TGL jedn. TGLI TGL zł TGL pkt. TGL TGL zł TGL zł pkt. szt. szt. szt.
istnieć5000 dokumentów10 000 dokumentów20 000 dokumentówNachylenie (*10exp(-6))
Pytanie 1 (s)0,66083,78347,3022442,76
Pytanie 2 (s)Numer katalogowy: 60.7761Numer katalogowy: 129.3645287.36215 105,73
Pytanie 3 (s)Numer katalogowy: 0,69761,771Nr kat. 4,1172227,96
Pytanie 4 (s)0,6445Nr kat. 3,76047,3216445,17
Pytanie 5 (s)Numer katalogowy 145.3373Numer katalogowy 291.2502Numer telefonu 597.721630 158,93
Pytanie 6 (s)Numer katalogowy: 68.3798Numer katalogowy: 138.9987Numer katalogowy: 475.266327 125,82
Rozmiar bazy danych1,25 GB2,54 GB5,12 GB
Ekstrakty ogółem500010 00020 000

Tabela 4: Średni czas odpowiedzi w sekundach dla sześciu zapytań w bazach danych eXist NoSQL DBMS. Ta tabela została zmodyfikowana z7 przy użyciu licencji Creative Commons (http://creativecommons.org/ licenses/by/4.0/) i pokazuje sześć czasów odpowiedzi każdego zapytania dla trzech baz danych o podwójnym rozmiarze przy użyciu NoSQL eXist DBMS oraz rozmiar w pamięci trzech baz danych. Pokazane jest również nachylenie liniowe każdego zapytania.

pkt. TGL pkt. TGL TGL TGL
Papier ARMARM (y)Węzeł+Ścieżka (i)
Pytanie 1Zapytanie 2.10,19124 866
Pytanie 3Zapytanie 3.10,27294.774
Rozmiar bazy danych2,90 GB43,87 GB
Ekstrakty ogółem29 74329 743

Tabela 5: Średni czas odpowiedzi w sekundach na zapytania podobne do Q1 i Q3 ulepszonych systemów relacyjnych przedstawionych w10. Ta tabela została zmodyfikowana z7 przy użyciu licencji Creative Commons (http://creativecommons.org/ licenses/by/4.0/) i pokazuje dwa najbardziej podobne zapytania do Q1 i Q3 przedstawione w10 odpowiadające dwóm ulepszonym systemom relacyjnych baz danych i ich czasom odpowiedzi. Pokazane są również dwa rozmiary bazy danych.

zł TGL zł pkt. zł
ORM/MySQLprzepustowośćCzas odpowiedzi
Pytanie 1 (s)4 711,600,0793
Pytanie 3 (s)4 711,600,1558
Pytanie 4 (s)4 711,600,9674

Tabela 6: Średnia przepustowość i czas odpowiedzi w sekundach zapytań Q1, Q3 i Q4 relacyjnego DBMS ORM MySQL w jednoczesnym wykonaniu. Ta tabela została zmodyfikowana z7 przy użyciu licencji Creative Commons (http://creativecommons.org/ licenses/by/4.0/) i pokazuje najwyższą średnią przepustowość trzech zapytań dla jednego pacjenta oraz ich średni czas odpowiedzi w eksperymencie równoczesnego wykonywania przy użyciu systemu relacyjnego ORM MySQL.

zł zł zł
Baza danych MongoDBprzepustowośćCzas odpowiedzi
Pytanie 1 (s)178 672,600,003
Pytanie 3 (s)178 672,600,0026
Pytanie 4 (s)178 672,600,0034

Tabela 7: Średnia przepustowość i czas odpowiedzi w sekundach zapytań Q1, Q3 i Q4 MongoDB NoSQL DBMS w jednoczesnym wykonywaniu. Ta tabela została zmodyfikowana z7 przy użyciu licencji Creative Commons (http://creativecommons.org/ licenses/by/4.0/) i pokazuje najwyższą średnią przepustowość trzech zapytań dla jednego pacjenta oraz ich średnie czasy odpowiedzi w eksperymencie z jednoczesnym wykonaniem przy użyciu systemu MongoDB NoSQL.

Rysunek uzupełniający 1: Zrzut ekranu pokazuje ekran oprogramowania do połączenia z serwerem MySQL. Kliknij tutaj, aby pobrać ten rysunek.

Rysunek uzupełniający 2: Zrzut ekranu pokazuje interfejs SQL do serwera MySQL, na którym zostało napisane pierwsze zapytanie SQL. Kliknij tutaj, aby pobrać ten rysunek.

Rysunek uzupełniający 3: Serwer hosta lokalnego MongoDB 2.6 jest uruchamiany za pomocą okna systemu DOS poprzez uruchomienie serwera mongod. Kliknij tutaj, aby pobrać ten rysunek.

Rysunek uzupełniający 4: Zrzut ekranu pokazuje zapytanie zapisane w polach tekstowych Kreatora zapytań, jak pokazano w krokach od 5.7.1 do 5.7.4. Zrzut ekranu ilustruje krok 5.7.3. Kliknij tutaj, aby pobrać ten rysunek.

Rysunek uzupełniający 5:Zrzut ekranu pokazuje krok 5.7.6. Kliknij tutaj, aby pobrać ten rysunek.

Rysunek uzupełniający 6: Zrzut ekranu ilustruje zapis zapytania XPath w górnej części okna dialogowego. Kliknij tutaj, aby pobrać ten rysunek.

Discussion

$$\rightleftharpoonup{xx}$$ $$\longleftharp{xx}$$, $$\longrightharp{xx}$$,

Protokół ten pokazuje, że czysto relacyjne systemy ORM nie wydają się praktyczne w przypadku zapytań dla jednego pacjenta (Q1, Q3 i Q4), ponieważ czasy odpowiedzi są wolniejsze, prawdopodobnie ze względu na dużą liczbę tabel relacyjnych wykonujących wiele kosztownych operacji łączenia oraz ze względu na system przechowywania używany przez określony rodzaj bazy danych. Bazy danych NoSQL przechowują dane w sposób oparty na dokumentach, podczas gdy systemy relacyjne używają sposobu opartego na tabelach, który rozprzestrzenia każdy dokument w całej bazie danych. Systemy NoSQL wykazują nachylenie liniowe, przy czym MongoDB działa znacznie szybciej niż eXist DBMS. W współbieżności MongoDB zachowuje się również znacznie lepiej niż relacyjny MySQL ORM7.

Ten protokół przedstawia protokół rozwiązywania problemów dla wyników przedstawionych w7 dotyczących ORM MySQL DBMS. System MySQL został zaktualizowany do najnowszej wersji, a wyniki zostały nieznacznie zmodyfikowane. Ponadto krytycznym punktem w systemach NoSQL opartych na dokumentach, takich jak MongoDB, jest to, że mogą one zachować spójność podczas przechowywania informacji medycznych7 , ponieważ gdy ekstrakt EHR jest aktualizowany, nie jest nadpisywany, ale generowany i przechowywany w systemie jest zupełnie nowy wyciąg z nowymi danymi, a oryginalny wyciąg jest zachowywany. Jest to ścisły wymóg dotyczący informacji medycznych, ponieważ niektórzy lekarze mogli podejmować ważne decyzje medyczne na podstawie oryginalnych danych.

Ulepszony relacyjny system ARM drastycznie zmniejsza liczbę tabel relacyjnych i poprawia wydajność relacyjną. Jednakże, ponieważ modyfikuje schemat relacyjny, informacje medyczne zawarte w ekstraktach mogą być przeszukiwane, ale ekstrakty nie mogą być odzyskane w ich dokładnej oryginalnej formie.

W przypadku bardzo dużych baz danych w wtórnym użyciu (badaniach) nie jest jasne, który system baz danych jest bardziej odpowiedni, ponieważ zapytania dla wszystkich pacjentów (Q2 i Q5) zachowują się lepiej w systemach ORM niż w systemach NoSQL, ale systemy te działają lepiej niż uproszczone systemy relacyjne w 12. Uważamy, że Q6 jest szczególnym zapytaniem pomiędzy praktyką kliniczną a wtórnym użyciem, którego zachowanie nie może być zdeterminowane przez wyniki uzyskane w tych eksperymentach.

Jednak jednym z ograniczeń metody jest brak bezpośrednich eksperymentów porównujących ulepszony relacyjny system ARM z NoSQL MongoDB dotyczących zapytań do pojedynczego pacjenta w praktyce medycznej z dokładnie tymi samymi danymi, które zostały użyte w protokole. Utrzymaliśmy wyniki interpolacji Tabeli 3 i Tabeli 5 dotyczącej zapytań u jednego pacjenta do czasu przeprowadzenia eksperymentu z uwzględnieniem zoptymalizowanego ARM w protokole. Pozostawiamy te eksperymenty na przyszłe zastosowania. Jednym z kluczowych kroków w ramach protokołu jest wybór darmowej bazy danych, podobnych wersji oprogramowania z ostatnich lat, abyśmy mogli porównać dokładny stan wiedzy z tych trzech technologii.

Jest to jedna z pierwszych prób bezpośredniego porównania systemów relacyjnych i NoSQL przy użyciu rzeczywistych, realistycznych, ustandaryzowanych informacji medycznych. Jednak konkretny system, który ma być zastosowany, zależy w dużej mierze od rzeczywistego scenariusza i problemu, który ma zostać rozwiązany8.

Disclosures

$$\rightleftharpoonup{xx}$$ $$\longleftharp{xx}$$, $$\longrightharp{xx}$$,

Autorzy nie mają nic do ujawnienia. Zestawy danych wykorzystane w tych eksperymentach zostały dostarczone przez kilka hiszpańskich szpitali na podstawie licencji na te eksperymenty i w związku z tym nie są publicznie dostępne. Schemat XML RM ISC/EN 13606 został dostarczony przez University College London Centre for Health Informatics & Multiprofessional Education (CHIME).

Acknowledgements

$$\rightleftharpoonup{xx}$$ $$\longleftharp{xx}$$, $$\longrightharp{xx}$$,

Autorzy chcieliby podziękować Dr Dipakowi Kalrze, liderowi grupy zadaniowej EHRCom, która zdefiniowała normę ISO/EN 13606 oraz jego zespołowi z University College London za zgodę na użycie schematu XML ISO/EN 13606 W3C.

Ta praca była wspierana przez Instituto de Salud Carlos III [numery grantów PI15/00321, PI15/00003, PI1500831, PI15CIII/00010 i RD16CIII].

Materials

List of materials used in this article
NameCompanyCatalog NumberComments
MySQL 5.7.20Eksperymenty MySQL
Red Hat Enterprise Linux Server release 7.4 (Maipo), 2.60GHz, RAM 16GB
MongoDB 2.6MongoDB eksperymenty
Windows 7, 2.66GHz, RAM 12GB 
eXist 3.0RC1eXist eksperymentuje
z Windows 7, 2.66GHz, RAM 12GB 
Graficzny interfejs użytkownika programu Studio 3T 5.5.13T Software Labs GmbhMongoDB

References

$$\rightleftharpoonup{xx}$$ $$\longleftharp{xx}$$, $$\longrightharp{xx}$$,
  1. A relational model for large shared data banks. Comm ACM. 13 (6), 377-387 (1970).">Codd, E. F. A relational model for large shared data banks. Comm ACM. 13 (6), 377-387 (1970).
  2. ISO 13606 electronic health record communication part 1: reference model. , ISO. Geneva. ISO 13606-1 (2008).">Kalra, D., Lloyd, D. ISO 13606 electronic health record communication part 1: reference model. , ISO. Geneva. ISO 13606-1 (2008).
  3. Electronic health record communication part 2: archetype interchange specification. , ISO. Geneva. ISO 13606-2 (2008).">Kalra, D., et al. Electronic health record communication part 2: archetype interchange specification. , ISO. Geneva. ISO 13606-2 (2008).
  4. The openEHR foundation. Stud. Health Technol. Inform. 115, 153-173 (2005).">Kalra, D., Beale, T., Heard, S. The openEHR foundation. Stud. Health Technol. Inform. 115, 153-173 (2005).
  5. http://www.hl7.org (2017).">Health Level seven. Health Level Seven International. , Available from: http://www.hl7.org (2017).
  6. Archetypes: constraint-based domain models for future proof information systems. OOPSLA, Workshop Behav Semant. , (2002).">Beale, T. Archetypes: constraint-based domain models for future proof information systems. OOPSLA, Workshop Behav Semant. , (2002).
  7. 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).">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).
  8. Understanding object-relational mapping: a framework based approach. Int. J. Adv. Softw. 2, 202-216 (2009).">Ireland, C., Bowers, D., Newton, M., Waugh, K. Understanding object-relational mapping: a framework based approach. Int. J. Adv. Softw. 2, 202-216 (2009).
  9. https://openehr.atlassian.net/wiki/spaces/dev/pages/6553626/Node+Path+Persistence (2017).">Node+Path Persistence. , Available from: https://openehr.atlassian.net/wiki/spaces/dev/pages/6553626/Node+Path+Persistence (2017).
  10. Archetype relational mapping - a practical openEHR persistence solution. BMC Medical Informatics and Decision Making. 15, 88(2015).">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).
  11. Managing data in healthcare information systems: many models, one solution. Computer. March. , 52-59 (2015).">Kaur, K., Rani, R. Managing data in healthcare information systems: many models, one solution. Computer. March. , 52-59 (2015).
  12. An innovative approach to manage heterogeneous information using relational database systems. Advances in Intelligent Systems and Computing. 557, Springer. (2017).">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).

Reprints and Permissions

Request permission to reuse the text or figures of this JoVE article

Request Permission

Tags

Complexity Increasing QueriesRelational Database SystemsNoSQL Database SystemsMySQL MongoDB EXistElectronic Health RecordsDatabase Management SystemsComputational Complexity AnalysisResponse Time MeasurementDoubling Size DatabasesStandardized EHR Databases

Related Articles