Modelowanie wielodostępnych aplikacji SaaS w usłudze Azure Cosmos DB for PostgreSQL

Ważne

Usługa Azure Cosmos DB for PostgreSQL nie jest już obsługiwana w przypadku nowych projektów. Nie używaj tej usługi dla nowych projektów. Zamiast tego użyj jednej z tych dwóch usług:

• Użyj usługi Azure Cosmos DB for NoSQL dla rozproszonego rozwiązania bazy danych przeznaczonego dla scenariuszy o dużej skali z umową dotyczącą poziomu usług dostępności 99,999% (SLA), natychmiastowym skalowaniem automatycznym i automatycznym przejściem w tryb failover w wielu regionach.

• Użyj funkcji Elastic Clusters usługi Azure Database for PostgreSQL na potrzeby fragmentowanej bazy danych PostgreSQL przy użyciu rozszerzenia Citus typu open source.

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:

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ę na szczycie hierarchii. Produkty, zamówienia i pozycje zamówienia są skojarzone ze sklepami, a tym samym niższe w hierarchii.
• Tabela krajów nie jest powiązana z poszczególnymi sklepami, lecz obejmuje wszystkie sklepy.

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 umieszczanie danych we wszystkich tabelach dla pojedynczego magazynu na jednym pracowniku.

Umieszczanie tabel według sklepu ma zalety:

• Zapewnia pokrycie SQL, takie jak klucze obce, JOIN. Transakcje dla pojedynczego dzierżawcy są zlokalizowane w jednym węźle roboczym, gdzie znajduje się ów dzierżawca.
• Osiąga wydajność na poziomie kilku milisekund. Zapytania dotyczące pojedynczej dzierżawy są kierowane do jednego węzła zamiast równoległego przetwarzania, co pomaga zoptymalizować przechody przez sieć i jednocześnie zwiększyć skalowalność zasobów obliczeniowych/pamięci.
• Skaluje. W miarę jak zwiększa się liczba najemców, można dodawać węzły i zrównoważyć najemców na nowe węzły, a nawet odizolować dużych najemców na własne węzły. Izolacja dzierżawcy umożliwia zapewnienie dedykowanych zasobó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ą.

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ą rozproszone. 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 ID dzierżawcy jest uwzględniany w ograniczeniach klucza podstawowego, unikatowego i obcego w tabelach rozproszonych w postaci klucza łączonego. Jeśli na przykład tabela ma klucz podstawowy id, przekształć go w klucz złożony (tenant_id,id). Nie ma potrzeby zmieniania kluczy dla tabel referencyjnych.

Aspekty zapytań do rozważenia pod kątem najlepszej wydajności

Rozproszone zapytania, które filtrują ID najemcy, działają z najwyższą wydajnością w aplikacjach wielodostępnych. Upewnij się, że zapytania są zawsze ograniczone do jednego tenanta.

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

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

Podobnie podczas łączenia dwóch tabel rozproszonych upewnij się, że obie tabele są ograniczone do jednego najemcy. Określenie zakresu można wykonać, upewniając się, że warunki łączenia 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:

• Instrukcje dotyczące języka Ruby on Rails
• Instrukcje Django
• ASP.NET
• Java Hibernate

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 >