先週のCHAR（10） 会議では、「クラウドデータベース」に関するワークショップがありました。簡単に言うと、ユースケースの要件がデータベースサーバーで利用可能なリソースを超えた場合の対処方法です。
これは会議全体のメイントピックであり、日中にいくつかのソリューションが示されました。共通のテーマは、すべてのユースケースに適合するソリューションはなく、各ソリューションにはコストが伴うというものでした。したがって、ユースケースで許容できるソリューションを選択する必要があります。
もう1つの一般的な（暗黙的ではありますが）ポイントは、「高レベル」ソリューションに焦点を当てることです。つまり、複数のデータベースサーバーをより高いレベルで接続して、より大きなリソースを持つ単一のサーバーをエミュレートします。
明らかな利点よく精査されたPostgreSQLコードを変更する必要がないということです。欠点は、独立したタイムラインを持つ複数のデータベースサーバーを使用すると、いくつかの有用なプロパティが失われることです。 2つの例：トランザクションセマンティクスが部分的に失われると、競合が発生します。データベースの外部で各クエリを事前に解析すると、受け入れられるクエリに制限が生じます。
議論は非常に興味深いものでした。DimitriFontaineがリモートテーブルスペースについて言及したとき、関連しているが明確なアイデア、つまり、下位レベルのアプローチかどうかについて疑問に思い始めました。リソースプーリングの問題に対処することは実際には非現実的です。ワークショップが終了した詳細を詳しく説明する前に、ホワイトボードの周りにいた一部の人々（Gabriele Bartolini、Nic Ferrier、Marko Kreen、Hannu Krosing、Greg Smithなど）に基本的なものと一緒にアイデアをスケッチすることしかできませんでした質問「それは実行可能に見えますか？」 「それはあなたがすでに知っているものに似ていますか？」
簡単なスケッチ：アプリケーションスタックはこのように表現できます
(application) --> (connection) --> (db server) --> (resources)
データベースで使用されるリソースには、ストレージ、RAM、CPUが含まれます。目的は、容量と速度を向上させるために、アプリケーションがより多くのリソースをコマンドできるようにすることです。複数のデータベースを管理する「賢い」アプリケーションは、次のように表すことができます
(application) --> (connection) --> (db server) --> (resources) | +---------> (connection) --> (db server) --> (resources)
一方、「接続プール」ソリューションは次のように表すことができます
(application) --> (connection) --> (db server) --> (resources) | +---------> (db server) --> (resources)>
「低レベル」ソリューションとは、次のようなものを意味します
(application) --> (connection) --> (db server) --> (resources) | +---------> (resources)
これはなじみのあるものに似ているかもしれませんが、私がここで提案しているものではありません。違いを説明するために、詳細を増やして書くことができます
(resources) = (virtual resources) --> (physical resources)
最下位レベルでは、物理オブジェクトと仮想オブジェクトの間に重要なマッピングを作成できるという事実を表すためです。たとえば、SANストレージまたはRAIDストライピングは、より小さな物理ディスクを結合することにより、より大きな仮想ディスクを提供できます。そのような場合は次のように描くことができます
(application) --> (connection) --> (db server) --> (virt.res.) --> (ph.res.) | +--------> (ph.res.)
私の提案は、データベースサーバーにリソースをプールすることです。 レベル。これにより、各リソース（CPU、RAM、ディスク）の特定のユースケースの知識を使用して、より効率的な「仮想化」を実現できると同時に、トランザクションパラダイムの問題を回避できます。写真は次のようになります：
(application) --> (connection) --> (db server) --> (virt.res.) --> (ph.res.) | +--------> (virt.res.) --> (ph.res.)
利点は、仮想リソースごとに考えられるすべてのユースケースを管理する必要がないことです。 PostgreSQLが実際に必要とするユースケースを管理（および最適化）する必要があります。例：WALは引き続きローカルの「非仮想化」ストレージに書き込む必要があります。bgwriterはローカルおよびリモートのリソース（RAMとディスク）などにアクセスします。
信頼性に関する最後の言葉。システム全体を適切に動作させるには、各サブシステムが必要です。このアーキテクチャは冗長ではないため、部分的な障害は管理されません。これは分散システムですが、共有されていません。このアーキテクチャが、より大きなリソースを備えた物理サーバーと機能的に同等の仮想データベースサーバーを介して安価でシンプルなスケーラビリティを提供できる場合、ホットスタンバイ構成で2つの同一の仮想サーバーをセットアップすることにより、標準的な方法で高可用性を実現できます。
ネットワークの品質は、全体的なパフォーマンスに大きな影響を与えます。この設計は、速度上の理由だけでなく、ネットワーク障害が実際にはシステム障害になるため、同じLAN内にマシンのアレイがある場合にのみ役立つ可能性があります。これらの制限があっても、このオプションがあると非常に便利だと思います。
これはまだスケッチであり、今後の議論の参考として使用されます。次の可能なステップ：
- リソースのユースケースの詳細なリストを作成する
- 各ユースケースでどのテクノロジーが最も役立つかを判断する
- 実際のパフォーマンス/開発コストを見積もる