Udostępnij za pośrednictwem

Wybieranie liczby shardów w usłudze Azure Cosmos DB for PostgreSQL

DOTYCZY: Usługa Azure Cosmos DB for PostgreSQL (obsługiwana przez rozszerzenie bazy danych Citus do bazy danych PostgreSQL)

Wybór liczby fragmentów dla każdej tabeli rozproszonej jest równowagą między elastycznością większej liczby fragmentów, a obciążeniem na potrzeby planowania i wykonywania zapytań między nimi. Jeśli zdecydujesz się zmienić liczbę fragmentów tabeli po dystrybucji, możesz użyć funkcji alter_distributed_table .

Przypadek użycia usługi SaaS dla wielodzierżawcy

Optymalny wybór zależy od wzorców dostępu dla danych. Na przykład w przypadku wielodzierżawczej bazy danych SaaS zalecamy wybranie od 32 do 128 fragmentów. W przypadku mniejszych obciążeń załóżmy <, że 100 GB, możesz zacząć od 32 fragmentów i dla większych obciążeń można wybrać 64 lub 128. Ten wybór umożliwia skalowanie z 32 do 128 maszyn roboczych.

Przypadek użycia analizy w czasie rzeczywistym

W przypadku użycia analizy w czasie rzeczywistym liczba fragmentów powinna być powiązana z całkowitą liczbą rdzeni w pracownikach. Aby zapewnić maksymalną równoległość, należy utworzyć wystarczającą liczbę odłamków na każdym węźle, tak aby był co najmniej jeden odłamek na rdzeń procesora. Zazwyczaj zalecamy utworzenie dużej liczby początkowych fragmentów, na przykład 2x lub 4x liczby bieżących rdzeni procesora CPU. Posiadanie większej liczby fragmentów umożliwia przyszłe skalowanie, jeśli dodasz więcej procesów roboczych i rdzeni CPU.

Należy pamiętać, że dla każdego zapytania usługa Azure Cosmos DB for PostgreSQL otwiera jedno połączenie bazy danych na fragment i że te połączenia są ograniczone. Należy zachować liczbę fragmentów na tyle małą, żeby zapytania rozproszone nie musiały często czekać na połączenie. Innymi słowy, wymagane połączenia , (max concurrent queries * shard count)nie powinny przekraczać łącznej liczby połączeń możliwych w systemie, (number of workers * max_connections per worker).

Następne kroki