次の方法で共有

Azure Cosmos DB for PostgreSQL でクラスターの初期サイズを選択する

  • [アーティクル]

適用対象: Azure Cosmos DB for PostgreSQL (PostgreSQL の Citus データベース拡張機能を利用)

クラスターのサイズは、ノードの数とそのハードウェア容量のどちらも簡単に変更できます。 ただし、新しいクラスターの初期サイズを選択する必要があります。 ここでは、適切な選択に向けたヒントをいくつか紹介します。

ユース ケース

Azure Cosmos DB for PostgreSQL は、次の方法でよく使用されます。

マルチテナント SaaS

既存の単一ノード PostgreSQL データベース インスタンスから Azure Cosmos DB for PostgreSQL への移行時には、worker 仮想コアの数と RAM の合計が、元のインスタンスでの合計と等しいクラスターを選びます。 このようなシナリオでは、シャーディングによるリソース使用率の向上や、より小さいインデックスの許可などのため、パフォーマンスが 2 倍から 3 倍向上しています。

実際には、仮想コアの数を決定するだけです。 現在、RAM の割り当ては、コンピューティングとストレージのページで説明されているように、仮想コア数に基づいて決定 されます。 コーディネーター ノードにはワーカーと同量の RAM は必要ありませんが、RAM と仮想コアを別々に選択する方法はありません。

リアルタイム分析

仮想コアの合計: 作業データが RAM に収まる場合、Azure Cosmos DB for PostgreSQL では、worker コアの数に比例してパフォーマンスが直線的に向上することが期待できます。 ニーズに合った適切な仮想コア数を決定するには、単一ノード データベースでのクエリの現在の待機時間と、Azure Cosmos DB for PostgreSQL で必要な待機時間を考慮します。 現在の待機時間を必要な待機時間で除算し、結果を丸めます。

ワーカー RAM: 最適なケースは、ワーキング セットのほとんどがメモリに収まる十分なメモリを提供することです。 アプリケーションによって使用されるクエリの種類は、メモリ要件に影響します。 クエリで EXPLAIN ANALYZE を実行して、必要なメモリの量を確認できます。 仮想コアと RAM は、コンピューティングとストレージに関する記事の説明のように、一緒にスケーリングされることに留意してください。

次の手順