DWH系処理に汎用DBMSを利用する課題 Vol.3

今回ご紹介する検証結果は、スモール・スタートが可能な「InfiniDB」の特性を活かし、サーバ1台による最もシンプルなシングル構成（図１）で実施しています。また、検証で使用したデータとSQLは、第1回でも取り上げた「Star Schema Benchmark」（以下、SSB）を利用しており、SSBのファクト表は論理データ・サイズを100GBとしています。

DWHシステムで重要視される検索性能からご紹介します。

図2は、SSBで提供されている12個のSELECT文（Q1～Q12）^※における実行時間を表したものです。SELECT文ごとに検索対象の列やデータのアクセス範囲が異なっていますが、InfiniDBは、垂直（列指向）＆水平（エクステントマップ）パーティションによる効率的なデータ・アクセスで、非常に高速に処理できていることがわかります。

※Q1～Q12の詳細およびStar Schema Benchmarkの解説についてはこちら をご参照ください。

・「汎用DBMS製品A」（DWH用チューニング機能なし）
パラメータ・チューニングや索引によるチューニングは実施していますが、全体的に検索性能が低いことがわかります。また、索引による効果が一定しないため、クエリによって実行時間にバラツキがあります。

・「汎用DBMS製品B」（DWH用チューニング機能あり）
パラメータ・チューニングや索引によるチューニングの他、パーティションやパラレルSQLといったDWH用のチューニングも実施してテストしています。汎用DBMSでも、DWH用チューニング機能を使いこなせば、クエリの速度を短縮できていることがわかります。

・「InfiniDB」
「InfiniDB」はデータをロードするだけで高い検索性能を発揮します。本テストも、データをロードしただけの状態でSQLを実行しています。検索条件が異なる複数パターンの処理でも、検索性能は安定しています。

・「InfiniDB」（オンキャッシュ）
キャッシュにデータが読み込まれた状態での検索性能です。「InfiniDB」は、オンキャッシュやディスクI/Oに関係なく、汎用DBMSと比べて安定した性能を発揮していることがわかります。

図3は、図2のクエリ（Q1）をもとに、「InfiniDB」と「汎用DBMS製品A」で物理読み込みされるデータ・サイズを比較したグラフです。図2の実行時間では、「InfiniDB」の方が10倍程度の高い検索性能を示していました。このクエリ（Q1）では、「汎用DBMS製品A」が80GB程度のデータを読み込まなければならないのに対して、「InfiniDB」はその1/4の20GB程度しか読み込んでいないことがわかります。効率的なデータ・アクセスによるものも大きいですが、列指向はデータ圧縮が効果的に行われるため、そもそもデータ量が少なくなっていることの結果でもあります。

図4は、図2のクエリ（Q1）を実行した時のCPU使用率を表しています。「InfiniDB」では、データ・アクセスにおいてPM（Performance Module）にてマルチスレッド処理が行われます。前回記事の「図11．InfiniDBのアーキテクチャとUM／PMの役割」のように、UM（User Module)でSQLが解析され、エクステントマップによる絞り込みが行われ、PMのI/Oスレッドに対してブロック処理の指示がされるため、PMのマルチスレッド処理は均等に実施されます。そのため、すべてのCPUコアが均等に高い割合を示し、CPUリソースが無駄なく利用できていることがわかります（この例では12コアを使用しており、1つの線が1つのコアの使用率を示します）。左のグラフはオンキャッシュ処理、右のグラフは物理ブロック読み込みが入ったものです。右のグラフのCPU使用率が低いのは、I/O waitの分だけ割合（%）が下がっているためです。

図5は、サーバのCPUコア数を増加して、各クエリ（Q1～Q3）における実行時間を比較したグラフです。例えば、Q1の紺色と黄色の実行時間を比較すると、CPUコア数を倍増（4コア→8コア）することで、実行時間が半分程度（12.3秒→6.38秒）になっていることがわかります。このように、CPUコア数を増やせば増やすほど、検索性能はリニアに向上します。

1つのサーバでのスケールアップに限界がきた場合、「InfiniDB」では、サーバ追加によるスケールアウトも可能です。図6は、PMのスケールアウト効果（1台→2台）を測定した複数台構成による検証環境です。

図7は、PMのノード数を１台から2台に変更して、その実行時間を比較しています。左のグラフでは、PMのノード数を増やすことで実行時間は半分に、つまり検索性能は2倍に向上しています（2台になることで、コア数は倍になっています）。また、右のグラフでは、2ノード処理のPMノードごとのCPU使用率を表しています。各ノードのCPUは均等に高い使用率を示しており、スケールアウトでも検索性能がリニアに向上することがわかります。この特長も、UMノードからエクステントマップを解析した後のブロック処理をそれぞれのPMノードに命令することで、PMノード間の協調処理が存在しないアーキテクチャをとっていることで実現しています。

最後に、データ・ロード性能の検証結果をご紹介します。

図8は、「InfiniDB」の専用ロード・ユーティリティ（cpimport）を使用したデータ・ロード時間を表しています。もちろんハードウェア性能にもよりますが、この環境では76GBのCSVファイルのデータ・ロードが1500秒程度で、およそ180GB/時間ロードできています。「汎用DBMS製品B」の専用ロード機能と比較すると、2倍以上のロード性能であることがわかります。

図9は、①のデータ・ロード後のオブジェクト・サイズです。「InfiniDB」は、ロード・データ（CSV）の1/3程度まで圧縮されていることがわかります。これはデータ内容によって変わりますが、列指向によるデータ圧縮効果の高さを、ご理解いただける結果ではないでしょうか。

Indyコラム

• 「育ち盛りのインディ」

紹介した検証環境では共有ディスクを使用した例だったんだけど、9月に日本国内でリリースしたInfiniDBバージョン3では、PMが複数ノードあればシェアード・ナッシング構成が採れるんだ（図10）。

データを分散配置できるから、検索処理もさらにスピードアップさ。それから速くなったのは検索だけじゃないよ。

図11はデータ・ロードのイメージなんだけど、複数のPMノードでパラレル・ロードできるようになったから、データ・ロード処理もさらにスピードアップさ。これまで以上にスケールアウト効果が発揮できるから、将来の性能問題も安心だね。

図10：バージョン3の検索性能

図11：バージョン3のデータ・ロード性能

DWH構築のアプローチとして、「Think Big, Start Small」（大きく構想し、小さく始める）という黄金律があります。DWHは使いながら育てていくシステムであり、最初から大きく始めるのではなく、効果を測定しながら増強していくという考え方です。「InfiniDB」は、この思想に合致する製品だと我々は考えています。例えば、拡張性についてはスケールアップとスケールアウトの2軸をサポートすることで、活用範囲の拡大に合わせて既存の仕組みや資産を無駄にすることなく、適宜追加投資が行えます。しかも、汎用的なPCサーバ上で稼働すること、様々な構成が取れること、かつ、シングル構成でも高い検索性能を引き出せるため、投資対効果の高い製品だと言えます。まさに、「Think Big, Start Small」を体現する製品だということが、ご理解いただけたのではないでしょうか。

本連載では、汎用DBMSをDWH系処理で利用する課題を検討し、DWH系処理に適した列指向DBMS「InfiniDB」をご紹介してきました。「InfiniDB」は3つの特長「Fast／Simple／Scalable」で、データ増加に伴うパフォーマンス不安を解消します。今後も進化し続ける「InfiniDB」に是非ご期待ください！!