キャッシングのトピックは22年前までPostgreSQLに登場し、当時はデータベースの信頼性に重点が置かれていました。
2020年に向けて、ディスクプラッターは、仮想化環境、ハイパーバイザー、および関連するストレージアプライアンスのさらに奥深くに隠されています。さらに、グローバル規模で動作する相互接続された分散アプリケーションは、低遅延接続とすべての突然のサーバーキャッシュの調整を求めて叫んでおり、SQLクエリは、結果がミリ秒以内にクライアントに返されるようにすることと競合します。アプリケーションレベルとメモリ内のキャッシュが生成され、読み取りクエリがアプリケーションサーバーの近くに保存されるようになりました。その結果、I / O操作が書き込みのみに削減され、ネットワーク遅延が大幅に改善されます。 1つのキャッチで。実装は独自のキャッシュ管理を担当し、パフォーマンスの低下につながる場合があります。
PostgreSQL wikiで説明されているように、書き込みのキャッシュははるかに複雑な問題です。
このブログは、PostgreSQLで使用されているメモリ内クエリキャッシュとロードバランサーの概要です。
PostgreSQL負荷分散
負荷分散のアイデアは、1999年にBruceMomjiamが次のように書いたときにキャッシングと同時に提起されました。
[...]近い将来_非常に_人気になる可能性があります。
PostgreSQLで負荷分散を実装するための基盤は、組み込みのホットスタンバイ機能によって提供されます。唯一の要件は、アプリケーションがフェイルオーバーを処理することです。これがサードパーティのソリューションの出番です。これらのソリューションのいくつかについては、次のセクションで説明します。
負荷分散されたクエリは、同期レプリケーションの遅延が低く抑えられている限り、一貫した結果のみを返すことができます。実際には、AWSなどの最先端のネットワークインフラストラクチャでさえ、数十ミリ秒の遅延が発生する可能性があります。
通常、ラグタイムは数十ミリ秒で観察されます。 [...]ただし、通常の条件下では、1分未満のレプリケーションラグが一般的です。 [...]
論理レプリケーションを使用するクロスリージョンレプリカは、選択した特定のリージョン間のネットワーク通信の変更/適用レートと遅延の影響を受けます。 Aurora Global Databaseを使用するクロスリージョンレプリカには、通常1秒未満の遅延があります。
前述のように、サードパーティのソリューションはPostgreSQLのコア機能に依存しています。たとえば、読み取りクエリの負荷分散は、複数の同期スタンバイを使用して実現されます。
pgpool-II
pgpool-IIは、負荷分散とメモリ内クエリキャッシュの両方を提供する機能豊富な製品です。これはドロップイン交換であり、アプリケーション側での変更は必要ありません。
ロードバランサーとして、pgpool-IIは各SQLクエリを調べます—負荷分散するには、SELECTクエリがいくつかの条件を満たす必要があります。
セットアップは、1つのノードと同じくらい簡単にすることができます。以下に示すのは、デュアルノードクラスターです。
優れたソフトウェアの場合と同様に、特定の制限があります。 、およびpgpool-IIも例外ではありません：
- 一時テーブルに対するSELECTクエリには、/ * NO LOAD BALANCE */SQLコメントが必要です。
高性能環境で実行されているアプリケーションは、pgBouncerが接続プールであり、pgpool-IIが負荷分散とキャッシュを処理する混合構成の恩恵を受けます。その結果、スループットが4倍に向上し、レイテンシが40％削減されます。
メモリ内キャッシュは、読み取りクエリでのみ機能し、キャッシュされます共有メモリまたは外部memcachedインストールのいずれかに保存されているデータ。ドキュメントはさまざまな構成オプションの説明に非常に優れていますが、実装が70％マークを下回るヒット率を警告するために、SHOW POOL CACHE出力を監視する必要があることを間接的に示唆しています。この時点で、キャッシュによって提供されるパフォーマンスの向上は失われます。
Bucardoは、PerlおよびPL/Perlで記述されたPostgreSQLレプリケーションツールです。
PostgreSQL wikiによると、負荷分散はその機能の1つであるため、Bucardoについて説明しましたが、インターネット検索では関連する結果が得られません。明確にするために、ソフトウェアが実際にどのように機能するかについての詳細が記載された公式ドキュメントに向かいました。
これは非常に明確ですが、Bucardoはロードバランサーではありません。 DatabaseSoupの人々から指摘されました。
HAProxy
HAProxyは、TCPレベルで動作する汎用ロードバランサーです（データベース接続の目的で）。ヘルスチェックにより、クエリが有効なノードにのみ送信されることが保証されます。
pgpool-IIと比較して、ロードバランサーとしてHAProxyを使用するアプリケーションは、エンドポイントがリーダーノードにリクエストをディスパッチすることを認識している必要があります。
Apache Ignite
Apache Igniteは、ANSI-99 SQLを理解し、ACIDトランザクションのサポートを提供する第2レベルのキャッシュです。 Apache IgniteはPostgreSQLフロントエンド/バックエンドプロトコルを理解しないため、アプリケーションはHibernateORMなどの永続層を使用する必要があります。アプリケーションを変更する代わりに、ApacheIgniteはmemcachedPostgreSQL拡張機能を必要とする`memcached統合`_を提供します。残念ながら、この後者のオプションは、pgmemcache拡張機能が2017年に最後に更新されたため、PostgreSQLの最近のバージョンと互換性がありません。
商用製品として、HeimdallDataは負荷分散とキャッシュの両方のチェックボックスをオンにします。これは成熟した製品であり、PGCon 2017までさかのぼってPostgreSQLカンファレンスで紹介されてきました：
詳細と製品デモは、AzureforPostgreSQLブログにあります。 。
今日の分散コンピューティングでは、クエリキャッシングと負荷分散は、よく知られているGUC、OSカーネル、ストレージ、クエリ最適化と同様に、PostgreSQLのパフォーマンスチューニングにとって重要です。 pgpool-IIとHeimdallDataはそれぞれオープンソースであり、商業的に推奨されるソリューションですが、意図的に作成されたツールをビルディングブロックとして使用して、同様の結果を達成できる場合があります。