DEIM Forum 2017 H1-2

NoSQL データソースに対する SQL クエリ処理実行の効率化
加藤 千裕†

中村実†† 株式会社富士通研究所 〒 211–8588 神奈川県川崎市中原区上小田中 4-1-1
E-mail: †{kato-chihiro,nminoru}@jp.fujitsu.com
あらまし

様々なデータソースに大量のデータが格納される昨今，データソースを跨いだ解析は重要な課題となっており，構造化データや半構造化データ，非構造化データに跨る処理をあたかも 1 つのデータソース上の処理に見せるデータ仮想化技術が注目されている．我々はその中でも，機能性に優れ複雑なデータ処理が可能なリレーショナルデータベースシステム（RDBMS）を処理エンジンとした仮想化に着目した．しかし，RDBMS による仮想化のデータソー
スに半構造化データが含まれる場合は，データアクセスにおいて二つの問題が生じる．一つはスキーマが事前に定義できないこと，もう一つは仮想化によるオーバーヘッドである．そこで本研究では，特にシリアライズされたバイナ
リ形式の JSON データについて注目し，これに対する読み込み前にスキーマ定義を必要としない SQL の入力を実現するとともに，実行計画を変更し二段階の型変換を内部的に一段階として処理することによって，仮想化のオーバーヘッドを削減し処理を効率化する方法を提案する．オープンソースの RDBMS である PostgreSQL を処理エンジンとして用い，ドキュメントデータベースの MongoDB に格納されたデータに対し，提案手法を適用し実機による効果検証を行った．
キーワード RDBMS，NoSQL, データ仮想化

1. は じ め に化データを扱うデータベースである．そのため，RDBMS による仮想化のデータソースに半構造化データを扱うデータソース

様々なデータが分析に用いられ格納される昨今においては，が含まれる場合は，データアクセスにおいて二つの問題が生じその利活用に重要な役割を果たすデータベースシステム技術がる．一つは半構造化データのスキーマが事前に定義できないこ重要視され，多様なデータベースが登場，発展してきた．いちと，もう一つは仮想化によるオーバーヘッドである．そこで本早く台頭したリレーショナルデータベースシステム（RDBMS）

研究では，まず RDBMS 上で SQL 入力前にスキーマを定義しは，SQL という言語を用いてデータの処理を記述するもので，ない問い合わせを行うため，データソースからの読み込みを一構造を一意に定める必要があるが複雑な分析処理を得意とする．

度文字列型データに変換して RDBMS に認識させる．そのう

これに対するものとして，キーバリューストアやドキュメントえで仮想化のオーバーヘッドに対し，特にシリアライズされたデータベースと呼ばれるデータベースシステムも近年盛んに開バイナリ形式の JSON データを扱う場合に着目し，最終的に必発されており，複雑な処理に関する速度や機能面では RDBMS要な型への変換処理の削減を提案する．具体的には，RDBMSに劣るものの，柔軟な非構造化データおよび半構造化データをによって生成された実行計画の，文字列を経由する型変換を連許して格納することができるため，注目を集めている．これら

続した処理に書き換えて纏め，文字列型への変換とその解析をのデータベースシステムの中には SQL に近い言語が使える場

内部的にスキップし直接バイナリから目的の型へと変換するこ合もあるが，多くは NoSQL という SQL を用いない記法によとでオーバーヘッドを削減する．

り処理を記述する．

この提案手法の有効性を確かめるため，検証用としてオー

このようなデータベースシステムの多様化に従って，これらプンソースの RDBMS である PostgreSQL をクエリ処理エンの使い分けは大きな課題となりつつある．管理の方法によってジンに用い，BSON 形式 [1] のデータを取り扱う MongoDB をは様々なデータベースシステムの中にデータが散逸してしまい，データソースとし，実際にデータ仮想化を行いクエリを実行し分析が困難になる場合がある．そのため，構造化データや半構て検証する．なお BSON は Binary JSON の略で，シリアラ造化データ，非構造化データに跨る分析をあたかも一つのデーイズされたバイナリ形式の JSON データであり，キーとフィータソース上の処理に見せる，データ仮想化は重要な技術の一つルドの組み合わせに加えて型情報（整数型，浮動小数点型，文と言える．その中でも RDBMS の処理エンジンを利用した仮字列型，論理型など）を保持している MongoDB 独自の型を指想化は，RDBMS の複雑なデータ処理機能などの機能性を十分す．これらの検証用データベースを用い，まず提案手法を適用に生かし細かい分析を行うことができる上，RDBMS のユーザした場合と適用しなかった場合について計測し，提案手法の性にとってはこれまで培ってきたデータベース管理のノウハウを能向上を確認する．そのうえで，MongoDB における直接実行そのまま流用できるという利点があるため，本論文においてはとの比較を行い，データ仮想化の有用性を示す．最後に既存のデータ仮想化の手段として着目した．
しかし RDBMS は，本来はスキーマが静的に決定された構造

MongoDB のデータ仮想化機構と性能を比較し，本提案を適用したデータ仮想化機構の実用性について検証する．

図 1 動的な計画変更を行う JSON データ処理機構

図 3 本提案の JSON データ処理機構

態でのアクセスを実現している [7]．しかし返り値は文字列であり，ユーザが必要に応じて型変換を指定することが求められる．これは，RDBMS のプランナーは実行計画やその中で使われる詳細な型までを実行前に一意に決定しなければならず，実行開始してから動的に変更することが出来ない，という制約の影響である．JSON 内部のスキーマを事前に定めない場合，実図2スキーマを事前に決定しない JSON データ処理機構 (RDBMS)

行前に読み込むデータの型を決定することは難しいため，最初に文字列のような一定の形式でデータを読み込む必要がある．
この方法は図 2 のように表され，入力の JSON がシリアライ

本論文の構成は次のとおりである．まず第 2. 章において関連ズされたバイナリ形式の場合にはバイナリを文字列に変換した研究について紹介する．第 3. 章で提案手法について述べ，第JSON データを更に解析しパース及び型変換する必要があるた

4. 章にて検証環境と検証方法を示し，第 5. 章において実際のめ，バイナリ形式の持つ情報は用いられずオーバーヘッドが大クエリを用いた検証を行い，この結果を考察する．最後に第 6.

きくなる．

章に本論文のまとめと今後の課題を示す．

2. 関 連 研 究

そこで本論文ではシリアライズされたバイナリ形式の JSON
データの読み込みを行う際，動的な実行計画の変更は行わず，見かけ上は文字列に変換して読み込みを行いながらも，ユーザ2. 1 半構造化データのスキーマと型決定の型変換指定があった場合に二段階になってしまう型変換を内

従来の RDBMS では，半構造化データを扱う際には事前に部的に纏める．そしてバイナリの情報を利用してパースし目的スキーマを定義する必要があり，これは以前から様々な研究がの型へと一段階に変換することで，図 3 のように実行方法を書行われてきた [2] [3] [4]．しかし半構造化データは元々一定のスき換えて JSON 解析の処理を省き高速化を図る．

キーマを持たないものであり，形式に反しない限りはどのよう2. 2 データソース仮想化なデータであっても格納・検索できることが求められる．クエ

NoSQL なデータベースは様々なデータに柔軟に対応しうる

リ実行前にスキーマを定義することは，半構造化データの読みが，一方で分析の機能面では RDBMS に劣る点が存在する．ま込み方法として最善であるとは言い難い．本来は問い合わせをた，大量のデータが用いられる現在では，単一のデータベース実行する際に格納するデータを読むことで初めてそのスキーに全てのデータが入っているという状況は少なくなっており，マを決定する方法を用いるのが適切である．このため半構造化

複数のデータソースからデータを読み出し，複雑な分析を行

データを扱う場合にはこの要件を満たす NoSQL データベースう場合がある．そのため，RDBMS から SQL ライクな方法でに格納し処理を行うのが一般的であった．

NoSQL のデータを読み，分析することは重要な課題の一つで近年は，SQL ライクな言語を用いながらもクエリ実行前にスあると言える．

キーマを定義せずにデータを読むことができる処理機構が多くこの課題は過去にも様々な研究がなされている．2013 年には登場している．一つは Norikra [5] と呼ばれるストリーム処理

ドキュメント DB の一つである MongoDB と PostgreSQL をエンジンである．これは最初の入力を読み込んだ時にそのデー接続し，データを読むだけでなく，MongoDB へのプッシュダタを見てスキーマやデータ型を判定し，動的に計画を変更する．

ウンや一時テーブルの作成による最適化を行った論文が発表さそして以降のデータに関しては同じスキーマであると仮定してれている [8]．また，2014 年には，様々なデータソースを繋ぎ，処理を進める．また，Apache Drill [6] は全てのデータに関しクエリを解析し，特に Join のプッシュダウンに力を入れて速てスキーマやデータ型の判定を行い，動的に対応している．こ度の最適化を試みたクエリ実行エンジンが発表されている [9]．

れらの方法は図 1 のように表せる．

オープンソースのプロダクトとして，Teiid というデータ仮想

一方 RDBMS にも事前にデータ内部のスキーマを定めない統合ソフトも存在し，製品化もなされている [10]．

状態での半構造化データへのアクセスをサポートする動きが

しかし，このような既存の研究は RDB 上で JSON 内部のスある．Oracle Database 12c は JSON が一つ入っているテーブ

キーマを決定するかどうかはあまり考慮されていない．そのたルを定義させることで，JSON 内部のスキーマを定義しない状CREATE FOREIGN TABLE t1 { doc json };図 4 JSON 内部の構造を事前決定しないスキーマ定義例

めプッシュダウンを行って NoSQL のデータベースをスキャンする際，読むフィールドの限定は行っているが，その型については特に触れていない．実際にはスキーマを事前に定めずにシリアライズされたバイナリ形式の JSON 型を読む場合は，バ
図 5 従来の実行計画における型変換イナリから目的の型へ直接変換することでバイナリの情報を利用して読み込みデータへの処理を減らすことができ，オーバーヘッドが削減できると考えられる．そこで本論文では型変換を一括化した読み込み方法を提案する．

3. 提 案 手 法
3. 1 半構造化データの内部構造を決定しないスキーマ定義
半構造化データは一定のスキーマを持たず，様々なフィールドを持つ．これに対応するために，まず RDBMS 上で外部のデータに対し，事前に JSON 内部のスキーマを定義せずにデー

図 6 型変換のオーバーヘッド削減のため変更された実行計画

タアクセスを行う必要がある．本提案においては，シリアライ表1 実験環境ズされたバイナリ形式の JSON データを一度文字列型として読み込み，これを RDBMS 側において解析し，欲しいフィールド

サーバ

Primergy RX300 S6の情報を読む，単純な機構を実装した．これにより，ユーザはプロセッサ

Xeon X5675 3.06GHz 6-core x2

事前にスキーマを定めずとも，図 4 のような記法で「JSON 形

メモリ

DDR3 16GB (1066 RDIMM) x12 (192GB)式の文字列データが一つ入ったテーブル」という定義をするこ

ストレージ

HDD 900GB x4 (RAID 0, Partition 1)とで中の情報を自由に読み込むことができる．なお本論文は仮OS

CentOS Linux release 7.2 (64bit)

データベースシステム

PostgreSQL 9.5.4 (buﬀer size 24GB)

想化によるデータ解析を目的にしているため，挿入や更新，削除クエリに関しては考慮していない．

MongoDB 3.2ワークロード

TPC-H SF10

この方法は一度文字列の形に変換しなくてはならないため，
図 2 の例と同様にバイナリから文字列，文字列から JSON 解析による目的のデータ抽出と型変換，という二度の変換の手間以上の流れを図として表したのが図 5 と図 6 である．本来を踏まなくてはならない．そこでこの問題を解消すべく，クエは図 5 のように結合処理の条件式などのために必要になったとリ実行前に JSON 内部のスキーマの定義を必要としないという前提は保持したままに，文字列への変換を無くす方法を次項において提案する．

3. 2 実行計画の変更による内部的な型変換の一括処理
RDBMS における計画は木構造の形で表される場合が多い．
それぞれのノードが読み込みや集約，ソート，表結合などの動作を表す．外部データソースからの読み込みは木構造の末端にあり，3. 1 節の方法を用いた場合，まずこのノードにはバイナ
リを文字列に変換したデータが読み込まれ，その後実行計画の中でユーザの求める型への変換処理が行われる．このユーザ指定の型変換は読み込みノードで必ず行われるわけではなく，文字列型のまま次のノードへ渡されてソートや絞り込みが行われ，結合の条件比較など，型変換が必要になった場面で初めて型変換が実行される．そこで我々は別々のノードにある型変換を一きに初めて行われる文字列から特定の型への変換処理を，全て読み込み時に行われるよう計画を変更し，図 6 に示すように，計画内における二段階の型変換を一か所に集める．そして実際の読み込み時にはこの二段階の型変換について，データソースからの入力型と最終的な出力型のみを参照し，図 3 のように文字列への変換を経ずに型変換を行う．これにより，ユーザが定義したスキーマ上は一度文字列として読み込んだ JSON デー
タを解析し，必要なデータを取り出して指定の型へキャストしているように見えるが，実際には文字列に変換する段階をスキップし，バイナリ形式の情報を利用したパースと一回の型変換によって処理を完了することになる．よって，クエリ実行前に JSON 内部のスキーマの定義を必要としないまま読み込みのオーバーヘッドを削減することができると考えられる．

4. 検証

つに纏めるために，RDBMS によって計画の木構造が作られた
後，それを解析し，外部データソース読み込み処理ノードの中

4. 1 実 験 環 境

で型変換が行われるよう計画を変更した．その上で，二段階のマシンや OS などの設定を表 1 に示す．今回，比較に用い型変換の代わりにバイナリから目的の型への直接の型変換を行たワークロードは TPC-H であり，そのスケールファクターはい，次のノードへと渡す．但し書き換えが難しい一部のノード10 とした．この実際のサイズはおよそ 10GB ほどである．シに関しては今回は非対応としている．

リアライズされたバイナリ形式の JSON データソースとして

MongoDB を用い，クエリ処理エンジンとして PostgreSQL をCREATE FOREIGN TABLE lineitem {用いた．MongoDB はチューニング等は行っておらず，TPC-H

li jsonの表一つ一つをそれぞれ別々のコレクションに挿入する形でデー} SERVER xxx;

タを格納し，主キーにのみインデックスを張った．PostgreSQLには実データは格納していない．PostgreSQL はバッファサイ
ズを 24GB とした．これはスケールファクター 10 のデータを全て載せることができる大きさである．また，PostgreSQL から MongoDB への接続と提案手法の適用は全て Foreign DataWrapper（FDW）として実装した．このため PostgreSQL とMongoDB のソースコードには手を加えておらず，PostgreSQLSELECT(li->>’l_orderkey’)::integer,sum((li->>’l_quantity’)::real) AS sum_qty
WHERE(li->>’l_shipdate’)::date <= date’1998-12-01’
GROUP BY (li->>’l_orderkey’)::integerのエクステンションの形で再コンパイルなしに適用し，使うこ

図 7 JSON 内部を事前定義しない場合のクエリ例とができる．

4. 2 使用した手法
本検証では，以下の方法において実行，計測し，性能比較を行った．
まず一つは 3. 1 節に記載した単純な機構を実装した FDW である．これは BSON 形式のデータを全て文字列として取得し，処理を行う．以下この FDW は SchemaOnReadFDW と記載

CREATE FOREIGN TABLE lineitem {l_orderkey integer,
l_linenumber integer,l_quantity real,...
} SERVER xxx;

する．また，既存手法として，必要なデータのみを取ってくるようにプロジェクションと単純な WHERE 句のフィルタのプッシュダウンを行う手法を SchemaOnReadFDW に適用したものについても計測を行う．以下この FDW は SchemaOn-ReadFDW+PP と記載する．この SchemaOnReadFDW+PPに本提案手法を適用したものを ProposeFDW とし，前述の二SELECT
l_orderkey,sum(l_quantity) AS sum_qty
WHERE l_shipdate <= date’1998-12-01’
GROUP BY l_orderkey
図8つの FDW との比較，検証を行う．
更に Enterprise 社がオープンソースとして公開している

事前にスキーマを定義するクエリ例
表 2 TPC-H のクエリ実行時間

MongoDB Foreign Data Wrapper [11] を用いて PostgreSQL

クエリにおいてクエリを実行する方法（MongoFDW）についての計

1

6,547.6

1,937.7339.5

測も行った．この MongoFDW は MongoDB へのプッシュダウ

34,026.2

1,231.3259.0

ンは単純な WHERE 句にのみ適用されており，必要なフィー

4

5,541.6

757.4

178.9

5

4,682.2

1,129.5235.0

62,554.6

175.1

82.3

に関しては事前に CREATE FOREIGN TABLE の段階でデー

76,934.7

1,487.5

288.1

タ型含め細かく指定する必要があるため，フィールドの増減に89,176.8

1,489.3

1,060.2

応じてテーブル定義からやり直さなければならないが，代わり910,000.9

2,685.6

1,124.0に事前に指定したスキーマの情報を用いて BSON 型からの直10

3,289.4

479.4

126.8

ルドに関わらず条件に合うデータ全てをロードする．スキーマ

SORFDW (s) SORFDW-PP (s) ProposeFDW (s)接変換を行うことができる．
また，比較対象として，MongoDB に直接クエリを投げた場

ReadFDW の三つについて比較を行う．そして ProposeFDW合についても計測を行った．MongoDB から PostgreSQL へのと MongoDB による直接実行と提案手法を比較し，RDBMS にデータ転送がないため，その部分のオーバーヘッドはゼロになよるデータ仮想化が複雑なクエリ処理において直接実行より有るが，代わりに集約と結合を MongoDB の処理エンジンで行う効であるかを確認する．最後に，既存の MongoFDW と性能比ため低速になる可能性がある．

較を行い，考察する．

な お ，PostgreSQL か ら ProposeFDW 及 び SchemaOn-ReadFDW，SchemaOnReadFDW-PP を介して実行するクエ

5. 検証結果・考察

リは，図 7 のように文字列以外の型全てについてユーザが型を5. 1 JSON 内部を事前定義しない読み込みの性能比較指定する形で問い合わせを行っている．一方 MongoFDW を介

表 2 に TPC-H ワークロードのクエリ 1 から 10 に対してしたクエリは，図 8 のように全てのスキーマを最初に定義しPostgreSQL から JSON 内部スキーマを事前定義せずに読みたのち，問い合わせを行う．MongoDB に直接投げるクエリは込みを行う三つの方式を実行したときの実行時間を示す．但しMongoDB の記法に従う．

クエリ 2 は長時間停止しなかったため，未計測とした．なお，

本 実 験 で は ，ま ず 提 案 手 法 の 効 果 を 確 認 す る た め ，ProposeFDW と ，SchemaOnReadFDW+PP，SchemaOn-

スペースの関係上 SchemaOnRead を SOR と記載する．また，

図 9 SchemaOnReadFDW を基準とした ProposeFDW の相対速度

図 11 TPC-H の MongoDB による直接実行結果処理が重い計画であった可能性があり，その結果，PostgreSQL側の処理が大きなオーバーヘッドとして残ってしまったことが考えられる．また，ProposeFDW を介したクエリ 6 の実行中には，MongoDB 側の CPU 使用率が 75%まで上昇していることを観測した．他のクエリは最大で 50%弱であったことから，
クエリ 6 は MongoDB 側のデータ読み込みがオーバーヘッドとなった可能性が考えられる．そのため PostgreSQL 側の処理を提案手法によって軽減しても大きな性能向上が得られなかったと思われる．
これらの結果から，クエリによって差はあるものの，型変換の効率化は実行性能を高めるために有用であると言える．Analyze
図 10 SchemaOnReadFDW+PP を基準とした ProposeFDW の相対速度に対応し実行計画そのものを改善することにより，更に性能向上を見込める可能性があるため，今後の課題としたい．

5. 2 MongoDB における直接実行との比較
図 9 は，表 2 の SchemaOnReadFDW の速度を 1 として三つ図 11 は提案手法を用いた ProposeFDW と MongoDB におけの方式の実行速度を比較したグラフである．横軸はクエリ番号，る直接実行の実行時間の比較である．横軸は TPC-H のクエリ番

縦軸は相対的な速度を表す．

号，縦軸は実行にかかった時間を秒数で表す．なお，MongoDB

何も手を加えていない SchemaOnReadFDW と比較すると，において複雑なクエリの実行は非常に難しく，全ての TPC-H既存手法であるプロジェクションとフィルタのプッシュダウンのクエリを変換することが困難であるため，代表として二つののみを適用した SchemaOnReadFDW+PP も大きく実行速度

クエリについての結果を記載する．クエリ 1 の場合，MongoDBが上がっていることが確認できる．更にこれに加えて型変換と比較すると提案手法の速度は 0.72 倍と，MongoDB の方がの一括化を行った ProposeFDW は最低でも 8.7 倍，幾何平均優位な性能を出している．しかし一方で，クエリ 9 に関して18.7 倍の性能向上が見られた．

は ProposeFDW は 1124 秒で止まったのに対し，MongoDB でまた，表 2 を元に SchemaOnReadFDW+PP の速度を 1 との実行は 3776 秒と，ProposeFDW が 3.6 倍早いという結果して ProposeFDW と比較したのが図 10 である．クエリ 1，3，になった．これは，MongoDB に実装されている表結合方式の4，5，7，10 は 4 倍近くかそれ以上に性能が上がっている．型問題であると考えられる．MongoDB は表結合方式としてネ変換を一括処理したことで，特に文字列を JSON として Post-ステッドループ結合のみをサポートしており，ハッシュ結合やgreSQL が解析して目的の型に変換する処理がなくなったことマージ結合を行うことができない．そのため，これらが最適とによるオーバーヘッドの減少が効いた結果，このように性能が考えられるクエリに関しては著しく性能が低下する．クエリ 1向上したと考えられる．

は表結合を必要としないクエリであったため，MongoDB によ

一方クエリ 6，8，9 は 2 倍弱から 2 倍未満の速度上昇に留まっる直接実行は PostgreSQL にデータを送らなくてよいという利た．クエリ 8，9 に関しては ProposeFDW を介した場合でも，点が発揮され，ProposeFDW よりもよい性能を出すことがでMongoDB からのデータ送信が止まった後に PostgreSQL のみきたと考えられる．しかしクエリ 9 は逆に 6 個の表を結合すが動いている時間が見られ，PostgreSQL 側の処理が追いついるクエリであり，PostgreSQL の EXPLAIN コマンドを用いるていないことが観測された．この原因としては，Analyze を行っと，その全てにおいてハッシュ結合かマージ結合が選択されてていないため，PostgreSQL 側が生成した実行計画そのものがいる．このようなクエリにおいては，ハッシュ結合とマージ結

決方法として既存の RDBMS をクエリ処理エンジンとして用いるデータ仮想化に注目した．そして RDBMS が半構造化データを用いているデータソースからデータを読み込む場合，実行前に JSON 内部のスキーマを定義しないことが好ましいと述べ，シリアライズされたバイナリ形式 JSON をこの方式で読み込む際に生じる二段階の型変換と冗長な解析について，RDBMSによって作成された計画を変更し，内部的に一段階の型変換に纏めて JSON 文字列の解析をスキップし，オーバーヘッドを削減する方法を提案した．オープンソースの RDBMS である

PostgreSQL と，BSON 形式のデータを扱う MongoDB を用いて検証を行った結果，提案手法により大きく性能向上するという結果を得た．また，MongoDB による直接実行と比較した場
図 12 MongoFDW を基準とした ProposeFDW の相対速度合には，結合を多用するような複雑なクエリにおいて提案手法が明らかに優位であるとの結果を得た．既存の MongoFDW と合が選択できずネステッドループ結合を行わなければならないの比較においては，クエリやスキーマの違いから同一の実行計

MongoDB での実行は効率が悪く，性能が大きく低下する原因画を得られず十分な比較とは言えないが，MongoFDW を上回になったと考えられる．この結果により，ProposeFDW によっる性能を発揮するクエリが存在することを確認した．てデータを読み込み PostgreSQL のクエリ処理エンジンで処理

今後は，Analyze への対応，集約関数のプッシュダウンなどすることは，MongoDB に格納された BSON 形式のデータにを行いさらなる性能向上を図るとともに，半構造化データ向け対して複雑な結合処理を行う場合には有用であるということがのベンチマークによる測定，挿入・削除・更新への対応，同一示された．の実行計画による MongoFDW との比較などを行っていく．

5. 3 既存の MongoFDW との比較
図 12 に，事前にスキーマを細かく定める既存の MongoFDWと，本提案手法を採用した ProposeFDW の実行速度の比較を示す．横軸は TPC-H のクエリ番号，縦軸は既存の MongoFDWの実行速度を 1 としたときの ProposeFDW の相対的な実行速度を表す．結果に示されるように，速度はクエリにより大きく違う．クエリ 8 や 9 は 0.2 倍程度の性能しか出ていない一方，クエリ 4 や 5 は既存の MongoFDW を上回る性能を記録している．但し 5. 1 節と同様，クエリ 2 に関しては未計測である．
この原因は MongoFDW と ProposeFDW の計画が違うことに起因すると考えられる．提案手法は RDBMS がクエリを解析し，実行計画を得た後，それを読み計画の変更を行うものである．しかし，そもそも MongoFDW を用いた時と Pro-poseFDW を用いた時は，PostgreSQL のオプティマイザーが出力する実行計画に差異が生じていた．図 7 と図 8 を見比べると明らかであるように，ProposeFDW を用いて実行するク
エリは，MongoFDW を用いて実行するクエリと比較してキャスト演算子などが追加されている上，PostgreSQL から見えるテーブル定義も全く違うものである．これらの差異が原因となって実行計画に差が生じ，その結果，単純に比較が難しい結果になったと考えられる．同一の実行計画による性能比較は今後の課題である．
但し MongoFDW を上回る性能を発揮したクエリがあったことから，提案手法でも十分な性能を得られる可能性があることは示唆されている．

6. お わ り に様々なデータソースにデータが散逸する昨今において，データの仮想化と一括管理は重要な課題である．本論文は，この解文

献[1] BSON – Binary JSON. http://bsonspec.org/.
[2] Alin Deutsch, Mary Fernandez, and Dan Suciu. Storing
semistructured data with STORED. In ACM SIGMOD
Record, Vol. 28, pp. 431–442. ACM, 1999.
[3] Daniela Florescu and Donald Kossmann. A performance
evaluation of alternative mapping schemes for storing XML
data in a relational database. PhD thesis, INRIA, 1999.
[4] Philip Bohannon, Juliana Freire, Prasan Roy, and Jérôme
Siméon. From XML schema to relations: A cost-based
approach to XML storage. In Data Engineering, 2002.
Proceedings. 18th International Conference on, pp. 64–75.
IEEE, 2002.
[5] Norikra: Stream processing with SQL for everybody.
http://norikra.github.io/index.html.
[6] Michael Hausenblas and Jacques Nadeau. Apache drill: interactive ad-hoc analysis at scale. Big Data, Vol. 1, No. 2,pp. 100–104, 2013.
[7] Zhen Hua Liu, Beda Hammerschmidt, and Doug McMahon. Json data management: supporting schema-less development in RDBMS. In Proceedings of the 2014 ACM SIGMOD international conference on Management of data, pp.
1247–1258. ACM, 2014.
[8] John Roijackers and George HL Fletcher. On bridging relational and document-centric data stores. In British National
Conference on Databases, pp. 135–148. Springer, 2013.
[9] Ramon Lawrence. Integration and virtualization of relational SQL and NoSQL systems including MySQL and MongoDB. In Computational Science and Computational Intelligence (CSCI), 2014 International Conference on, Vol. 1,
pp. 285–290. IEEE, 2014.
[10] Teiid Homepage . Teiid. http://teiid.jboss.org/.
[11] PostgreSQL foreign data wrapper for MongoDB. https://github.com/EnterpriseDB/mongo fdw.