Udostępnij za pośrednictwem

Podstawowe pojęcia dotyczące skalowania w usłudze Azure Cosmos DB for PostgreSQL

  • Artykuł

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

Zanim zbadamy kroki tworzenia nowej aplikacji, warto zapoznać się z szybkim omówieniem terminów i pojęć.

Omówienie architektury

Usługa Azure Cosmos DB for PostgreSQL umożliwia dystrybuowanie tabel i/lub schematów na wielu maszynach w klastrze i przezroczyste wykonywanie zapytań o nie w taki sam sposób, jak w przypadku zwykłego bazy danych PostgreSQL:

Diagram węzła koordynacji dzielenia tabeli na węzły robocze.

W architekturze usługi Azure Cosmos DB for PostgreSQL istnieje wiele rodzajów węzłów:

  • Węzeł koordynacji przechowuje rozproszone metadane tabeli i jest odpowiedzialny za planowanie rozproszone.
  • Natomiast węzły procesu roboczego przechowują rzeczywiste dane, metadane i wykonują obliczenia.
  • Zarówno koordynator, jak i pracownicy są zwykłymi bazami danych PostgreSQL z citus załadowanym rozszerzeniem.

Aby rozłożyć normalną tabelę PostgreSQL, na przykład campaigns na powyższym diagramie, uruchom polecenie o nazwie create_distributed_table(). Po uruchomieniu tego polecenia usługa Azure Cosmos DB for PostgreSQL w sposób przezroczysty tworzy fragmenty dla tabeli między węzłami procesu roboczego. Na diagramie fragmenty są reprezentowane jako niebieskie pola.

Aby rozpowszechnić normalny schemat postgreSQL, uruchom citus_schema_distribute() polecenie . Po uruchomieniu tego polecenia usługa Azure Cosmos DB for PostgreSQL w sposób przezroczysty zamienia tabele w takie schematy w pojedyncze tabele kolokowane fragmentów, które można przenieść jako jednostkę między węzłami klastra.

Uwaga

W klastrze bez węzłów roboczych fragmenty tabel rozproszonych znajdują się w węźle koordynacji.

Fragmenty są zwykłe (ale specjalnie nazwane) tabele PostgreSQL, które przechowują wycinki danych. W naszym przykładzie, ponieważ rozpowszechnialiśmy campaigns przez company_idelement , fragmenty przechowują kampanie, w których kampanie różnych firm są przypisywane do różnych fragmentów.

Kolumna dystrybucji (znana również jako klucz fragmentu)

create_distributed_table() to funkcja magic, którą usługa Azure Cosmos DB for PostgreSQL udostępnia w celu dystrybuowania tabel i używania zasobów na wielu maszynach.

SELECT create_distributed_table(
	'table_name',
	'distribution_column');

Drugi argument powyżej wybiera kolumnę z tabeli jako kolumnę dystrybucji. Może to być dowolna kolumna z natywnym typem postgreSQL (z liczbą całkowitą i tekstem najczęściej spotykanym). Wartość kolumny dystrybucji określa, które wiersze przechodzą do których fragmentów, dlatego kolumna rozkładu jest również nazywana kluczem fragmentu.

Usługa Azure Cosmos DB for PostgreSQL decyduje, jak uruchamiać zapytania na podstawie ich użycia klucza fragmentu:

Zapytanie obejmuje Gdzie jest uruchamiany
tylko jeden klucz fragmentu w węźle roboczym, w którym znajduje się jego fragment
wiele kluczy fragmentów równoległe między wieloma węzłami

Wybór klucza fragmentu określa wydajność i skalowalność aplikacji.

  • Nierównomierna dystrybucja danych na klucze fragmentów (znana również jako niesymetryczność danych) nie jest optymalna dla wydajności. Na przykład nie wybieraj kolumny, dla której pojedyncza wartość reprezentuje 50% danych.
  • Klucze fragmentów o niskiej kardynalności mogą mieć wpływ na skalowalność. Można używać tylko tak wielu fragmentów, jak istnieją różne wartości klucza. Wybierz klucz z kardynalnością w setkach do tysięcy.
  • Łączenie dwóch dużych tabel z różnymi kluczami fragmentów może być powolne. Wybierz wspólny klucz fragmentu w dużych tabelach. Dowiedz się więcej w kolokacji.

Colocation (Kolokacja)

Inną koncepcją ściśle powiązaną z kluczem fragmentu jest kolokacja. Tabele podzielone na fragmenty według tych samych wartości kolumn rozkładu są kolokowane — fragmenty tabel kolokowanych są przechowywane razem w tych samych procesach roboczych.

Poniżej znajdują się dwie tabele podzielone na fragmenty według tego samego klucza: site_id. Są one przeniesione.

Diagram tabel http_request i http_request_1min kolokowanych przez site_id.

Usługa Azure Cosmos DB for PostgreSQL zapewnia, że wiersze o pasującej site_id wartości w obu tabelach są przechowywane w tym samym węźle roboczym. Zobaczysz, że w przypadku obu tabel wiersze z ciągiem site_id=1 są przechowywane w obszarze roboczym 1. Podobnie w przypadku innych identyfikatorów witryn.

Kolokacja ułatwia optymalizowanie numerów JOIN w tych tabelach. Jeśli połączysz dwie tabele w usłudze site_id, usługa Azure Cosmos DB for PostgreSQL może wykonać sprzężenie lokalnie w węzłach roboczych bez mieszania danych między węzłami.

Tabele w schemacie rozproszonym są zawsze współlokowane ze sobą.

Następne kroki

Klasyfikowanie obciążenia aplikacji >