Teilen über

Auswählen der Shardanzahl in Azure Cosmos DB for PostgreSQL

  • Artikel

GILT FÜR: Azure Cosmos DB for PostgreSQL (unterstützt von der Citus-Datenbankerweiterung auf PostgreSQL)

Die Auswahl der Shardanzahl für jede verteilte Tabelle ist ein Gleichgewicht zwischen der Flexibilität, mehr Shards zu haben, und dem Mehraufwand für die Abfrageplanung und -ausführung in diesen Tabellen. Wenn Sie sich entscheiden, die Shardanzahl einer Tabelle nach der Verteilung zu ändern, können Sie die Funktion alter_distributed_table verwenden.

Anwendungsfall für mehrinstanzenfähige SaaS-Anwendungen

Die optimale Auswahl hängt von Ihren Zugriffsmustern für die Daten ab. Für den Anwendungsfall für mehrinstanzenfähige SaaS-Anwendungen empfehlen wir beispielsweise, zwischen 32 und 128 Shards auszuwählen. Bei kleineren Workloads wie <100 GB könnten Sie mit 32 Shards beginnen und bei größeren Workloads mit 64 oder 128. Diese Wahl gibt Ihnen den Spielraum, um von 32 auf 128 Arbeitsmaschinen zu skalieren.

Anwendungsfall für Echtzeitanalysen

Im Anwendungsfall für Echtzeitanalysen sollte die Anzahl der Shards auf die Gesamtzahl der Kerne auf den Workern bezogen sein. Um maximale Parallelität sicherzustellen, sollten Sie auf jedem Knoten genügend Shards erstellen, sodass mindestens ein Shard pro CPU-Kern vorhanden ist. In der Regel wird empfohlen, eine hohe Anzahl anfänglicher Shards zu erstellen, z. B. das 2- oder 4-fache der Anzahl aktueller CPU-Kerne. Wenn Sie mehr Shards haben, können Sie zukünftige Skalierungen durchführen, wenn Sie weitere Worker und CPU-Kerne hinzufügen.

Beachten Sie, dass Azure Cosmos DB for PostgreSQL für jede Abfrage eine Datenbankverbindung pro Shard öffnet und dass diese Verbindungen begrenzt sind. Achten Sie darauf, die Shardanzahl so klein zu halten, dass verteilte Abfragen nicht oft auf eine Verbindung warten müssen. Anders ausgedrückt: Die erforderlichen Verbindungen (max concurrent queries * shard count) sollten die gesamt möglichen Verbindungen im System (number of workers * max_connections per worker) nicht überschreiten.

Nächste Schritte