Shoeisha Technology Media

EnterpriseZine(エンタープライズジン)

EnterpriseZine(エンタープライズジン)

テーマ別に探す

オランダ国立情報数学研究所のデータベースを100倍速くするプロジェクトから生まれたVectorwiseの全貌

edited by DB Online   2012/12/06 00:00

アムステルダムにあるオランダ国立情報数学研究所、ここで「X100」というプロジェクトが行われていた。このプロジェクトの目的は、「100倍高速なデータベースを作る」こと。100倍という数値目標を設定したきっかけは「C言語で書かれたプログラムとリレーショナルデータベースの処理では、100倍くらいの差がある」ということからだった。その後、このX100プロジェクトの成果は、Actian社に引き継がれ商用化することになる。このActian、元はデータベースとしては歴史も実績もある「Ingres」を提供していたIngres Corporationだ。そして、X100プロジェクトの成果である「100倍速いデータベース」として生まれたのが、データウェアハウスなどの分析処理向けの高速データベース「Vectorwise」だ。

Vectorwiseはカラム型で分析やBIに特化したデータベース

Mark Van de Wiel氏
Mark Van de Wiel氏

 「Vectorwiseには100倍速くするためのさまざまなトリックがあります」と語るのは、ActianでVectorwiseの製品担当をしているMark Van de Wiel氏。彼は、一般的なリレーショナルデータベースが遅いのは、ストレージの処理が非効率的だからだと指摘する。

 「通常のデータベースは、ストレージの中の構造が行ベースになっています。これはOLTPトランザクションであれば効率はいいのですが、分析などの用途には向いていません。そこでVectorwiseでは、ストレージの中の構造を分析用途に最適化した、カラム型にしています」

 Vectorwiseでは、ディスク上のデータブロックのサイズも大きく、性能が最大化するよう調整されている。すべてのデータブロックはカラムごとに生成され、ブロック内にミニマム、マックス値を持っており、それを使って高速な参照処理ができる。さらに、高速なメモリバッファを、ディスクの手前に割り付けることでも高速化を図っている。このメモリバッファは、CPUの処理を効率化するためにディスクとは非同期でデータを読み込めるようになっている。また、データの圧縮も活用されている。ディスク上だけでなくメモリ上でも圧縮することで、CPUが処理するデータサイズも小さくなるように工夫されているのだ。

 Vectorwiseでは、内部的にストレージインデックスと呼ばれるものを持っており、いわゆるデータベースのインデックスは必要ないとのこと。このストレージインデックスについては、データベース側でなんらその存在を意識する必要はない。

 「ですから、たとえばSQLの書き方が悪くて遅いといった場合に、SQLを調整するようなことはありますが、Vectorwiseでは特別なチューニングは必要ありません」

独自のベクトル処理でCPU性能も最大限に引き出す

 また、Vectorwiseは、より高速化するためにCPUでの処理効率の向上も図っている。旧いデータベースではデータ処理が複雑なコードとなっており、CPUの使用率は高くなるが、それが現在のCPUに対して親和性が高い処理となってはいない。これは、旧いデータベースの多くが、かつてのメモリも少なくCPUの処理能力が高くなかった時代に効率的な処理ができるよう工夫されていたためだ。つまり、マルチコア化し複数の処理を同時並行に行えるようになった現在のCPUに、必ずしも最適化されていないと言うこと。

 Vectorwiseでは、現状のCPU性能を最大限に引き出すため、独自のベクトルベース処理を採用している。CPU内部でデータをベクトル処理することにより、システムのスループットを最大化しているのだ。これはたとえば、1つの命令で1つの処理をするのではなく、1024の処理を同時に行うことができるというもの。さらに、CPUのキャッシュを有効活用するようにも設計されているので、データ処理効率がさらに向上している。カラム型とこのCPUでの効率的な処理で「データウェアハウスや分析、BIに特化した領域において、従来の100倍の処理を実現しています」とWiel氏は言う。

 このようにまったく新しいデータベースではあるが、チューニングが不要など扱いが簡単なのもVectorwiseの特長だ。そして、VectorwiseのSQL処理部分は、実績のあるデータベースであるIngresを取り込んでいるのも、大きな特長の1つだ。これは、MySQLがストレージエンジンを取り替えて利用できるのと同様で、アプリケーションからは、世の中で多数の実績があるIngresと同じように扱えることになる。

 また、ハードウェア的にも特別なものは必要としない。パフォーマンスを出すためには「コアあたり8GBのメモリ搭載を推奨しています。CPUはよりパワフルであるに越したことはありません」とのこと。ストレージについては、当然ながらIO幅が太いほうがいい。そして、推奨は複数ディスク構成のRAIDで、もちろんSSDを採用すれば高速化に寄与する。とはいえ、少ないメモリでSSDを採用するよりは、より多くのメモリでストレージという組み合わせのほうが性能は出しやすいとのことだ。

※この続きは、会員の方のみお読みいただけます(登録無料)。


※この続きは、会員の方のみお読みいただけます(登録無料)。


著者プロフィール

  • 谷川 耕一(タニカワ コウイチ)

    EnterpriseZine/DB Online チーフキュレーター かつてAI、エキスパートシステムが流行っていたころに、開発エンジニアとしてIT業界に。その後UNIXの専門雑誌の編集者を経て、外資系ソフトウェアベンダーの製品マーケティング、広告、広報などの業務を経験。現在はフリーランスのITジ...

バックナンバー

連載:DB Press

もっと読む

All contents copyright © 2007-2019 Shoeisha Co., Ltd. All rights reserved. ver.1.5