NoSQLを上回る性能のVoltDB、そのアーキテクチャとは

2010年6月1日

データベース研究者の大御所、マイケル・ストーンブレイカー氏が開発し、NoSQLデータベースをも上回る性能を発揮するリレーショナルデータベース「VoltDB」。前回の記事では、その特徴と、NoSQLデータベースのCassandraとのベンチマーク比較を紹介しました。

VoltDB: Fast, Scalable SQL RDBMS with ACID

今回はVoltDBのアーキテクチャについて調べたことをご紹介しようと思います。基本的にはVoltDBのWebサイトやリンク先の内容を基にしています。また、ブログ「独り言v6」のエントリ「VoltDB登場 – RDBMSのようでRDBMSではない新システム」も参考にさせていただきました。

シェアドナッシングな分散インメモリデータベース

VoltDBのアーキテクチャは、FAQのページで以下のように説明されています（英語を訳したものを引用しています。以下同じです）。

VoltDBは、シェアドナッシングなサーバ群から構成されるスケーラブルなクラスタ上の分散されたインメモリデータベースである。トランザクションはANSI標準のSQLを用いたJavaストアドプロシージャで定義され、過去のデータベースにあるようなロック、ラッチ、リソース管理のようなオーバーヘッドを排除しつつトランザクションの一貫性を備えるために並列的なシングルスレッド処理によるデータアクセスを行う。

冗長性を含めた特徴を箇条書きにすると、以下のようになります。

データはメモリ内に保持される。これによってスループットを最大化し、（HDDを使わないため）バッファ制御を不要にする
データとそれを処理するSQLエンジンを、クラスタのCPUコアごとに分散配置する
それぞれのシングルスレッド化したパーティションの操作は独立しているため、ロックやラッチを排除できる
データは可用性のためにクラスタ内で自動的にレプリケートされる。これによりログが不要になる
クラスタにサーバを追加していくごとに、性能はリニアに近い形で向上していく

すべてのSQLはストアドプロシージャとして

アプリケーションの開発者にとってVoltDBがこれまでのデータベースともっとも異なるのは、SQL文がJavaのクラスとなることでしょう。基本的にアドホックなクエリはできず、あらかじめすべてのSQL文をJavaクラスとして定義しておき、データベースの中にストアドプロシージャとしてデプロイしておく必要があるようです。

VoltDBの「Prodcut Overview」のページには以下のような説明があります。

クライアントとサーバ間のやりとりを最小化するため、データアクセスはストアドプロシージャとして提供される。ストアドプロシージャはJavaで書かれ、それぞれのプロシージャは1つのJava Calssとなる。ストアドプロシージャ内では、OLTPにフォーカスしたSQLのサブセット、ジョイン、グループバイ、ソート、集計、一般的な計算、リミットなどが利用可能だ。

そしてストアドプロシージャとデータは、コンパイラによって分散配置されます。

アプリケーションが利用するスキーマとストアドプロシージャの作成には、VoltDB Application Compilerを用いる。コンパイラは性能と可用性を最適化するためにデータのパーティションとレプリカを自動的に作成する。

このアーカイブは1つもしくはそれ以上のVoltDBのクラスタにデプロイ可能だ。

つまり、あらかじめデータと、そのデータを操作するためのストアドプロシージャをクラスタ内のサーバに最適化して分散配置することによって、アドホックなクエリに対する柔軟性を犠牲にする代わりに高度なシェアドナッシングアーキテクチャによる分散処理で高性能を実現する、ということのようです。

データのパーティションは、できるだけそれぞれのシングルパーティション内でトランザクションが完了するようにする一方で、複数のパーティションにまたがるトランザクションを最小化するように行われます。ただし、アプリケーションやハードウェア構成ごとに性能の出方が変わるため、ベンチマークを繰り返して最適なパーティション数を決定すべきだとしています。

しかも、スループットを最大化するために、非同期コールによってクラスタ内の全ノードとクライアントをコネクションすることが推奨されています。

クラスタ間レプリケーションで冗長性

インメモリデータベースでは、サーバが落ちたときにデータをすべて失う可能性があるため耐久性や可用性が気になります。VoltDBでは、クラスタ内サーバ間のレプリケーションと、クラスタ間のレプリケーションをサポートしているようです。引き続き「Product Overview」から。

VoltDBはクラスタ内あるいはクラスタ間レプリケーションによる耐久性を実現している。データはノード故障に対する耐久性を備えるため、クラスタ内の複数のサイトで同時に処理されコミットされる。また（データセンター倒壊のような破滅的な）クラスタ全体の故障に対する耐久性を実現するため、クラスタのあいだでのトランザクションは非同期にコミットされる。

VoltDBはホットスタンバイのスレーブサーバは必要なく、障害を起こしたサーバが復帰する場合もマニュアルでの操作は不要で、稼働中のレプリカ相手のノードもしくはクラスタが自動的にリストアを行う。

また、メモリ内のデータベースはバックアップのためにディスクへ保存、もしくはデータウェアハウスへのロードなどが可能だ。

NoSQLに対抗できる強力なソリューション

こうしてみると、データとあらかじめ決められたSQL文をセットで分散配置することで、並列処理とスケーラビリティを実現することがVoltDBの中心的なコンセプトのようです。それにインメモリデータベースを組み合わせることで、非常に高い性能を実現しているといえます。

これはOracleやSQL Server、DB2といった既存のリレーショナルデータベースで構築された、アドホックなクエリを柔軟に処理するタイプの業務アプリケーションの置き換えにはあまり向いていないかもしれません。しかしNoSQLがいま狙おうとしている、パターン化された検索中心のWebサービスのバックエンドとしては、NoSQLよりも複雑なデータ構造と従来のプログラマが使い慣れたSQLを備えており、しかも性能面でも圧倒していることを考えると、魅力的なソリューションの1つになるのではないかと思えます。

ただしインメモリデータベースですからデータ容量がメモリ容量で決まってしまうので、データ容量は予測可能な範囲でないといけないため、使い所は難しそうですね……。