シェアードナッシング、もう遅いとは言わせない／DWH業界のチャレンジャー、EMCにGreenplumの話を訊いた

そもそも「DWHが速い」とはどういうことなのか

さて、ここでいまいちど、DWHの「速さ」についておさらいしておきたい。

データベースのシステムで「速さ」をもっとも気にするのは、DWHのシステムだろう。この速さの追求は、15年ほど前に日本でDWHという言葉を使い始めたころから変わりのない究極の目的とも言える。そして、このデータウェアハウスの速さに大きく影響するのが、大量データというものの存在だ。つまり、莫大なデータをいかに高速に処理するのかが、15年以上にわたりデータウェアハウスが追い求めていることでもある。

ところで、DWHの速さと言っても、じつはその中身は1つではない。

• レポーティングなどのための定型的な検索処理の速さ
• 大量のデータをデータウェアハウスにロードする速さ
• 複雑な分析処理などのレスポンスの速さ

といったように、速さにも種類がある。さらには、これら要素すべてを網羅する「DWHのトータルでの速さ」というものもあるだろう。レポーティングなどの定型的な検索処理の速さは、インデックス機能やデータベース設計などが大きく影響を及ぼす部分であろう。このあたりを速くするための技術は、かなり古くからノウハウが蓄積されている分野でもある。

大量のデータをローディングする速さは、ハードウェア性能、さらにはDWHシステムそのもののアーキテクチャなどにも影響されやすいところだ。そして、大量データに対する複雑な分析処理は、ストレージの性能などにも大きく影響を受ける。

じつは、これら種類の異なる「速さ」は、すべてを同時に満足させるのはなかなか難しいものがある。

たとえば、定型的な検索処理を高速化しようとすると、データ更新時にはインデックス作成などに多大な時間がかかってしまい、管理手間も増大することになる。また、データロード時間を大幅に短縮するには、更新分だけをロードするようにしたいところだが、そうなると検索処理を高速化するために採用することが多いシェアードナッシング型アーキテクチャでは、あまり効率的なデータ配置ができない可能性もある。こちらを立てればあちらが立たず、それをいかにして克服するかが各ベンダーの工夫のしどころだったりもするわけだ。

従来のシェアードナッシング型ではデータロードに時間がかかってしまう