大規模化するDWHのチューニング

4.データ圧縮によるI/O削減

データ圧縮も、ディスクを効率的に活用してパフォーマンスを向上させるために欠かせない機能です。多くの製品が提供している定番の機能と言えます。ここでは、パフォーマンスの観点で解説します。

DWHは、データの量が多くて範囲も広いため、キャッシュの効果が得られにくく、ディスクI/Oがボトルネックになる傾向があります。最新のマルチコアCPUを使ったとしても、I/O待ち状態になってしまっては、CPU能力を有効に活用できません。

このような場合は、データ圧縮機能を使って物理的にデータ・サイズを減らす手法が有効です。一般的には、データ圧縮によって3～4倍の圧縮率を得られることが多いようです。

また、読み込む物理的なデータ量が少なくなるので、使用するメモリーも少なく済みます。データを圧縮/伸長するためにCPU負荷がかかりますが、ボトルネックであるI/O負荷を削減してCPU負荷へと処理をオフロードできるため、結果的にパフォーマンスが向上します。

圧縮機能にも、注意すべきポイントがあります。それは、CPU負荷が高い状態で使うと逆効果になる点です。DWHでは分析関数などのような複雑なSQLが用いられることが多いので、場合によってはCPU負荷が非常に高くなります。余談ですが、最近では、CPU負荷を参考にしながら圧縮レベルなどのパラメータを任意の値に変えられるなど、柔軟な設定が可能な製品もあるようです。

5.分散キーの活用

ここまで、走査するデータ量を削減するためのチューニング方法について解説してきました。以下では、シェアード・ナッシング型のDWHにおける分散キーの活用例を紹介します。シェアード・ナッシング型アーキテクチャについては、第2回を参照してください。

分散キーを検討する際に最も重要なポイントは、各ノードに格納されるデータの量が均等になるような値を選択することです。まずはこの条件を満たすことを大前提に、さらなるチューニング方法を検討します。

シェアード・ナッシング型で最も効率的な状態は、他ノードに処理を依頼することなく自ノードで処理が完結することです。

例えば、表を結合する際に結合キーと分散キーが異なる場合、自ノードが持っている結合キーの値が他ノードでマッチする可能性があります。このため、それらのデータを他ノードに転送する必要が生じます。

しかし、結合キーと分散キーが同じであれば、マッチするキーは自ノードにしかないことがあらかじめ分かります。このため、他ノードへのデータ転送が発生せずに、非常に効率の良い処理になります。

実際には、テーブルの数は数百から数千に及ぶため、すべての結合においてデータ転送が発生しないように分散キーを選ぶことは不可能です。しかし、データ量が多い表での結合に絞れば、効率のよい分散キーを選ぶことは可能です。

このように、データ量を均等に配置するだけではなく、なるべくデータ転送量を少なくするという観点も含めて分散キーの設定をしてみることが重要です。

以上、今回は大規模DWHにおけるチューニングのいくつかを解説しました。実際には筆者も試行錯誤の毎日であり、最適解は1つではないと考えています。

最終回となる次回は、DWHのクラウド化サービスと、その事例を紹介します。