Important
Azure Cosmos DB for PostgreSQL は、新しいプロジェクトではサポートされなくなりました。 このサービスは、新しいプロジェクトには使用しないでください。 代わりに、次の 2 つのサービスのいずれかを使用します。
Azure Cosmos DB for NoSQL は、99.999% 可用性サービス レベル アグリーメント (SLA)、インスタント 自動スケール、および複数のリージョン間の自動フェールオーバーを使用する 大規模 なシナリオ向けに設計された分散データベース ソリューションに使用します。
オープンソースの Citus 拡張機能を使用して、シャード化された PostgreSQL 用の Azure Database For PostgreSQL のエラスティック クラスター機能 を使用します。
分散テーブルごとのシャード数の選択は、シャードを増やす柔軟性と、それらの間でのクエリの計画と実行のオーバーヘッドとのバランスになります。 分散の後でテーブルのシャード数を変更する場合は、alter_distributed_table 関数を使用できます。
マルチテナント SaaS のユース ケース
最適な選択は、データのアクセス パターンによって異なります。 たとえば、マルチテナント SaaS データベースのユース ケースでは、32 から 128 個のシャードを選ぶことをお勧めします。 100 GB 未満のような小さいワークロードでは、32 個のシャードから始めることができ、大きなワークロードでは、64 または 128 個を選択できます。 この選択により、ワーカー マシンを 32 個から 128 個にスケーリングする余裕が生まれます。
リアルタイム分析のユース ケース
リアルタイム分析のユース ケースでは、シャード数をワーカーの合計コア数に関連させる必要があります。 並列処理を最大限にするには、CPU コアごとに少なくとも 1 つのシャードが存在するように、各ノードに十分なシャードを作成する必要があります。 通常は、最初に多数のシャードを作成することをお勧めします (たとえば、現在の CPU コア数の 2 倍または 4 倍)。 シャードを増やすと、将来ワーカーと CPU コアを追加する場合のスケーリングに対応できます。
Azure Cosmos DB for PostgreSQL では、クエリのたびに、シャードごとに 1 つのデータベース接続が開かれ、これらの接続には制限があることに注意してください。 分散クエリが接続を頻繁に待機する必要がないように、シャード数を十分に少なく保つように注意してください。 つまり、必要な接続の数 ((max concurrent queries * shard count)) が、システムで可能な合計接続数 ((number of workers * max_connections per worker)) を超えないようにする必要があります。
次の手順
- クラスターのパフォーマンス オプションに関する詳細情報を学びます。
- クラスターのスケールアップまたはスケールアウト
- シャードの再調整