Important
Azure Cosmos DB for PostgreSQL は、新しいプロジェクトではサポートされなくなりました。 このサービスは、新しいプロジェクトには使用しないでください。 代わりに、次の 2 つのサービスのいずれかを使用します。
Azure Cosmos DB for NoSQL は、99.999% 可用性サービス レベル アグリーメント (SLA)、インスタント 自動スケール、および複数のリージョン間の自動フェールオーバーを使用する 大規模 なシナリオ向けに設計された分散データベース ソリューションに使用します。
オープンソースの Citus 拡張機能を使用して、シャード化された PostgreSQL 用の Azure Database For PostgreSQL のエラスティック クラスター機能 を使用します。
クラスターのサイズは、ノードの数とそのハードウェア容量のどちらも簡単に変更できます。 ただし、新しいクラスターの初期サイズを選択する必要があります。 ここでは、適切な選択に向けたヒントをいくつか紹介します。
ユース ケース
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 は、コンピューティングとストレージに関する記事の説明のように、一緒にスケーリングされることに留意してください。
次の手順
- クラスターを拡張する
- クラスターのパフォーマンス オプションに関する詳細情報を学びます。