新しいPostgreSQLクラスタ

6. SQLの解析

PostgreSQLでは、各テーブルがレプリケーションを持っていたり、テーブル内の各行が各データベース（Data Node）に分散配置されていたりします。これを考慮してSQLを解析する必要があります。

レプリケーション型のテーブルへの書き込みは、まず、特定のData Node（プライマリ・ノードと呼びます）に送って処理させ、次に、ほかのData Nodeに送るようにします。プライマリ・ノードを、すべてのCoordinatorで同一のものにすることによって、テーブルへの書き出しを矛盾なく行えるようにしています。これは、前回紹介したpgpool-IIと同じ方法です。

分散配置されているテーブルに対しては、それぞれのテーブルの配置方法によって、SQLをきちんと処理し、必要なData Nodeに送り届ける必要があります。SQLの解析でやるべきことは、以下のように、多くあります。

• SQLをどのノードで処理させるか（1つのData Nodeでよいか）
• 合計、カウントなどの集約関数は、どのように処理すればよいか
• ユーザー定義関数は、どのように扱えばよいか
• 異なるData Nodeに格納されている行同士の結合は、どうすればよいか

Postgre-XCでは、元になったPostgreSQLのSQL文を、できる限りそのまま使えるようにするため、上記の解析処理も行っています。SQLの解析の詳細は、別の機会にまた紹介します。

7. 検証と評価

Postgres-XCは、図8に示した構成のクラスタを用いて、性能検証を行いました。最大10台までのデータベース・クラスタを構成できるようにしています。各サーバー・ハードウエアには、CoordinatorとData Nodeを、それぞれ1つインストールしました。

性能検証は、DBT-1に基づいたベンチマークで行いました。DBT-1は、インターネット書店のアプリケーションを模擬した「TPC-W」のベンチマークの、データベース部分の評価をできるようにしたものです。

このベンチマークは、Postgres-XCにとっては厳しい条件でした。理由の1つは、CPUに負荷がかかりやすく、空いたCPUを使ってCoordinatorを動かすことが難しいことです。もう1つは、テーブルの構成上、トランザクション中のSQL文を、別々のデータベースで動かさなければならない場合が多いことです。

こうした悪条件にもかかわらず、図9に示すような性能特性を得ることができました。 5台のサーバで約3倍の読み書きスケールが達成されており、サーバ10台まで性能がスケールしています。

この評価では、ロード・バランサは使いません。「ローダ」上にある複数のDBT-1アプリケーションが、それぞれ別のCoordinatorに接続して処理を行います。読み書きの際に接続先を選ぶことはなく、それぞれ決まった接続先に対して、データベースの読み書きを行うSQL文を送っています。

8. 課題と今後の予定

Postgres-XCは、読み書き双方のトランスペアレント（アクセス透過型）なスケール・アウトが可能な、数少ないデータベース・クラスタです。開発中のものも含め、ソース・コードが公開されています。

2010年5月と7月に、PostgreSQLの会合で、Postgres-XCを紹介する機会がありました（関連URL1、関連URL2）。その時点では、サポートできるSQLは、基本的なものに限られていました。その後は、Coordinatorの拡張に注力しています。サポートするSQLを、元来のPostgreSQLが利用可能なSQLに近づける努力を継続中です。

現在のPostgres-XCのバージョンは、0.9.2です。近々、0.9.3をリリースする予定です。バージョン0.9.3では、大幅に拡張したSQLサポート（DDLも含まれます）、ユーザー定義関数、統合されたインストーラ、コンフィギュレータなどが含まれる予定です。

今後は、さらに高可用性を高める機能の組み込みを行い、完成度を向上させた「バージョン1.0」を提供していく予定です。

Postgres-XCの開発は、オープンです。プロジェクト・ページからメーリング・リストを購読できますし、開発への参加も歓迎しています。すでに国外からも開発協力者がでてきています。多くの人がプロジェクトに参加してくれることを期待しています。

今回の記事では、テーブル生成などのDDL文、集計などを行う集約関数、複数のデータベース上のデータを使ったSQL文の処理などは割愛し、読み書き双方のSQLをトランスペアレントにスケールさせる方法に焦点を当てて解説しました。ほかの部分についても、今後紹介していければと思っています。