TOP>企業情報>コラム>技術情報>DWH系処理に汎用DBMSを利用する課題 Vol.3

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

前回はDWH系処理に適した列指向DBMSの優位性について、「InfiniDB」の紹介をとおして解説しました。第3回目となる今回は、「InfiniDB」の実力を裏付ける検証結果を一挙公開します。

(全3回連載)

Vol.3 InfiniDBの実力や如何に?検証結果を一挙公開!

検証環境


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

図1:基本的な検証環境

図1:基本的な検証環境

検索性能


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

①汎用DBMS製品との性能比較


図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と比べて安定した性能を発揮していることがわかります。

図2:汎用DBMS製品との性能比較

図2:汎用DBMS製品との性能比較

②物理読み込みデータ・サイズの比較


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

図3:物理読み込みデータ・サイズ

図3:物理読み込みデータ・サイズ

CPUリソースの利用傾向


図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の分だけ割合(%)が下がっているためです。

図4:「InfiniDB」のCPU使用率

図4:「InfiniDB」のCPU使用率

スケールアップ効果


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

図5:CPUスケールアップ効果

図5:CPUスケールアップ効果

スケールアウト効果


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

図6:スケールアウト効果の検証環境

図6:スケールアウト効果の検証環境

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

図7:複数PMノードによるスケールアウト効果

図7:複数PMノードによるスケールアウト効果

データ・ロードとデータベースのサイズ


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

①データ・ロード時間


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

図8:データ・ロード時間

図8:データ・ロード時間

②データ・ロード後のオブジェクト・サイズ


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

図9:データ・ロード後のオブジェクト・サイズ

図9:データ・ロード後のオブジェクト・サイズ

Indyコラム

Indy

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

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

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

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

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

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

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


Think Big, Start Small


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

図12:Think Big, Start Small

図12:Think Big, Start Small

最後に


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


執筆者紹介

岸和田 隆

岸和田 隆(Takashi Kishiwada)

株式会社アシスト データベース技術本部

アシスト入社後、Oracle Database の研修講師、フィールド・ サポート、新バージョンの検証を経て、2007年 自社ブランド 「DODAI」の準アプライアンス製品の企画・開発、2009年 PostgreSQL、2011年 EDB Postgres、MySQL / MariaDB の事業立上を担当。 現在は「データベースのアシスト」を目指した活動を行っている。

岸和田の紹介記事はこちら



関 俊洋

関 俊洋(Toshihiro Seki)

株式会社アシスト データベース技術本部

2006年、株式会社アシスト入社。データベース・システムの構築や運用トラブルの解決といったフィールド・サポート業務を経験し、その後は新製品の検証やハードウェアとデータベースを組み合わせたソリューション(DODAI)の立ち上げに従事。現在はデータベースの価値や魅力を伝えるための執筆・講演活動を行っている。『SQL逆引き大全363の極意』共著。

関の紹介記事はこちら

連載記事一覧


Facebookで情報をお届けしています

Facebookでは、アシストの「今」を週3回のペースでお届けしています。「めげない、逃げない、あまり儲けない」を合言葉に日々頑張っておりますので、応援よろしくお願いします。



ページの先頭へ戻る