Zagadnienia dotyczące platformy danych dla obciążeń o znaczeniu krytycznym na platformie Azure

Wybór efektywnej platformy danych aplikacji jest kolejnym kluczowym obszarem decyzyjnym, który ma daleko idące konsekwencje w innych obszarach projektowania. Platforma Azure oferuje ostatecznie wiele relacyjnych, nierelacyjnych i analitycznych platform danych, które znacznie różnią się możliwościami. Dlatego istotne jest, aby kluczowe wymagania niefunkcjonalne uwzględniały w pełni oprócz innych czynników decyzyjnych, takich jak spójność, funkcjonalność, koszt i złożoność. Na przykład możliwość działania w konfiguracji zapisu w wielu regionach będzie miała krytyczne znaczenie dla przydatności dla globalnej dostępnej platformy.

Ten obszar projektowania rozszerza projekt aplikacji, udostępniając kluczowe zagadnienia i zalecenia, aby poinformować o wyborze optymalnej platformy danych.

Ważne

Ten artykuł jest częścią serii obciążeń o kluczowym znaczeniu dla architektury platformy Azure. Jeśli nie znasz tej serii, zalecamy rozpoczęcie od tego, co to jest obciążenie o znaczeniu krytycznym?

Cztery a dane big data

"Four Vs of Big Data" (Cztery vs danych big data) zapewnia strukturę, która lepiej rozumie wymagania wymagane dla platformy danych o wysokiej dostępności oraz sposób wykorzystania danych w celu zmaksymalizowania wartości biznesowej. W tej sekcji dowiesz się zatem, jak można zastosować charakterystykę Volume, Velocity, Variety i Veracity na poziomie koncepcyjnym, aby ułatwić projektowanie platformy danych przy użyciu odpowiednich technologii danych.

• Volume: ile danych przychodzi w celu informowania o pojemności magazynu i wymaganiach dotyczących obsługi warstw — czyli rozmiaru zestawu danych.
• Vwymowa: szybkość przetwarzania danych, zarówno jako partie, jak i strumienie ciągłe - czyli szybkość przepływu.
• Variety: organizacja i format danych, przechwytywanie ustrukturyzowanych, częściowo ustrukturyzowanych i nieustrukturyzowanych formatów — czyli danych w wielu magazynach lub typach.
• Veracity: obejmuje pochodzenie i curation rozważanych zestawów danych w celu zapewnienia ładu i jakości danych — to jest dokładność danych.

Zagadnienia dotyczące projektowania

Volume

• Istniejące (jeśli istnieją) i oczekiwane przyszłe woluminy danych na podstawie prognozowanych wskaźników wzrostu danych dostosowanych do celów biznesowych i planów.

  • Wolumin danych powinien obejmować same dane i indeksy, dzienniki, dane telemetryczne i inne odpowiednie zestawy danych.
  • Duże aplikacje krytyczne dla działania firmy i aplikacje o krytycznym znaczeniu zwykle generują i przechowują duże woluminy (GB i TB) codziennie.
  • Mogą istnieć znaczne konsekwencje związane z rozszerzaniem danych.

• Ilość danych może się zmieniać z powodu zmieniających się okoliczności biznesowych lub procedur utrzymywania domu.

• Ilość danych może mieć głęboki wpływ na wydajność zapytań platformy danych.

• Może istnieć głęboki wpływ związany z osiągnięciem limitów woluminów platformy danych.

  • Czy spowoduje to przestój? a jeśli tak, przez jak długo?
  • Jakie są procedury ograniczania ryzyka? i czy środki zaradcze będą wymagały zmian aplikacji?
  • Czy wystąpi ryzyko utraty danych?

• Funkcje takie jak Czas wygaśnięcia (TTL) mogą służyć do zarządzania wzrostem danych przez automatyczne usuwanie rekordów po upływie czasu, przy użyciu tworzenia lub modyfikowania rekordów.

  • Na przykład usługa Azure Cosmos DB zapewnia wbudowaną funkcję czasu wygaśnięcia .

Prędkość

• Szybkość, z jaką dane są emitowane z różnych składników aplikacji, oraz wymagania dotyczące przepływności dotyczące tego, jak szybko należy zatwierdzać i pobierać dane, mają kluczowe znaczenie dla określenia optymalnej technologii danych dla kluczowych scenariuszy obciążeń.

  • Charakter wymagań dotyczących przepływności będzie się różnić w zależności od scenariusza obciążenia, takiego jak te, które są ciężkie do odczytu lub dużego zapisu.
    • Na przykład obciążenia analityczne zwykle muszą obsługiwać dużą przepływność odczytu.
  • Jaka jest wymagana przepływność? A jak oczekuje się wzrostu przepływności?
  • Jakie są wymagania dotyczące opóźnienia danych na poziomie P50/P99 na poziomie obciążenia referencyjnego?

• Możliwości, takie jak obsługa projektowania bez blokady, dostrajania indeksów i zasad spójności, mają kluczowe znaczenie dla osiągnięcia wysokiej przepływności.

  • Optymalizacja konfiguracji pod kątem wysokiej przepływności wiąże się z kompromisami, co powinno być w pełni zrozumiałe.
  • Wzorce trwałości i obsługi komunikatów na poziomie obciążenia, takie jak CQRS i Określanie źródła zdarzeń, mogą służyć do dalszej optymalizacji przepływności.

• Poziomy obciążenia będą naturalnie wahać się w przypadku wielu scenariuszy aplikacji, a naturalne szczyty wymagają wystarczającego stopnia elastyczności do obsługi zmiennego zapotrzebowania przy zachowaniu przepływności i opóźnień.

  • Elastyczna skalowalność jest kluczem do efektywnego obsługi zmiennej przepływności i poziomów obciążenia bez nadmiernego aprowizowania poziomów pojemności.
    • Przepływność odczytu i zapisu musi być skalowana zgodnie z wymaganiami aplikacji i obciążeniem.
    • Operacje skalowania w pionie i w poziomie można stosować w celu reagowania na zmieniające się poziomy obciążenia.

• Wpływ spadku przepływności może się różnić w zależności od scenariusza obciążenia.

  • Czy będą występować przerwy w łączności?
  • Czy poszczególne operacje będą zwracać kody błędów, gdy płaszczyzna sterowania będzie nadal działać?
  • Czy platforma danych aktywuje ograniczanie przepustowości, a jeśli tak długo?

• Podstawowe zalecenie dotyczące projektowania aplikacji do korzystania z aktywnej aktywnej dystrybucji geograficznej stanowi wyzwanie związane ze spójnością danych.

  • Istnieje kompromis między spójnością a wydajnością w odniesieniu do pełnej semantyki transakcyjnej ACID i tradycyjnego zachowania blokowania.
    • Zminimalizowanie opóźnienia zapisu będzie kosztować spójność danych.

• W konfiguracji zapisu w wielu regionach należy zsynchronizować i scalić zmiany między wszystkimi replikami, z rozwiązaniem konfliktów tam, gdzie jest to wymagane, a może to mieć wpływ na poziomy wydajności i skalowalność.

• Repliki tylko do odczytu (wewnątrz regionów i między regionami) mogą służyć do zminimalizowania opóźnień dwukierunkowych i dystrybucji ruchu w celu zwiększenia wydajności, przepływności, dostępności i skalowalności.

• Warstwę buforowania można użyć do zwiększenia przepływności odczytu w celu zwiększenia czasu reakcji użytkownika i kompleksowego klienta.

  • Czas wygaśnięcia pamięci podręcznej i zasady należy wziąć pod uwagę, aby zoptymalizować ostatnio używane dane.

Odmiana

• Model danych, typy danych, relacje danych i zamierzony model zapytań będą silnie wpływać na decyzje dotyczące platformy danych.

  • Czy aplikacja wymaga modelu danych relacyjnych, czy może obsługiwać model danych zmiennych lub nierelacyjnych?
  • W jaki sposób aplikacja będzie wykonywać zapytania dotyczące danych? Czy zapytania będą zależeć od koncepcji warstwy bazy danych, takich jak sprzężenia relacyjne? Czy też aplikacja udostępnia taką semantyka?

• Charakter zestawów danych, które są brane pod uwagę przez aplikację, może być różny, od zawartości bez struktury, takiej jak obrazy i filmy wideo, lub pliki ustrukturyzowane, takie jak CSV i Parquet.

  • Obciążenia aplikacji złożonych zwykle mają odrębne zestawy danych i skojarzone wymagania.

• Oprócz relacyjnych lub nierelacyjnych platform danych, platformy danych grafów lub klucz-wartość mogą być również odpowiednie dla niektórych obciążeń danych.

  • Niektóre technologie zaspokajają modele danych schematu zmiennych, w których elementy danych są semantycznie podobne i/lub przechowywane i odpytywane razem, ale różnią się strukturalnie.

• W architekturze mikrousług poszczególne usługi aplikacji można tworzyć przy użyciu różnych magazynów danych zoptymalizowanych pod kątem scenariusza, a nie w zależności od pojedynczego monolitycznego magazynu danych.

  • Wzorce projektowe, takie jak SAGA , można stosować do zarządzania spójnością i zależnościami między różnymi magazynami danych.
    • Zapytania bezpośrednie między bazami danych mogą nakładać ograniczenia dotyczące współlokacyjnej lokalizacji.
  • Zastosowanie wielu technologii danych spowoduje dodanie stopnia nakładu pracy związanego z zarządzaniem w celu utrzymania obejmujących je technologii.

• Zestawy funkcji dla każdej usługi platformy Azure różnią się w różnych językach, zestawach SDK i interfejsach API, co może mieć duży wpływ na poziom dostrajania konfiguracji, który można zastosować.

• Możliwości zoptymalizowanego dopasowania do modelu danych i obejmujących typy danych będą silnie wpływać na decyzje dotyczące platformy danych.

  • Warstwy zapytań, takie jak procedury składowane i mapery relacyjne obiektów.
  • Możliwość zapytań neutralnych dla języka, takich jak zabezpieczona warstwa interfejsu API REST.
  • Możliwości ciągłości działania, takie jak tworzenie kopii zapasowych i przywracanie.

• Magazyny danych analitycznych zwykle obsługują magazyny wielolotowe dla różnych typów struktur danych.

  • Środowiska uruchomieniowe analityczne, takie jak Apache Spark, mogą mieć ograniczenia integracji do analizowania struktur danych wielolotu.

• W kontekście przedsiębiorstwa wykorzystanie istniejących procesów i narzędzi oraz ciągłości umiejętności może mieć znaczący wpływ na projektowanie i wybór technologii danych.

Prawdziwości

• Należy wziąć pod uwagę kilka czynników, aby zweryfikować dokładność danych w aplikacji, a zarządzanie tymi czynnikami może mieć znaczący wpływ na projektowanie platformy danych.

  • Spójność danych.
  • Funkcje zabezpieczeń platformy.
  • Nadzór nad danymi.
  • Zarządzanie zmianami i ewolucja schematu.
  • Zależności między zestawami danych.

• W każdej aplikacji rozproszonej z wieloma replikami danych istnieje kompromis między spójnością a opóźnieniem, jak wyrażono w twierdzeniach CAP i PACELC .

  • Gdy czytniki i autorzy są wyraźnie dystrybuowane, aplikacja musi wybrać opcję zwrócenia najszybszej dostępnej wersji elementu danych, nawet jeśli jest nieaktualna w porównaniu z właśnie ukończonym zapisem (aktualizacją) tego elementu danych w innej replice lub najbardziej aktualną wersją elementu danych, co może spowodować dodatkowe opóźnienie w celu określenia i uzyskania najnowszego stanu.
  • Spójność i dostępność można skonfigurować na poziomie platformy lub na poziomie poszczególnych żądań danych.
  • Jakie jest środowisko użytkownika, jeśli dane mają być obsługiwane z repliki najbliższej użytkownikowi, która nie odzwierciedla najnowszego stanu innej repliki? tj. czy aplikacja może obsługiwać nieaktualne dane?

• W kontekście zapisu w wielu regionach, gdy ten sam element danych jest zmieniany w dwóch oddzielnych replikach zapisu przed zreplikowanie każdej zmiany, tworzony jest konflikt, który należy rozwiązać.

  • Można zastosować standardowe zasady rozwiązywania konfliktów, takie jak "Ostatnia wygrana zapisu" lub niestandardowa strategia z logiką niestandardową.

• Implementacja wymagań dotyczących zabezpieczeń może mieć negatywny wpływ na przepływność lub wydajność.

• Szyfrowanie magazynowane można zaimplementować w warstwie aplikacji przy użyciu szyfrowania po stronie klienta i/lub warstwy danych przy użyciu szyfrowania po stronie serwera w razie potrzeby.

• pomoc techniczna platformy Azure różne modele szyfrowania, w tym szyfrowanie po stronie serwera, które używa kluczy zarządzanych przez usługę, kluczy zarządzanych przez klienta w usłudze Key Vault lub kluczy zarządzanych przez klienta na sprzęcie kontrolowanym przez klienta.

  • Za pomocą szyfrowania po stronie klienta klucze mogą być zarządzane w usłudze Key Vault lub w innej bezpiecznej lokalizacji.

• Szyfrowanie łączy danych MACsec (IEEE 802.1AE MAC) służy do zabezpieczania całego ruchu przenoszonego między centrami danych platformy Azure w sieci szkieletowej firmy Microsoft.

  • Pakiety są szyfrowane i odszyfrowywane na urządzeniach przed wysłaniem, uniemożliwiając fizyczne ataki "man-in-the-middle" lub snooping/wiretapping.

• Uwierzytelnianie i autoryzacja na płaszczyźnie danych i płaszczyźnie sterowania.

  • W jaki sposób platforma danych będzie uwierzytelniać i autoryzować dostęp do aplikacji oraz dostęp operacyjny?

• Możliwość obserwowania za pośrednictwem monitorowania kondycji platformy i dostępu do danych.

  • Jak będzie stosowane alerty dla warunków poza dopuszczalnymi granicami operacyjnymi?

Zalecenia dotyczące projektowania

Volume

• Upewnij się, że przyszłe woluminy danych skojarzone ze wzrostem organicznym nie powinny przekraczać możliwości platformy danych.

  • Prognozowanie wskaźników wzrostu danych dostosowanych do planów biznesowych i używanie ustalonych stawek w celu informowania o bieżących wymaganiach dotyczących pojemności.
  • Porównaj woluminy zagregowanych i rekordów na dane z limitami platformy danych.
  • Jeśli istnieje ryzyko osiągnięcia limitów w wyjątkowych okolicznościach, upewnij się, że obowiązują środki zaradcze operacyjne, aby zapobiec przestojom i utracie danych.

• Monitoruj ilość danych i zweryfikuj ją względem modelu pojemności, biorąc pod uwagę limity skalowania i oczekiwane wskaźniki wzrostu danych.

  • Upewnij się, że operacje skalowania są zgodne z wymaganiami dotyczącymi magazynu, wydajności i spójności.
  • Po wprowadzeniu nowej jednostki skalowania konieczne może być zreplikowanie danych bazowych, co zajmie trochę czasu i prawdopodobnie wprowadzi karę za wydajność podczas replikacji. Upewnij się, że te operacje są wykonywane poza krytycznymi godzinami pracy, jeśli to możliwe.

• Zdefiniuj warstwy danych aplikacji w celu klasyfikowania zestawów danych na podstawie użycia i krytycznego sposobu ułatwiania usuwania lub odciążania starszych danych.

  • Rozważ klasyfikowanie zestawów danych w warstwach "gorąca", "ciepłe" i "zimne" ('archiwum').
    • Na przykład podstawowe implementacje referencyjne używają usługi Azure Cosmos DB do przechowywania "gorących" danych aktywnie używanych przez aplikację, podczas gdy usługa Azure Storage jest używana do "zimnych" danych operacji do celów analitycznych.

• Skonfiguruj procedury przechowywania danych, aby zoptymalizować wzrost danych i zwiększyć wydajność danych, takie jak wydajność zapytań i zarządzanie rozszerzeniem danych.

  • Skonfiguruj wygaśnięcie czasu wygaśnięcia (TTL) dla danych, które nie są już wymagane i nie mają długoterminowej wartości analitycznej.
    • Sprawdź, czy stare dane można bezpiecznie warstwować do magazynu pomocniczego lub usunąć je wprost bez negatywnego wpływu na aplikację.
  • Odciążanie danych niekrytycznych do pomocniczego magazynu zimnego, ale utrzymywanie ich pod kątem wartości analitycznej i spełnienia wymagań inspekcji.
  • Zbierz dane telemetryczne i statystyki użycia platformy danych, aby umożliwić zespołom DevOps ciągłe ocenianie wymagań dotyczących utrzymania domu i magazynów danych o odpowiednim rozmiarze.

• Zgodnie z projektem aplikacji mikrousług należy wziąć pod uwagę użycie wielu różnych technologii danych równolegle z zoptymalizowanymi rozwiązaniami danych dla określonych scenariuszy obciążeń i wymagań dotyczących woluminów.

  • Unikaj tworzenia pojedynczego monolitycznego magazynu danych, w którym wolumin danych z rozszerzenia może być trudny do zarządzania.

Prędkość

• Platforma danych musi być z założenia zaprojektowana i skonfigurowana do obsługi wysokiej przepływności, z obciążeniami podzielonymi na różne konteksty w celu zmaksymalizowania wydajności przy użyciu zoptymalizowanych pod kątem scenariuszy rozwiązań danych.

  • Upewnij się, że przepływność odczytu i zapisu dla każdego scenariusza danych może być skalowana zgodnie z oczekiwanymi wzorcami obciążenia z wystarczającą tolerancją dla nieoczekiwanej wariancji.
  • Rozdziel różne obciążenia danych, takie jak operacje transakcyjne i analityczne, na różne konteksty wydajności.

• Poziom obciążenia przy użyciu asynchronicznych komunikatów nieblokujących, na przykład przy użyciu wzorców CQRS lub źródła zdarzeń.

  • Może wystąpić opóźnienie między żądaniami zapisu a udostępnieniem nowych danych do odczytu, co może mieć wpływ na środowisko użytkownika.
    • Ten wpływ musi być zrozumiały i akceptowalny w kontekście kluczowych wymagań biznesowych.

• Zapewnienie elastycznej skalowalności w celu obsługi zmiennej przepływności i poziomów obciążenia.

  • Jeśli poziomy obciążenia są wysoce niestabilne, rozważ nadmierne aprowizowanie poziomów pojemności, aby zapewnić utrzymanie przepływności i wydajności.
  • Przetestuj i zweryfikuj wpływ na złożone obciążenia aplikacji, gdy nie można utrzymać przepływności.

• Określanie priorytetów usług danych natywnych dla platformy Azure za pomocą zautomatyzowanych operacji skalowania w celu ułatwienia szybkiej reakcji na zmienność na poziomie obciążenia.

  • Skonfiguruj skalowanie automatyczne na podstawie progów usługi wewnętrznej i zestawu aplikacji.
  • Skalowanie powinno inicjować i wykonywać w przedziałach czasu spójnych z wymaganiami biznesowymi.
  • W przypadku scenariuszy, w których konieczna jest interakcja ręczna, ustanów zautomatyzowane podręczniki operacyjne, które mogą być wyzwalane, a nie wykonywanie ręcznych akcji operacyjnych.
    • Zastanów się, czy zautomatyzowane wyzwalacze mogą być stosowane w ramach kolejnych inwestycji inżynieryjnych.

• Monitoruj przepływność odczytu i zapisu danych aplikacji względem wymagań dotyczących opóźnienia P50/P99 i dopasuj je do modelu pojemności aplikacji.

• Nadmiar przepływności powinien być bezpiecznie obsługiwany przez platformę danych lub warstwę aplikacji i przechwycony przez model kondycji na potrzeby reprezentacji operacyjnej.

• Zaimplementuj buforowanie dla scenariuszy danych "gorąca", aby zminimalizować czas odpowiedzi.

  • Zastosuj odpowiednie zasady dotyczące wygasania pamięci podręcznej i utrzymania domu, aby uniknąć wzrostu danych ucieczki.
    • Wygasanie elementów pamięci podręcznej po zmianie danych zapasowych.
    • Jeśli wygaśnięcie pamięci podręcznej jest ściśle oparte na czasie wygaśnięcia (TTL), należy zrozumieć wpływ i doświadczenie klienta w obsłudze nieaktualnych danych.

Odmiana

• Zgodnie z zasadą projektowania chmurowego i natywnego dla platformy Azure zdecydowanie zaleca się ustalanie priorytetów zarządzanych usług platformy Azure w celu zmniejszenia złożoności operacyjnej i zarządzania oraz wykorzystania przyszłych inwestycji w platformę Microsoft.

• Zgodnie z zasadą projektowania aplikacji luźno powiązane architektury mikrousług umożliwiają poszczególnym usługom korzystanie z odrębnych magazynów danych i zoptymalizowanych pod kątem scenariusza technologii danych.

  • Zidentyfikuj typy struktury danych, które aplikacja będzie obsługiwać w określonych scenariuszach obciążeń.
  • Unikaj tworzenia zależności od pojedynczego monolitycznego magazynu danych.
    • Rozważ wzorzec projektowania SAGA, w którym istnieją zależności między magazynami danych.

• Sprawdź, czy wymagane możliwości są dostępne dla wybranych technologii danych.

  • Zapewnij obsługę wymaganych języków i możliwości zestawu SDK. Nie każda funkcja jest dostępna dla każdego języka/zestawu SDK w taki sam sposób.

Prawdziwości

• Wdrożenie projektu i dystrybucji replik danych w wielu regionach w celu zapewnienia maksymalnej niezawodności, dostępności i wydajności dzięki przeniesieniu danych bliżej punktów końcowych aplikacji.

  • Dystrybuuj repliki danych między Strefy dostępności (AZ) w regionie (lub użyj warstw usług strefowo nadmiarowych), aby zmaksymalizować dostępność wewnątrz regionu.

• Jeśli zezwalają na to wymagania dotyczące spójności, użyj projektu platformy danych zapisu w wielu regionach, aby zmaksymalizować ogólną dostępność i niezawodność.

  • Rozważ wymagania biznesowe dotyczące rozwiązywania konfliktów, gdy ten sam element danych jest zmieniany w dwóch oddzielnych replikach zapisu, zanim każda zmiana może zostać zreplikowana, a tym samym konflikt.
    • Używaj ustandaryzowanych zasad rozwiązywania konfliktów, takich jak "Ostatnie zwycięstwo", jeśli to możliwe
      • Jeśli wymagana jest strategia niestandardowa z logiką niestandardową, upewnij się, że praktyki devops ciągłej integracji/ciągłego wdrażania są stosowane do zarządzania logiką niestandardową.

• Przetestuj i zweryfikuj możliwości tworzenia kopii zapasowych i przywracania oraz operacje trybu failover za pomocą testowania chaosu w ramach procesów ciągłego dostarczania.

• Uruchamianie testów porównawczych wydajności w celu zapewnienia, że wymagania dotyczące przepływności i wydajności nie mają wpływu na włączenie wymaganych funkcji zabezpieczeń, takich jak szyfrowanie.

  • Upewnij się, że procesy ciągłego dostarczania uwzględniają testowanie obciążenia względem znanych testów porównawczych wydajności.

• Podczas stosowania szyfrowania zdecydowanie zaleca się używanie kluczy szyfrowania zarządzanych przez usługę jako sposób zmniejszenia złożoności zarządzania.

  • Jeśli istnieje określone wymaganie dotyczące zabezpieczeń kluczy zarządzanych przez klienta, upewnij się, że zastosowano odpowiednie procedury zarządzania kluczami w celu zapewnienia dostępności, tworzenia kopii zapasowych i rotacji wszystkich uwzględnionych kluczy.

Uwaga

Podczas integrowania z szerszą implementacją organizacyjną kluczowe jest zastosowanie podejścia skoncentrowanego na aplikacji na potrzeby aprowizacji i działania składników platformy danych w projekcie aplikacji.

Mówiąc dokładniej, aby zmaksymalizować niezawodność, ważne jest, aby poszczególne składniki platformy danych odpowiednio reagowały na kondycję aplikacji za pomocą akcji operacyjnych, które mogą obejmować inne składniki aplikacji. Na przykład w scenariuszu, w którym potrzebne są dodatkowe zasoby platformy danych, skalowanie platformy danych wraz z innymi składnikami aplikacji zgodnie z modelem pojemności prawdopodobnie będzie wymagane, potencjalnie poprzez aprowizowanie dodatkowych jednostek skalowania. Takie podejście zostanie ostatecznie ograniczone, jeśli istnieje trudna zależność od scentralizowanego zespołu operacji w celu rozwiązania problemów związanych z platformą danych w izolacji.

Ostatecznie korzystanie ze scentralizowanych usług danych (czyli centralnych usług IT DBaaS) wprowadza wąskie gardła operacyjne, które znacząco utrudniają elastyczność w dużej mierze nietekstualizowane środowisko zarządzania i należy unikać ich w kontekście krytycznym lub krytycznym dla działania firmy.

Dodatkowa dokumentacja

Dodatkowe wskazówki dotyczące platformy danych są dostępne w przewodniku po architekturze aplikacja systemu Azure.

• Drzewo decyzyjne magazynu danych platformy Azure
• Kryteria wybierania magazynu danych
• Magazyny danych nierelacyjnych
• Relacyjne magazyny danych OLTP

Rozproszony globalnie magazyn danych zapisu w wielu regionach

Aby w pełni pomieścić globalnie rozproszone aktywne-aktywne aspiracje projektu aplikacji, zdecydowanie zaleca się rozważenie rozproszonej wieloregionowej platformy danych zapisu, gdzie zmiany w oddzielnych replikach zapisywalnych są synchronizowane i scalane między wszystkimi replikami, z rozwiązaniem konfliktów, jeśli jest to wymagane.

Ważne

Mikrousługi mogą nie wymagać rozproszonego magazynu danych zapisu w wielu regionach, dlatego należy wziąć pod uwagę kontekst architektury i wymagania biznesowe każdego scenariusza obciążenia.

Usługa Azure Cosmos DB udostępnia globalnie rozproszony i wysoce dostępny magazyn danych NoSQL, oferując zapisy w wielu regionach i możliwość dostosowania spójności gotowe do użycia. Zagadnienia i zalecenia dotyczące projektowania w tej sekcji skoncentrują się zatem na optymalnym użyciu usługi Azure Cosmos DB.

Uwagi dotyczące projektowania

Azure Cosmos DB

• Usługa Azure Cosmos DB przechowuje dane w kontenerach, które są indeksowane magazynami transakcyjnymi opartymi na wierszach, które umożliwiają szybkie operacje odczytu transakcyjnego i zapisu z czasem odpowiedzi w kolejności milisekund.

• Usługa Azure Cosmos DB obsługuje wiele różnych interfejsów API z różnymi zestawami funkcji, takimi jak SQL, Cassandra i MongoDB.

  • Pierwszy zestaw funkcji usługi Azure Cosmos DB for NoSQL zapewnia najbogatszy zestaw funkcji i jest zazwyczaj interfejsem API, w którym nowe funkcje staną się dostępne jako pierwsze.

• Usługa Azure Cosmos DB obsługuje tryby bramy i łączności bezpośredniej, w których funkcja Direct ułatwia łączność za pośrednictwem protokołu TCP z węzłami repliki usługi Azure Cosmos DB w celu zwiększenia wydajności przy mniejszej liczbie przeskoków sieciowych, a brama zapewnia łączność HTTPS z węzłami bramy frontonu.

  • Tryb bezpośredni jest dostępny tylko w przypadku korzystania z usługi Azure Cosmos DB for NoSQL i jest obecnie obsługiwany tylko na platformach .NET i Java SDK.

• W regionach z obsługą strefy dostępności usługa Azure Cosmos DB oferuje obsługę nadmiarowości strefy dostępności (AZ) w celu zapewnienia wysokiej dostępności i odporności na awarie strefowe w regionie.

• Usługa Azure Cosmos DB obsługuje cztery repliki danych w jednym regionie, a po włączeniu nadmiarowości strefy dostępności (AZ) usługa Azure Cosmos DB zapewnia umieszczenie replik danych w wielu strefach dostępności w celu ochrony przed awariami strefowymi.

  • Protokół konsensusu Paxos jest stosowany do osiągnięcia kworum między replikami w regionie.

• Konto usługi Azure Cosmos DB można łatwo skonfigurować tak, aby replikować dane w wielu regionach w celu ograniczenia ryzyka niedostępności jednego regionu.

  • Replikację można skonfigurować przy użyciu operacji zapisu w jednym regionie lub zapisu w wielu regionach.
    • W przypadku zapisu w jednym regionie podstawowy region "centrum" jest używany do obsługi wszystkich zapisów, a jeśli ten region "hub" stanie się niedostępny, operacja trybu failover musi zostać wykonana w celu podwyższenia poziomu innego regionu jako zapisywalnego.
    • Dzięki zapisom w wielu regionach aplikacje mogą zapisywać dane w dowolnym skonfigurowanym regionie wdrażania, co spowoduje replikowanie zmian między wszystkimi innymi regionami. Jeśli region jest niedostępny, pozostałe regiony będą używane do obsługi ruchu zapisu.

• W konfiguracji zapisu w wielu regionach konflikty aktualizacji (wstawianie, zastępowanie, usuwanie) mogą wystąpić, gdy składniki zapisywania jednocześnie aktualizują ten sam element w wielu regionach.

• Usługa Azure Cosmos DB udostępnia dwie zasady rozwiązywania konfliktów, które można stosować do automatycznego rozwiązywania konfliktów.

  • Funkcja Last Write Wins (LWW) stosuje protokół zegara synchronizacji czasowej przy użyciu właściwości znacznika _ts czasu zdefiniowanego przez system jako ścieżki rozwiązywania konfliktów. Jeśli element o najwyższej wartości dla ścieżki rozwiązywania konfliktów stanie się zwycięzcą, a jeśli wiele elementów ma tę samą wartość liczbową, system wybierze zwycięzcę, aby wszystkie regiony mogły zbiegać się z tą samą wersją zatwierdzonego elementu.
    • W przypadku konfliktów usuwania usunięta wersja zawsze wygrywa konflikty wstawiania lub zastępowania niezależnie od wartości ścieżki rozwiązywania konfliktów.
    • Ostatni zapis wygrywa to domyślne zasady rozwiązywania konfliktów.
    • W przypadku korzystania z usługi Azure Cosmos DB for NoSQL niestandardowa właściwość liczbowa, taka jak niestandardowa definicja znacznika czasu, może służyć do rozwiązywania konfliktów.
  • Niestandardowe zasady rozwiązywania umożliwiają semantyka zdefiniowana przez aplikację w celu uzgadniania konfliktów przy użyciu zarejestrowanej procedury składowanej scalania, która jest automatycznie wywoływana w przypadku wykrycia konfliktów.
    • System zapewnia dokładnie raz gwarancję wykonania procedury scalania w ramach protokołu zobowiązania.
    • Niestandardowe zasady rozwiązywania konfliktów są dostępne tylko w usłudze Azure Cosmos DB for NoSQL i można je ustawić tylko w czasie tworzenia kontenera.

• W konfiguracji zapisu w wielu regionach istnieje zależność od jednego regionu "centrum" usługi Azure Cosmos DB w celu wykonania wszystkich rozwiązań konfliktów, a protokół konsensusu Paxos zastosowany w celu osiągnięcia kworum między replikami w regionie centrum.

  • Platforma udostępnia bufor komunikatów dla konfliktów zapisu w regionie centrum w celu załadowania poziomu i zapewnia nadmiarowość błędów przejściowych.
    • Bufor może przechowywać kilka minut wartych zapisu aktualizacji wymagających konsensusu.

Strategicznym kierunkiem platformy Azure Cosmos DB jest usunięcie tej pojedynczej zależności regionu na potrzeby rozwiązywania konfliktów w konfiguracji zapisu w wielu regionach przy użyciu 2-fazowego podejścia Paxos w celu uzyskania kworum na poziomie globalnym i w obrębie regionu.

• Podstawowy region "centrum" jest określany przez pierwszy region skonfigurowany przez usługę Azure Cosmos DB.

  • Kolejność priorytetu jest skonfigurowana dla dodatkowych regionów wdrażania satelitarnego na potrzeby trybu failover.

• Model danych i partycjonowanie w partycjach logicznych i fizycznych odgrywa ważną rolę w osiągnięciu optymalnej wydajności i dostępności.

• Po wdrożeniu przy użyciu jednego regionu zapisu usługę Azure Cosmos DB można skonfigurować do automatycznego przejścia w tryb failover na podstawie zdefiniowanego priorytetu trybu failover , biorąc pod uwagę wszystkie repliki regionów odczytu.

• Cel czasu odzyskiwania zapewniany przez platformę Azure Cosmos DB wynosi około 10–15 minut, przechwytując czas, który upłynął do wykonania regionalnego przejścia w tryb failover usługi Azure Cosmos DB, jeśli katastrofalna awaria wpływa na region centrum.

  • Ten cel czasu odzyskiwania jest również istotny w kontekście zapisu w wielu regionach, biorąc pod uwagę zależność od jednego regionu "centrum" na potrzeby rozwiązywania konfliktów.
    • Jeśli region "hub" stanie się niedostępny, zapisy dokonane w innych regionach nie powiedzą się po wypełnieniu buforu komunikatów, ponieważ rozwiązanie konfliktów nie będzie mogło wystąpić, dopóki usługa nie przejdzie w tryb failover i zostanie ustanowiony nowy region centrum.

Strategicznym kierunkiem platformy usługi Azure Cosmos DB jest zmniejszenie celu czasu odzyskiwania do około 5 minut przez zezwolenie na przejście w tryb failover na poziomie partycji.

• Cele punktu odzyskiwania (RPO) i cele czasu odzyskiwania (RTO) można konfigurować za pomocą poziomów spójności, z kompromisem między trwałością danych i przepływnością.

  • Usługa Azure Cosmos DB zapewnia minimalny cel czasu odzyskiwania wynoszący 0 dla złagodzonego poziomu spójności z zapisami w wielu regionach lub celu punktu odzyskiwania o wartości 0 w celu zapewnienia silnej spójności z regionem pojedynczego zapisu.

• Usługa Azure Cosmos DB oferuje umowę SLA na 99,999% dla dostępności odczytu i zapisu dla kont baz danych skonfigurowanych z wieloma regionami platformy Azure jako zapisywalnymi.

  • Umowa SLA jest reprezentowana przez wartość procentową miesięcznego czasu pracy, która jest obliczana jako 100% — średni współczynnik błędów.
  • Średni współczynnik błędów jest definiowany jako suma stawek błędów dla każdej godziny w miesiącu rozliczeniowym podzielonym przez łączną liczbę godzin w miesiącu rozliczeniowym, gdzie współczynnik błędów to łączna liczba żądań zakończonych niepowodzeniem podzielona przez łączną liczbę żądań w danym interwale jednogodzinnym.

• Usługa Azure Cosmos DB oferuje umowę SLA na poziomie 99,99% dla przepływności, spójności, dostępności i opóźnień dla kont bazy danych w zakresie jednego regionu świadczenia usługi Azure, jeśli jest skonfigurowany przy użyciu dowolnego z pięciu poziomów spójności.

  • Umowa SLA na poziomie 99,99% dotyczy również kont baz danych obejmujących wiele regionów platformy Azure skonfigurowanych przy użyciu dowolnego z czterech zrelaksowanych poziomów spójności.

• Istnieją dwa typy przepływności, które można aprowizować w usłudze Azure Cosmos DB, w warstwie Standardowa i Autoskalowanie, które są mierzone przy użyciu jednostek żądań na sekundę (RU/s).

  • Przepływność Standardowa przydziela zasoby wymagane do zagwarantowania określonej wartości RU/s.
    • Standardowa jest rozliczana godzinowo dla aprowizowanej przepływności.
  • Autoskalowanie definiuje maksymalną wartość przepływności, a usługa Azure Cosmos DB będzie automatycznie skalować w górę lub w dół w zależności od obciążenia aplikacji między maksymalną wartością przepływności a co najmniej 10% maksymalnej wartości przepływności.
    • Automatyczne skalowanie jest rozliczane godzinowo za maksymalną zużytą przepływność.

• Statyczna aprowizowana przepływność ze zmiennym obciążeniem może spowodować błędy ograniczania przepustowości, co wpłynie na postrzeganą dostępność aplikacji.

  • Skalowanie automatyczne chroni przed błędami ograniczania przepustowości, umożliwiając usłudze Azure Cosmos DB skalowanie w górę zgodnie z potrzebami, zachowując ochronę kosztów przez skalowanie z powrotem w dół po zmniejszeniu obciążenia.

• Gdy usługa Azure Cosmos DB jest replikowana w wielu regionach, aprowizowane jednostki żądań (RU) są rozliczane w poszczególnych regionach.

• Istnieje znaczna różnica kosztów między konfiguracją zapisu w wielu regionach i zapisem w jednym regionie, która w wielu przypadkach może spowodować, że koszt wielowzorcowej platformy danych usługi Azure Cosmos DB jest zbyt duży.

Odczyt/zapis w jednym regionie	Zapis w jednym regionie — odczyt w dwóch regionach	Odczyt/zapis w dwóch regionach
1 RU	2 RU	4 RU

Różnica między zapisem w jednym regionie i zapisem w wielu regionach jest faktycznie mniejsza niż współczynnik 1:2 odzwierciedlone w powyższej tabeli. W szczególności istnieje opłata za transfer danych między regionami skojarzona z aktualizacjami zapisu w konfiguracji pojedynczego zapisu, która nie jest przechwytywana w ramach kosztów jednostek RU, tak jak w przypadku konfiguracji zapisu w wielu regionach.

• Zużyte miejsce do magazynowania jest rozliczane jako stawka płaska dla całkowitej ilości miejsca do magazynowania (GB) używanego do hostowania danych i indeksów przez daną godzinę.

• Session jest domyślnym i najczęściej używanym poziomem spójności, ponieważ dane są odbierane w tej samej kolejności co zapisy.

• Usługa Azure Cosmos DB obsługuje uwierzytelnianie za pośrednictwem tożsamości entra firmy Microsoft lub kluczy usługi Azure Cosmos DB i tokenów zasobów, które zapewniają nakładające się możliwości.

• Można wyłączyć operacje zarządzania zasobami przy użyciu kluczy lub tokenów zasobów, aby ograniczyć klucze i tokeny zasobów tylko do operacji danych, co pozwala na precyzyjną kontrolę dostępu do zasobów przy użyciu kontroli dostępu opartej na rolach (RBAC) firmy Microsoft.

  • Ograniczenie dostępu do płaszczyzny sterowania za pośrednictwem kluczy lub tokenów zasobów spowoduje wyłączenie operacji płaszczyzny sterowania dla klientów korzystających z zestawów SDK usługi Azure Cosmos DB i dlatego należy je dokładnie ocenić i przetestować.
  • Ustawienie disableKeyBasedMetadataWriteAccess można skonfigurować za pomocą definicji IaC szablonu usługi ARM lub wbudowanej usługi Azure Policy.

• Obsługa kontroli dostępu opartej na rolach firmy Microsoft w usłudze Azure Cosmos DB dotyczy operacji zarządzania płaszczyzną kontroli zasobów i kont.

  • Administratorzy aplikacji mogą tworzyć przypisania ról dla użytkowników, grup, jednostek usługi lub tożsamości zarządzanych w celu udzielenia lub odmowy dostępu do zasobów i operacji w zasobach usługi Azure Cosmos DB.
  • Istnieje kilka wbudowanych ról RBAC dostępnych do przypisania ról, a niestandardowe role RBAC mogą być również używane do tworzenia określonych kombinacji uprawnień.
    • Czytelnik konta usługi Cosmos DB umożliwia dostęp tylko do odczytu do zasobu usługi Azure Cosmos DB.
    • Współautor konta usługi DocumentDB umożliwia zarządzanie kontami usługi Azure Cosmos DB, w tym kluczami i przypisaniami ról, ale nie umożliwia dostępu do płaszczyzny danych.
    • Operator usługi Cosmos DB, który jest podobny do współautora konta usługi DocumentDB, ale nie zapewnia możliwości zarządzania kluczami ani przypisaniami ról.

• Zasoby usługi Azure Cosmos DB (konta, bazy danych i kontenery) mogą być chronione przed niepoprawnymi modyfikacjami lub usunięciem przy użyciu blokad zasobów.

  • Blokady zasobów można ustawić na poziomie konta, bazy danych lub kontenera.
  • Blokada zasobu ustawiona na poziomie zasobu będzie dziedziczona przez wszystkie zasoby podrzędne. Na przykład blokada zasobu ustawiona na koncie usługi Azure Cosmos DB będzie dziedziczona przez wszystkie bazy danych i kontenery w ramach konta.
  • Blokady zasobów mają zastosowanie tylko do operacji płaszczyzny sterowania i nie uniemożliwiają operacji płaszczyzny danych, takich jak tworzenie, zmienianie lub usuwanie danych.
  • Jeśli dostęp do płaszczyzny sterowania nie jest ograniczony przy disableKeyBasedMetadataWriteAccessużyciu programu , klienci będą mogli wykonywać operacje płaszczyzny sterowania przy użyciu kluczy kont.

• Źródło zmian usługi Azure Cosmos DB udostępnia uporządkowane czasowo źródło zmian danych w kontenerze usługi Azure Cosmos DB.

  • Źródło zmian obejmuje tylko operacje wstawiania i aktualizowania do źródłowego kontenera usługi Azure Cosmos DB; nie zawiera usunięcia.

• Kanał informacyjny zmian może służyć do obsługi oddzielnego magazynu danych od podstawowego kontenera używanego przez aplikację, a bieżące aktualizacje docelowego magazynu danych przekazywanego przez źródło danych z kontenera źródłowego.

  • Źródło zmian może służyć do wypełniania pomocniczego magazynu w celu zapewnienia dodatkowej nadmiarowości platformy danych lub kolejnych scenariuszy analitycznych.

• Jeśli operacje usuwania rutynowo wpływają na dane w ramach źródłowego kontenera, magazyn karmiony przez zestawienie zmian będzie niedokładny i nierefleksyjny usuniętych danych.

  • Wzorzec usuwania nietrwałego można zaimplementować, aby rekordy danych były uwzględniane w kanale informacyjnym zmian.
    • Zamiast jawnie usuwać rekordy danych, rekordy danych są aktualizowane przez ustawienie flagi (np. IsDeleted) w celu wskazania, że element jest uznawany za usunięty.
    • Każdy docelowy magazyn danych karmiony przez źródło zmian będzie musiał wykrywać i przetwarzać elementy z usuniętą flagą ustawioną na true; zamiast przechowywać rekordy danych usuniętych nietrwale, należy usunąć istniejącą wersję rekordu danych w magazynie docelowym.
  • Krótki czas wygaśnięcia (TTL) jest zwykle używany ze wzorcem usuwania nietrwałego, dzięki czemu usługa Azure Cosmos DB automatycznie usuwa wygasłe dane, ale dopiero po ich odzwierciedleniu w kanale zmian z usuniętą flagą ustawioną na true.
    • Wykonuje oryginalną intencję usuwania, a jednocześnie propaguje usunięcie za pośrednictwem zestawienia zmian.

• Usługę Azure Cosmos DB można skonfigurować jako magazyn analityczny, który stosuje format kolumny do zoptymalizowanych zapytań analitycznych, aby sprostać wyzwaniom związanym ze złożonością i opóźnieniami występującymi w tradycyjnych potokach ETL.

• Usługa Azure Cosmos DB automatycznie wykonuje kopie zapasowe danych w regularnych odstępach czasu bez wpływu na wydajność lub dostępność oraz bez korzystania z jednostek RU/s.

• Usługę Azure Cosmos DB można skonfigurować zgodnie z dwoma odrębnymi trybami tworzenia kopii zapasowych.

  • Okresowy jest domyślnym trybem tworzenia kopii zapasowych dla wszystkich kont, w którym kopie zapasowe są wykonywane w okresowym odstępie czasu, a dane są przywracane przez utworzenie żądania z zespołem pomocy technicznej.
    • Domyślny okres okresowy okres przechowywania kopii zapasowych wynosi osiem godzin, a domyślny interwał tworzenia kopii zapasowych to cztery godziny, co oznacza, że domyślnie są przechowywane tylko dwie najnowsze kopie zapasowe.
    • Interwał tworzenia kopii zapasowych i okres przechowywania można skonfigurować w ramach konta.
      • Maksymalny okres przechowywania wynosi miesiąc z minimalnym interwałem tworzenia kopii zapasowych wynoszącym jedną godzinę.
      • Aby skonfigurować nadmiarowość magazynu kopii zapasowych, wymagane jest przypisanie roli do roli czytelnika konta usługi Azure Cosmos DB.
    • Dwie kopie zapasowe są uwzględniane bez dodatkowych kosztów, ale dodatkowe kopie zapasowe generują dodatkowe koszty.
    • Domyślnie okresowe kopie zapasowe są przechowywane w oddzielnym magazynie geograficznie nadmiarowym (GRS), który nie jest bezpośrednio dostępny.
      • Magazyn kopii zapasowych istnieje w regionie podstawowym "centrum" i jest replikowany do sparowanego regionu za pomocą podstawowej replikacji magazynu.
      • Konfiguracja nadmiarowości bazowego konta magazynu kopii zapasowych można skonfigurować do magazynu strefowo nadmiarowego lub magazynu lokalnie nadmiarowego.
    • Wykonanie operacji przywracania wymaga żądania pomocy technicznej, ponieważ klienci nie mogą bezpośrednio wykonać przywracania.
      • Przed otwarciem biletu pomocy technicznej okres przechowywania kopii zapasowej powinien zostać zwiększony do co najmniej siedmiu dni w ciągu ośmiu godzin od zdarzenia utraty danych.
    • Operacja przywracania tworzy nowe konto usługi Azure Cosmos DB, na którym dane są odzyskiwane.
      • Nie można użyć istniejącego konta usługi Azure Cosmos DB do przywracania
      • Domyślnie będzie używane nowe konto usługi Azure Cosmos DB o nazwie <Azure_Cosmos_account_original_name>-restored<n> .
        • Tę nazwę można dostosować, na przykład przez ponowne użycie istniejącej nazwy, jeśli oryginalne konto zostało usunięte.
    • Jeśli przepływność jest aprowizowana na poziomie bazy danych, tworzenie kopii zapasowych i przywracanie nastąpi na poziomie bazy danych
      • Nie można wybrać podzbioru kontenerów do przywrócenia.
  • Tryb ciągłej kopii zapasowej umożliwia przywracanie do dowolnego punktu w ciągu ostatnich 30 dni.
    • Operacje przywracania można wykonać, aby powrócić do określonego punktu w czasie (PITR) z jednosekundowym szczegółowością.
    • Dostępne okno dla operacji przywracania wynosi do 30 dni.
      • Można również przywrócić stan wystąpienia zasobu.
    • Ciągłe kopie zapasowe są wykonywane w każdym regionie świadczenia usługi Azure, w którym istnieje konto usługi Azure Cosmos DB.
      • Ciągłe kopie zapasowe są przechowywane w tym samym regionie świadczenia usługi Azure co każda replika usługi Azure Cosmos DB przy użyciu magazynu lokalnie nadmiarowego (LRS) lub magazynu strefowo nadmiarowego (ZRS) w regionach obsługujących Strefy dostępności.
    • Przywracanie samoobsługowe można wykonać przy użyciu witryny Azure Portal lub artefaktów IaC, takich jak szablony usługi ARM.
    • Istnieje kilka ograniczeń dotyczących ciągłej kopii zapasowej.
      • Tryb ciągłej kopii zapasowej nie jest obecnie dostępny w konfiguracji zapisu w wielu regionach.
      • W tej chwili można skonfigurować tylko usługę Azure Cosmos DB dla baz danych NoSQL i Azure Cosmos DB dla bazy danych MongoDB na potrzeby ciągłej kopii zapasowej.
      • Jeśli kontener ma skonfigurowany czas wygaśnięcia, przywrócone dane, które przekroczyły czas wygaśnięcia, mogą zostać natychmiast usunięte
    • Operacja przywracania tworzy nowe konto usługi Azure Cosmos DB na potrzeby przywracania do punktu w czasie.
    • Istnieje dodatkowy koszt magazynowania dla operacji ciągłego tworzenia kopii zapasowych i przywracania.

• Istniejące konta usługi Azure Cosmos DB można migrować z okresowego do ciągłego, ale nie z ciągłego do okresowego; migracja jest jednokierunkowa i nie jest odwracalna.

• Każda kopia zapasowa usługi Azure Cosmos DB składa się z samych danych i szczegółów konfiguracji dla aprowizowanej przepływności, zasad indeksowania, regionów wdrażania i ustawień czasu wygaśnięcia kontenera.

  • Kopie zapasowe nie zawierają ustawień zapory, list kontroli dostępu do sieci wirtualnej, ustawień prywatnego punktu końcowego, ustawień spójności (konto jest przywracane ze spójnością sesji), procedur składowanych, wyzwalaczy, funkcji zdefiniowanych przez użytkownika lub ustawień wielu regionów.
    • Klienci są odpowiedzialni za ponowne wdrażanie możliwości i ustawień konfiguracji. Nie są one przywracane za pośrednictwem kopii zapasowej usługi Azure Cosmos DB.
  • Dane magazynu analitycznego usługi Azure Synapse Link nie są również uwzględniane w kopiach zapasowych usługi Azure Cosmos DB.

• Istnieje możliwość zaimplementowania niestandardowej funkcji tworzenia i przywracania kopii zapasowych w scenariuszach, w których podejścia okresowe i ciągłe nie są odpowiednie.

  • Podejście niestandardowe wprowadza znaczne koszty i dodatkowe nakłady administracyjne, które należy zrozumieć i starannie ocenić.
    • Typowe scenariusze przywracania powinny być modelowane, takie jak uszkodzenie lub usunięcie konta, bazy danych, kontenera na elemencie danych.
    • Należy wdrożyć procedury sprzątania, aby zapobiec rozrastaniu kopii zapasowych.
  • Można użyć usługi Azure Storage lub alternatywnej technologii danych, takiej jak alternatywny kontener usługi Azure Cosmos DB.
    • Usługi Azure Storage i Azure Cosmos DB zapewniają natywną integrację z usługami platformy Azure, takimi jak Azure Functions i Azure Data Factory.

• Dokumentacja usługi Azure Cosmos DB określa dwie potencjalne opcje implementowania niestandardowych kopii zapasowych.

  • Zestawienie zmian usługi Azure Cosmos DB umożliwia zapisywanie danych w oddzielnym magazynie.
    • Funkcja platformy Azure lub równoważny proces aplikacji używa procesora zestawienia zmian do powiązania ze źródłem zmian i przetwarzania elementów do magazynu.
  • Zarówno ciągłe, jak i okresowe (wsadowe) niestandardowe kopie zapasowe można zaimplementować przy użyciu zestawienia zmian.
  • Źródło zmian usługi Azure Cosmos DB nie odzwierciedla jeszcze usuwania, dlatego należy zastosować wzorzec usuwania nietrwałego przy użyciu właściwości logicznej i czasu wygaśnięcia.
    • Ten wzorzec nie będzie wymagany, gdy źródło zmian zapewnia aktualizacje pełnej wierności.
  • Łącznik usługi Azure Data Factory dla usługi Azure Cosmos DB (łączniki interfejsu API NoSQL lub MongoDB) usługi Azure Cosmos DB do kopiowania danych.
    • Usługa Azure Data Factory (ADF) obsługuje ręczne wykonywanie i harmonogram, okno wirowania i wyzwalacze oparte na zdarzeniach.
      • Zapewnia obsługę zarówno usługi Storage, jak i Event Grid.
    • Usługa ADF jest odpowiednia głównie do okresowych niestandardowych implementacji kopii zapasowych ze względu na aranżację zorientowaną na partie.
      • Mniej nadaje się do ciągłej implementacji kopii zapasowych z częstymi zdarzeniami ze względu na obciążenie związane z wykonywaniem orkiestracji.
    • Usługa ADF obsługuje usługę Azure Private Link na potrzeby scenariuszy zabezpieczeń sieci o wysokim poziomie

Usługa Azure Cosmos DB jest używana w projekcie wielu usług platformy Azure, więc znaczna awaria regionalna usługi Azure Cosmos DB będzie miała wpływ kaskadowy na różne usługi platformy Azure w tym regionie. Dokładny wpływ na określoną usługę będzie w dużym stopniu zależeć od tego, jak projekt podstawowej usługi korzysta z usługi Azure Cosmos DB.

Zalecenia dotyczące projektowania

Azure Cosmos DB

• Użyj usługi Azure Cosmos DB jako podstawowej platformy danych, na której są dozwolone wymagania.

• W przypadku scenariuszy obciążeń o krytycznym znaczeniu skonfiguruj usługę Azure Cosmos DB z repliką zapisu w każdym regionie wdrażania, aby zmniejszyć opóźnienie i zapewnić maksymalną nadmiarowość.

  • Skonfiguruj aplikację, aby określić priorytety użycia lokalnej repliki usługi Azure Cosmos DB na potrzeby zapisów i odczytów, aby zoptymalizować obciążenie aplikacji, wydajność i użycie regionalnych jednostek RU/s.
  • Konfiguracja zapisu w wielu regionach wiąże się ze znacznym kosztem i powinna być priorytetowa tylko w przypadku scenariuszy obciążeń wymagających maksymalnej niezawodności.

• W przypadku scenariuszy obciążeń o mniejszym znaczeniu należy określić priorytety użycia konfiguracji zapisu w jednym regionie (w przypadku używania Strefy dostępności) z globalnie rozproszonymi replikami do odczytu, ponieważ zapewnia to wysoki poziom niezawodności platformy danych (umowa SLA na poziomie 99,999% dla odczytu, 99,995% umowa SLA dla operacji zapisu) w bardziej atrakcyjnym punkcie cenowym.

  • Skonfiguruj aplikację tak, aby korzystała z lokalnej repliki do odczytu usługi Azure Cosmos DB w celu zoptymalizowania wydajności odczytu.

• Wybierz optymalny region wdrożenia "centrum", w którym będzie występować rozwiązywanie konfliktów w konfiguracji zapisu w wielu regionach, a wszystkie operacje zapisu będą wykonywane w konfiguracji zapisu w jednym regionie.

  • Rozważ odległość względem innych regionów wdrażania i skojarzone opóźnienie podczas wybierania regionu podstawowego oraz wymagane możliwości, takie jak obsługa Strefy dostępności.

• Skonfiguruj nadmiarowość usługi Azure Cosmos DB ze strefą dostępności (AZ) we wszystkich regionach wdrażania z obsługą az, aby zapewnić odporność na awarie strefowe w regionie.

• Użyj usługi Azure Cosmos DB for NoSQL, ponieważ oferuje ona najbardziej kompleksowy zestaw funkcji, szczególnie w przypadku, gdy dotyczy to dostrajania wydajności.

  • Alternatywne interfejsy API powinny być brane pod uwagę głównie w przypadku scenariuszy migracji lub zgodności.
    • W przypadku korzystania z alternatywnych interfejsów API sprawdź, czy wymagane możliwości są dostępne w wybranym języku i zestawie SDK, aby zapewnić optymalną konfigurację i wydajność.

• Użyj trybu połączenia bezpośredniego, aby zoptymalizować wydajność sieci poprzez bezpośrednią łączność TCP z węzłami usługi Azure Cosmos DB zaplecza z ograniczoną liczbą przeskoków sieciowych.

Umowa SLA usługi Azure Cosmos DB jest obliczana przez średnio nieudane żądania, które mogą nie być bezpośrednio zgodne z budżetem błędów warstwy niezawodności na poziomie 99,999%. Podczas projektowania celu slo na poziomie 99,999% ważne jest zatem zaplanowanie regionalnej i wieloregionowej niedostępności zapisu w usłudze Azure Cosmos DB, zapewniając, że rezerwowa technologia magazynu jest umieszczona w przypadku awarii, takiej jak utrwalona kolejka komunikatów na potrzeby późniejszego odtwarzania.

• Zdefiniuj strategię partycjonowania zarówno na partycjach logicznych, jak i fizycznych, aby zoptymalizować dystrybucję danych zgodnie z modelem danych.

  • Zminimalizuj liczbę zapytań między partycjami.
  • Iteracyjne testowanie i weryfikowanie strategii partycjonowania w celu zapewnienia optymalnej wydajności.

• Wybierz optymalny klucz partycji.

  • Nie można zmienić klucza partycji po jego utworzeniu w kolekcji.
  • Klucz partycji powinien być wartością właściwości, która nie zmienia się.
  • Wybierz klucz partycji o wysokiej kardynalności z szerokim zakresem możliwych wartości.
  • Klucz partycji powinien równomiernie rozpowszechniać użycie jednostek RU i magazyn danych we wszystkich partycjach logicznych, aby zapewnić równomierne użycie jednostek RU i dystrybucję magazynu między partycjami fizycznymi.
  • Uruchom zapytania odczytu w kolumnie partycjonowanej, aby zmniejszyć użycie jednostek RU i opóźnienie.

• Indeksowanie ma również kluczowe znaczenie dla wydajności, dlatego upewnij się, że wykluczenia indeksów są używane do zmniejszenia liczby jednostek RU/s i wymagań dotyczących magazynu.

  • Indeksuj tylko te pola, które są potrzebne do filtrowania w zapytaniach; indeksy projektowe dla najczęściej używanych predykatów.

• Skorzystaj z wbudowanych możliwości obsługi błędów, ponawiania prób i szerszej niezawodności zestawu SDK usługi Azure Cosmos DB.

  • Zaimplementuj logikę ponawiania prób w ramach zestawu SDK na klientach.

• Użyj kluczy szyfrowania zarządzanych przez usługę, aby zmniejszyć złożoność zarządzania.

  • Jeśli istnieje określone wymaganie dotyczące zabezpieczeń kluczy zarządzanych przez klienta, upewnij się, że są stosowane odpowiednie procedury zarządzania kluczami, takie jak tworzenie kopii zapasowych i rotacja.

• Wyłącz dostęp do zapisu metadanych opartych na kluczach usługi Azure Cosmos DB przez zastosowanie wbudowanej usługi Azure Policy.

• Włącz usługę Azure Monitor , aby zbierać kluczowe metryki i dzienniki diagnostyczne, takie jak aprowizowana przepływność (RU/s).

  • Kierowanie danych operacyjnych usługi Azure Monitor do obszaru roboczego usługi Log Analytics dedykowanego usłudze Azure Cosmos DB i innych zasobów globalnych w projekcie aplikacji.
  • Użyj metryk usługi Azure Monitor, aby określić, czy wzorce ruchu aplikacji są odpowiednie do automatycznego skalowania.

• Oceń wzorce ruchu aplikacji, aby wybrać optymalną opcję dla aprowizowanych typów przepływności.

  • Rozważ automatyczne skalowanie aprowizowanej przepływności, aby automatycznie wyrównać zapotrzebowanie na obciążenie w poziomie.

• Oceń porady dotyczące wydajności firmy Microsoft dla usługi Azure Cosmos DB , aby zoptymalizować konfigurację po stronie klienta i po stronie serwera w celu zwiększenia opóźnienia i przepływności.

• W przypadku korzystania z usługi AKS jako platformy obliczeniowej: w przypadku obciążeń intensywnie korzystających z zapytań wybierz jednostkę SKU węzła usługi AKS z włączoną przyspieszoną siecią, aby zmniejszyć opóźnienia i zakłócenia procesora CPU.

• W przypadku wdrożeń w jednym regionie zapisu zdecydowanie zaleca się skonfigurowanie usługi Azure Cosmos DB na potrzeby automatycznego przejścia w tryb failover.

• Poziom obciążenia dzięki użyciu asynchronicznych komunikatów nieblokujących w przepływach systemowych, które zapisują aktualizacje w usłudze Azure Cosmos DB.

  • Rozważ wzorce, takie jak podział odpowiedzialności poleceń i zapytań oraz określanie źródła zdarzeń.

• Skonfiguruj konto usługi Azure Cosmos DB dla ciągłych kopii zapasowych w celu uzyskania dokładnego stopnia szczegółowości punktów odzyskiwania w ciągu ostatnich 30 dni.

  • Rozważ użycie kopii zapasowych usługi Azure Cosmos DB w scenariuszach, w których zawarte dane lub konto usługi Azure Cosmos DB zostało usunięte lub uszkodzone.
  • Unikaj używania niestandardowego podejścia do tworzenia kopii zapasowych, chyba że jest to absolutnie konieczne.

• Zdecydowanie zaleca się przećwiczenie procedur odzyskiwania na nieprodukcyjnych zasobach i danych w ramach standardowego przygotowania operacji ciągłości działalności biznesowej.

• Zdefiniuj artefakty IaC, aby ponownie ustanowić ustawienia konfiguracji i możliwości przywracania kopii zapasowej usługi Azure Cosmos DB.

• Oceń i zastosuj wskazówki dotyczące kontroli punktu odniesienia zabezpieczeń platformy Azure dla usługi Azure Cosmos DB Backup and Recovery.

  • BR-1: Zapewnienie regularnych automatycznych kopii zapasowych
  • BR-3: Weryfikowanie wszystkich kopii zapasowych, w tym kluczy zarządzanych przez klienta
  • BR-4, Ograniczenie ryzyka utraty kluczy

• W przypadku obciążeń analitycznych wymagających dostępności w wielu regionach użyj magazynu analitycznego usługi Azure Cosmos DB, który stosuje format kolumn dla zoptymalizowanych zapytań analitycznych.

Technologie danych relacyjnych

W przypadku scenariuszy z wysoce relacyjnym modelem danych lub zależnościami w istniejących technologiach relacyjnych użycie usługi Azure Cosmos DB w konfiguracji zapisu w wielu regionach może nie mieć bezpośredniego zastosowania. W takich przypadkach ważne jest, aby używane technologie relacyjne zostały zaprojektowane i skonfigurowane do utrzymania wieloregionowych aktywnych aspiracji projektu aplikacji.

Platforma Azure udostępnia wiele zarządzanych platform danych relacyjnych, w tym usług Azure SQL Database i Azure Database dla typowych rozwiązań relacyjnych systemu operacyjnego, w tym MySQL, PostgreSQL i MariaDB. Zagadnienia i zalecenia dotyczące projektowania w tej sekcji skoncentrują się zatem na optymalnym użyciu smaków usług Azure SQL Database i Azure Database OSS w celu zmaksymalizowania niezawodności i dostępności globalnej.

Uwagi dotyczące projektowania

• Chociaż technologie danych relacyjnych można skonfigurować do łatwego skalowania operacji odczytu, zapisy są zwykle ograniczone do przechodzenia przez pojedyncze wystąpienie podstawowe, co powoduje znaczne ograniczenie skalowalności i wydajności.

• Fragmentowanie można zastosować do dystrybucji danych i przetwarzania w wielu identycznych strukturalnych bazach danych, partycjonując bazy danych w poziomie w celu nawigowania po ograniczeniach platformy.

  • Na przykład fragmentowanie jest często stosowane w wielodostępnych platformach SaaS w celu odizolowania grup dzierżaw w odrębne konstrukcje platformy danych.

Azure SQL Database

• Usługa Azure SQL Database udostępnia w pełni zarządzany aparat bazy danych, który jest zawsze uruchomiony w najnowszej stabilnej wersji aparatu bazy danych programu SQL Server i bazowego systemu operacyjnego.

  • Udostępnia inteligentne funkcje, takie jak dostrajanie wydajności, monitorowanie zagrożeń i oceny luk w zabezpieczeniach.

• Usługa Azure SQL Database zapewnia wbudowaną regionalną wysoką dostępność i gotową replikację geograficzną w celu dystrybucji replik do odczytu w różnych regionach świadczenia usługi Azure.

  • W przypadku replikacji geograficznej pomocnicze repliki bazy danych pozostają tylko do odczytu do momentu zainicjowania trybu failover.
  • W tych samych lub różnych regionach obsługiwane są maksymalnie cztery sekundy.
  • Repliki pomocnicze mogą być również używane do dostępu do zapytań tylko do odczytu w celu zoptymalizowania wydajności odczytu.
  • Przejście w tryb failover należy zainicjować ręcznie, ale można je opakować w zautomatyzowane procedury operacyjne.

• Usługa Azure SQL Database udostępnia grupy automatycznego trybu failover, które replikują bazy danych na serwer pomocniczy i umożliwiają przezroczyste przejście w tryb failover w przypadku awarii.

  • Grupy automatycznego trybu failover obsługują replikację geograficzną wszystkich baz danych w grupie tylko do jednego serwera pomocniczego lub wystąpienia w innym regionie.
  • Grupy automatycznego trybu failover nie są obecnie obsługiwane w warstwie usługi Hiperskala.
  • Pomocnicze bazy danych mogą służyć do odciążania ruchu odczytu.

• Repliki bazy danych w warstwie usługi Premium lub Krytyczne dla działania firmy można dystrybuować między Strefy dostępności bez dodatkowych kosztów.

  • Pierścień kontrolny jest również duplikowany w wielu strefach jako trzy pierścienie bramy (GW).
    • Routing do określonego pierścienia bramy jest kontrolowany przez usługę Azure Traffic Manager.
  • W przypadku korzystania z warstwy Krytyczne dla działania firmy konfiguracja strefowo nadmiarowa jest dostępna tylko po wybraniu sprzętu obliczeniowego Gen5.

• Usługa Azure SQL Database oferuje umowę SLA dotyczącą dostępności na poziomie 99,99% dla wszystkich jej warstw usług, ale zapewnia wyższą umowę SLA na poziomie 99,995% dla warstw Krytyczne dla działania firmy lub Premium w regionach, które obsługują strefy dostępności.

  • Usługa Azure SQL Database Krytyczne dla działania firmy lub warstwy Premium nieskonfigurowane dla wdrożeń strefowo nadmiarowych mają umowę SLA gwarantującą dostępność na poziomie 99,99%.

• Po skonfigurowaniu replikacji geograficznej warstwa usługi Azure SQL Database Krytyczne dla działania firmy zapewnia cel czasu odzyskiwania (RTO) 30 sekund przez 100% wdrożonych godzin.

• Po skonfigurowaniu replikacji geograficznej warstwa usługi Azure SQL Database Krytyczne dla działania firmy ma cel punktu odzyskiwania (RPO) 5 sekund przez 100% wdrożonych godzin.

• Warstwa Hiperskala usługi Azure SQL Database, skonfigurowana z co najmniej dwiema replikami, ma umowę SLA dostępności na poziomie 99,99%.

• Koszty obliczeń skojarzone z usługą Azure SQL Database można zmniejszyć przy użyciu rabatu za rezerwację.

  • Nie można zastosować pojemności zarezerwowanej dla baz danych opartych na jednostkach DTU.

• Przywracanie do punktu w czasie może służyć do zwracania bazy danych i zawartych danych do wcześniejszego punktu w czasie.

• Przywracanie geograficzne może służyć do odzyskiwania bazy danych z geograficznie nadmiarowej kopii zapasowej.

Azure Database For PostgreSQL

• Usługa Azure Database For PostgreSQL jest oferowana w trzech różnych opcjach wdrażania:

  • Pojedynczy serwer, umowa SLA 99,99%
  • Serwer elastyczny, który oferuje nadmiarowość stref dostępności, umowa SLA 99,99%
  • Hiperskala (Citus), umowa SLA 99,95% po włączeniu trybu wysokiej dostępności.

• Hiperskala (Citus) zapewnia dynamiczną skalowalność dzięki fragmentowaniu bez zmian aplikacji.

  • Dystrybucja wierszy tabeli na wielu serwerach PostgreSQL jest kluczem do zapewnienia skalowalnych zapytań w warstwie Hiperskala (Citus).
  • Wiele węzłów może zbiorczo przechowywać więcej danych niż tradycyjna baza danych, a w wielu przypadkach może używać procesorów roboczych równolegle do optymalizowania kosztów.

• Skalowanie automatyczne można skonfigurować za pomocą automatyzacji elementu Runbook w celu zapewnienia elastyczności w odpowiedzi na zmieniające się wzorce ruchu.

• Serwer elastyczny zapewnia efektywność kosztową dla obciążeń nieprodukcyjnych dzięki możliwości zatrzymywania/uruchamiania serwera oraz warstwy obliczeniowej z możliwością zwiększania szybkości, która jest odpowiednia dla obciążeń, które nie wymagają ciągłej pojemności obliczeniowej.

• Za magazyn kopii zapasowych nie są naliczane dodatkowe opłaty za maksymalnie 100% całkowitego zaaprowizowanego magazynu serwera.

  • Dodatkowe użycie magazynu kopii zapasowych jest naliczane zgodnie z użyciem GB/miesiąc.

• Koszty obliczeń skojarzone z usługą Azure Database for PostgreSQL można zmniejszyć przy użyciu rabatu na rezerwację pojedynczego serwera lub rabatu na rezerwację w warstwie Hiperskala (Citus).

Zalecenia dotyczące projektowania

• Rozważ dzielenie na fragmenty relacyjnych baz danych na podstawie różnych kontekstów aplikacji i danych, pomagając nawigować po ograniczeniach platformy, zmaksymalizować skalowalność i dostępność oraz izolację błędów.

  • To zalecenie jest szczególnie powszechne, gdy projekt aplikacji uwzględnia trzy lub więcej regionów świadczenia usługi Azure, ponieważ ograniczenia technologii relacyjnych mogą znacznie utrudniać globalnie rozproszone platformy danych.
  • Fragmentowanie nie jest odpowiednie dla wszystkich scenariuszy aplikacji, dlatego wymagana jest kontekstowa ocena.

• Określanie priorytetów użycia usługi Azure SQL Database, w której istnieją wymagania relacyjne ze względu na jej dojrzałość na platformie Azure i szeroką gamę możliwości niezawodności.

Azure SQL Database

• Użyj warstwy usługi Krytyczne dla działania firmy, aby zmaksymalizować niezawodność i dostępność, w tym dostęp do krytycznych możliwości odporności.

• Użyj modelu zużycia opartego na rdzeniach wirtualnych, aby ułatwić niezależny wybór zasobów obliczeniowych i magazynowych dostosowanych do wymagań dotyczących woluminu obciążenia i przepływności.

  • Upewnij się, że zdefiniowany model pojemności jest stosowany w celu informowania o wymaganiach dotyczących zasobów obliczeniowych i magazynu.
    • Rozważ użycie pojemności zarezerwowanej, aby zapewnić potencjalne optymalizacje kosztów.

• Skonfiguruj model wdrażania strefowo nadmiarowego, aby rozpowszechniać repliki bazy danych Krytyczne dla działania firmy w tym samym regionie w Strefy dostępności.

• Użyj aktywnej replikacji geograficznej, aby wdrożyć repliki z możliwością odczytu we wszystkich regionach wdrażania (do czterech).

• Użyj grup automatycznego trybu failover, aby zapewnić przezroczyste przejście w tryb failover do regionu pomocniczego z replikacją geograficzną zastosowaną w celu zapewnienia replikacji do dodatkowych regionów wdrażania na potrzeby optymalizacji odczytu i nadmiarowości bazy danych.

  • W przypadku scenariuszy aplikacji ograniczonych tylko do dwóch regionów wdrażania należy określić priorytety użycia grup automatycznego trybu failover.

• Rozważ automatyczne wyzwalacze operacyjne oparte na alertach dopasowanych do modelu kondycji aplikacji, aby przeprowadzić przechodzenie w tryb failover do wystąpień replikowanych geograficznie, jeśli awaria ma wpływ na podstawową i pomocniczą grupę automatycznego trybu failover.

Ważne

W przypadku aplikacji, które rozważają więcej niż cztery regiony wdrażania, należy wziąć pod uwagę poważne kwestie dotyczące fragmentowania w zakresie aplikacji lub refaktoryzacji w celu obsługi technologii zapisu w wielu regionach, takich jak usługa Azure Cosmos DB. Jeśli jednak nie jest to możliwe w scenariuszu obciążenia aplikacji, zaleca się podniesienie poziomu regionu w jednej lokalizacji geograficznej do stanu podstawowego obejmującego wystąpienie replikowane geograficznie w celu bardziej równomiernego rozproszonego dostępu do odczytu.

• Skonfiguruj aplikację do wykonywania zapytań dotyczących wystąpień repliki do odczytu w celu zoptymalizowania wydajności odczytu.

• Użyj usług Azure Monitor i Azure SQL Analytics , aby uzyskać szczegółowe informacje operacyjne niemal w czasie rzeczywistym w usłudze Azure SQL DB w celu wykrywania zdarzeń dotyczących niezawodności.

• Użyj usługi Azure Monitor, aby ocenić użycie dla wszystkich baz danych, aby określić, czy zostały one odpowiednio dopasowane.

  • Upewnij się, że potoki ciągłego wdrażania uwzględniają testowanie obciążenia na reprezentatywnych poziomach obciążenia w celu zweryfikowania odpowiedniego zachowania platformy danych.

• Oblicz metrykę kondycji dla składników bazy danych, aby obserwować kondycję w stosunku do wymagań biznesowych i wykorzystania zasobów, używając monitorowania i alertów , aby w razie potrzeby prowadzić zautomatyzowane działania operacyjne.

  • Upewnij się, że kluczowe metryki wydajności zapytań są włączone, aby można było podjąć szybką akcję w przypadku pogorszenia wydajności usługi.

• Optymalizowanie zapytań, tabel i baz danych przy użyciu szczegółowych informacji o wydajności zapytań i typowych zaleceń dotyczących wydajności udostępnianych przez firmę Microsoft.

• Zaimplementuj logikę ponawiania prób przy użyciu zestawu SDK, aby wyeliminować przejściowe błędy wpływające na łączność z usługą Azure SQL Database.

• Określanie priorytetów użycia kluczy zarządzanych przez usługę podczas stosowania funkcji Transparent Data Encryption (TDE) po stronie serwera na potrzeby szyfrowania magazynowanych.

  • Jeśli wymagane jest szyfrowanie kluczy zarządzanych przez klienta lub po stronie klienta (AlwaysEncrypted), upewnij się, że klucze są odpowiednio odporne na kopie zapasowe i zautomatyzowane obiekty rotacji.

• Rozważ użycie przywracania do punktu w czasie jako podręcznika operacyjnego w celu odzyskania sprawności po poważnych błędach konfiguracji.

Azure Database For PostgreSQL

• Serwer elastyczny jest zalecany do korzystania z niego w przypadku obciążeń o znaczeniu krytycznym dla działania firmy ze względu na obsługę strefy dostępności.

• W przypadku korzystania z warstwy Hiperskala (Citus) dla obciążeń o krytycznym znaczeniu dla działania firmy włącz tryb wysokiej dostępności, aby otrzymać gwarancję SLA na poziomie 99,95%.

• Użyj konfiguracji serwera Hiperskala (Citus), aby zmaksymalizować dostępność w wielu węzłach.

• Zdefiniuj model pojemności dla aplikacji w celu informowania o wymaganiach dotyczących zasobów obliczeniowych i magazynu w ramach platformy danych.

  • Rozważ rabat na rezerwację w warstwie Hiperskala (Citus), aby zapewnić potencjalne optymalizacje kosztów.

Buforowanie danych warstwy Gorąca

Warstwę buforowania w pamięci można zastosować w celu zwiększenia platformy danych przez znaczne zwiększenie przepływności odczytu i skrócenie czasu odpowiedzi klienta kompleksowego dla scenariuszy danych warstwy gorąca.

Platforma Azure udostępnia kilka usług z odpowiednimi funkcjami buforowania kluczowych struktur danych, a usługa Azure Cache for Redis została umieszczona w celu abstrakcji i optymalizacji dostępu do odczytu platformy danych. W tej sekcji skoncentrujemy się na optymalnym użyciu usługi Azure Cache for Redis w scenariuszach, w których wymagana jest dodatkowa wydajność odczytu i trwałość dostępu do danych.

Zagadnienia dotyczące projektowania

• Warstwa buforowania zapewnia dodatkową trwałość dostępu do danych, ponieważ nawet jeśli awaria wpływająca na podstawowe technologie danych, migawka danych aplikacji nadal może być dostępna za pośrednictwem warstwy buforowania.

• W niektórych scenariuszach obciążeń buforowanie w pamięci można zaimplementować w samej platformie aplikacji.

Azure Cache for Redis

• Pamięć podręczna Redis Cache to system magazynu typu open source NoSQL typu klucz-wartość w pamięci.

• Warstwy Flash przedsiębiorstwa i Enterprise można wdrożyć w konfiguracji aktywne-aktywne w Strefy dostępności w regionie i różnych regionach świadczenia usługi Azure za pomocą replikacji geograficznej.

  • Po wdrożeniu w co najmniej trzech regionach platformy Azure i co najmniej trzech Strefy dostępności w każdym regionie z włączoną aktywną replikacją geograficzną dla wszystkich wystąpień pamięci podręcznej usługa Azure Cache for Redis zapewnia umowę SLA wynoszącą 99,999% dla łączności z jednym regionalnym punktem końcowym pamięci podręcznej.
  • Po wdrożeniu w trzech Strefy dostępności w jednym regionie świadczenia usługi Azure jest zapewniana umowa SLA dotycząca łączności na 99,99%.

• Warstwa Flash przedsiębiorstwa działa w połączeniu pamięci RAM i pamięci flash nietrwałej, a jednocześnie wprowadza to niewielką karę wydajności, która umożliwia również bardzo duże rozmiary pamięci podręcznej, do 13 TB z klastrowaniem.

• W przypadku replikacji geograficznej opłaty za transfer danych między regionami będą również stosowane oprócz kosztów bezpośrednich skojarzonych z wystąpieniami pamięci podręcznej.

• Funkcja Zaplanowane aktualizacje nie obejmuje aktualizacji ani aktualizacji platformy Azure zastosowanych do bazowego systemu operacyjnego maszyny wirtualnej.

• Podczas operacji skalowania w poziomie nastąpi zwiększenie wykorzystania procesora CPU podczas migrowania danych do nowych wystąpień.

Zalecenia dotyczące projektowania

• Rozważ zoptymalizowaną warstwę buforowania dla scenariuszy danych "gorąca", aby zwiększyć przepływność odczytu i poprawić czasy odpowiedzi.

• Zastosuj odpowiednie zasady dotyczące wygasania pamięci podręcznej i przechowywania danych, aby uniknąć wzrostu danych ucieczki.

  • Rozważ wygaśnięcie elementów pamięci podręcznej, gdy dane zapasowe zmienią się.

Azure Cache for Redis

• Użyj jednostki SKU Premium lub Enterprise, aby zmaksymalizować niezawodność i wydajność.

  • W przypadku scenariuszy z bardzo dużymi ilościami danych należy wziąć pod uwagę warstwę Flash przedsiębiorstwa.
  • W przypadku scenariuszy, w których wymagana jest tylko pasywna replikacja geograficzna, można również rozważyć warstwę Premium.

• Wdróż wystąpienia repliki przy użyciu replikacji geograficznej w aktywnej konfiguracji we wszystkich regionach wdrażania.

• Upewnij się, że wystąpienia repliki są wdrażane w Strefy dostępności w każdym uznanym regionie świadczenia usługi Azure.

• Użyj usługi Azure Monitor, aby ocenić usługę Azure Cache for Redis.

  • Oblicz wskaźnik kondycji dla regionalnych składników pamięci podręcznej, aby obserwować kondycję względem wymagań biznesowych i wykorzystania zasobów.
  • Obserwuj i ostrzegaj o kluczowych metrykach, takich jak wysokie użycie procesora CPU, wysokie użycie pamięci, wysokie obciążenie serwera i eksmitowane klucze, aby uzyskać szczegółowe informacje dotyczące skalowania pamięci podręcznej.

• Zoptymalizuj odporność połączenia, implementując logikę ponawiania prób, przekroczenia limitu czasu i używając pojedynczej implementacji multipleksera połączenia Redis.

• Skonfiguruj zaplanowane aktualizacje, aby określić dni i godziny stosowania aktualizacji serwera Redis do pamięci podręcznej.

Scenariusze analityczne

Coraz częściej aplikacje o znaczeniu krytycznym uwzględniają scenariusze analityczne jako środki do kierowania dodatkową wartością z uwzględnionych przepływów danych. Scenariusze analityczne aplikacji i operacji (AIOps) stanowią zatem kluczowy aspekt wysoce niezawodnej platformy danych.

Obciążenia analityczne i transakcyjne wymagają różnych możliwości i optymalizacji platformy danych w celu uzyskania akceptowalnej wydajności w odpowiednich kontekstach.

opis	Analityczny	Transakcyjne
Przypadek użycia	Analizowanie bardzo dużych ilości danych ("dane big data")	Przetwarzanie bardzo dużych ilości poszczególnych transakcji
Zoptymalizowano pod kątem	Odczytywanie zapytań i agregacji w wielu rekordach	Zapytania tworzenia/odczytu/aktualizowania/usuwania (CRUD) niemal w czasie rzeczywistym w kilku rekordach
Kluczowe cechy	— Konsolidacja ze źródeł danych rekordu — Magazyn oparty na kolumnach - Magazyn rozproszony - Przetwarzanie równoległe -Nieznormalizowane - Niskie odczyty i zapisy współbieżności — Optymalizowanie pod kątem woluminu magazynu przy użyciu kompresji	— Źródło danych rekordu dla aplikacji — Magazyn oparty na wierszach - Ciągły magazyn - Przetwarzanie symetryczne -Znormalizowana - Wysokie odczyty i zapisy współbieżności, aktualizacje indeksu — Optymalizowanie pod kątem szybkiego dostępu do danych za pomocą magazynu w pamięci

Usługa Azure Synapse udostępnia platformę analityczną przedsiębiorstwa, która łączy dane relacyjne i nierelacyjne z technologiami Spark przy użyciu wbudowanej integracji z usługami platformy Azure, takimi jak Azure Cosmos DB, aby ułatwić analizę danych big data. Zagadnienia i zalecenia dotyczące projektowania w tej sekcji skoncentrują się zatem na optymalnym użyciu usługi Azure Synapse i usługi Azure Cosmos DB na potrzeby scenariuszy analitycznych.

Zagadnienia dotyczące projektowania

• Tradycyjnie scenariusze analityczne na dużą skalę są obsługiwane przez wyodrębnianie danych do oddzielnej platformy danych zoptymalizowanej pod kątem kolejnych zapytań analitycznych.
  • Potoki wyodrębniania, przekształcania i ładowania (ETL) służą do wyodrębniania danych będą zużywać przepływność i wpływać na wydajność obciążeń transakcyjnych.
  • Uruchamianie potoków ETL rzadko w celu zmniejszenia wpływu przepływności i wydajności spowoduje, że dane analityczne są mniej aktualne.
  • Rozwój i konserwacja potoków ETL zwiększa się wraz ze wzrostem liczby przekształceń danych.
    • Jeśli na przykład dane źródłowe są często zmieniane lub usuwane, potoki ETL muszą uwzględniać te zmiany w danych docelowych dla zapytań analitycznych za pomocą podejścia addytywnego/wersji, zrzutu i ponownego ładowania lub zmian w miejscu na danych analitycznych. Każde z tych podejść będzie miało wpływ na pochodną, na przykład ponowne utworzenie indeksu lub aktualizację.

Azure Cosmos DB

• Zapytania analityczne uruchamiane na danych transakcyjnych usługi Azure Cosmos DB zwykle agregują między partycjami na dużych ilościach danych, zużywając znaczną przepływność jednostki żądań (RU), co może mieć wpływ na wydajność otaczających obciążeń transakcyjnych.

• Magazyn analityczny usługi Azure Cosmos DB zapewnia schematyzowany, w pełni izolowany magazyn danych zorientowany na kolumnę, który umożliwia analizę na dużą skalę danych usługi Azure Cosmos DB z usługi Azure Synapse bez wpływu na obciążenia transakcyjne usługi Azure Cosmos DB.

  • Gdy kontener usługi Azure Cosmos DB jest włączony jako magazyn analityczny, nowy magazyn kolumn jest wewnętrznie tworzony na podstawie danych operacyjnych w kontenerze. Ten magazyn kolumn jest utrwalany oddzielnie od magazynu transakcji zorientowanego na wiersz dla kontenera.
  • Operacje tworzenia, aktualizowania i usuwania danych operacyjnych są automatycznie synchronizowane z magazynem analitycznym, więc nie jest wymagane żadne przetwarzanie ETL ani zestawienia zmian.
  • Synchronizacja danych z operacji do magazynu analitycznego nie korzysta z jednostek żądań przepływności aprowizowania w kontenerze lub bazie danych. Nie ma wpływu na wydajność obciążeń transakcyjnych. Magazyn analityczny nie wymaga alokacji dodatkowych jednostek RU w bazie danych lub kontenerze usługi Azure Cosmos DB.
  • Automatyczna synchronizacja to proces, w którym zmiany danych operacyjnych są automatycznie synchronizowane z magazynem analitycznym. Opóźnienie automatycznej synchronizacji jest zwykle mniejsze niż dwa (2) minuty.
    • Opóźnienie automatycznej synchronizacji może potrwać do pięciu (5) minut dla bazy danych z udostępnioną przepływnością i dużą liczbą kontenerów.
    • Po zakończeniu automatycznej synchronizacji najnowsze dane mogą być odpytywane z usługi Azure Synapse.
  • Magazyn analityczny korzysta z modelu cenowego opartego na użyciu, który pobiera opłaty za ilość danych i liczbę operacji odczytu i zapisu. Cennik magazynu analitycznego jest oddzielony od cen magazynu transakcyjnego.

• Korzystając z usługi Azure Synapse Link, magazyn analityczny usługi Azure Cosmos DB można wykonywać zapytania bezpośrednio z usługi Azure Synapse. Umożliwia to korzystanie z funkcji no-ETL, hybrydowego przetwarzania transakcyjnego i analitycznego (HTAP) z usługi Synapse, dzięki czemu dane usługi Azure Cosmos DB można wykonywać zapytania wraz z innymi obciążeniami analitycznymi z usługi Synapse niemal w czasie rzeczywistym.

• Magazyn analityczny usługi Azure Cosmos DB nie jest domyślnie podzielony na partycje.

  • W przypadku niektórych scenariuszy zapytań wydajność poprawi się przez partycjonowanie danych magazynu analitycznego przy użyciu kluczy, które są często używane w predykatach zapytań.
  • Partycjonowanie jest wyzwalane przez zadanie w usłudze Azure Synapse, które uruchamia notes platformy Spark przy użyciu usługi Synapse Link, który ładuje dane z magazynu analitycznego usługi Azure Cosmos DB i zapisuje je w magazynie podzielonym na partycje usługi Synapse w podstawowym koncie magazynu obszaru roboczego usługi Synapse.

• Pule bezserwerowe usługi Azure Synapse Analytics mogą wysyłać zapytania do magazynu analitycznego za pomocą automatycznie aktualizowanych widoków lub poleceń SELECT / OPENROWSET .

• Pule platformy Spark usługi Azure Synapse Analytics mogą wysyłać zapytania do magazynu analitycznego za pomocą automatycznie zaktualizowanych tabel platformy Spark lub spark.read polecenia.

• Dane można również skopiować z magazynu analitycznego usługi Azure Cosmos DB do dedykowanej puli SQL usługi Synapse przy użyciu platformy Spark, aby można było użyć aprowizowania zasobów puli SQL usługi Azure Synapse.

• Zapytania dotyczące danych magazynu analitycznego usługi Azure Cosmos DB można wykonywać za pomocą usługi Azure Synapse Spark.

  • Notesy platformy Spark umożliwiają łączenie ramek danych platformy Spark w celu agregowania i przekształcania danych analitycznych usługi Azure Cosmos DB z innymi zestawami danych oraz używania innych zaawansowanych funkcji platformy Synapse Spark, w tym pisania przekształconych danych do innych magazynów lub trenowania modeli uczenia maszynowego AIOps.

• Źródło zmian usługi Azure Cosmos DB może również służyć do obsługi oddzielnego pomocniczego magazynu danych na potrzeby scenariuszy analitycznych.

Azure Synapse

• Usługa Azure Synapse łączy funkcje analityczne, w tym magazynowanie danych SQL, dane big data platformy Spark i Eksplorator danych na potrzeby analizy dzienników i szeregów czasowych.

  • Usługa Azure Synapse używa połączonych usług do definiowania połączeń z innymi usługami, takimi jak Azure Storage.
  • Dane można pozyskiwać do usługi Synapse Analytics za pośrednictwem działanie Kopiuj z obsługiwanych źródeł. Pozwala to na analizę danych w usłudze Synapse bez wpływu na źródłowy magazyn danych, ale zwiększa koszty i opóźnienia związane z transferem danych.
  • Dane mogą być również wyszukiwane w miejscu w obsługiwanych magazynach zewnętrznych, co pozwala uniknąć narzutów związanych z pozyskiwaniem i przenoszeniem danych. Usługa Azure Storage z usługą Data Lake Gen2 jest obsługiwanym magazynem dla wyeksportowanych danych usługi Synapse i usługi Log Analytics, do których można wysyłać zapytania za pośrednictwem usługi Synapse Spark.

• Usługa Azure Synapse Studio łączy zadania pozyskiwania i wykonywania zapytań.

  • Dane źródłowe, w tym dane magazynu analitycznego usługi Azure Cosmos DB i dane eksportu usługi Log Analytics, są odpytywane i przetwarzane w celu obsługi analizy biznesowej i innych zagregowanych przypadków użycia analitycznych.

Zalecenia dotyczące projektowania

• Upewnij się, że obciążenia analityczne nie wpływają na obciążenia aplikacji transakcyjnych w celu zachowania wydajności transakcyjnej.

Analiza aplikacji

• Użyj usługi Azure Synapse Link z magazynem analitycznym usługi Azure Cosmos DB, aby wykonywać analizy danych operacyjnych usługi Azure Cosmos DB przez utworzenie zoptymalizowanego magazynu danych, co nie wpłynie na wydajność transakcyjną.

  • Włącz usługę Azure Synapse Link na kontach usługi Azure Cosmos DB.
  • Utwórz kontener włączony dla magazynu analitycznego lub włącz istniejący kontener dla magazynu analitycznego.
  • Połącz obszar roboczy usługi Azure Synapse z magazynem analitycznym usługi Azure Cosmos DB, aby włączyć obciążenia analityczne w usłudze Azure Synapse w celu wykonywania zapytań dotyczących danych usługi Azure Cosmos DB. Użyj parametry połączenia z kluczem usługi Azure Cosmos DB tylko do odczytu.

• Określanie priorytetów magazynu analitycznego usługi Azure Cosmos DB za pomocą usługi Azure Synapse Link zamiast używania zestawienia zmian usługi Azure Cosmos DB w celu utrzymania analitycznego magazynu danych.

  • Źródło zmian usługi Azure Cosmos DB może być odpowiednie dla bardzo prostych scenariuszy analitycznych.

Sztuczna inteligencja i analiza operacyjna

• Utwórz pojedynczy obszar roboczy usługi Azure Synapse z połączonymi usługami i zestawami danych dla każdego źródłowego konta usługi Azure Storage, do którego są wysyłane dane operacyjne z zasobów.

• Utwórz dedykowane konto usługi Azure Storage i użyj go jako podstawowego konta magazynu obszaru roboczego do przechowywania danych i metadanych katalogu obszarów roboczych usługi Synapse. Skonfiguruj ją przy użyciu hierarchicznej przestrzeni nazw, aby włączyć usługę Azure Data Lake Gen2.

  • Zachowaj separację danych analitycznych źródła i danych obszaru roboczego usługi Synapse oraz metadanych.
    • Nie używaj jednego z regionalnych lub globalnych kont usługi Azure Storage, na których są wysyłane dane operacyjne.

Następny krok

Zapoznaj się z zagadnieniami dotyczącymi sieci.

Sieć i łączność