Udostępnij za pośrednictwem

Modelowanie wielodostępnych aplikacji SaaS 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)

Identyfikator dzierżawy jako klucz fragmentu

Identyfikator dzierżawy to kolumna w katalogu głównym obciążenia lub górna część hierarchii w modelu danych. Na przykład w tym schemacie handlu elektronicznego SaaS będzie to identyfikator sklepu:

Diagram tabel z wyróżnioną kolumną store_id.

Ten model danych byłby typowy dla firmy, takiejjakej. Hostuje witryny dla wielu sklepów online, w których każdy sklep współdziała z własnymi danymi.

  • Ten model danych zawiera wiele tabel: sklepów, produktów, zamówień, elementów liniowych i krajów.
  • Tabela stores znajduje się w górnej części hierarchii. Produkty, zamówienia i elementy wiersza są skojarzone z magazynami, a tym samym niższe w hierarchii.
  • Tabela krajów nie jest powiązana z poszczególnymi sklepami, znajduje się w różnych sklepach.

W tym przykładzie , store_idktóry znajduje się w górnej części hierarchii, jest identyfikatorem dzierżawy. Jest to odpowiedni klucz fragmentu. Wybranie store_id jako klucza fragmentu umożliwia sortowanie danych we wszystkich tabelach dla pojedynczego magazynu w ramach jednego procesu roboczego.

Kolokowanie tabel według magazynu ma zalety:

  • Zapewnia pokrycie SQL, takie jak klucze obce, JOIN. Transakcje dla jednej dzierżawy są zlokalizowane w jednym węźle roboczym, w którym istnieje każda dzierżawa.
  • Osiąga wydajność z jedną cyfrą milisekund. Zapytania dotyczące pojedynczej dzierżawy są kierowane do jednego węzła zamiast równoległości, co pomaga zoptymalizować przeskoki sieciowe i nadal skalować zasoby obliczeniowe/pamięć.
  • Skaluje. Wraz ze wzrostem liczby dzierżaw można dodawać węzły i ponownie równoważyć dzierżawy do nowych węzłów, a nawet odizolować duże dzierżawy do własnych węzłów. Izolacja dzierżawy umożliwia udostępnianie dedykowanych zasobów.

Diagram tabel przeniesionych do tych samych węzłów.

Optymalny model danych dla aplikacji wielodostępnych

W tym przykładzie powinniśmy dystrybuować tabele specyficzne dla magazynu według identyfikatora sklepu i utworzyć countries tabelę referencyjną.

Diagram tabel z wyróżnionymi store_id bardziej uniwersalnie.

Zwróć uwagę, że tabele specyficzne dla dzierżawy mają identyfikator dzierżawy i są dystrybuowane. W naszym przykładzie sklepy, produkty i line_items są dystrybuowane. Pozostałe tabele to tabele referencyjne. W naszym przykładzie tabela kraje jest tabelą referencyjną.

-- Distribute large tables by the tenant ID

SELECT create_distributed_table('stores', 'store_id');
SELECT create_distributed_table('products', 'store_id', colocate_with => 'stores');
-- etc for the rest of the tenant tables...

-- Then, make "countries" a reference table, with a synchronized copy of the
-- table maintained on every worker node

SELECT create_reference_table('countries');

Duże tabele powinny mieć identyfikator dzierżawy.

  • Jeśli migrujesz istniejącą aplikację wielodostępną do usługi Azure Cosmos DB for PostgreSQL, może być konieczne znienormalizowanie nieco i dodanie kolumny identyfikatora dzierżawy do dużych tabel, jeśli jej brakuje, a następnie wypełnienie brakujących wartości w kolumnie.
  • W przypadku nowych aplikacji w usłudze Azure Cosmos DB for PostgreSQL upewnij się, że identyfikator dzierżawy jest obecny we wszystkich tabelach specyficznych dla dzierżawy.

Upewnij się, że identyfikator dzierżawy jest uwzględniany w ograniczeniach klucza podstawowego, unikatowego i obcego w tabelach rozproszonych w postaci klucza złożonego. Jeśli na przykład tabela ma klucz idpodstawowy , przekształcić go w klucz (tenant_id,id)złożony . Nie ma potrzeby zmieniania kluczy dla tabel odwołań.

Zagadnienia dotyczące zapytań pod kątem najlepszej wydajności

Zapytania rozproszone, które filtrują identyfikator dzierżawy, działają najbardziej wydajnie w aplikacjach wielodostępnych. Upewnij się, że zapytania są zawsze ograniczone do jednej dzierżawy.

SELECT *
  FROM orders
 WHERE order_id = 123
   AND store_id = 42;  -- ← tenant ID filter

Należy dodać filtr identyfikatora dzierżawy, nawet jeśli oryginalne warunki filtrowania jednoznacznie identyfikują żądane wiersze. Filtr identyfikatora dzierżawy, choć pozornie nadmiarowy, informuje usługę Azure Cosmos DB for PostgreSQL, jak kierować zapytanie do jednego węzła roboczego.

Podobnie podczas łączenia dwóch tabel rozproszonych upewnij się, że oba tabele są ograniczone do jednej dzierżawy. Określenie zakresu można wykonać, upewniając się, że warunki dołączania zawierają identyfikator dzierżawy.

SELECT sum(l.quantity)
  FROM line_items l
 INNER JOIN products p
    ON l.product_id = p.product_id
   AND l.store_id = p.store_id   -- ← tenant ID in join
 WHERE p.name='Awesome Wool Pants'
   AND l.store_id='8c69aa0d-3f13-4440-86ca-443566c1fc75';
       -- ↑ tenant ID filter

Istnieją biblioteki pomocnicze dla kilku popularnych struktur aplikacji, które ułatwiają dołączanie identyfikatora dzierżawy w zapytaniach. Poniżej przedstawiono instrukcje:

Następne kroki

Teraz zakończyliśmy eksplorowanie modelowania danych dla skalowalnych aplikacji. Następnym krokiem jest nawiązanie połączenia z bazą danych i wykonywanie zapytań względem bazy danych przy użyciu wybranego języka programowania.

Stosy aplikacji >