Summary
本研究比較リレーショナルと非リレーショナル (NoSQL) は、医療情報システムを標準化します。このようなデータベース管理システム (DBMS) のクエリの応答時間の計算量が 2 倍規模のデータベースを使用して計算されます。これらの結果は、さまざまなシナリオや問題に各データベースのアプローチの妥当性の議論を助けます。
Abstract
この研究を示してリレーショナル クエリの計算量を評価するためにプロトコルと非リレーショナル (NoSQL (だけでなく構造化照会言語)) 標準化電子健康記録 (EHR) 医療情報データベース システム (DBMS)。3 倍規模のデータベース、すなわち5000 を格納するデータベース、10,000 そして 20,000 人の現実的な標準化電子カルテの抽出物、3 つの別のデータベース管理システム (DBMS) でのセットを使用して: リレーショナル MySQL オブジェクト リレーショナル マッピング (ORM)NoSQL MongoDB ドキュメント ベースおよびネイティブ拡張マークアップ言語 (XML) の NoSQL の存在します。
6 複雑さ増加クエリの平均応答時間は、計算された、結果は、NoSQL の場合線形挙動を示した。NoSQL フィールドでは、MongoDB は存在より多くに平坦な線形勾配を表示します。
NoSQL システムは、一貫性と NoSQL データベースに格納されているデータの効率に影響する必要があります医療情報のアップデート ポリシーの特別な性質のための標準化された医療情報システムを維持するためにより適切な場合があります。
このプロトコルの制限の 1 つは、原型リレーショナル マッピング (ARM) 同じデータを持つなど改良されたリレーショナル システムの直接結果の欠如です。しかし、それらに 2 倍サイズのデータベース結果の補間は文献の提示、他の公開されている結果を NoSQL システムは多くの特定のシナリオと解決すべき問題より適切かもしれない示唆しています。たとえば、NoSQL は、臨床実習や版と可視化、または目的のだけではなく状況で使われている EHR 抽出クエリ医療情報もまさにその元の形式で電子カルテを復元するなどのドキュメント ベースのタスクの適切な可能性があります。
Introduction
NoSQL (SQL だけでなく) DBMS は伝統的なリレーショナル DBMS (RDMBS) に代わるものとして最近浮上しています。RDBMS では、何十年もデータベース システムにデータが保存された方法を支配しています。よく研究、理解のリレーショナル代数と微積分は、効率と RDBMS1の一貫性を保証しています。NoSQL システム、リレーショナル システムでは、代わりになっていないが、特定のシナリオでは、いくつかの条件の下で、彼らが有利に動作します。
いくつかのこれらの特定のシナリオや条件が管理および医療情報を保存するために使用する電子健康記録 (EHR) システムのデータベースの永続性を設計するときに発生します。相互運用性と実際には、いくつかの国際基準 ISO/EN 13606、openEHR、HL72,3、4などの持続可能なをするためには、EHR エキスを標準化する,5を使用されています。
ISO/EN 13606 openEHR などいくつかの基準が 2 つの異なるレベルの抽象化は、参照モデル (RM) によって表されると原型と呼ばれる特殊なデータ構造に情報や知識を分離します。この分離はデュアル モデルを呼ばれ、それにより、EHR システム全体の電子カルテ システムをプログラムし直すことがなく、その結果に進化する意味的相互運用性と医療の知識を保守と実践6 で持続可能な.ただし、標準化された電子カルテ システムで実装されているデュアル モデルには、特定の構造に続く情報の組織化、これは、システムのデータベースの永続性レベルが設計された7方法の深遠な影響が必要です。
オブジェクト リレーショナル マッピング (ORM)8はリレーショナル データベース パラダイムを使用した電子カルテ システムを実装する 1 つの方法です。ORM は、余すところなくリレーショナル データベース システムで使用される標準化された EHR エキス XML (拡張マークアップ言語) ファイルの構造をマップします。ORM は、余すところなく標準化された電子カルテの抽出物の XML ファイルの構造に続く多くのリレーショナル テーブルを構築します。多くの外部キーを介して関連するこれらのリレーショナル テーブルとシステムの結果は、非常に効率が悪くなります。
ORM リレーショナル改良がいくつか提案されている.openEHR のノード + パス9は、Blob (バイナリ ラージ オブジェクト) を XML ファイル全体のエキスのシリアル化のサブツリー、リレーショナル テーブルの数を減らします。しかし、この単純化は、複雑な検索ロジックは、複雑なクエリの損傷を発生します。原型リレーショナル マッピング (ARM)10は、原型、原型とリレーショナル テーブルのマッピングに基づいて新しいリレーショナル スキーマの構築によって駆動されるデータベース モデルを生成します。その結果、電子カルテの抽出物の非医療情報の一部が失われます。
多くのドキュメント ベースの NoSQL データベース元 XML や JSON (JavaScript オブジェクト表記) を尊重する全体の Blob としてドキュメント全体を格納形式。これは、リレーショナル テーブルは作成されませんを意味します。これらの NoSQL データベースはスキーマを持たず、結合または11(酸) のプロパティ、すなわち、原子性、整合性、分離、または耐久性をサポートしていません。結果として、彼らがありますない非常に効率的なドキュメントの要素の同じ要素を参照する場合、または間接リンクを利用したその他の文書。これは、一貫性を維持するために参照先のドキュメントの全体がある順番に処理されるために発生します。ただし、非リレーショナル データベースがまだ適切な DBMS によって実行される主なタスク ドキュメント ベースのタスクがある場合あります。これはもっと密接にドキュメント ベースの NoSQL データベースを使用して、真の形式の近似にこれはまた電子カルテ医療ドキュメント (ディスカッション セクション参照) には、特別な永続性ポリシーのため、フォームにデータが残る場合があります。
これらのメソッドの目的は、3 つの異なる Dbms を使用して標準化された電子カルテ システムの永続化層の実装を比較するいくつかの実験を紹介する: 1 つのリレーショナル (MySQL) と 2 つの NoSQL (MongoDB ドキュメント ベースおよびネイティブ XML が存在)。自分の計算がされている計算され、3 つの異なる増加規模のデータベースと六つの異なる複雑さ増加クエリを使用して比較します。3 つのデータベース サーバーをインストールし、クエリが実行された同じコンピューターにローカルで構成されています。技術的な詳細のための材料表を参照してください。
同時実行制御の実験は、リレーショナルの MySQL と NoSQL MongoDB Dbms のパフォーマンスを比較するために行われています。記載されている ORM 改善 (ノード + パスと腕) は、文学10から関連性の高い適切な結果を使用して比較されているも。
データベース管理システムは、加速率で継続的に進化しています。誰には、唯一の既存のパラダイムのリレーショナル モデル頃この指数の開発についてと思うでしょう。例を見て、参照してください、例えば12、酸の性質を保持した応答時間改善されたリレーショナル データベースを実装するモデルを提案します。
Protocol
1. 3 つの二重大きさで分類された標準化された EHR 抽出データベースを格納するリレーショナル MySQL DBMS を構築します。
- インポート、W3C (ワールド ・ ワイド ・ ウェブ ・ コンソーシアム) XML スキーマ、'Java IDE' (統合開発環境) に ISO/EN13606 RM と ISO21090 データ型に対応します。
注: ISO は、国際標準化機構の略です。EN は、欧州統一規格の略です。 - JAXB (Java XML バインディング) IDE にプラグインを実行します。これは、EHR エキス XML ファイルの要素の構造に対応する Java クラスを生成します。
- JPA ラベルで生成される Java クラスを手動でタグ付けします。これらのラベルは、基数と MySQL データベースのリレーショナル テーブルの間の他の関係を参照してください。
- JPA (Java の永続性 API) のライブラリを IDE にインポートし、タグの Java クラスからのMySQLデータベースを作成するメソッドを実行します。
- XML ファイル、5,000、10,000、20,000 の現実的な EHR エキスと 3 つのディレクトリを作成します。
- 5,000 抽出ディレクトリの抽出物すべての MySQL DBMS に XML の抜粋をロードする JPA メソッドを実行します。
- 10,000 抽出ディレクトリと一度と 20,000 抽出ディレクトリ 1.6 のステップを 2 回、繰り返します。
2. 3 つの二重大きさで分類された標準化された EHR 抽出データベースを格納するために NoSQL MongoDB DBMS を構築します。
- プロセスごとの 5,000、10,000、20,000 現実的な EHR エキス XML ファイルを含む json.org.XML などの JSON ファイルを XML ファイルに変換する標準のプログラムと 3 つのディレクトリ。5,000、10,000、20,000 の JSON ファイルを 3 つのディレクトリを生成する必要があります。
- MongoDB の GUI を起動 (グラフィック ユーザー インターフェイス、材料表を参照してください)。
- MongoDB 2.6サーバー DOS (ディスク ・ オペレーティング ・ システム) システム ウィンドウからmongodプログラムを実行するを起動します。
- MongoDB GUI をポート 27017 を使用してローカル ホスト サーバーに接続します。
- 「接続」メニューを選択します。
- 接続の名前を書く (例えば ' 最初')。
- DB サーバー テキスト ボックスに localhost:27017 を記述します。
- 「接続」ボタンを押す現在のデータベースを持つツリーが左側に表示されます。
- エキス 5,000 標準化された電子カルテを含むデータベースを構築します。
- 左側のツリーの上部に接続の名前をクリックします。
- 「ファイル」メニューを選択します。
- 「データベースを追加」を選択します。
- 表示されるダイアログ ボックスにデータベースの名前を入力します。
- [Ok] を。
- 5,000 の標準化された電子カルテを含むコレクションの抽出物を構築します。
- 左側のツリーに、データベースの名前をクリックします。
- メニューの「データベース」を選択します。
- 「AddCollection」を選択します。
- 表示されるダイアログ ボックスにコレクションの名前を入力します。
- 「作成」をクリックしてします。
- コレクションの名前をクリックします。
- 「インポート」メニューを選択します。
- ラジオ ボタンを選択するには 'JSON - mongo シェル//mongoexport」。
- 「次へ」をクリックします。
- 「ソース ファイルの追加」ボタンを押します。
- ダイアログ ボックスを使用してコンピューターに移動します。
- オープン 5,000 JSON を含むディレクトリは、ファイルを抽出します。
- ディレクトリ内のすべてのファイルを選択します。
- 「開く」を押します。インポート ダイアログでは、JSON ファイルの一覧が表示されます。
- 押して"次へ";データベースに新しいコレクションのプレビューは左側に表示されます。
- 「次へ」を押します。
- 「インポートの開始」を押します。インポートの進行状況は、インポートされたファイルと経過時間の数を示す、左にダウン表示されます。
- 手順 5 とエキス 10,000 標準化された EHR のコレクションを構築する 6 を繰り返します。
- 手順 5 と 20,000 の標準化された EHR のコレクションの抽出物を構築する 6 を繰り返します。
3. ビルド、NoSQL ストア 3 ダブル サイズ標準化電子カルテ抽出データベースを DBMS が存在します。
- 存在するデータベースを起動します。
- データベースのアイコンを使用して、管理者クライアントを開きます。
- 管理者パスワードを入力します。
- 「接続」ボタンを押します。
- 5,000 の標準化された電子カルテを含むコレクションの抽出物を構築します。
- ツールバー、メニューの「新しいコレクションを作成する」を選択します。
- 表示されるダイアログで、新しいコレクションの名前を入力します。
- 「受け入れる」をクリックします。新しいコレクションが表示されます。
- コレクションの名前を選択します。
- ツールバーのメニュー「データベース ストア ファイル」を選択します。
- ダイアログ ボックスを使用してコンピューターに移動します。
- 5,000 の標準化された XML 抽出ファイルを含むディレクトリを選択します。
- 「ファイルを保存するディレクトリを選択」ボタンをクリックします。進行状況、格納されているファイルの表示と作成されるデータベースの割合] ダイアログ ボックスが表示されることに注意してください。
- 10,000 の標準化された電子カルテを含むコレクションの抽出物を構築する 5 の手順を繰り返します。
- 20,000 の標準化された電子カルテを含むコレクションの抽出物を構築する 5 の手順を繰り返します。
4 設計および 3 のリレーショナル データベースに 6 複雑さ増加クエリを実行
- EHR の抽出で使用される原型に従って 6 複雑さ増加クエリをデザインします。
- MySQL のデータベースの最初のクエリで SQL スクリプトをプログラムします。SQL は、標準化エキス (アーキタイプ) により、MySQL データベースの特殊な構造に適応しなければなりません。データベース抽出物の全体の構造にマップします。結果として、SQL クエリは複雑です。
- ほとんどのインデックスは、DBMS によって自動的に構築されますが、インデックスはその上に構築された場合、クエリの応答時間をスピードアップし、そのようなインデックスを作成するデータベースの属性を識別します。
- クエリは、非自動的に構築したインデックスを必要とする場合は、手動でビルドします。
- MySQL サーバ (補足図 1) に接続します。
- 選択し、左側のデータベース名をクリックします。
- 選択し、インデックス付きのフィールドが格納されているリレーショナル テーブルの上をクリックします。
- 「構造」のタブをクリックしてします。
- 選択し、列をインデックスの作成場所をクリックします。
- 「インデックス」をクリックしてします。インデックスを構築する SQL 文が表示されます、その文が正常にビルドされたことを示すメッセージが表示されますに注意してください。
- 最初のクエリを実行します。
- 選択し、左側のデータベース名をクリックします。
- "SQL"タブをクリックします。
- 書き込みまたは、最初のクエリの SQL コードを貼り付けます (補足図 2を参照)。
- 「続行」を押します。クエリの実行時間をメッセージと共に結果のリストの最初の画面が表示されることに注意してください。
- 5 回実行を繰り返し、平均応答時間を計算します。
- クエリ 2 6 からで、手順 5 を繰り返します。
- 5,000、10,000、20,000 抽出データベースで 3 回の全体のプロセスを行います。
5. 設計し、3 の NoSQL MongoDB データベースに 6 複雑さ増加クエリを実行
- MongoDB の GUI を起動 (材料の表を参照してください)。
- DOS システム ウィンドウからmongodプログラムを実行 2.6 MongoDB サーバーを起動 (補足の図 3を参照)。
- 2.4 MongoDB GUI をポート 27017 を使用してローカル ホスト サーバーに接続するための手順に従ってください。
- 選択し、左側の MongoDB データベースを展開します。
- コレクションを選択します。
- ツールバーの「コレクション」メニューをクリックします。
- 最初の MongoDB クエリを実行します。
- 「クエリービルダー」ボタンをダブルクリックします。
- 右側にあるクエリ ビルダーの「クエリ フィールド」をダブルクリックします。
- クエリ パネル (補足図 4を参照) のフィールドのテキスト ボックスで MongoDB クエリのフィールドを記述します。
- クエリ パネルの値] テキスト ボックスに、MongoDB クエリの値を書き込みます。
注: このクエリは、{"ns3:EHRExtract.allCompositions.content.items.parts.parts.name.ns2:originalText のような何かをする必要があります.値":"Descripcion"}。フィールド、値を引用し、セミコロンで区切られました。 - クエリ ビルダーの [投影] フィールドをダブルクリックします
- 投影のテキスト ボックスに最初の投影を書く (補足図 5を参照)。
- 新しい投影 textbox を追加する投影フィールドをダブルクリックします。
- 投影テキスト ボックスで 2 番目の投影を記述します。
注: 投影は、クエリから取得された文書の一部を選択します。これらは {"ns3:EHRExtract のような何かをする必要があります.allCompositions.content.items.parts.parts.value.value": 1} と {"ns3: EHRExtract.all Compositions.content.items.parts.parts.value.nullFlavor": 1} - クエリ実行のための青い再生ボタンをクリックします。
- [クエリ] タブでクエリのコードを視覚化します。
- [説明] タブで、結果の詳細を表示: 結果の数、実行時間 (ミリ秒)。
- 表示、展開、および [結果] タブに結果を調べます。
- クエリの処理が必要な場合は、結果を処理すると、クエリとメソッド MongoDB Java ドライバーと Java プログラムを記述します。
- 5 回実行を繰り返し、平均応答時間を計算します。
- 5.7 6 クエリを通じて残りの 2 ステップを実行します。
- MongoDB データベースを抽出、5,000、10,000、20,000 で全体のプロセスを繰り返します。
6. 設計および 3 で実行 NoSQL データベース 6 増加複雑なクエリが存在します。
- 存在するDBMS を起動します。
- Java 管理者クライアントを開きます。
- 「データベースに接続」ボタンを押します。
- データベースを選択し、それをクリックします。
- 「XPath を使用してください。、データベースを参照してください」メニューをクリックして[参照] ダイアログ ボックスが表示されます。
- 最初のXPath クエリの実行 (補足図 6を参照)。
- 書き込みまたは、最初のクエリの XPath コード] ダイアログ ボックスの上部に貼り付けます。
- ダイアログ ボックスのツールバーのメニューの「実行」をクリックします。
- ダイアログ ボックスの下部に「XML」タブを使用して、XML 結果を表示します。
- 結果とコンパイルおよび実行時間] ダイアログ ボックスの下部での数を表示します。
- 5 回実行を繰り返し、平均応答時間を計算します。
- クエリ 2 6 からの手順 6 を繰り返します。
- 全体のプロセスを行うと、5,000、10,000、20,000 抽出データベースが存在するため、3 回。
7. 設計し、MySQL および 5,000 抽出データベースの MongoDB を使用して同時実行制御実験を実行
注: 存在するデータベースは、以前の実験でパフォーマンスが悪いためこの時点で実験から削除されました。
- (数秒) の下で通常 5,000 抽出データベースを使用する前の実験で 3 つの最短時間応答をクエリを選択します。
- 識別し、必要に応じて手動でこれらのクエリの適切な属性インデックスを構築します。
- MySQL 用と MongoDB; の Java マルチ スレッド アプリケーションのプログラミング 2各アプリケーションには、3 つの優先順位が異なるスレッドを手順 1 で選択した各クエリの 1 つがあります。
- 実行し、 CPU (中央処理装置)分布を使用して各スレッド (クエリ) を計算します。
- 各 10 分間に 5 回実行ボタンをクリックしてごとのマルチ スレッド アプリケーションを実行し、最も実行 (最高優先順位) を計算平均スループットと 3 つのクエリの平均時間応答をクエリします。
- 優先順位と実行時間、実行中のクエリを表示します。
- 平均スループットと各 3 つのクエリの平均応答時間を計算します。
Representative Results
名前、最初と最後の日付および重症度を含め、患者の問題についての情報を含む現実的な標準化電子カルテを抽出に対して六つの異なるクエリは、表 1のとおりです。
6 各 DBMS の 3 倍規模のデータベース クエリの平均応答時間は、表 2-4のとおりです。図 1-6は、同じ結果をグラフィカルに表示 (垂直軸がこれらの数字の中で非常に異なる尺度を使用することに注意)。
計算複雑性の強い線形動作は使用される 3 のデータセットの比較的小さいサイズのために適切な注意が、NoSQL データベースのすべてのクエリで顕著です。ただし、リレーショナルの ORM データベースは、不明瞭な線形動作を示します。MongoDB データベースが存在するデータベースよりかなり平坦な傾斜です。
表 5に文献の公開導入で説明した改良型リレーショナル システムによって結果があります。類似のクエリと表 5から腕結果のデータベース サイズ表 3から MongoDB 結果を補間第 1 四半期の両方のデータベース システムに等しいが、Q3 で MongoDB を支持します。
表 5と表6に同時実行制御実験の結果があります。MongoDB は、スループットと応答時間の両方の MySQL を打ちます。実際には、MongoDB より分離では、同時実行制御の動作が改善と同時実行の印象的なデータベースとして立っています。
図 1: アルゴリズムの複雑さ、MongoDB ORM MySQL のクエリ Q1 と Q4 の DBMS が存在して。この図は、クリエイティブ ・ コモンズ ・ ライセンス (http://creativecommons.org/ licenses/by/4.0/) を使用して7から変更されているし、秒数 5,000、10,000 および 20,000 中型 EHR は、各 DBMS およびクエリ Q1 と Q4 のデータベースを抽出応答時間を示します。この図の拡大版を表示するのにはここをクリックしてください。
図 2:クエリ Q2 の ORM MySQL DBMS のアルゴリズムの複雑さ。この図は、10,000 と 20,000 中型 EHR extracts ORM MySQL データベース クエリ Q2 の 5,000、秒単位で応答時間を示しています。この図の拡大版を表示するのにはここをクリックしてください。
図 3:アルゴリズムの複雑さ MongoDB の DBMS は、クエリ Q2、Q5 と。この図は、クリエイティブ ・ コモンズ ・ ライセンスを使用して7から変更されている (によって http://creativecommons.org/licenses//4.0) と、10,000 および 20,000 中型 EHR は、各 DBMS およびクエリ Q2、Q5 のデータベースを抽出 5,000、秒単位での応答時間を示しています。この図の拡大版を表示するのにはここをクリックしてください。
図 4: クエリ Q3 Q5 の ORM MySQL DBMS のアルゴリズムの複雑さ。10,000 および 20,000 中型 EHR は各 DBMS およびクエリ Q3 Q5 のデータベースを抽出 5,000、秒の応答時間を示しています。この図の拡大版を表示するのにはここをクリックしてください。
図 5:存在とクエリ Q3 の MongoDB DBMS のアルゴリズムの複雑さ。この図は、クリエイティブ ・ コモンズ ・ ライセンス (で/4.0/http://creativecommons.org/licenses/) を使用して7から変更されているし、秒数 5,000、10,000 および 20,000 中型 EHR は、各 DBMS およびクエリ Q3 のデータベースを抽出応答時間を示します。この図の拡大版を表示するのにはここをクリックしてください。
図 6:ORM MySQL のアルゴリズムの複雑さがあり MongoDB DBMS クエリ Q6。この図は、クリエイティブ ・ コモンズ ・ ライセンス (で/4.0/http://creativecommons.org/licenses/) を使用して7から変更されているし、秒数 5,000、10,000 および 20,000 中型 EHR は各 DBMS およびクエリ Q6 のデータベースを抽出応答時間を示します。この図の拡大版を表示するのにはここをクリックしてください。
| クエリ | |
| 第 1 四半期 | 1 人の患者のすべての問題を検索します。 |
| 第 2 四半期 | すべての患者のすべての問題を検索します。 |
| 第 3 四半期 | 最初の日、決議日と重症度を検索します。 |
| 1 人の患者の 1 つの問題の | |
| 第 4 四半期 | 最初の日、決議日と重症度を検索します。 |
| 1 人の患者のすべての問題の問題の | |
| Q5 | 最初の日、決議日と重症度を検索します。 |
| すべての患者のすべての問題の問題の | |
| Q6 | 問題「咽頭炎」、すべての患者をを見つける |
| 初版日 > 2007 年 10 月 16 日 ='、決議日 | |
| < = 2008 年 6 月 5 日 ' と '高' の重要度 |
表 1: 6 のクエリがリレーショナルで実行し、NoSQL データベース含む標準化された電子カルテは、患者の問題について抽出します。このテーブル7クリエイティブ ・ コモンズ ・ ライセンス (http://creativecommons.org/ licenses/by/4.0/) を使用してから変更されている、各 DBMS の自然表現の 3 つのサイズ成長データベースに対して実行 6 複雑さ成長クエリを示します言語です。
| ORM/MySQL | 5000 ドキュメント | 10,000 ドキュメント | 20,000 ドキュメント |
| 第 1 四半期 (s) | 25.0474 | 32.6868 | 170.7342 |
| 第 2 四半期 (s) | 0.0158 | 0.0147 | 0.0222 |
| 第 3 四半期 (s) | 3.3849 | 6.4225 | 207.2348 |
| 第 4 四半期 (s) | 33.5457 | 114.6607 | 115.4169 |
| Q5 (s) | 9.6393 | 74.3767 | 29.0993 |
| Q6 (s) | 1.4382 | 2.4844 | 183.4979 |
| データベースのサイズ | 4.6 GB | 9.4 GB | 19.4 GB |
| 総エキス | 5000 | 10,000 | 20,000 |
表 2: 2 倍サイズ ORM MySQL リレーショナル DBMS のデータベースの 6 クエリの秒単位での応答時間の平均です。このテーブルORM MySQL リレーショナル DBMS および 3 つのデータベースのメモリ内サイズを使用して 3 つの倍規模のデータベースのクエリごとに六つの応答時間を示しています。
| MongoDB | 5000 ドキュメント | 10,000 ドキュメント | 20,000 ドキュメント | 斜面 (*10exp(-6)) |
| 第 1 四半期 (s) | 0.046 | 0.057 | 0.1221 | 5.07 |
| 第 2 四半期 (s) | 34.5181 | 68.6945 | 136.2329 | 6,780.99 |
| 第 3 四半期 (s) | 0.048 | 0.058 | 0.1201 | 4.81 |
| 第 4 四半期 (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 |
| データベースのサイズ | 1.95 GB | 3.95 GB | 7.95 GB | |
| 総エキス | 5000 | 10,000 | 20,000 |
テーブル 3: MongoDB NoSQL DBMS の 2 倍規模のデータベースに 6 クエリの秒単位での応答時間の平均です。次の表7は、クリエイティブ ・ コモンズ ・ ライセンス (http://creativecommons.org/ licenses/by/4.0/) を使用してから変更されているし、NoSQL MongoDB DBMS とメモリのサイズを使用して 3 つの倍規模のデータベースの各クエリの六つの応答時間を示しています3 つのデータベース。各クエリの勾配が表示されますも。
| 存在します。 | 5000 ドキュメント | 10,000 ドキュメント | 20,000 ドキュメント | 斜面 (*10exp(-6)) |
| 第 1 四半期 (s) | 0.6608 | 3.7834 | 7.3022 | 442.76 |
| 第 2 四半期 (s) | 60.7761 | 129.3645 | 287.362 | 15,105.73 |
| 第 3 四半期 (s) | 0.6976 | 1.771 | 4.1172 | 227.96 |
| 第 4 四半期 (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 |
| データベースのサイズ | 1.25 GB | 2.54 GB | 5.12 GB | |
| 総エキス | 5000 | 10,000 | 20,000 |
表 4: 存在 NoSQL DBMS の 2 倍規模のデータベースに 6 クエリの秒単位での応答時間の平均です。この表7クリエイティブ ・ コモンズ ・ ライセンス (http://creativecommons.org/ licenses/by/4.0/) を使用してから変更されており、DBMS とのメモリ内サイズ存在することの 3 倍規模のデータベース、NoSQL を使用して各クエリの六つの応答時間を示しています3 つのデータベース。各クエリの勾配が表示されますも。
| 腕紙 | 腕 (s) | ノード + パス (s) | |
| 第 1 四半期 | クエリ 2.1 | 0.191 | 24.866 |
| 第 3 四半期 | クエリ 3.1 | 0.27 | 294.774 |
| データベースのサイズ | 2.90 GB | 43.87 GB | |
| 総エキス | 29,743 | 29,743 |
表 5: Q1 と Q3 で改良されたリレーショナル システムのようにクエリの秒単位での応答時間の平均10. この表7クリエイティブ ・ コモンズ ・ ライセンス (http://creativecommons.org/ licenses/by/4.0/) を使用してから変更されており、第 1 四半期と第 3 四半期10 2 つの改良されたリレーショナル データベース システムに対応する「2 つのほとんど同じようなクエリを示していますその応答時間。2 つのデータベースのサイズも示されます。
| ORM/MySQL | スループット | 応答時間 |
| 第 1 四半期 (s) | 4,711.60 | 0.0793 |
| 第 3 四半期 (s) | 4,711.60 | 0.1558 |
| 第 4 四半期 (s) | 4,711.60 | 0.9674 |
表 6: Q1、Q3 と Q4 の ORM MySQL リレーショナル DBMS で同時実行のクエリの秒のスループットと応答時間の平均です。この表7クリエイティブ ・ コモンズ ・ ライセンス (http://creativecommons.org/ licenses/by/4.0/) を使用してから変更されており、同時に 3 つの単一患者クエリおよびその平均応答時間の最高の平均スループットを示していますORM MySQL リレーショナル システムを用いた実行実験。
| MongoDB | スループット | 応答時間 |
| 第 1 四半期 (s) | 178,672.60 | 0.003 |
| 第 3 四半期 (s) | 178,672.60 | 0.0026 |
| 第 4 四半期 (s) | 178,672.60 | 0.0034 |
表 7: 同時実行クエリ Q1、Q3 と Q4 の MongoDB NoSQL DBMS の秒のスループットと応答時間の平均です。この表7クリエイティブ ・ コモンズ ・ ライセンス (http://creativecommons.org/ licenses/by/4.0/) を使用してから変更されており、同時に 3 つの単一患者クエリおよびその平均応答時間の最高の平均スループットを示していますMongoDB の NoSQL システムを用いた実行実験。
補足図 1: スクリーン ショットは、MySQL サーバーに接続するソフトウェア画面を示しています。この図をダウンロードするここをクリックしてください。
補足図 2: スクリーン ショットは最初の SQL クエリが書かれて MySQL サーバーに SQL インタ フェースを示します。この図をダウンロードするここをクリックしてください。
補足図 3: サーバー mongod を実行して DOS システムのウィンドウを使用して、MongoDB 2.6 localhost サーバーを起動します。この図をダウンロードするここをクリックしてください。
補足図 4: スクリーン ショットは 5.7.4 を通じて 5.7.1 の手順で示すように、クエリ ビルダーのテキスト ボックスに書かれたクエリを示しています。スクリーン ショットは、5.7.3 のステップを示しています。この図をダウンロードするここをクリックしてください。
補足図 5: スクリーン ショットを示しますステップ 5.7.6 。この図をダウンロードするここをクリックしてください。
補足図 6: スクリーン ショットは、ダイアログの上の部分の XPath クエリの書き込みを示しています。この図をダウンロードするここをクリックしてください。
Discussion
このプロトコルを示します、純粋なリレーショナル ORM システムそうにない単一患者クエリ (Q1、Q3、および Q4) の実用的な応答時間が遅く、おそらくのために多くの高価な結合操作を実行するリレーショナル テーブルのために数が多いので、ストレージ ・ システムは、特定の種類のデータベースで使用されます。NoSQL データベースは、リレーショナル システムを使用して、各ドキュメント全体のデータベース全体に広がるテーブル ベースのファッション間ドキュメント ベースの方法でデータを保存します。NoSQL システムは、DBMS の存在よりもかなり速く実行する MongoDB を線形勾配を示します。同時実行制御、MongoDB も動作リレーショナル MySQL ORM7よりはるかに良い。
このプロトコルは、ORM MySQL DBMS に関する7で示された結果のトラブルシューティング プロトコルを提示します。MySQL システムが最新のバージョンにアップデートされて、結果が若干変更されています。さらに、ドキュメント ベースの NoSQL システムの臨界点 MongoDB は EHR エキスが更新されたときは上書きされません、ために医療情報7を保存することが、全体を新しい新しいデータを抽出するときの一貫性を保つことができる彼らのようです。生成され、システムに格納されている元の抽出は維持されます。いくつかの医療専門家は、元のデータに基づいて重要な医療決定をした可能性がありますので、これは、医療情報の厳格な要件です。
改良されたリレーショナル アーム システムは大幅にリレーショナル テーブルの数を減少する、リレーショナル パフォーマンスが向上します。リレーショナル スキーマ修飾するので抽出物が保有する医療情報のクエリを実行可能性があります、しかし、抽出物は正確な原型では復元できません。
二次非常に大規模なデータベース (研究) を使用して、データベース システムがより適切なのですべて患者クエリ (Q2、Q5) は NoSQL システムでより ORM でより良い動作は不明だが、これらのシステムをより簡略化した実行リレーショナル12のシステム。Q6 ・臨床実習の間に特殊なクエリを使用して、これらの実験で得られた結果によって行動を決定できないと考えています。
ただし、メソッドの制限の 1 つは直接実験プロトコルで使用されている正確に同じデータを持つ単一患者、医療クエリに関する NoSQL MongoDB を改良されたリレーショナル アーム システムを比較することの少ないです。プロトコルに最適化された ARM を含む実験を行ったまで単一患者クエリについて表 3 表 5の補間結果を維持しています。将来のアプリケーションこれらの実験にしておきます。プロトコル内で 1 つの重要なステップは、我々 は、正確な状態の-最新鋭の 3 つの技術を比較可能性があるために、無料データベースで、近年の同様のソフトウェア バージョンの選択です。
これは NoSQL システム実際、現実的な標準化された医療情報を使用して、リレーショナルを直接比較する最初の試みの 1 つです。ただし、使用する特定のシステムは、実際のシナリオと問題を解決8によって大いに決まります。
Disclosures
著者が明らかに何もありません。これらの実験で使用されるデータセットはこれらの実験のライセンスの下でいくつかのスペインの病院によって提供され、その結果は公にご利用いただけません。ISO/EN 13606 RM XML スキーマは、医療情報部 Multiprofessional 教育 (チャイム) の大学大学ロンドン中心部によって提供されました。
Acknowledgments
著者は、博士 Dipak Kalra、ISO/EN 13606 標準と ISO/EN 13606 W3C XML スキーマを使用するそのような許可の大学大学ロンドンから彼のチームを定義する EHRCom タスクフォースのリーダーに感謝したいと思います。
この作品は、セルバンテス ・ デ ・によって支えられたサラッド カルロス 3 世 [許可番号 RD16CIII、PI15CIII/00010 PI1500831 PI15/00003 PI15/00321]。
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).
