まずはSQL Serverの中でインメモリを活用する
システム上で広大なメモリ空間が、比較的安価に利用できるようになった。その結果、データベースベンダー各社はそれを利用して大幅な性能向上を図る、新たな製品や機能の提供を加速している。SQL Server 2012のリリースが迫っているマイクロソフトでは、このインメモリという領域をどう捉えているのだろうか。
日本マイクロソフト サーバープラットフォームビジネス本部 クラウド＆アプリケーションプラットフォーム製品部でSQL Server製品を担当しているエグゼクティブプロダクトマネージャの北川 剛氏は「SQL Serverにはインメモリで稼動するカラムストアインデックス機能があります」と語る。専用のインメモリデータベースを用意するのではなく、まずは既存のSQL Serverの中で広大で高速なメモリ空間を活用するというのだ。
SQL Serverのカラムストアインデックスは、基本的にデータウェアハウスやBIのワークロード、つまりは参照系のクエリを対象としたもの。
もともとマイクロソフトが提供してきたBI機能の1つ「PowerPivot VertiPaq」のエンジンをSQL Serverに組み込んで活用している。VertiPaqは、OLAPなど多次元分析を行う際に利用するキューブデータベースと同様なエンジンだ。VertiPaqのキューブを圧縮するロジックを使って、リレーショナルデータベースのカラムデータを圧縮し、そのインデックスをインメモリの上に載せてしまう。このインデックスには、値も一緒に格納されており、それらを利用することで検索処理を極めて高速に行うのだ。
カラムストアインデックスは、SQL Serverのインデックスの1つとして機能する。そのため、利用するのになんら特別な処理は必要としない。
「SQL Serverのコストベース?オプティマイザが自動的に判断し、有効であればカラムストアインデックスを利用します」（北川氏）
これにより、OLAP的な検索が高速に行えるようになるのだが、多次元データベースを別途作るわけではないので特殊なアクセス方法は必要ない。
これは、新たな列指向のインデックスというだけでなく、インデックスがすべてメモリに載ってしまうところがポイントとなる機能だ。インメモリで機能するので、極めて高速な検索ができる。インメモリを活用する機能とはいえ、メモリの管理はSQL Serverが自動で行う。そのため、この機能を使うためにユーザーがメモリ周りの設定などをなんらか意識する必要もない。
集計処理なら50倍から100倍速くなる
SQL Serverのカラムストアナイキ ズーム コービー ンデックスの圧縮は、前出の実績あるVertiPaqのロジックを利用している。
カラムをチャンクと呼ばれる単位に分割し、その単位ごとに圧縮する。圧縮率だけを考えれば、テーブル全体などより大きな単位で圧縮したほうが高圧縮が期待できる。
しかしそうなれば、検索時には圧縮された大きな範囲を対象にすることになる。特定条件に合ったものだけを集計するような場合には、対象が小さいほうがより高速に検索できる可能性が高い。さらに、チャンクの中での最大値や合計値などのデータもあらかじめ計算済みなので、そういったデータが必要な際にも高速な処理が可能となる。
「カラムストアインデックスを利用すれば、集計処理が従来の50倍から100倍くらい速くなる」（北川氏）
カラムストアインデックスは、昨今流行の専用のインメモリデータベースというわけではない。ある意味、SQL Serverの1つの拡張された新機能に過ぎない。なので、インメモリデータベースが欲しいというニーズに対し、これで競合しようという位置づけのものではないだろう。むしろ、現在SQL Server 2000や2005などの旧いバージョンを利用していて、集計するデータ量が多いなどのために十分なパフォーマンスが得られずやむなく日次や週次で集計処理を行っている。そのような場合に、データベースをバージョンアップしカラムストアインデックスを有効にするだけで、よりリアルタイムに近い集計が可能になるということだ。こういった顧客であれば、追加のコストや手間なく、大きな効果が得られることになる。
とはいえ、このカラムストアインデックスを含むSQL Serverが、十分なサイズのメモリを搭載するアプライアンスの形で登場してくれば、それはインメモリデータベースの市場領域とも重なってくる可能性はある。その際には、利用するのにSQL Serverの知識だけでいいというのは、1つの優位性となる可能性がある。当然、3rdパーティー製のBIツールからも透過的に利用可能だ。
「SQL Server 2012でベンチマークであるTPC-Hの結果を出せば、かなりいい値が出ると思います。データウェアハウスアプライアンスの1つであるFastTrackについても、カラムストアインデックスを活用する2012ベースのものが、2012年の夏頃には提供できる予定です」（北川氏）
カラムストアインデックスを活用するためのガイドラインも整備
カラムストアインデックスの活用は、いいことばかりのように聞こえるが、もちろん使用の上での制限事項もある。サポートしないデータ型があり、更新データには対応していない。とはいえ、データの更新については、運用でカバーできる面もあるとのこと。パーティションスイッチの機能を利用し、過去分と当日分をパーティション分割すれば、過去分についてはインデックスを作り替える必要はなくなる。そして、当日分が確定したならば、その分だけインデックスを作成すればいいだろう。
また、1行単位のデータが多数抽出されるような検索の場合には、カラムストアよりこれまでのクラスター化インデックスのほうが効率的な場合もあるだろう。どちらを利用すればいいかは、コストベースオプティマイザが自動で判断するので、ユーザー側で頭を悩ます必要はないとのこと。
もう1つ気になるのが、メモリ上で稼動させるということで、相当なサイズのメモリが必要になるのではということ。これについて北川氏は「圧縮率が高いので、インデックスのサイズは極めてコンパクトです。なので、データウェアハウスなどを目的としたそれなりの構成であれば、メモリに載り切らないということはまずないでしょう」と言う。とはいえ、メモリに載らなければカラムストアインデックスの高性能は享受できない。自分たちのシステムで利用する際に、具体的にどのくらいのメモリが必要になるかはきちんと検証する必要がある。必要以上にメモリを搭載したからより速くなるというものではない。なので、必要最小限のメモリが確保できればいい。そして、必要なメモリ量を計算するための計算式などはマイクロソフトから提供されている。
また、利用してみたものの期待したほどインデックスが圧縮されていない、クエリが速くならない、バッチが並列処理で高速化されないなどの状況になることもある。そういった際にどういうポイントをチェックして、どう改善すればいいかのガイドラインの整備も進んでいる。
別途、OLTPに対応するインメモリデータベースの提供予定もあり
「将来的には、更新にも対応していく予定があります」（北川氏）
これまでSQL Serverは、前を行くOracleに追いつけ追い越せで拡張が行われてきたところがある。しかし、このカラムストアインデックスなどは、そういった方向性とは少し異なり独自の進化の1つだと言う。「やっとSQL Serverの独自性が発揮できるようになってきた」とのこと。
SQL Server 2012の新機能は、おいおいクラウドサービスであるSQL Azureにも搭載されていくという。
「現行の150GBまでというサイズ制限の中ではあまり効果は得られないかもしれませんが、将来的にはかなり有効な機能になると思います」（北川氏）
さらに、OLTPの更新系インメモリデータベースについては、SQL Serverとは別の製品ラインで対応する予定もある。市場に出てくるまでにはまだ時間がかかり、詳細はまだ明らかにできないようだが、こちらにも期待がかかるところだ。
谷川 耕一 [著]