先月のCHAR（10）会議に参加したかどうかに関係なく、会議のスライドをダウンロードすることで、体験の一部を追体験できるようになりました。それらのいくつかは会議中にライブで投稿され、いくつかは後で現れましたが、ほとんどすべてが現在そこにあります。残念ながら、WooMe（Zooskが買収）がLondisteとDjangoを使用してどのようにスケールアップされたかについてのニック・フェリアーの面白いプレゼンテーションは、簡単に再生できる形式では利用できませんでした。そのためには、確かに1つ以上の方法でそこにいなければなりませんでした。
私が最も有益だと思った2つの講演は、pgpool-IIとpgmemcacheの状態に関する最新情報でした。これらのツールはどちらも、非常に便利で、複雑さ（少なくとも英語では！）に比べて少し文書化されていないという少し苛立たしい組み合わせを持っているため、実際にコードで作業しているツールからツールへの追加の洞察を得ることができました。
MarkusのMVCCとクラスタリングに関する議論も、それに楽しいひねりを加えました。彼の講演は、ストリーミングレプリケーションとホットスタンバイを使用したpgpool-II、Postgres-XC、およびPostgreSQL 9に対するPostgres-Rのパフォーマンス分析で終わりました。これらはすべて、dbt2テスト結果を高速化するためにクラスター構成で使用されます。 「全体的なコンピューティング能力、メモリ、ストレージ容量は簡単に拡張できる」ため、ネットワークの輻輳が最も重要なクラスタコンポーネントであるという彼の前提に完全には同意しませんが、PG9 HS/SRを確認することは満足のいくものでした。ペアリングはその点で効率的です。
会議では、比較的構造化されていない方法で一般的なクラスタリングトピックについて話し合うために2つのセッションが用意されました。より熱心な議論は、クラウドコンピューティングインフラストラクチャへのPostgreSQLの展開を扱いやすくするものについて話しました。これにより、同僚から2つのブログエントリを生成するのに十分なアイデアが生まれました。
特に興味深いと思ったそのセッションのアイデアの1つは、ノードが「弾力性のある」方法で追加される展開がある場合、クラウドの概念に関連して議論するために、アプリケーションがそのノードセットと簡単に通信できるようにするという点で、現在そこには管理性のギャップがあります。アプリケーションとノードのセットの間にpgpool-IIまたはpgBouncerを配置できる場合は、ノードの背後にあるものを今すぐ抽象化できます。しかし今、あなたは別のレイヤーを追加したので、全体に潜在的なボトルネックがあります。これは、エラスティッククラウドの導入が想定していることとは逆です。最小限の管理作業で必要に応じて容量を追加するだけです。
提案されたソリューションアプローチは、アプリケーションレベルでデータベースルーティングディレクトリを簡単に構築できるようにすることでした。必要なノードのタイプを尋ねて、直接接続するノードを取得できます。ノードは、オンラインになる（または停止される）ときに、ディレクトリに登録するだけで済みます。これは、すでに浮かんでいるいくつかのコンポーネントと類似しています。 LDAPに入れる可能性のあるディレクトリルックアップ部分。 PostgreSQLサーバーは、ZeroConfAKABonjourを介してすでにアナウンスできます。これら2つを組み合わせて、LDAPルックアップを実行するアプリケーション層を、任意の数のプロトコルを介して使用可能なノードを追跡するルーティングバックエンドに接続することを想像するのは難しいことではありません。いつものように、悪魔は細部にあります。障害が発生したノードのタイムアウト、読み取りトラフィックと書き込みトラフィックの区別（pgpool-IIは実際にSQLを解析することで処理しますが、これはコストがかかります）、結果のディレクトリブロードキャストをキャッシュして高性能にすると同時に、キャッシュの無効化を特徴とするなど、すべてトリッキーな実装の詳細です。
PostgreSQL 9.0は、データベースアーキテクチャをスケールアップするためにこれまで以上に多くの方法を備えているため、この問題は解消されません。まだ人々がそれを解決しようとしている形はわかりませんが、それは解決する価値のある十分に一般的な問題です。
