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.
Artykuł metodologiczny
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
W tym artykule
Podsumowanie
Streszczenie
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.
Wprowadzenie
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.
Protokół
1. Zbuduj relacyjny baz danych MySQL DBMS do przechowywania trzech dwuwymiarowych standardowych baz danych ekstraktów EHR
- 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). - 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.
- 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.
- Zaimportuj biblioteki JPA (Java Persistence API) do IDE i wykonaj metodę, która buduje bazę danych MySQL z oznaczonych klas Java.
- Utwórz trzy katalogi z 5 000, 10 000 i 20 000 realistycznych plików XML wyodrębnianych przez EHR.
- Wykonaj metodę JPA, aby załadować ekstrakt XML do MySQL DBMS we wszystkich ekstraktach z katalogu 5 000 ekstraktów.
- 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
- 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 .
- Uruchom MongoDB GUI (graficzny interfejs użytkownika, patrz tabela materiałów).
- Uruchom serwer MongoDB 2.6 wykonując program mongod z okna systemu DOS (Disk Operating System).
- Połącz graficzny interfejs użytkownika bazy danych MongoDB z serwerem hosta lokalnego przy użyciu portu 27017.
- Wybierz menu "Połącz".
- Wpisz nazwę połączenia (na przykład "pierwszy").
- Wpisz localhost:27017 w polu tekstowym serwera bazy danych.
- Naciśnij przycisk "Połącz"; po lewej stronie powinno pojawić się drzewo z aktualnymi bazami danych.
- Zbuduj bazę danych zawierającą 5 000 standaryzowanych wyciągów z elektronicznej dokumentacji medycznej.
- Kliknij nazwę połączenia w górnej części drzewa po lewej stronie.
- Wybierz menu "Plik".
- Wybierz "Dodaj bazę danych".
- Wprowadź nazwę bazy danych w wyświetlonym oknie dialogowym.
- Kliknij przycisk OK.
- Zbuduj kolekcję zawierającą 5 000 standaryzowanych ekstraktów elektronicznej dokumentacji medycznej.
- Kliknij nazwę bazy danych w drzewie po lewej stronie.
- Wybierz menu "Baza danych".
- Wybierz "Dodaj Kolekcję".
- Wprowadź nazwę kolekcji w wyświetlonym oknie dialogowym.
- Kliknij " Utwórz".
- Kliknij na nazwę kolekcji.
- Wybierz menu "Importuj".
- Wybierz przycisk opcji ''JSON - mongo shell / / mongoexport'.
- Kliknij "Dalej".
- Naciśnij przycisk "Dodaj pliki źródłowe".
- Poruszaj się po komputerze za pomocą okna dialogowego.
- Otwórz katalog zawierający 5 000 plików wyodrębniania JSON.
- Zaznacz wszystkie pliki w katalogu.
- Naciśnij "Otwórz". Lista plików JSON powinna pojawić się w oknie dialogowym Importowanie.
- Naciśnij "Dalej"; po lewej stronie pojawi się podgląd nowej kolekcji w bazie danych.
- Naciśnij "Dalej".
- 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ął.
- Powtórz kroki 5 i 6, aby utworzyć kolekcję 10 000 standardowych fragmentów elektronicznej dokumentacji medycznej.
- 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
- Uruchom bazę danych eXist.
- Korzystając z ikony bazy danych, otwórz klienta Java Admin Client.
- Wprowadź hasło administratora.
- Naciśnij przycisk "Połącz".
- Zbuduj kolekcję zawierającą 5 000 standaryzowanych ekstraktów elektronicznej dokumentacji medycznej.
- Na pasku narzędzi wybierz menu "Utwórz nową kolekcję".
- W wyświetlonym oknie dialogowym wpisz nazwę nowej kolekcji.
- Kliknij "akceptuj"; pojawi się nowa kolekcja.
- Wybierz nazwę kolekcji.
- Na pasku narzędzi wybierz menu "Przechowuj pliki w bazie danych".
- Nawiguj po komputerze za pomocą okna dialogowego.
- Wybierz katalog zawierający 5 000 standardowych plików wyodrębniania XML.
- 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.
- Powtórz krok 5, aby utworzyć kolekcję zawierającą 10 000 standaryzowanych ekstraktów EHR.
- 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ść
- Zaprojektuj sześć zapytań zwiększających złożoność zgodnie z archetypami używanymi przez ekstrakty EHR.
- 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.
- 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.
- Jeśli zapytanie wymaga indeksu, który nie jest tworzony automatycznie, skompiluj go ręcznie.
- Połącz się z serwerem MySQL (rysunek uzupełniający 1).
- Wybierz i kliknij nazwę bazy danych po lewej stronie.
- Wybierz i kliknij tabelę relacyjną, w której znajduje się indeksowane pole.
- Kliknij zakładkę "Struktura".
- Wybierz i kliknij kolumnę, w której zostanie zbudowany indeks.
- Kliknij "indeks". Zauważ, że pojawi się zdanie SQL budujące indeks i pojawi się komunikat informujący, że zdanie zostało pomyślnie zbudowane.
- Wykonaj pierwsze zapytanie.
- Wybierz i kliknij nazwę bazy danych po lewej stronie.
- Kliknij zakładkę "SQL".
- Wpisz lub wklej kod SQL pierwszego zapytania (patrz rysunek uzupełniający 2).
- Naciśnij "kontynuuj". Należy zauważyć, że zostanie wyświetlony pierwszy ekran listy wyników wraz z komunikatem z czasem wykonania zapytania.
- Powtórz wykonanie 5 razy i oblicz średni czas odpowiedzi.
- Powtórz krok 5 z zapytaniami od 2 do 6.
- 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ść
- Uruchom graficzny interfejs użytkownika MongoDB (patrz tabela materiałów).
- Uruchom serwer MongoDB 2.6 wykonując program mongod z okna systemu DOS (patrz Rysunek 3).
- Wykonaj krok 2.4, aby połączyć graficzny interfejs użytkownika bazy danych MongoDB z serwerem hosta lokalnego przy użyciu portu 27017.
- Wybierz i rozwiń bazę danych MongoDB po lewej stronie.
- Wybierz kolekcję.
- Kliknij menu "Kolekcja" na pasku narzędzi.
- Wykonaj pierwsze zapytanie bazy danych MongoDB.
- Kliknij dwukrotnie przycisk "Kreator zapytań".
- Kliknij dwukrotnie "Pole zapytania" w Kreatorze zapytań po prawej stronie.
- Wpisz pole zapytania MongoDB w polu tekstowym pola panelu zapytań (patrz rysunek uzupełniający 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. - Kliknij dwukrotnie pole Projekcja w Konstruktorze zapytań
- Wpisz pierwsze rzutowanie w polu tekstowym projekcji (patrz rysunek uzupełniający 5).
- Kliknij dwukrotnie pole projekcji, aby dodać nowe pole tekstowe projekcji.
- 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} - Kliknij niebieski przycisk odtwarzania, aby wykonać zapytanie.
- Wizualizacja kodu zapytania na karcie Kod zapytania.
- Wyświetl szczegóły wyniku w zakładce Wyjaśnienie: liczba wyników, czas wykonania w milisekundach.
- Wyświetl, rozwiń i sprawdź wyniki na karcie Wynik.
- Jeśli wymagane jest dalsze przetwarzanie zapytania, napisz program Java ze sterownikiem Java MongoDB z zapytaniem i metodą do przetwarzania wyników.
- Powtórz wykonanie 5 razy i oblicz średni czas odpowiedzi.
- Wykonaj krok 5.7 dla pozostałych zapytań od 2 do 6 .
- 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
- Uruchom system zarządzania bazami danych eXist.
- Otwórz klienta Java Admin Client.
- Naciśnij przycisk "połącz z bazą danych".
- Wybierz bazę danych i kliknij na nią.
- Kliknij menu "Skonsultuj bazę danych za pomocą XPath"; pojawi się okno dialogowe konsultacji.
- Wykonaj pierwsze zapytanie XPath (patrz rysunek uzupełniający 6).
- Wpisz lub wklej kod XPath pierwszego zapytania w górnej części okna dialogowego.
- Kliknij menu "Wykonaj" na pasku narzędzi okna dialogowego.
- Wyświetl wyniki XML za pomocą zakładki "XML" w dolnej części okna dialogowego.
- Wyświetl liczbę wyników oraz czas kompilacji i wykonania w dolnej części okna dialogowego.
- Powtórz wykonanie 5 razy i oblicz średni czas odpowiedzi.
- Powtórz krok 6 dla zapytań od 2 do 6.
- 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.
- 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).
- W razie potrzeby zidentyfikuj i ręcznie utwórz odpowiednie indeksy atrybutów dla tych zapytań.
- 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.
- Wykonaj i oblicz dystrybucję użycia procesora CPU (jednostki centralnej) dla każdego wątku (zapytania).
- 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ń.
- Wyświetlanie wykonywanych zapytań z priorytetami i czasem wykonywania.
- Obliczanie średniej przepływności i średniego czasu odpowiedzi dla każdego z trzech zapytań.
Wyniki
W Tabeli 1 przedstawiono sześć różnych zapytań wykonanych na realistycznych, zestandaryzowanych ekstraktach z elektronicznej dokumentacji medycznej (EHR), zawierających informacje o problemach pacjentów, w tym ich nazwy, daty początkowe i końcowe oraz stopień nasilenia.
Średnie czasy odpowiedzi sześciu zapytań w trzech bazach danych o podwojonej wielkości w każdym systemie DBMS przedstawiono w Tabelach 2-4. Rysunki 1-6 przedstawiają te same wyniki graficznie (należy zauważyć, że osie pionowe na tych rysunkach mają bardzo różne skale).
Silna liniowa charakterystyka złożoności obliczeniowej jest widoczna we wszystkich zapytaniach baz danych NoSQL, choć należy zachować odpowiednią ostrożność ze względu na stosunkowo niewielki rozmiar użytych 3 zbiorów danych. Z kolei relacyjna baza danych ORM wykazuje niejednoznaczną charakterystykę liniową. Baza danych MongoDB ma znacznie łagodniejszy nachylenie krzywej niż baza danych eXist.
Wyniki uzyskane za pomocą ulepszonych systemów relacyjnych omówionych we wstępie i opublikowane w literaturze znajdują się w Tabeli 5. Interpolacja wyników MongoDB z Tabeli 3 przy zastosowaniu podobnych zapytań i rozmiarów baz danych w odniesieniu do wyników ARM z Tabeli 5 wskazuje na równorzędność obu systemów baz danych w Q1, jednak faworyzuje MongoDB w Q3.
Wyniki eksperymentów dotyczących współbieżności znajdują się w Tabeli 5 i Tabeli6. MongoDB przewyższa MySQL zarówno pod względem przepustowości, jak i czasu odpowiedzi. W rzeczywistości MongoDB wykazuje lepsze zachowanie w warunkach współbieżności niż w izolacji i stanowi imponującą bazę danych w przypadku wykonywania równoległego.
Rycina 1: Złożoność algorytmiczna systemów zarządzania bazami danych ORM MySQL, MongoDB i eXist dla zapytań Q1 i Q4. Rycina ta została zmodyfikowana na podstawie źródła 7 zgodnie z licencją Creative Commons (http://creativecommons.org/ licenses/by/4.0/) i przedstawia czasy odpowiedzi w sekundach dla baz danych zawierających ekstrakty EHR o rozmiarach 5 000, 10 000 i 20 000 dla każdego DBMS oraz zapytań Q1 i Q4. Kliknij tutaj, aby wyświetlić powiększoną wersję tej ryciny.
Rycina 2: Złożoność algorytmiczna ORM MySQL DBMS dla zapytania Q2. Rycina przedstawia czasy odpowiedzi w sekundach dla ekstraktów EHR o rozmiarach 5 000, 10 000 i 20 000 w bazie danych ORM MySQL dla zapytania Q2. Kliknij tutaj, aby wyświetlić większą wersję tej ryciny.
Rycina 3: Złożoność algorytmiczna systemów DBMS MongoDB i eXist dla zapytań Q2 i Q5. Rycina ta została zmodyfikowana na podstawie źródła7 zgodnie z licencją Creative Commons (http://creativecommons.org/licenses/ by/4.0) i przedstawia czasy odpowiedzi w sekundach dla baz danych z ekstraktami EHR o rozmiarach 5 000, 10 000 i 20 000 dla każdego DBMS oraz zapytań Q2 i Q5. Kliknij tutaj, aby wyświetlić powiększoną wersję tej ryciny.
Rysunek 4: Złożoność algorytmiczna systemu ORM MySQL DBMS dla zapytań Q3 i Q5. Przedstawiono czasy odpowiedzi w sekundach dla baz danych ekstraktów EHR o rozmiarach 5 000, 10 000 i 20 000 dla każdego DBMS oraz zapytań Q3 i Q5. Kliknij tutaj, aby wyświetlić powiększoną wersję tego rysunku.
Rycina 5: Złożoność algorytmiczna systemów DBMS eXist i MongoDB dla zapytania Q3. Rycina ta została zmodyfikowana na podstawie źródła7 zgodnie z licencją Creative Commons (http://creativecommons.org/licenses/ by/4.0/ ) i przedstawia czasy odpowiedzi w sekundach dla baz danych zawierających ekstrakty EHR o rozmiarach 5 000, 10 000 i 20 000 dla każdego DBMS i zapytania Q3. Kliknij tutaj, aby wyświetlić powiększoną wersję tej ryciny.
Rycina 6: Złożoność algorytmiczna DBMS ORM MySQL, eXist oraz MongoDB dla zapytania Q6. Rycina ta została zmodyfikowana na podstawie źródła7 przy użyciu licencji Creative Commons (http://creativecommons.org/licenses/ by/4.0/) i przedstawia czasy odpowiedzi w sekundach dla baz danych ekstraktów EHR o rozmiarach 5 000, 10 000 i 20 000 dla każdego DBMS oraz zapytania Q6. Kliknij tutaj, aby wyświetlić powiększoną wersję tej ryciny.
| Zapytanie | |
| P1 | Znajdź wszystkie problemy jednego pacjenta |
| Q2 | Znajdź wszystkie problemy wszystkich pacjentów |
| Q3 | Znajdź datę początkową, datę rozwiązania oraz stopień nasilenia |
| pojedynczego problemu pojedynczego pacjenta | |
| Q4 | Znajdź datę początkową, datę rozwiązania i stopień nasilenia |
| spośród wszystkich problemów problem pojedynczego pacjenta | |
| Q5 | Znajdź datę początkową, datę rozwiązania i stopień nasilenia |
| ze wszystkich problemów, problem wszystkich pacjentów | |
| Q6 | Znajdź wszystkich pacjentów z problemem „pharyngitis” (zapalenie gardła), |
| data początkowa >= '16/10/2007', data rozstrzygnięcia | |
| <= '06/05/2008' oraz nasilenie 'wysokie' |
Tabela 1: Sześć zapytań wykonanych na relacyjnych i NoSQL bazach danych zawierających ustandaryzowane wyciągi z EHR dotyczące problemów pacjentów.Tabela ta została zmodyfikowana na podstawie opracowania7 zgodnie z licencją Creative Commons (http://creativecommons.org/ licenses/by/4.0/) i przedstawia sześć zapytań o rosnącym stopniu złożoności, wykonanych na trzech bazach danych o rosnącej wielkości dla każdego systemu DBMS, sformułowanych w języku naturalnym.
| ORM/MySQL | 5000 dokumentów | 10 000 dokumentów | 20 000 dokumentów |
| 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 |
| Q6 (s) | 1.4382 | 2.4844 | 183.4979 |
| Rozmiar bazy danych | 4,6 GB | 9,4 GB | 19,4 GB |
| Ekstrakty całkowite | 5000 | 10,000 | 20,000 |
Tabela 2: Średni czas odpowiedzi w sekundach dla sześciu zapytań w bazach danych o podwajającej się wielkości w relacyjnym DBMS ORM MySQL. Tabela ta przedstawia sześć czasów odpowiedzi dla każdego zapytania dla trzech baz danych o podwajającej się wielkości przy użyciu relacyjnego DBMS ORM MySQL oraz rozmiar w pamięci dla tych trzech baz danych.
| MongoDB | 5000 dok. | 10 000 dok. | 20 000 dok. | nachylenie (*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 |
| Q6 (s) | 9.5153 | 18.5566 | 36.7805 | 1,817.68 |
| Rozmiar bazy danych | 1.95GB | 3.95GB | 7.95GB | |
| Łączna liczba ekstraktów | 5000 | 10,000 | 20,000 |
Tabela 3: Średnie czasy odpowiedzi w sekundach dla sześciu zapytań w bazach danych o podwajającym się rozmiarze w systemie zarządzania bazami danych NoSQL MongoDB.Tabela ta została zmodyfikowana na podstawie 7 przy użyciu licencji Creative Commons (http://creativecommons.org/ licenses/by/4.0/) i przedstawia sześć czasów odpowiedzi dla każdego zapytania dla trzech baz danych o podwajającym się rozmiarze z wykorzystaniem systemu NoSQL MongoDB oraz rozmiar w pamięci operacyjnej trzech baz danych. Przedstawiono również nachylenie liniowe dla każdego zapytania.
| eXist | 5000 dok. | 10 000 dok. | 20 000 dok. | nachylenie (*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 |
| Q6 (s) | 68.3798 | 138.9987 | 475.2663 | 27 125,82 |
| Rozmiar bazy danych | 1.25GB | 2.54GB | 5.12GB | |
| Całkowita liczba ekstraktów | 5000 | 10 000 | 20 000 |
Tabela 4: Średnie czasy odpowiedzi w sekundach dla sześciu zapytań w bazach danych o podwajanej wielkości w systemie NoSQL DBMS eXist. Tabela ta została zmodyfikowana na podstawie źródła 7 zgodnie z licencją Creative Commons (http://creativecommons.org/ licenses/by/4.0/) i przedstawia sześć czasów odpowiedzi dla każdego zapytania w trzech bazach danych o podwajanej wielkości przy użyciu systemu NoSQL eXist DBMS oraz rozmiar w pamięci trzech baz danych. Przedstawiono również nachylenie liniowe dla każdego zapytania.
| Artykuł ARM | RAM (pamięć operacyjna) | Węzeł+Ścieżka (s) | |
| Q1 | Zapytanie 2.1 | 0.191 | 24.866 |
| Q3 | Zapytanie 3.1 | 0.27 | 294.774 |
| Rozmiar bazy danych | 2,90 GB | 43,87 GB | |
| Ekstrakty całkowite | 29,743 | 29,743 |
Tabela 5: Średnie czasy odpowiedzi w sekundach dla zapytań podobnych do Q1 i Q3 w ulepszonych systemach relacyjnych przedstawionych w10. Tabela ta została zmodyfikowana na podstawie 7 zgodnie z licencją Creative Commons (http://creativecommons.org/ licenses/by/4.0/) i przedstawia dwa najbardziej podobne zapytania do Q1 i Q3 opisanych w 10, odpowiadające dwóm ulepszonym systemom relacyjnych baz danych, wraz z ich czasami odpowiedzi. Przedstawiono również dwa rozmiary baz danych.
| ORM/MySQL | Przepustowość | Czas reakcji |
| Q1 (s) | 4,711.60 | 0.0793 |
| Q3 (s) | 4,711.60 | 0.1558 |
| Q4 (s) | 4,711.60 | 0.9674 |
Tabela 6: Średnia przepustowość i czas odpowiedzi w sekundach dla zapytań Q1, Q3 i Q4 relacyjnego systemu DBMS ORM MySQL w wykonaniu równoległym. Tabela ta została zmodyfikowana na podstawie 7 przy użyciu licencji Creative Commons (http://creativecommons.org/ licenses/by/4.0/) i przedstawia najwyższą średnią przepustowość trzech zapytań dotyczących pojedynczego pacjenta oraz ich średnie czasy odpowiedzi w eksperymencie wykonania równoległego z wykorzystaniem relacyjnego systemu ORM MySQL.
| MongoDB | Przepustowość | Czas reakcji |
| Q1 (s) | 178,672.60 | 0.003 |
| Q3 (s) | 178,672.60 | 0.0026 |
| Q4 (s) | 178,672.60 | 0.0034 |
Tabela 7: Średnia przepustowość oraz czas odpowiedzi w sekundach dla zapytań Q1, Q3 i Q4 systemu MongoDB NoSQL DBMS podczas jednoczesnego wykonywania. Tabela ta została zmodyfikowana na podstawie źródła 7 przy użyciu licencji Creative Commons (http://creativecommons.org/ licenses/by/4.0/) i przedstawia najwyższą średnią przepustowość spośród trzech zapytań dotyczących pojedynczego pacjenta oraz ich średnie czasy odpowiedzi w eksperymencie jednoczesnego wykonywania z wykorzystaniem systemu MongoDB NoSQL.
Rysunek uzupełniający 1: Zrzut ekranu przedstawia okno oprogramowania służącego do połączenia z serwerem MySQL. Kliknij tutaj, aby pobrać ten rysunek.
Rycina uzupełniająca 2: Zrzut ekranu przedstawia interfejs SQL serwera MySQL, w którym zapisano pierwsze zapytanie SQL. Kliknij tutaj, aby pobrać tę rycinę.
Rysunek uzupełniający 3: Lokalny serwer MongoDB 2.6 jest uruchamiany w oknie systemowym DOS poprzez wykonanie polecenia serwera mongod. Kliknij tutaj, aby pobrać ten rysunek.
Rysunek uzupełniający 4: Zrzut ekranu przedstawia zapytanie wpisane w polach tekstowych Query Builder, zgodnie z opisem w krokach od 5.7.1 do 5.7.4. Zrzut ekranu ilustruje krok 5.7.3. Kliknij tutaj, aby pobrać ten rysunek.
Rycina uzupełniająca 5: Zrzut ekranu przedstawia krok 5.7.6. Kliknij tutaj, aby pobrać tę rycinę.
Rysunek uzupełniający 6: Zrzut ekranu przedstawia zapisywanie zapytania XPath w górnej części okna dialogowego.Kliknij tutaj, aby pobrać ten rysunek.
Dyskusja
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.
Oświadczenia
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).
Podziękowania
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].
Materiały
| Nazwa | Firma | Numer katalogowy | Komentarze |
|---|---|---|---|
| MySQL 5.7.20 | Eksperymenty MySQL | ||
| Red Hat Enterprise Linux Server release 7.4 (Maipo), 2.60GHz, RAM 16GB | |||
| MongoDB 2.6 | MongoDB eksperymenty | ||
| Windows 7, 2.66GHz, RAM 12GB | |||
| eXist 3.0RC1 | eXist eksperymentuje | ||
| z Windows 7, 2.66GHz, RAM 12GB | |||
| Graficzny interfejs użytkownika programu Studio 3T 5.5.1 | 3T Software Labs Gmbh | MongoDB |
Bibliografia
- 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).
Przedruki i uprawnienia
