Azure Cosmos DB for PostgreSQL でシャード数を選択する
適用対象: Azure Cosmos DB for PostgreSQL (PostgreSQL の Citus データベース拡張機能を利用)
分散テーブルごとのシャード数の選択は、シャードを増やす柔軟性と、それらの間でのクエリの計画と実行のオーバーヘッドとのバランスになります。 分散の後でテーブルのシャード数を変更する場合は、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)
) を超えないようにする必要があります。
次の手順
- クラスターのパフォーマンス オプションに関する詳細情報を学びます。
- クラスターのスケールアップまたはスケールアウト
- シャードの再調整