Strategie partycjonowania danych

Azure Table Storage

W tym artykule opisano niektóre strategie partycjonowania danych w różnych magazynach danych platformy Azure. Aby uzyskać ogólne wskazówki dotyczące partycjonowania danych i najlepszych rozwiązań, zobacz Partycjonowanie danych.

Partycjonowanie usługi Azure SQL Database

Pojedyncza baza danych SQL ma limit ilości danych, które może zawierać. Przepływność jest ograniczona przez czynniki architektoniczne i liczbę współbieżnych połączeń, które obsługuje.

Elastyczne pule obsługują funkcję skalowania w poziomie dla bazy danych SQL. Za pomocą elastycznych pul można podzielić dane na fragmenty rozłożone na wiele baz danych SQL. Możesz również dodawać lub usuwać fragmenty jako ilość danych, które są potrzebne do obsługi wzrostu i zmniejszania. Elastyczne pule mogą również pomóc zmniejszyć rywalizację poprzez dystrybucję obciążenia między bazami danych.

Każdy fragment jest implementowany jako baza danych SQL. Fragment może zawierać więcej niż jeden zestaw danych (nazywany fragmentem). Każda baza danych przechowuje metadane opisujące zawarte w niej podfragmenty. Fragmentlet może być pojedynczym elementem danych lub grupą elementów, które współużytkujące ten sam klucz fragmentu. Na przykład w aplikacji wielodostępnej klucz podfragmentu może być identyfikatorem dzierżawy, a wszystkie dane dzierżawy mogą być przechowywane w tym samym podfragmentze.

Aplikacje klienckie są odpowiedzialne za kojarzenie zestawu danych z kluczem podfragmentu. Oddzielna baza danych SQL działa jako globalny menedżer mapy fragmentów. Ta baza danych zawiera listę wszystkich fragmentów i mikrofragmentów w systemie. Aplikacja łączy się z bazą danych menedżera mapy fragmentów w celu uzyskania kopii mapy fragmentów. Buforuje ona lokalnie mapę fragmentów i używa mapy do kierowania żądań danych do odpowiedniego fragmentu. Ta funkcja jest ukryta za serią interfejsów API zawartych w bibliotece klienta elastic database, która jest dostępna dla języków Java i .NET.

Aby uzyskać więcej informacji na temat elastycznych pul, zobacz Skalowanie w górę za pomocą usługi Azure SQL Database.

Aby zmniejszyć opóźnienia i zwiększyć dostępność, można replikować globalną bazę danych menedżera map fragmentów. W warstwach cenowych Premium można skonfigurować aktywną replikację geograficzną, aby stale kopiować dane do baz danych w różnych regionach.

Alternatywnie użyj usługi Azure SQL Data Sync lub Azure Data Factory , aby replikować bazę danych menedżera map fragmentów w różnych regionach. Ta forma replikacji jest okresowo uruchamiana i jest bardziej odpowiednia, jeśli mapa fragmentów zmienia się rzadko i nie wymaga warstwy Premium.

Elastyczna baza danych udostępnia dwa schematy mapowania danych na fragmenty i przechowywania ich w fragmentach:

• Mapa fragmentów listy kojarzy pojedynczy klucz z podfragmentem. Na przykład w systemie wielodostępnym dane dla każdego najemcy mogą być skojarzone z unikatowym kluczem i przechowywane w osobnym kawałku danych. Aby zagwarantować izolację, każdy mikrofragment może być przechowywany w ramach własnej części.

  

  Pobierz plik programu Visio tego diagramu.

• Mapa fragmentów zakresu kojarzy zestaw ciągłych wartości kluczy do fragmentu. Można na przykład zgrupować dane dla zestawu dzierżaw (z których każdy ma własny klucz) w ramach tego samego fragmentu. Ten schemat jest mniej kosztowny niż pierwszy, ponieważ dzierżawcy współdzielą magazyn danych, ale mają mniej izolacji.

  

  Pobierz plik Visio tego diagramu

Pojedynczy fragment może zawierać dane dla kilku podfragmentów. Na przykład można użyć fragmentów listy do przechowywania danych dla różnych dzierżaw nieciągłych w tym samym fragmentzie. Można również mieszać podfragmenty zakresu i podfragmenty listy w tym samym fragmentzie, chociaż będą one rozwiązywane za pomocą różnych map. Na poniższym diagramie przedstawiono takie podejście:

Pobierz plik programu Visio tego diagramu.

Elastyczne pule umożliwiają dodawanie i usuwanie fragmentów w miarę zmniejszania i zmniejszania ilości danych. Aplikacje klienckie mogą dynamicznie tworzyć i usuwać fragmenty oraz w sposób niewidoczny aktualizować menedżera map fragmentów. Jednak usunięcie fragmentu jest operacją destruktywną, która wymaga również usunięcia wszystkich danych w tym fragmentzie.

Jeśli aplikacja musi podzielić fragment na dwa oddzielne fragmenty lub połączyć fragmenty, użyj narzędzia split-merge. To narzędzie działa jako usługa internetowa platformy Azure i bezpiecznie migruje dane między fragmentami.

Schemat partycjonowania może znacząco wpłynąć na wydajność systemu. Może to również mieć wpływ na szybkość dodawania lub usuwania fragmentów albo ponowne partycjonowanie danych między fragmentami. Rozważ następujące kwestie:

• Grupuj dane używane razem w tym samym fragmentzie i unikaj operacji, które uzyskują dostęp do danych z wielu fragmentów. Fragment jest własną bazą danych SQL, a sprzężenia między bazami danych muszą być wykonywane po stronie klienta.

  Chociaż usługa SQL Database nie obsługuje sprzężeń między bazami danych, można użyć narzędzi Elastic Database do wykonywania zapytań obejmujących wiele fragmentów. Zapytanie wielofragmentowe wysyła poszczególne zapytania do każdej bazy danych i scala wyniki.

• Nie projektuj systemu, który ma zależności między fragmentami. Ograniczenia integralności referencyjnej, wyzwalacze i procedury składowane w jednej bazie danych nie mogą odwoływać się do obiektów w innej bazie danych.

• Jeśli masz dane referencyjne, które są często używane przez zapytania, rozważ replikowanie tych danych między fragmentami. Takie podejście może usunąć konieczność łączenia danych między bazami danych. W idealnym przypadku takie dane powinny być statyczne lub wolno przenoszone, aby zminimalizować nakład pracy związany z replikacją i zmniejszyć prawdopodobieństwo ich nieaktualności.

• Fragmenty należące do tej samej mapy fragmentów powinny mieć ten sam schemat. Ta reguła nie jest wymuszana przez usługę SQL Database, ale zarządzanie danymi i wykonywanie zapytań staje się bardzo złożone, jeśli każdy fragmentlet ma inny schemat. Zamiast tego utwórz oddzielne mapy fragmentów dla każdego schematu. Pamiętaj, że dane należące do różnych fragmentów mogą być przechowywane w tym samym fragmentzie.

• Operacje transakcyjne są obsługiwane tylko w przypadku danych w obrębie fragmentu, a nie między fragmentami. Transakcje mogą obejmować fragmenty, o ile są one częścią tego samego fragmentu. W związku z tym, jeśli logika biznesowa musi wykonywać transakcje, zapisz dane w tym samym fragmentze lub zaimplementuj spójność ostateczną.

• Umieść fragmenty w pobliżu użytkowników, którzy uzyskują dostęp do danych w tych fragmentach. Ta strategia pomaga zmniejszyć opóźnienie.

• Unikaj posiadania mieszaniny bardzo aktywnych i stosunkowo nieaktywnych fragmentów. Spróbuj równomiernie rozłożyć obciążenie na fragmenty. Może to wymagać tworzenia skrótów kluczy fragmentowania. Jeśli lokalizujesz fragmenty geograficzne, upewnij się, że skróty kluczy są mapowane na fragmenty przechowywane w fragmentach przechowywanych blisko użytkowników, którzy uzyskują dostęp do tych danych.

Partycjonowanie usługi Azure Table Storage

Azure Table Storage to magazyn klucz-wartość zaprojektowany wokół partycjonowania. Wszystkie jednostki są przechowywane w partycji, a partycje są zarządzane wewnętrznie przez usługę Azure Table Storage. Każda jednostka przechowywana w tabeli musi zawierać dwuczęściowy klucz, który obejmuje:

• Klucz partycji. Jest to wartość ciągu, która określa partycję, w której usługa Azure Table Storage umieści jednostkę. Wszystkie jednostki z tym samym kluczem partycji są przechowywane w tej samej partycji.

• Klucz wiersza. Jest to wartość ciągu, która identyfikuje jednostkę w partycji. Wszystkie jednostki w partycji są sortowane leksykalnie w kolejności rosnącej według tego klucza. Kombinacja klucza partycji/klucza wiersza musi być unikatowa dla każdej jednostki i nie może przekraczać 1 KB długości.

Jeśli jednostka zostanie dodana do tabeli z wcześniej nieużywanym kluczem partycji, usługa Azure Table Storage utworzy nową partycję dla tej jednostki. Inne jednostki z tym samym kluczem partycji będą przechowywane w tej samej partycji.

Ten mechanizm skutecznie implementuje strategię automatycznego skalowania w poziomie. Każda partycja jest przechowywana na tym samym serwerze w centrum danych platformy Azure, aby zapewnić szybkie uruchamianie zapytań pobierających dane z pojedynczej partycji.

Firma Microsoft opublikowała cele skalowalności dla usługi Azure Storage. Jeśli system prawdopodobnie przekroczy te limity, rozważ podzielenie jednostek na wiele tabel. Użyj partycjonowania pionowego, aby podzielić pola na grupy, do których najprawdopodobniej będzie uzyskiwany dostęp.

Na poniższym diagramie przedstawiono strukturę logiczną przykładowego konta magazynu. Konto magazynu zawiera trzy tabele: Informacje o kliencie, Informacje o produkcie i Informacje o zamówieniu.

Każda tabela ma wiele partycji.

• W tabeli Informacje o kliencie dane są partycjonowane według miasta, w którym znajduje się klient. Klucz wiersza zawiera identyfikator klienta.
• W tabeli Informacje o produkcie produkty są partycjonowane według kategorii produktów, a klucz wiersza zawiera numer produktu.
• W tabeli Informacje o zamówieniu zamówienia zamówienia są partycjonowane według daty zamówienia, a klucz wiersza określa godzinę odebrania zamówienia. Wszystkie dane są uporządkowane według klucza wiersza w każdej partycji.

Podczas projektowania jednostek dla usługi Azure Table Storage należy wziąć pod uwagę następujące kwestie:

• Wybierz klucz partycji i klucz wiersza według sposobu uzyskiwania dostępu do danych. Wybierz kombinację klucza partycji/klucza wiersza, która obsługuje większość zapytań. Najbardziej wydajne zapytania pobierają dane, określając klucz partycji i klucz wiersza. Zapytania określające klucz partycji i zakres kluczy wierszy można wykonać przez skanowanie pojedynczej partycji. Jest to stosunkowo szybkie, ponieważ dane są przechowywane w kolejności klucza wiersza. Jeśli zapytania nie określają partycji do skanowania, każda partycja musi zostać przeskanowana.

• Jeśli jednostka ma jeden klucz naturalny, użyj go jako klucza partycji i określ pusty ciąg jako klucz wiersza. Jeśli jednostka ma klucz złożony składający się z dwóch właściwości, wybierz najwolniej zmieniającą właściwość jako klucz partycji, a drugi jako klucz wiersza. Jeśli jednostka ma więcej niż dwie właściwości klucza, użyj łączenia właściwości w celu udostępnienia kluczy partycji i wierszy.

• Jeśli regularnie wykonujesz zapytania, które wyszukują dane przy użyciu pól innych niż klucze partycji i wierszy, rozważ zaimplementowanie wzorca tabeli indeksu lub rozważ użycie innego magazynu danych obsługującego indeksowanie, takiego jak usługa Azure Cosmos DB.

• W przypadku generowania kluczy partycji przy użyciu sekwencji monotonicznej (takiej jak "0001", "0002", "0003") i każda partycja zawiera tylko ograniczoną ilość danych, usługa Azure Table Storage może fizycznie zgrupować te partycje na tym samym serwerze. Usługa Azure Storage zakłada, że aplikacja najprawdopodobniej wykonuje zapytania w ciągłym zakresie partycji (zapytania zakresu) i jest zoptymalizowana pod kątem tego przypadku. Jednak takie podejście może prowadzić do hotspotów, ponieważ wszystkie wstawienia nowych jednostek mogą być skoncentrowane na jednym końcu ciągłego zakresu. Może również zmniejszyć skalowalność. Aby jeszcze bardziej równomiernie rozłożyć obciążenie, rozważ utworzenie skrótu klucza partycji.

• Usługa Azure Table Storage obsługuje operacje transakcyjne dla jednostek należących do tej samej partycji. Aplikacja może wykonywać wiele operacji wstawiania, aktualizowania, usuwania, zastępowania lub scalania jako jednostki niepodzielnej, o ile transakcja nie zawiera więcej niż 100 jednostek, a ładunek żądania nie przekracza 4 MB. Operacje obejmujące wiele partycji nie są transakcyjne i mogą wymagać zaimplementowania spójności ostatecznej. Aby uzyskać więcej informacji na temat magazynu tabel i transakcji, zobacz Wykonywanie transakcji grupy jednostek.

• Rozważ stopień szczegółowości klucza partycji:

  • Użycie tego samego klucza partycji dla każdej jednostki powoduje utworzenie pojedynczej partycji przechowywanej na jednym serwerze. Zapobiega to skalowaniu partycji w poziomie i skupia obciążenie na jednym serwerze. W związku z tym takie podejście jest odpowiednie tylko do przechowywania niewielkiej liczby jednostek. Jednak zapewnia, że wszystkie jednostki mogą uczestniczyć w transakcjach grupy jednostek.

  • Użycie unikatowego klucza partycji dla każdej jednostki powoduje utworzenie oddzielnej partycji dla każdej jednostki, co może spowodować powstanie dużej liczby małych partycji. Takie podejście jest bardziej skalowalne niż użycie pojedynczego klucza partycji, ale transakcje grup jednostek nie są możliwe. Ponadto zapytania pobierające więcej niż jedną jednostkę mogą obejmować odczytywanie z więcej niż jednego serwera. Jeśli jednak aplikacja wykonuje zapytania zakresu, użycie sekwencji monotonicznej dla kluczy partycji może pomóc w optymalizacji tych zapytań.

  • Udostępnianie klucza partycji w podzestawie jednostek umożliwia grupowanie powiązanych jednostek w tej samej partycji. Operacje obejmujące powiązane jednostki mogą być wykonywane przy użyciu transakcji grupy jednostek, a zapytania pobierające zestaw powiązanych jednostek mogą być spełnione przez uzyskanie dostępu do jednego serwera.

Aby uzyskać więcej informacji, zobacz Przewodnik projektowania tabel usługi Azure Storage i Skalowalna strategia partycjonowania.

Partycjonowanie usługi Azure Blob Storage

Usługa Azure Blob Storage umożliwia przechowywanie dużych obiektów binarnych. Blokowe obiekty blob można używać w scenariuszach, gdy trzeba szybko przekazać lub pobrać duże ilości danych. Użyj stronicowych obiektów blob dla aplikacji, które wymagają losowego, a nie szeregowego dostępu do części danych.

Każdy obiekt blob (blok lub strona) jest przechowywany w kontenerze na koncie usługi Azure Storage. Kontenery umożliwiają grupowanie powiązanych obiektów blob, które mają te same wymagania dotyczące zabezpieczeń. To grupowanie jest logiczne, a nie fizyczne. Wewnątrz kontenera każdy obiekt typu blob ma unikatową nazwę.

Klucz partycji dla obiektu blob to nazwa konta + nazwa kontenera i nazwa obiektu blob. Klucz partycji jest używany do partycjonowania danych na zakresy, a te zakresy są zrównoważone w całym systemie. Obiekty blob można dystrybuować na wielu serwerach w celu skalowania dostępu w poziomie do nich, ale pojedynczy obiekt blob może być obsługiwany tylko przez jeden serwer.

Jeśli schemat nazewnictwa używa sygnatur czasowych lub identyfikatorów liczbowych, może to prowadzić do nadmiernego ruchu przechodzącego do jednej partycji, ograniczając system od efektywnego równoważenia obciążenia. Jeśli na przykład masz codzienne operacje, które używają obiektu blob z sygnaturą czasową, taką jak rrrr-mm-dd, cały ruch dla tej operacji będzie kierowany do pojedynczego serwera partycji. Zamiast tego należy rozważyć prefiksowanie nazwy z trzycyfrowym skrótem. Aby uzyskać więcej informacji, zobacz Partition Naming Convention (Konwencja nazewnictwa partycji).

Akcje zapisu pojedynczego bloku lub strony są niepodzielne, ale operacje obejmujące bloki, strony lub obiekty blob nie są. Jeśli chcesz zapewnić spójność podczas wykonywania operacji zapisu w blokach, stronach i obiektach blob, wyjmij blokadę zapisu przy użyciu dzierżawy obiektu blob.

Partycjonowanie kolejek usługi Azure Storage

Kolejki usługi Azure Storage umożliwiają implementowanie asynchronicznych komunikatów między procesami. Konto usługi Azure Storage może zawierać dowolną liczbę kolejek, a każda kolejka może zawierać dowolną liczbę komunikatów. Jedynym ograniczeniem jest miejsce dostępne na koncie magazynu. Maksymalny rozmiar pojedynczego komunikatu to 64 KB. Jeśli potrzebujesz komunikatów większych niż ten, rozważ użycie kolejek usługi Azure Service Bus.

Każda kolejka magazynu ma unikatową nazwę na koncie magazynu, które go zawiera. Kolejki partycji platformy Azure są oparte na nazwie. Wszystkie komunikaty dla tej samej kolejki są przechowywane w tej samej partycji, która jest kontrolowana przez pojedynczy serwer. Różne kolejki mogą być zarządzane przez różne serwery, aby ułatwić równoważenie obciążenia. Alokacja kolejek do serwerów jest niewidoczna dla aplikacji i użytkowników.

W aplikacji na dużą skalę nie używaj tej samej kolejki magazynu dla wszystkich wystąpień aplikacji, ponieważ takie podejście może spowodować, że serwer hostujący kolejkę stanie się punktem gorącym. Zamiast tego należy używać różnych kolejek dla różnych obszarów funkcjonalnych aplikacji. Kolejki usługi Azure Storage nie obsługują transakcji, więc kierowanie komunikatów do różnych kolejek powinno mieć niewielki wpływ na spójność komunikatów.

Kolejka usługi Azure Storage może obsługiwać maksymalnie 2000 komunikatów na sekundę. Jeśli musisz przetwarzać komunikaty z większą szybkością, rozważ utworzenie wielu kolejek. Na przykład w aplikacji globalnej utwórz oddzielne kolejki magazynu na oddzielnych kontach magazynu w celu obsługi wystąpień aplikacji uruchomionych w każdym regionie.

Partycjonowanie usługi Azure Service Bus

Usługa Azure Service Bus używa brokera komunikatów do obsługi komunikatów wysyłanych do kolejki lub tematu usługi Service Bus. Domyślnie wszystkie komunikaty wysyłane do kolejki lub tematu są obsługiwane przez ten sam proces brokera komunikatów. Ta architektura może ograniczać ogólną przepływność kolejki komunikatów. Można jednak również partycjonować kolejkę lub temat podczas jego tworzenia. W tym celu należy ustawić właściwość EnablePartitioning kolejki lub opisu tematu na wartość true.

Partycjonowana kolejka lub temat jest podzielona na wiele fragmentów, z których każda jest wspierana przez oddzielny magazyn komunikatów i broker komunikatów. Usługa Service Bus ponosi odpowiedzialność za tworzenie tych fragmentów i zarządzanie nimi. Gdy aplikacja publikuje komunikat do partycjonowanej kolejki lub tematu, usługa Service Bus przypisuje komunikat do fragmentu dla tej kolejki lub tematu. Gdy aplikacja odbiera komunikat z kolejki lub subskrypcji, usługa Service Bus sprawdza każdy fragment następnego dostępnego komunikatu, a następnie przekazuje go do aplikacji do przetwarzania.

Ta struktura ułatwia dystrybucję obciążenia między brokerami komunikatów i magazynami komunikatów, zwiększając skalowalność i zwiększając dostępność. Jeśli broker komunikatów lub magazyn komunikatów dla jednego fragmentu jest tymczasowo niedostępny, usługa Service Bus może pobrać komunikaty z jednego z pozostałych dostępnych fragmentów.

Usługa Service Bus przypisuje komunikat do fragmentu w następujący sposób:

• Jeśli komunikat należy do sesji, wszystkie komunikaty o tej samej wartości właściwości SessionId są wysyłane do tego samego fragmentu.

• Jeśli komunikat nie należy do sesji, ale nadawca określił wartość właściwości PartitionKey , wszystkie komunikaty o tej samej wartości PartitionKey są wysyłane do tego samego fragmentu.

  Uwaga / Notatka

  Jeśli właściwości SessionId i PartitionKey są określone, muszą być ustawione na tę samą wartość lub komunikat zostanie odrzucony.

• Jeśli właściwości SessionId i PartitionKey dla komunikatu nie zostaną określone, ale zostanie włączone wykrywanie duplikatów, zostanie użyta właściwość MessageId . Wszystkie komunikaty o tym samym identyfikatorze MessageId zostaną przekierowane do tego samego fragmentu.

• Jeśli komunikaty nie zawierają właściwości SessionId, PartitionKey lub MessageId , usługa Service Bus przypisuje komunikaty do fragmentów sekwencyjnie. Jeśli fragment jest niedostępny, usługa Service Bus przejdzie do następnego. Oznacza to, że tymczasowa usterka w infrastrukturze obsługi komunikatów nie powoduje niepowodzenia operacji wysyłania komunikatów.

Podczas określania, czy lub jak partycjonować kolejkę komunikatów usługi Service Bus lub temat, należy wziąć pod uwagę następujące kwestie:

• Kolejki i tematy usługi Service Bus są tworzone w zakresie przestrzeni nazw usługi Service Bus. Usługa Service Bus obecnie umożliwia maksymalnie 100 partycjonowanych kolejek lub tematów na przestrzeń nazw.

• Każda przestrzeń nazw usługi Service Bus nakłada limity przydziału na dostępne zasoby, takie jak liczba subskrypcji na temat, liczba współbieżnych żądań wysyłania i odbierania na sekundę oraz maksymalna liczba współbieżnych połączeń, które można ustanowić. Te przydziały są udokumentowane w temacie Limity przydziału usługi Service Bus. Jeśli spodziewasz się przekroczyć te wartości, utwórz dodatkowe przestrzenie nazw z własnymi kolejkami i tematami i rozłóż pracę w tych przestrzeniach nazw. Na przykład w aplikacji globalnej utwórz oddzielne przestrzenie nazw w każdym regionie i skonfiguruj wystąpienia aplikacji do używania kolejek i tematów w najbliższej przestrzeni nazw.

• Komunikaty wysyłane w ramach transakcji muszą określać klucz partycji. Może to być właściwość SessionId, PartitionKey lub MessageId . Wszystkie komunikaty wysyłane w ramach tej samej transakcji muszą określać ten sam klucz partycji, ponieważ muszą być obsługiwane przez ten sam proces brokera komunikatów. Nie można wysyłać komunikatów do różnych kolejek lub tematów w ramach tej samej transakcji.

• Nie można skonfigurować partycjonowanych kolejek i tematów do automatycznego usuwania, gdy staną się bezczynne.

• Partycjonowane kolejki i tematy nie mogą być obecnie używane z protokołem Advanced Message Queuing Protocol (AMQP), jeśli tworzysz rozwiązania międzyplatformowe lub hybrydowe.

Partycjonowanie usługi Azure Cosmos DB

Usługa Azure Cosmos DB for NoSQL to baza danych NoSQL służąca do przechowywania dokumentów JSON. Dokument w bazie danych usługi Azure Cosmos DB jest serializowaną reprezentacją obiektu lub innego elementu danych w formacie JSON. Nie są wymuszane żadne stałe schematy, z tą różnicą, że każdy dokument musi zawierać unikatowy identyfikator.

Dokumenty są zorganizowane w kolekcje. Powiązane dokumenty można grupować razem w kolekcji. Na przykład w systemie, który przechowuje wpisy w blogu, można przechowywać zawartość każdego wpisu w blogu jako dokument w kolekcji. Można również tworzyć kolekcje dla każdego typu tematu. Alternatywnie w aplikacji wielodostępnej, takiej jak system, w którym różni autorzy kontrolują własne wpisy w blogu i zarządzają nimi, możesz podzielić blogi według autora i utworzyć oddzielne kolekcje dla każdego autora. Miejsce do magazynowania przydzielone do kolekcji jest elastyczne i może się zmniejszać lub zwiększać w razie potrzeby.

Usługa Azure Cosmos DB obsługuje automatyczne partycjonowanie danych na podstawie klucza partycji zdefiniowanego przez aplikację. Partycja logiczna to partycja, która przechowuje wszystkie dane dla pojedynczej wartości klucza partycji. Wszystkie dokumenty, które współużytkują tę samą wartość klucza partycji, są umieszczane w tej samej partycji logicznej. Usługa Azure Cosmos DB dystrybuuje wartości według skrótu klucza partycji. Partycja logiczna ma maksymalny rozmiar 20 GB. W związku z tym wybór klucza partycji jest ważną decyzją w czasie projektowania. Wybierz właściwość z szerokim zakresem wartości, a nawet wzorcami dostępu. Aby uzyskać więcej informacji, zobacz Partition and scale in Azure Cosmos DB (Partycjonowanie i skalowanie w usłudze Azure Cosmos DB).

Uwaga / Notatka

Każda baza danych usługi Azure Cosmos DB ma poziom wydajności , który określa ilość pobieranych zasobów. Poziom wydajności jest skojarzony z limitem szybkości jednostki żądania (RU). Limit szybkości jednostek żądania określa ilość zasobów zarezerwowanych i dostępnych do wyłącznego użytku przez te kolekcje. Koszt kolekcji zależy od poziomu wydajności wybranego dla tej kolekcji. Im wyższy poziom wydajności (i limit szybkości jednostek RU), tym wyższe opłaty. Poziom wydajności kolekcji można dostosować przy użyciu witryny Azure Portal. Aby uzyskać więcej informacji, zobacz Request Units in Azure Cosmos DB (Jednostki żądań w usłudze Azure Cosmos DB).

Jeśli mechanizm partycjonowania zapewniany przez usługę Azure Cosmos DB nie jest wystarczający, może być konieczne podzielenie danych na poziomie aplikacji. Kolekcje dokumentów zapewniają naturalny mechanizm partycjonowania danych w jednej bazie danych. Najprostszym sposobem zaimplementowania fragmentowania jest utworzenie kolekcji dla każdego fragmentu. Kontenery są zasobami logicznymi i mogą obejmować co najmniej jeden serwer. Kontenery o stałym rozmiarze mają maksymalny limit 20 GB i 10 000 RU/s przepływności. Kontenery bez ograniczeń nie mają maksymalnego rozmiaru magazynu, ale muszą określać klucz partycji. W przypadku fragmentowania aplikacji aplikacja kliencka musi kierować żądania do odpowiedniego fragmentu, zwykle implementując własny mechanizm mapowania na podstawie niektórych atrybutów danych, które definiują klucz fragmentu.

Wszystkie bazy danych są tworzone w kontekście konta bazy danych usługi Azure Cosmos DB. Jedno konto może zawierać kilka baz danych i określa, w których regionach tworzone są bazy danych. Każde konto wymusza również własną kontrolę dostępu. Konta usługi Azure Cosmos DB można używać do lokalizowania fragmentów geograficznych (kolekcji w bazach danych) blisko użytkowników, którzy muszą uzyskać do nich dostęp, i wymuszać ograniczenia, aby tylko ci użytkownicy mogli się z nimi łączyć.

Podczas podejmowania decyzji o sposobie partycjonowania danych za pomocą usługi Azure Cosmos DB for NoSQL należy wziąć pod uwagę następujące kwestie:

• Zasoby dostępne dla bazy danych usługi Azure Cosmos DB podlegają ograniczeniom przydziału konta. Każda baza danych może przechowywać wiele kolekcji, a każda kolekcja jest skojarzona z poziomem wydajności, który zarządza limitem szybkości jednostek ŻĄDANIA (zarezerwowaną przepływnością) dla tej kolekcji. Aby uzyskać więcej informacji, zobacz Ograniczenia subskrypcji i usług Azure, limity, kwoty i ograniczenia.

• Każdy dokument musi mieć atrybut, który może służyć do unikatowego identyfikowania tego dokumentu w kolekcji, w której jest przechowywany. Ten atrybut różni się od klucza fragmentu, który definiuje, która kolekcja zawiera dokument. Kolekcja może zawierać dużą liczbę dokumentów. Teoretycznie jest to ograniczone tylko przez maksymalną długość identyfikatora dokumentu. Identyfikator dokumentu może zawierać maksymalnie 255 znaków.

• Wszystkie operacje względem dokumentu są wykonywane w kontekście transakcji. Transakcje są ograniczone do kolekcji, w której znajduje się dokument. Jeśli operacja zakończy się niepowodzeniem, praca, którą wykonała, zostanie wycofana. Gdy dokument podlega operacji, wszelkie wprowadzone zmiany podlegają izolacji na poziomie migawki. Ten mechanizm gwarantuje, że jeśli na przykład żądanie utworzenia nowego dokumentu zakończy się niepowodzeniem, inny użytkownik, który wysyła zapytanie do bazy danych jednocześnie, nie zobaczy częściowego dokumentu, który zostanie usunięty.

• Zapytania bazy danych są również ograniczone do poziomu kolekcji. Pojedyncze zapytanie może pobierać dane tylko z jednej kolekcji. Jeśli musisz pobrać dane z wielu kolekcji, musisz wykonać zapytanie dotyczące każdej kolekcji indywidualnie i scalić wyniki w kodzie aplikacji.

• Usługa Azure Cosmos DB obsługuje programowalne elementy, które mogą być przechowywane w kolekcji wraz z dokumentami. Obejmują one procedury składowane, funkcje zdefiniowane przez użytkownika i wyzwalacze (napisane w języku JavaScript). Te elementy mogą uzyskiwać dostęp do dowolnego dokumentu w tej samej kolekcji. Ponadto te elementy są uruchamiane wewnątrz zakresu transakcji otoczenia (w przypadku wyzwalacza uruchamianego w wyniku operacji tworzenia, usuwania lub zastępowania wykonywanej względem dokumentu) lub przez uruchomienie nowej transakcji (w przypadku procedury składowanej, która jest uruchamiana w wyniku jawnego żądania klienta). Jeśli kod w elemencie programowalnym zgłasza wyjątek, transakcja zostanie wycofana. Można użyć procedur składowanych i wyzwalaczy, aby zachować integralność i spójność między dokumentami, ale wszystkie te dokumenty muszą być częścią tej samej kolekcji.

• Kolekcje, które mają być przechowywane w bazach danych, powinny być mało prawdopodobne, aby przekroczyć limity przepływności zdefiniowane przez poziomy wydajności kolekcji. Aby uzyskać więcej informacji, zobacz Request Units in Azure Cosmos DB (Jednostki żądań w usłudze Azure Cosmos DB). Jeśli przewidujesz osiągnięcie tych limitów, rozważ podzielenie kolekcji między bazami danych na różnych kontach, aby zmniejszyć obciążenie kolekcji.

Partycjonowanie usługi Azure AI Search

Możliwość wyszukiwania danych jest często podstawową metodą nawigacji i eksploracji zapewnianej przez wiele aplikacji internetowych. Ułatwia to użytkownikom szybkie znajdowanie zasobów (na przykład produktów w aplikacji do handlu elektronicznego) na podstawie kombinacji kryteriów wyszukiwania. Usługa wyszukiwania sztucznej inteligencji udostępnia funkcje wyszukiwania pełnotekstowego za pośrednictwem zawartości internetowej i zawiera funkcje, takie jak typ-ahead, sugerowane zapytania na podstawie bliskich dopasowań i nawigacja aspektowa. Aby uzyskać więcej informacji, zobacz Co to jest wyszukiwanie sztucznej inteligencji?.

Usługa AI Search przechowuje zawartość z możliwością wyszukiwania jako dokumenty JSON w bazie danych. Definiujesz indeksy, które określają pola z możliwością wyszukiwania w tych dokumentach i udostępniają te definicje w wyszukiwaniu sztucznej inteligencji. Gdy użytkownik przesyła żądanie wyszukiwania, wyszukiwanie sztucznej inteligencji używa odpowiednich indeksów do znajdowania pasujących elementów.

Aby zmniejszyć rywalizację, magazyn używany przez wyszukiwanie sztucznej inteligencji można podzielić na 1, 2, 3, 4, 6 lub 12 partycji, a każda partycja może być replikowana maksymalnie 6 razy. Iloczyn liczby partycji pomnożonych przez liczbę replik jest nazywany jednostką wyszukiwania (SU). Pojedyncze wystąpienie wyszukiwania sztucznej inteligencji może zawierać maksymalnie 36 jednostek jednostki operacyjnego (baza danych z 12 partycjami obsługuje tylko maksymalnie 3 repliki).

Opłaty są naliczane za każdą jednostkę SU przydzieloną do usługi. W miarę zwiększania się ilości zawartości z możliwością wyszukiwania lub zwiększania szybkości żądań wyszukiwania można dodać jednostki SU do istniejącego wystąpienia wyszukiwania sztucznej inteligencji w celu obsługi dodatkowego obciążenia. Samo wyszukiwanie sztucznej inteligencji równomiernie dystrybuuje dokumenty między partycjami. Obecnie nie są obsługiwane żadne strategie partycjonowania ręcznego.

Każda partycja może zawierać maksymalnie 15 milionów dokumentów lub zajmować 300 GB miejsca do magazynowania (w zależności od tego, co jest mniejsze). Można utworzyć maksymalnie 50 indeksów. Wydajność usługi różni się i zależy od złożoności dokumentów, dostępnych indeksów i wpływu opóźnienia sieci. Średnio pojedyncza replika (1 jednostka SU) powinna być w stanie obsłużyć 15 zapytań na sekundę (QPS), chociaż zalecamy przeprowadzenie testów porównawczych z własnymi danymi w celu uzyskania bardziej precyzyjnej miary przepływności. Aby uzyskać więcej informacji, zobacz Limity usługi w wyszukiwaniu sztucznej inteligencji.

Uwaga / Notatka

Ograniczony zestaw typów danych można przechowywać w dokumentach z możliwością wyszukiwania, w tym ciągów, wartości logicznych, danych liczbowych, danych daty/godziny i niektórych danych geograficznych. Aby uzyskać więcej informacji, zobacz stronę Obsługiwane typy danych (AI Search) w witrynie internetowej firmy Microsoft.

Masz ograniczoną kontrolę nad sposobem partycjonowania danych wyszukiwania sztucznej inteligencji dla każdego wystąpienia usługi. Jednak w środowisku globalnym może być możliwe dalsze zwiększenie wydajności i zmniejszenie opóźnienia i rywalizacji przez partycjonowanie samej usługi przy użyciu jednej z następujących strategii:

• Utwórz wystąpienie wyszukiwania sztucznej inteligencji w każdym regionie geograficznym i upewnij się, że aplikacje klienckie są kierowane do najbliższego dostępnego wystąpienia. Ta strategia wymaga, aby wszystkie aktualizacje zawartości z możliwością wyszukiwania zostały zreplikowane w odpowiednim czasie we wszystkich wystąpieniach usługi.

• Utwórz dwie warstwy wyszukiwania sztucznej inteligencji:

  • Usługa lokalna w każdym regionie, która zawiera dane najczęściej używane przez użytkowników w tym regionie. Użytkownicy mogą tutaj kierować żądania w celu uzyskania szybkich, ale ograniczonych wyników.
  • Globalna usługa obejmująca wszystkie dane. Użytkownicy mogą tutaj kierować żądania, aby uzyskać wolniejsze, ale bardziej kompletne wyniki.

Takie podejście jest najbardziej odpowiednie, gdy istnieje znaczna odmiana regionalna danych, które są przeszukiwane.

Partycjonowanie usługi Azure Cache for Redis

Usługa Azure Cache for Redis udostępnia udostępnioną usługę buforowania w chmurze opartą na magazynie danych klucz-wartość usługi Redis. Jak sama nazwa wskazuje, usługa Azure Cache for Redis jest przeznaczona jako rozwiązanie buforowania. Służy tylko do przechowywania danych przejściowych, a nie jako trwałego magazynu danych. Aplikacje korzystające z usługi Azure Cache for Redis powinny mieć możliwość kontynuowania działania, jeśli pamięć podręczna jest niedostępna. Usługa Azure Cache for Redis obsługuje replikację podstawową/pomocniczą w celu zapewnienia wysokiej dostępności, ale obecnie ogranicza maksymalny rozmiar pamięci podręcznej do 53 GB. Jeśli potrzebujesz więcej miejsca, musisz utworzyć dodatkowe pamięci podręczne. Aby uzyskać więcej informacji, zobacz Pamięć podręczna Azure Cache for Redis.

Partycjonowanie magazynu danych Usługi Redis obejmuje podzielenie danych między wystąpienia usługi Redis. Każde wystąpienie stanowi jedną partycję. Usługa Azure Cache for Redis abstruje usługi Redis za fasadą i nie udostępnia ich bezpośrednio. Najprostszym sposobem implementacji partycjonowania jest utworzenie wielu wystąpień usługi Azure Cache for Redis i rozłożenie na nie danych.

Każdy element danych można skojarzyć z identyfikatorem (kluczem partycji), który określa, która pamięć podręczna przechowuje element danych. Logika aplikacji klienckiej może następnie użyć tego identyfikatora do kierowania żądań do odpowiedniej partycji. Ten schemat jest bardzo prosty, ale jeśli schemat partycjonowania ulegnie zmianie (na przykład w przypadku utworzenia dodatkowych wystąpień usługi Azure Cache for Redis), aplikacje klienckie mogą wymagać ponownej konfiguracji.

Natywna usługa Redis (a nie usługa Azure Cache for Redis) obsługuje partycjonowanie po stronie serwera na podstawie klastrowania Usługi Redis. W tym podejściu można równomiernie podzielić dane między serwerami przy użyciu mechanizmu tworzenia skrótów. Każdy serwer Redis przechowuje metadane opisujące zakres kluczy skrótów przechowywanych przez partycję, a także informacje o tym, które klucze skrótu znajdują się w partycjach na innych serwerach.

Aplikacje klienckie po prostu wysyłają żądania do dowolnego z uczestniczących serwerów Redis (prawdopodobnie najbliższego). Serwer Redis sprawdza żądanie klienta. Jeśli można go rozpoznać lokalnie, wykonuje żądaną operację. W przeciwnym razie przekazuje żądanie do odpowiedniego serwera.

Ten model jest implementowany przy użyciu klastrowania Redis i opisano go bardziej szczegółowo na stronie samouczka klastra Redis w witrynie internetowej usługi Redis. Klastrowanie usługi Redis jest niewidoczne dla aplikacji klienckich. Dodatkowe serwery Redis można dodać do klastra (a dane można ponownie partycjonować) bez konieczności ponownego konfigurowania klientów.

Ważne

Usługa Azure Cache for Redis obecnie obsługuje klastrowanie usługi Redis tylko w warstwie Premium.

Strona Partycjonowanie: sposób dzielenia danych między wiele wystąpień usługi Redis w witrynie internetowej usługi Redis zawiera więcej informacji na temat implementowania partycjonowania za pomocą usługi Redis. W pozostałej części tej sekcji założono, że implementujesz partycjonowanie po stronie klienta lub oparte na serwerze proxy.

Podczas podejmowania decyzji o sposobie partycjonowania danych za pomocą usługi Azure Cache for Redis należy wziąć pod uwagę następujące kwestie:

• Usługa Azure Cache for Redis nie jest przeznaczona do działania jako trwały magazyn danych, dlatego niezależnie od wdrożonego schematu partycjonowania kod aplikacji musi mieć możliwość pobierania danych z lokalizacji, która nie jest pamięcią podręczną.

• Dane, do których często uzyskuje się dostęp, powinny być przechowywane w tej samej partycji. Redis to zaawansowany magazyn par klucz-wartość, który zapewnia kilka wysoce zoptymalizowanych mechanizmów do tworzenia struktur danych. Te mechanizmy mogą być jednym z następujących elementów:

  • Proste ciągi (dane binarne o długości do 512 MB)
  • Typy agregacji, takie jak listy (które mogą działać jako kolejki i stosy)
  • Zestawy (uporządkowane i nieurządzone)
  • Skróty (które mogą grupować powiązane pola, takie jak elementy reprezentujące pola w obiekcie)

• Typy agregacji umożliwiają skojarzenie wielu powiązanych wartości z tym samym kluczem. Klucz usługi Redis identyfikuje listę, zestaw lub skrót, a nie elementy danych, które zawiera. Wszystkie te typy są dostępne w usłudze Azure Cache for Redis i są opisane na stronie Typy danych w witrynie internetowej usługi Redis. Na przykład w części systemu handlu elektronicznego, który śledzi zamówienia złożone przez klientów, szczegóły każdego klienta mogą być przechowywane w skrótie usługi Redis, który jest kluczem przy użyciu identyfikatora klienta. Każdy skrót może przechowywać kolekcję identyfikatorów zamówień dla klienta. Oddzielny zestaw usługi Redis może przechowywać zamówienia, ponownie ustrukturyzowane jako skróty i kluczowane przy użyciu identyfikatora zamówienia. Rysunek 8 przedstawia tę strukturę. Należy pamiętać, że usługa Redis nie implementuje żadnej formy integralności referencyjnej, dlatego deweloper odpowiada za utrzymanie relacji między klientami i zamówieniami.

Rysunek 8. Sugerowana struktura w magazynie Redis na potrzeby rejestrowania zamówień klientów i ich szczegółów.

Uwaga / Notatka

W usłudze Redis wszystkie klucze są wartościami danych binarnych (takimi jak ciągi usługi Redis) i mogą zawierać do 512 MB danych. Teoretycznie klucz może zawierać prawie wszystkie informacje. Zalecamy jednak przyjęcie spójnej konwencji nazewnictwa kluczy opisowych typu danych i identyfikacji jednostki, ale nie jest zbyt długa. Typowym podejściem jest użycie kluczy formularza "entity_type:ID". Na przykład możesz użyć ciągu "customer:99", aby wskazać klucz klienta o identyfikatorze 99.

• Partycjonowanie pionowe można zaimplementować, przechowując powiązane informacje w różnych agregacjach w tej samej bazie danych. Na przykład w aplikacji do handlu elektronicznego można przechowywać często używane informacje o produktach w jednym skrótzie usługi Redis i rzadziej używane szczegółowe informacje w innym. Oba skróty mogą używać tego samego identyfikatora produktu w ramach klucza. Na przykład możesz użyć wartości "product: nn" (gdzie nn jest identyfikatorem produktu) dla informacji o produkcie i "product_details: nn" dla szczegółowych danych. Ta strategia może pomóc zmniejszyć ilość danych, które najprawdopodobniej będą pobierane przez większość zapytań.

• Magazyn danych usługi Redis można ponownie partycjonować, ale należy pamiętać, że jest to złożone i czasochłonne zadanie. Klastrowanie usługi Redis może automatycznie ponownie partycjonować dane, ale ta funkcja nie jest dostępna w usłudze Azure Cache for Redis. W związku z tym podczas projektowania schematu partycjonowania spróbuj pozostawić wystarczającą ilość wolnego miejsca w każdej partycji, aby umożliwić oczekiwany wzrost danych w czasie. Należy jednak pamiętać, że usługa Azure Cache for Redis jest przeznaczona do tymczasowego buforowania danych, a dane przechowywane w pamięci podręcznej mogą mieć ograniczony okres istnienia określony jako wartość czasu wygaśnięcia (TTL). W przypadku stosunkowo nietrwałych danych czas wygaśnięcia może być krótki, ale w przypadku danych statycznych czas wygaśnięcia może być znacznie dłuższy. Unikaj przechowywania dużych ilości danych długotrwałych w pamięci podręcznej, jeśli ilość tych danych może wypełnić pamięć podręczną. Możesz określić zasady eksmisji, które powodują, że usługa Azure Cache for Redis usuwa dane, jeśli miejsce jest w warstwie Premium.

  Uwaga / Notatka

  W przypadku korzystania z usługi Azure Cache for Redis należy określić maksymalny rozmiar pamięci podręcznej (od 250 MB do 53 GB), wybierając odpowiednią warstwę cenową. Jednak po utworzeniu usługi Azure Cache for Redis nie można zwiększyć (ani zmniejszyć) jej rozmiaru.

• Partie i transakcje usługi Redis nie mogą obejmować wielu połączeń, więc wszystkie dane, których dotyczy partia lub transakcja, powinny być przechowywane w tej samej bazie danych (fragment).

  Uwaga / Notatka

  Sekwencja operacji w transakcji redis nie musi być niepodzielna. Polecenia tworzące transakcję są weryfikowane i kolejkowane przed ich uruchomieniem. Jeśli w tej fazie wystąpi błąd, cała kolejka zostanie odrzucona. Jednak po pomyślnym przesłaniu transakcji kolejkowane polecenia są uruchamiane w sekwencji. Jeśli jakiekolwiek polecenie zakończy się niepowodzeniem, tylko to polecenie przestanie działać. Wszystkie poprzednie i kolejne polecenia w kolejce są wykonywane. Aby uzyskać więcej informacji, przejdź do strony Transakcje w witrynie internetowej usługi Redis.

• Usługa Redis obsługuje ograniczoną liczbę operacji niepodzielnych. Jedynymi operacjami tego typu, które obsługują wiele kluczy i wartości, są operacje MGET i MSET. Operacje MGET zwracają kolekcję wartości dla określonej listy kluczy, a operacje MSET przechowują kolekcję wartości dla określonej listy kluczy. Jeśli chcesz użyć tych operacji, pary klucz-wartość, do których odwołują się polecenia MSET i MGET, muszą być przechowywane w tej samej bazie danych.

Partycjonowanie usługi Azure Service Fabric

Azure Service Fabric to platforma mikrousług, która udostępnia środowisko uruchomieniowe dla aplikacji rozproszonych w chmurze. Usługa Service Fabric obsługuje pliki wykonywalne gościa platformy .NET, usługi stanowe i bezstanowe oraz kontenery. Usługi stanowe zapewniają niezawodną kolekcję do trwałego przechowywania danych w kolekcji klucz-wartość w klastrze usługi Service Fabric. Aby uzyskać więcej informacji na temat strategii partycjonowania kluczy w niezawodnej kolekcji, zobacz Wytyczne i zalecenia dotyczące niezawodnych kolekcji w usłudze Azure Service Fabric.

Dalsze kroki

• Omówienie usługi Azure Service Fabric to wprowadzenie do usługi Azure Service Fabric.

• Partycjonowanie niezawodnych usług usługi Service Fabric zawiera więcej informacji na temat niezawodnych usług w usłudze Azure Service Fabric.

Partycjonowanie usługi Azure Event Hubs

Usługa Azure Event Hubs jest przeznaczona do przesyłania strumieniowego danych na dużą skalę, a partycjonowanie jest wbudowane w usługę w celu umożliwienia skalowania w poziomie. Każdy odbiorca odczytuje tylko określoną partycję strumienia komunikatów.

Wydawca zdarzeń ma informacje tylko o kluczu partycji, a nie o partycji, do której publikowane są zdarzenia. To oddzielenie klucza od partycji powoduje, że nadawca nie musi wiedzieć zbyt dużo o przetwarzaniu podrzędnym. (Istnieje również możliwość wysyłania zdarzeń bezpośrednio do danej partycji, ale zazwyczaj nie jest to zalecane).

Podczas wybierania liczby partycji należy rozważyć długoterminową skalę. Po utworzeniu centrum zdarzeń nie można zmienić liczby partycji.

Dalsze kroki

Aby uzyskać więcej informacji na temat używania partycji w usłudze Event Hubs, zobacz Co to jest usługa Event Hubs?.

Aby zapoznać się z zagadnieniami dotyczącymi kompromisów między dostępnością a spójnością, zobacz Dostępność i spójność w usłudze Event Hubs.

W tym artykule opisano niektóre strategie partycjonowania danych w różnych magazynach danych platformy Azure. Aby uzyskać ogólne wskazówki dotyczące partycjonowania danych i najlepszych rozwiązań, zobacz Partycjonowanie danych.

Partycjonowanie usługi Azure SQL Database

Pojedyncza baza danych SQL ma limit ilości danych, które może zawierać. Przepływność jest ograniczona przez czynniki architektoniczne i liczbę współbieżnych połączeń, które obsługuje.

Elastyczne pule obsługują funkcję skalowania w poziomie dla bazy danych SQL. Za pomocą elastycznych pul można podzielić dane na fragmenty rozłożone na wiele baz danych SQL. Możesz również dodawać lub usuwać fragmenty jako ilość danych, które są potrzebne do obsługi wzrostu i zmniejszania. Elastyczne pule mogą również pomóc zmniejszyć rywalizację poprzez dystrybucję obciążenia między bazami danych.

Każdy fragment jest implementowany jako baza danych SQL. Fragment może zawierać więcej niż jeden zestaw danych (nazywany fragmentem). Każda baza danych przechowuje metadane opisujące zawarte w niej podfragmenty. Fragmentlet może być pojedynczym elementem danych lub grupą elementów, które współużytkujące ten sam klucz fragmentu. Na przykład w aplikacji wielodostępnej klucz podfragmentu może być identyfikatorem dzierżawy, a wszystkie dane dzierżawy mogą być przechowywane w tym samym podfragmentze.

Aplikacje klienckie są odpowiedzialne za kojarzenie zestawu danych z kluczem podfragmentu. Oddzielna baza danych SQL działa jako globalny menedżer mapy fragmentów. Ta baza danych zawiera listę wszystkich fragmentów i mikrofragmentów w systemie. Aplikacja łączy się z bazą danych menedżera mapy fragmentów w celu uzyskania kopii mapy fragmentów. Buforuje ona lokalnie mapę fragmentów i używa mapy do kierowania żądań danych do odpowiedniego fragmentu. Ta funkcja jest ukryta za serią interfejsów API zawartych w bibliotece klienta elastic database, która jest dostępna dla języków Java i .NET.

Aby uzyskać więcej informacji na temat elastycznych pul, zobacz Skalowanie w górę za pomocą usługi Azure SQL Database.

Aby zmniejszyć opóźnienia i zwiększyć dostępność, można replikować globalną bazę danych menedżera map fragmentów. W warstwach cenowych Premium można skonfigurować aktywną replikację geograficzną, aby stale kopiować dane do baz danych w różnych regionach.

Alternatywnie użyj usługi Azure SQL Data Sync lub Azure Data Factory , aby replikować bazę danych menedżera map fragmentów w różnych regionach. Ta forma replikacji jest okresowo uruchamiana i jest bardziej odpowiednia, jeśli mapa fragmentów zmienia się rzadko i nie wymaga warstwy Premium.

Elastyczna baza danych udostępnia dwa schematy mapowania danych na fragmenty i przechowywania ich w fragmentach:

• Mapa fragmentów listy kojarzy pojedynczy klucz z podfragmentem. Na przykład w systemie wielodostępnym dane dla każdego najemcy mogą być skojarzone z unikatowym kluczem i przechowywane w osobnym kawałku danych. Aby zagwarantować izolację, każdy mikrofragment może być przechowywany w ramach własnej części.

  

  Pobierz plik programu Visio tego diagramu.

• Mapa fragmentów zakresu kojarzy zestaw ciągłych wartości kluczy do fragmentu. Można na przykład zgrupować dane dla zestawu dzierżaw (z których każdy ma własny klucz) w ramach tego samego fragmentu. Ten schemat jest mniej kosztowny niż pierwszy, ponieważ dzierżawcy współdzielą magazyn danych, ale mają mniej izolacji.

  

  Pobierz plik Visio tego diagramu

Pojedynczy fragment może zawierać dane dla kilku podfragmentów. Na przykład można użyć fragmentów listy do przechowywania danych dla różnych dzierżaw nieciągłych w tym samym fragmentzie. Można również mieszać podfragmenty zakresu i podfragmenty listy w tym samym fragmentzie, chociaż będą one rozwiązywane za pomocą różnych map. Na poniższym diagramie przedstawiono takie podejście:

Pobierz plik programu Visio tego diagramu.

Elastyczne pule umożliwiają dodawanie i usuwanie fragmentów w miarę zmniejszania i zmniejszania ilości danych. Aplikacje klienckie mogą dynamicznie tworzyć i usuwać fragmenty oraz w sposób niewidoczny aktualizować menedżera map fragmentów. Jednak usunięcie fragmentu jest operacją destruktywną, która wymaga również usunięcia wszystkich danych w tym fragmentzie.

Jeśli aplikacja musi podzielić fragment na dwa oddzielne fragmenty lub połączyć fragmenty, użyj narzędzia split-merge. To narzędzie działa jako usługa internetowa platformy Azure i bezpiecznie migruje dane między fragmentami.

Schemat partycjonowania może znacząco wpłynąć na wydajność systemu. Może to również mieć wpływ na szybkość dodawania lub usuwania fragmentów albo ponowne partycjonowanie danych między fragmentami. Rozważ następujące kwestie:

• Grupuj dane używane razem w tym samym fragmentzie i unikaj operacji, które uzyskują dostęp do danych z wielu fragmentów. Fragment jest własną bazą danych SQL, a sprzężenia między bazami danych muszą być wykonywane po stronie klienta.

  Chociaż usługa SQL Database nie obsługuje sprzężeń między bazami danych, można użyć narzędzi Elastic Database do wykonywania zapytań obejmujących wiele fragmentów. Zapytanie wielofragmentowe wysyła poszczególne zapytania do każdej bazy danych i scala wyniki.

• Nie projektuj systemu, który ma zależności między fragmentami. Ograniczenia integralności referencyjnej, wyzwalacze i procedury składowane w jednej bazie danych nie mogą odwoływać się do obiektów w innej bazie danych.

• Jeśli masz dane referencyjne, które są często używane przez zapytania, rozważ replikowanie tych danych między fragmentami. Takie podejście może usunąć konieczność łączenia danych między bazami danych. W idealnym przypadku takie dane powinny być statyczne lub wolno przenoszone, aby zminimalizować nakład pracy związany z replikacją i zmniejszyć prawdopodobieństwo ich nieaktualności.

• Fragmenty należące do tej samej mapy fragmentów powinny mieć ten sam schemat. Ta reguła nie jest wymuszana przez usługę SQL Database, ale zarządzanie danymi i wykonywanie zapytań staje się bardzo złożone, jeśli każdy fragmentlet ma inny schemat. Zamiast tego utwórz oddzielne mapy fragmentów dla każdego schematu. Pamiętaj, że dane należące do różnych fragmentów mogą być przechowywane w tym samym fragmentzie.

• Operacje transakcyjne są obsługiwane tylko w przypadku danych w obrębie fragmentu, a nie między fragmentami. Transakcje mogą obejmować fragmenty, o ile są one częścią tego samego fragmentu. W związku z tym, jeśli logika biznesowa musi wykonywać transakcje, zapisz dane w tym samym fragmentze lub zaimplementuj spójność ostateczną.

• Umieść fragmenty w pobliżu użytkowników, którzy uzyskują dostęp do danych w tych fragmentach. Ta strategia pomaga zmniejszyć opóźnienie.

• Unikaj posiadania mieszaniny bardzo aktywnych i stosunkowo nieaktywnych fragmentów. Spróbuj równomiernie rozłożyć obciążenie na fragmenty. Może to wymagać tworzenia skrótów kluczy fragmentowania. Jeśli lokalizujesz fragmenty geograficzne, upewnij się, że skróty kluczy są mapowane na fragmenty przechowywane w fragmentach przechowywanych blisko użytkowników, którzy uzyskują dostęp do tych danych.

Partycjonowanie usługi Azure Table Storage

Azure Table Storage to magazyn klucz-wartość zaprojektowany wokół partycjonowania. Wszystkie jednostki są przechowywane w partycji, a partycje są zarządzane wewnętrznie przez usługę Azure Table Storage. Każda jednostka przechowywana w tabeli musi zawierać dwuczęściowy klucz, który obejmuje:

• Klucz partycji. Jest to wartość ciągu, która określa partycję, w której usługa Azure Table Storage umieści jednostkę. Wszystkie jednostki z tym samym kluczem partycji są przechowywane w tej samej partycji.

• Klucz wiersza. Jest to wartość ciągu, która identyfikuje jednostkę w partycji. Wszystkie jednostki w partycji są sortowane leksykalnie w kolejności rosnącej według tego klucza. Kombinacja klucza partycji/klucza wiersza musi być unikatowa dla każdej jednostki i nie może przekraczać 1 KB długości.

Jeśli jednostka zostanie dodana do tabeli z wcześniej nieużywanym kluczem partycji, usługa Azure Table Storage utworzy nową partycję dla tej jednostki. Inne jednostki z tym samym kluczem partycji będą przechowywane w tej samej partycji.

Ten mechanizm skutecznie implementuje strategię automatycznego skalowania w poziomie. Każda partycja jest przechowywana na tym samym serwerze w centrum danych platformy Azure, aby zapewnić szybkie uruchamianie zapytań pobierających dane z pojedynczej partycji.

Firma Microsoft opublikowała cele skalowalności dla usługi Azure Storage. Jeśli system prawdopodobnie przekroczy te limity, rozważ podzielenie jednostek na wiele tabel. Użyj partycjonowania pionowego, aby podzielić pola na grupy, do których najprawdopodobniej będzie uzyskiwany dostęp.

Na poniższym diagramie przedstawiono strukturę logiczną przykładowego konta magazynu. Konto magazynu zawiera trzy tabele: Informacje o kliencie, Informacje o produkcie i Informacje o zamówieniu.

Każda tabela ma wiele partycji.

• W tabeli Informacje o kliencie dane są partycjonowane według miasta, w którym znajduje się klient. Klucz wiersza zawiera identyfikator klienta.
• W tabeli Informacje o produkcie produkty są partycjonowane według kategorii produktów, a klucz wiersza zawiera numer produktu.
• W tabeli Informacje o zamówieniu zamówienia zamówienia są partycjonowane według daty zamówienia, a klucz wiersza określa godzinę odebrania zamówienia. Wszystkie dane są uporządkowane według klucza wiersza w każdej partycji.

Podczas projektowania jednostek dla usługi Azure Table Storage należy wziąć pod uwagę następujące kwestie:

• Wybierz klucz partycji i klucz wiersza według sposobu uzyskiwania dostępu do danych. Wybierz kombinację klucza partycji/klucza wiersza, która obsługuje większość zapytań. Najbardziej wydajne zapytania pobierają dane, określając klucz partycji i klucz wiersza. Zapytania określające klucz partycji i zakres kluczy wierszy można wykonać przez skanowanie pojedynczej partycji. Jest to stosunkowo szybkie, ponieważ dane są przechowywane w kolejności klucza wiersza. Jeśli zapytania nie określają partycji do skanowania, każda partycja musi zostać przeskanowana.

• Jeśli jednostka ma jeden klucz naturalny, użyj go jako klucza partycji i określ pusty ciąg jako klucz wiersza. Jeśli jednostka ma klucz złożony składający się z dwóch właściwości, wybierz najwolniej zmieniającą właściwość jako klucz partycji, a drugi jako klucz wiersza. Jeśli jednostka ma więcej niż dwie właściwości klucza, użyj łączenia właściwości w celu udostępnienia kluczy partycji i wierszy.

• Jeśli regularnie wykonujesz zapytania, które wyszukują dane przy użyciu pól innych niż klucze partycji i wierszy, rozważ zaimplementowanie wzorca tabeli indeksu lub rozważ użycie innego magazynu danych obsługującego indeksowanie, takiego jak usługa Azure Cosmos DB.

• W przypadku generowania kluczy partycji przy użyciu sekwencji monotonicznej (takiej jak "0001", "0002", "0003") i każda partycja zawiera tylko ograniczoną ilość danych, usługa Azure Table Storage może fizycznie zgrupować te partycje na tym samym serwerze. Usługa Azure Storage zakłada, że aplikacja najprawdopodobniej wykonuje zapytania w ciągłym zakresie partycji (zapytania zakresu) i jest zoptymalizowana pod kątem tego przypadku. Jednak takie podejście może prowadzić do hotspotów, ponieważ wszystkie wstawienia nowych jednostek mogą być skoncentrowane na jednym końcu ciągłego zakresu. Może również zmniejszyć skalowalność. Aby jeszcze bardziej równomiernie rozłożyć obciążenie, rozważ utworzenie skrótu klucza partycji.

• Usługa Azure Table Storage obsługuje operacje transakcyjne dla jednostek należących do tej samej partycji. Aplikacja może wykonywać wiele operacji wstawiania, aktualizowania, usuwania, zastępowania lub scalania jako jednostki niepodzielnej, o ile transakcja nie zawiera więcej niż 100 jednostek, a ładunek żądania nie przekracza 4 MB. Operacje obejmujące wiele partycji nie są transakcyjne i mogą wymagać zaimplementowania spójności ostatecznej. Aby uzyskać więcej informacji na temat magazynu tabel i transakcji, zobacz Wykonywanie transakcji grupy jednostek.

• Rozważ stopień szczegółowości klucza partycji:

  • Użycie tego samego klucza partycji dla każdej jednostki powoduje utworzenie pojedynczej partycji przechowywanej na jednym serwerze. Zapobiega to skalowaniu partycji w poziomie i skupia obciążenie na jednym serwerze. W związku z tym takie podejście jest odpowiednie tylko do przechowywania niewielkiej liczby jednostek. Jednak zapewnia, że wszystkie jednostki mogą uczestniczyć w transakcjach grupy jednostek.

  • Użycie unikatowego klucza partycji dla każdej jednostki powoduje utworzenie oddzielnej partycji dla każdej jednostki, co może spowodować powstanie dużej liczby małych partycji. Takie podejście jest bardziej skalowalne niż użycie pojedynczego klucza partycji, ale transakcje grup jednostek nie są możliwe. Ponadto zapytania pobierające więcej niż jedną jednostkę mogą obejmować odczytywanie z więcej niż jednego serwera. Jeśli jednak aplikacja wykonuje zapytania zakresu, użycie sekwencji monotonicznej dla kluczy partycji może pomóc w optymalizacji tych zapytań.

  • Udostępnianie klucza partycji w podzestawie jednostek umożliwia grupowanie powiązanych jednostek w tej samej partycji. Operacje obejmujące powiązane jednostki mogą być wykonywane przy użyciu transakcji grupy jednostek, a zapytania pobierające zestaw powiązanych jednostek mogą być spełnione przez uzyskanie dostępu do jednego serwera.

Aby uzyskać więcej informacji, zobacz Przewodnik projektowania tabel usługi Azure Storage i Skalowalna strategia partycjonowania.

Partycjonowanie usługi Azure Blob Storage

Usługa Azure Blob Storage umożliwia przechowywanie dużych obiektów binarnych. Blokowe obiekty blob można używać w scenariuszach, gdy trzeba szybko przekazać lub pobrać duże ilości danych. Użyj stronicowych obiektów blob dla aplikacji, które wymagają losowego, a nie szeregowego dostępu do części danych.

Każdy obiekt blob (blok lub strona) jest przechowywany w kontenerze na koncie usługi Azure Storage. Kontenery umożliwiają grupowanie powiązanych obiektów blob, które mają te same wymagania dotyczące zabezpieczeń. To grupowanie jest logiczne, a nie fizyczne. Wewnątrz kontenera każdy obiekt typu blob ma unikatową nazwę.

Klucz partycji dla obiektu blob to nazwa konta + nazwa kontenera i nazwa obiektu blob. Klucz partycji jest używany do partycjonowania danych na zakresy, a te zakresy są zrównoważone w całym systemie. Obiekty blob można dystrybuować na wielu serwerach w celu skalowania dostępu w poziomie do nich, ale pojedynczy obiekt blob może być obsługiwany tylko przez jeden serwer.

Jeśli schemat nazewnictwa używa sygnatur czasowych lub identyfikatorów liczbowych, może to prowadzić do nadmiernego ruchu przechodzącego do jednej partycji, ograniczając system od efektywnego równoważenia obciążenia. Jeśli na przykład masz codzienne operacje, które używają obiektu blob z sygnaturą czasową, taką jak rrrr-mm-dd, cały ruch dla tej operacji będzie kierowany do pojedynczego serwera partycji. Zamiast tego należy rozważyć prefiksowanie nazwy z trzycyfrowym skrótem. Aby uzyskać więcej informacji, zobacz Partition Naming Convention (Konwencja nazewnictwa partycji).

Akcje zapisu pojedynczego bloku lub strony są niepodzielne, ale operacje obejmujące bloki, strony lub obiekty blob nie są. Jeśli chcesz zapewnić spójność podczas wykonywania operacji zapisu w blokach, stronach i obiektach blob, wyjmij blokadę zapisu przy użyciu dzierżawy obiektu blob.

Partycjonowanie kolejek usługi Azure Storage

Kolejki usługi Azure Storage umożliwiają implementowanie asynchronicznych komunikatów między procesami. Konto usługi Azure Storage może zawierać dowolną liczbę kolejek, a każda kolejka może zawierać dowolną liczbę komunikatów. Jedynym ograniczeniem jest miejsce dostępne na koncie magazynu. Maksymalny rozmiar pojedynczego komunikatu to 64 KB. Jeśli potrzebujesz komunikatów większych niż ten, rozważ użycie kolejek usługi Azure Service Bus.

Każda kolejka magazynu ma unikatową nazwę na koncie magazynu, które go zawiera. Kolejki partycji platformy Azure są oparte na nazwie. Wszystkie komunikaty dla tej samej kolejki są przechowywane w tej samej partycji, która jest kontrolowana przez pojedynczy serwer. Różne kolejki mogą być zarządzane przez różne serwery, aby ułatwić równoważenie obciążenia. Alokacja kolejek do serwerów jest niewidoczna dla aplikacji i użytkowników.

W aplikacji na dużą skalę nie używaj tej samej kolejki magazynu dla wszystkich wystąpień aplikacji, ponieważ takie podejście może spowodować, że serwer hostujący kolejkę stanie się punktem gorącym. Zamiast tego należy używać różnych kolejek dla różnych obszarów funkcjonalnych aplikacji. Kolejki usługi Azure Storage nie obsługują transakcji, więc kierowanie komunikatów do różnych kolejek powinno mieć niewielki wpływ na spójność komunikatów.

Kolejka usługi Azure Storage może obsługiwać maksymalnie 2000 komunikatów na sekundę. Jeśli musisz przetwarzać komunikaty z większą szybkością, rozważ utworzenie wielu kolejek. Na przykład w aplikacji globalnej utwórz oddzielne kolejki magazynu na oddzielnych kontach magazynu w celu obsługi wystąpień aplikacji uruchomionych w każdym regionie.

Partycjonowanie usługi Azure Service Bus

Usługa Azure Service Bus używa brokera komunikatów do obsługi komunikatów wysyłanych do kolejki lub tematu usługi Service Bus. Domyślnie wszystkie komunikaty wysyłane do kolejki lub tematu są obsługiwane przez ten sam proces brokera komunikatów. Ta architektura może ograniczać ogólną przepływność kolejki komunikatów. Można jednak również partycjonować kolejkę lub temat podczas jego tworzenia. W tym celu należy ustawić właściwość EnablePartitioning kolejki lub opisu tematu na wartość true.

Partycjonowana kolejka lub temat jest podzielona na wiele fragmentów, z których każda jest wspierana przez oddzielny magazyn komunikatów i broker komunikatów. Usługa Service Bus ponosi odpowiedzialność za tworzenie tych fragmentów i zarządzanie nimi. Gdy aplikacja publikuje komunikat do partycjonowanej kolejki lub tematu, usługa Service Bus przypisuje komunikat do fragmentu dla tej kolejki lub tematu. Gdy aplikacja odbiera komunikat z kolejki lub subskrypcji, usługa Service Bus sprawdza każdy fragment następnego dostępnego komunikatu, a następnie przekazuje go do aplikacji do przetwarzania.

Ta struktura ułatwia dystrybucję obciążenia między brokerami komunikatów i magazynami komunikatów, zwiększając skalowalność i zwiększając dostępność. Jeśli broker komunikatów lub magazyn komunikatów dla jednego fragmentu jest tymczasowo niedostępny, usługa Service Bus może pobrać komunikaty z jednego z pozostałych dostępnych fragmentów.

Usługa Service Bus przypisuje komunikat do fragmentu w następujący sposób:

• Jeśli komunikat należy do sesji, wszystkie komunikaty o tej samej wartości właściwości SessionId są wysyłane do tego samego fragmentu.

• Jeśli komunikat nie należy do sesji, ale nadawca określił wartość właściwości PartitionKey , wszystkie komunikaty o tej samej wartości PartitionKey są wysyłane do tego samego fragmentu.

  Uwaga / Notatka

  Jeśli właściwości SessionId i PartitionKey są określone, muszą być ustawione na tę samą wartość lub komunikat zostanie odrzucony.

• Jeśli właściwości SessionId i PartitionKey dla komunikatu nie zostaną określone, ale zostanie włączone wykrywanie duplikatów, zostanie użyta właściwość MessageId . Wszystkie komunikaty o tym samym identyfikatorze MessageId zostaną przekierowane do tego samego fragmentu.

• Jeśli komunikaty nie zawierają właściwości SessionId, PartitionKey lub MessageId , usługa Service Bus przypisuje komunikaty do fragmentów sekwencyjnie. Jeśli fragment jest niedostępny, usługa Service Bus przejdzie do następnego. Oznacza to, że tymczasowa usterka w infrastrukturze obsługi komunikatów nie powoduje niepowodzenia operacji wysyłania komunikatów.

Podczas określania, czy lub jak partycjonować kolejkę komunikatów usługi Service Bus lub temat, należy wziąć pod uwagę następujące kwestie:

• Kolejki i tematy usługi Service Bus są tworzone w zakresie przestrzeni nazw usługi Service Bus. Usługa Service Bus obecnie umożliwia maksymalnie 100 partycjonowanych kolejek lub tematów na przestrzeń nazw.

• Każda przestrzeń nazw usługi Service Bus nakłada limity przydziału na dostępne zasoby, takie jak liczba subskrypcji na temat, liczba współbieżnych żądań wysyłania i odbierania na sekundę oraz maksymalna liczba współbieżnych połączeń, które można ustanowić. Te przydziały są udokumentowane w temacie Limity przydziału usługi Service Bus. Jeśli spodziewasz się przekroczyć te wartości, utwórz dodatkowe przestrzenie nazw z własnymi kolejkami i tematami i rozłóż pracę w tych przestrzeniach nazw. Na przykład w aplikacji globalnej utwórz oddzielne przestrzenie nazw w każdym regionie i skonfiguruj wystąpienia aplikacji do używania kolejek i tematów w najbliższej przestrzeni nazw.

• Komunikaty wysyłane w ramach transakcji muszą określać klucz partycji. Może to być właściwość SessionId, PartitionKey lub MessageId . Wszystkie komunikaty wysyłane w ramach tej samej transakcji muszą określać ten sam klucz partycji, ponieważ muszą być obsługiwane przez ten sam proces brokera komunikatów. Nie można wysyłać komunikatów do różnych kolejek lub tematów w ramach tej samej transakcji.

• Nie można skonfigurować partycjonowanych kolejek i tematów do automatycznego usuwania, gdy staną się bezczynne.

• Partycjonowane kolejki i tematy nie mogą być obecnie używane z protokołem Advanced Message Queuing Protocol (AMQP), jeśli tworzysz rozwiązania międzyplatformowe lub hybrydowe.

Partycjonowanie usługi Azure Cosmos DB

Usługa Azure Cosmos DB for NoSQL to baza danych NoSQL służąca do przechowywania dokumentów JSON. Dokument w bazie danych usługi Azure Cosmos DB jest serializowaną reprezentacją obiektu lub innego elementu danych w formacie JSON. Nie są wymuszane żadne stałe schematy, z tą różnicą, że każdy dokument musi zawierać unikatowy identyfikator.

Dokumenty są zorganizowane w kolekcje. Powiązane dokumenty można grupować razem w kolekcji. Na przykład w systemie, który przechowuje wpisy w blogu, można przechowywać zawartość każdego wpisu w blogu jako dokument w kolekcji. Można również tworzyć kolekcje dla każdego typu tematu. Alternatywnie w aplikacji wielodostępnej, takiej jak system, w którym różni autorzy kontrolują własne wpisy w blogu i zarządzają nimi, możesz podzielić blogi według autora i utworzyć oddzielne kolekcje dla każdego autora. Miejsce do magazynowania przydzielone do kolekcji jest elastyczne i może się zmniejszać lub zwiększać w razie potrzeby.

Usługa Azure Cosmos DB obsługuje automatyczne partycjonowanie danych na podstawie klucza partycji zdefiniowanego przez aplikację. Partycja logiczna to partycja, która przechowuje wszystkie dane dla pojedynczej wartości klucza partycji. Wszystkie dokumenty, które współużytkują tę samą wartość klucza partycji, są umieszczane w tej samej partycji logicznej. Usługa Azure Cosmos DB dystrybuuje wartości według skrótu klucza partycji. Partycja logiczna ma maksymalny rozmiar 20 GB. W związku z tym wybór klucza partycji jest ważną decyzją w czasie projektowania. Wybierz właściwość z szerokim zakresem wartości, a nawet wzorcami dostępu. Aby uzyskać więcej informacji, zobacz Partition and scale in Azure Cosmos DB (Partycjonowanie i skalowanie w usłudze Azure Cosmos DB).

Uwaga / Notatka

Każda baza danych usługi Azure Cosmos DB ma poziom wydajności , który określa ilość pobieranych zasobów. Poziom wydajności jest skojarzony z limitem szybkości jednostki żądania (RU). Limit szybkości jednostek żądania określa ilość zasobów zarezerwowanych i dostępnych do wyłącznego użytku przez te kolekcje. Koszt kolekcji zależy od poziomu wydajności wybranego dla tej kolekcji. Im wyższy poziom wydajności (i limit szybkości jednostek RU), tym wyższe opłaty. Poziom wydajności kolekcji można dostosować przy użyciu witryny Azure Portal. Aby uzyskać więcej informacji, zobacz Request Units in Azure Cosmos DB (Jednostki żądań w usłudze Azure Cosmos DB).

Jeśli mechanizm partycjonowania zapewniany przez usługę Azure Cosmos DB nie jest wystarczający, może być konieczne podzielenie danych na poziomie aplikacji. Kolekcje dokumentów zapewniają naturalny mechanizm partycjonowania danych w jednej bazie danych. Najprostszym sposobem zaimplementowania fragmentowania jest utworzenie kolekcji dla każdego fragmentu. Kontenery są zasobami logicznymi i mogą obejmować co najmniej jeden serwer. Kontenery o stałym rozmiarze mają maksymalny limit 20 GB i 10 000 RU/s przepływności. Kontenery bez ograniczeń nie mają maksymalnego rozmiaru magazynu, ale muszą określać klucz partycji. W przypadku fragmentowania aplikacji aplikacja kliencka musi kierować żądania do odpowiedniego fragmentu, zwykle implementując własny mechanizm mapowania na podstawie niektórych atrybutów danych, które definiują klucz fragmentu.

Wszystkie bazy danych są tworzone w kontekście konta bazy danych usługi Azure Cosmos DB. Jedno konto może zawierać kilka baz danych i określa, w których regionach tworzone są bazy danych. Każde konto wymusza również własną kontrolę dostępu. Konta usługi Azure Cosmos DB można używać do lokalizowania fragmentów geograficznych (kolekcji w bazach danych) blisko użytkowników, którzy muszą uzyskać do nich dostęp, i wymuszać ograniczenia, aby tylko ci użytkownicy mogli się z nimi łączyć.

Podczas podejmowania decyzji o sposobie partycjonowania danych za pomocą usługi Azure Cosmos DB for NoSQL należy wziąć pod uwagę następujące kwestie:

• Zasoby dostępne dla bazy danych usługi Azure Cosmos DB podlegają ograniczeniom przydziału konta. Każda baza danych może przechowywać wiele kolekcji, a każda kolekcja jest skojarzona z poziomem wydajności, który zarządza limitem szybkości jednostek ŻĄDANIA (zarezerwowaną przepływnością) dla tej kolekcji. Aby uzyskać więcej informacji, zobacz Ograniczenia subskrypcji i usług Azure, limity, kwoty i ograniczenia.

• Każdy dokument musi mieć atrybut, który może służyć do unikatowego identyfikowania tego dokumentu w kolekcji, w której jest przechowywany. Ten atrybut różni się od klucza fragmentu, który definiuje, która kolekcja zawiera dokument. Kolekcja może zawierać dużą liczbę dokumentów. Teoretycznie jest to ograniczone tylko przez maksymalną długość identyfikatora dokumentu. Identyfikator dokumentu może zawierać maksymalnie 255 znaków.

• Wszystkie operacje względem dokumentu są wykonywane w kontekście transakcji. Transakcje są ograniczone do kolekcji, w której znajduje się dokument. Jeśli operacja zakończy się niepowodzeniem, praca, którą wykonała, zostanie wycofana. Gdy dokument podlega operacji, wszelkie wprowadzone zmiany podlegają izolacji na poziomie migawki. Ten mechanizm gwarantuje, że jeśli na przykład żądanie utworzenia nowego dokumentu zakończy się niepowodzeniem, inny użytkownik, który wysyła zapytanie do bazy danych jednocześnie, nie zobaczy częściowego dokumentu, który zostanie usunięty.

• Zapytania bazy danych są również ograniczone do poziomu kolekcji. Pojedyncze zapytanie może pobierać dane tylko z jednej kolekcji. Jeśli musisz pobrać dane z wielu kolekcji, musisz wykonać zapytanie dotyczące każdej kolekcji indywidualnie i scalić wyniki w kodzie aplikacji.

• Usługa Azure Cosmos DB obsługuje programowalne elementy, które mogą być przechowywane w kolekcji wraz z dokumentami. Obejmują one procedury składowane, funkcje zdefiniowane przez użytkownika i wyzwalacze (napisane w języku JavaScript). Te elementy mogą uzyskiwać dostęp do dowolnego dokumentu w tej samej kolekcji. Ponadto te elementy są uruchamiane wewnątrz zakresu transakcji otoczenia (w przypadku wyzwalacza uruchamianego w wyniku operacji tworzenia, usuwania lub zastępowania wykonywanej względem dokumentu) lub przez uruchomienie nowej transakcji (w przypadku procedury składowanej, która jest uruchamiana w wyniku jawnego żądania klienta). Jeśli kod w elemencie programowalnym zgłasza wyjątek, transakcja zostanie wycofana. Można użyć procedur składowanych i wyzwalaczy, aby zachować integralność i spójność między dokumentami, ale wszystkie te dokumenty muszą być częścią tej samej kolekcji.

• Kolekcje, które mają być przechowywane w bazach danych, powinny być mało prawdopodobne, aby przekroczyć limity przepływności zdefiniowane przez poziomy wydajności kolekcji. Aby uzyskać więcej informacji, zobacz Request Units in Azure Cosmos DB (Jednostki żądań w usłudze Azure Cosmos DB). Jeśli przewidujesz osiągnięcie tych limitów, rozważ podzielenie kolekcji między bazami danych na różnych kontach, aby zmniejszyć obciążenie kolekcji.

Partycjonowanie usługi Azure AI Search

Możliwość wyszukiwania danych jest często podstawową metodą nawigacji i eksploracji zapewnianej przez wiele aplikacji internetowych. Ułatwia to użytkownikom szybkie znajdowanie zasobów (na przykład produktów w aplikacji do handlu elektronicznego) na podstawie kombinacji kryteriów wyszukiwania. Usługa wyszukiwania sztucznej inteligencji udostępnia funkcje wyszukiwania pełnotekstowego za pośrednictwem zawartości internetowej i zawiera funkcje, takie jak typ-ahead, sugerowane zapytania na podstawie bliskich dopasowań i nawigacja aspektowa. Aby uzyskać więcej informacji, zobacz Co to jest wyszukiwanie sztucznej inteligencji?.

Usługa AI Search przechowuje zawartość z możliwością wyszukiwania jako dokumenty JSON w bazie danych. Definiujesz indeksy, które określają pola z możliwością wyszukiwania w tych dokumentach i udostępniają te definicje w wyszukiwaniu sztucznej inteligencji. Gdy użytkownik przesyła żądanie wyszukiwania, wyszukiwanie sztucznej inteligencji używa odpowiednich indeksów do znajdowania pasujących elementów.

Aby zmniejszyć rywalizację, magazyn używany przez wyszukiwanie sztucznej inteligencji można podzielić na 1, 2, 3, 4, 6 lub 12 partycji, a każda partycja może być replikowana maksymalnie 6 razy. Iloczyn liczby partycji pomnożonych przez liczbę replik jest nazywany jednostką wyszukiwania (SU). Pojedyncze wystąpienie wyszukiwania sztucznej inteligencji może zawierać maksymalnie 36 jednostek jednostki operacyjnego (baza danych z 12 partycjami obsługuje tylko maksymalnie 3 repliki).

Opłaty są naliczane za każdą jednostkę SU przydzieloną do usługi. W miarę zwiększania się ilości zawartości z możliwością wyszukiwania lub zwiększania szybkości żądań wyszukiwania można dodać jednostki SU do istniejącego wystąpienia wyszukiwania sztucznej inteligencji w celu obsługi dodatkowego obciążenia. Samo wyszukiwanie sztucznej inteligencji równomiernie dystrybuuje dokumenty między partycjami. Obecnie nie są obsługiwane żadne strategie partycjonowania ręcznego.

Każda partycja może zawierać maksymalnie 15 milionów dokumentów lub zajmować 300 GB miejsca do magazynowania (w zależności od tego, co jest mniejsze). Można utworzyć maksymalnie 50 indeksów. Wydajność usługi różni się i zależy od złożoności dokumentów, dostępnych indeksów i wpływu opóźnienia sieci. Średnio pojedyncza replika (1 jednostka SU) powinna być w stanie obsłużyć 15 zapytań na sekundę (QPS), chociaż zalecamy przeprowadzenie testów porównawczych z własnymi danymi w celu uzyskania bardziej precyzyjnej miary przepływności. Aby uzyskać więcej informacji, zobacz Limity usługi w wyszukiwaniu sztucznej inteligencji.

Uwaga / Notatka

Ograniczony zestaw typów danych można przechowywać w dokumentach z możliwością wyszukiwania, w tym ciągów, wartości logicznych, danych liczbowych, danych daty/godziny i niektórych danych geograficznych. Aby uzyskać więcej informacji, zobacz stronę Obsługiwane typy danych (AI Search) w witrynie internetowej firmy Microsoft.

Masz ograniczoną kontrolę nad sposobem partycjonowania danych wyszukiwania sztucznej inteligencji dla każdego wystąpienia usługi. Jednak w środowisku globalnym może być możliwe dalsze zwiększenie wydajności i zmniejszenie opóźnienia i rywalizacji przez partycjonowanie samej usługi przy użyciu jednej z następujących strategii:

• Utwórz wystąpienie wyszukiwania sztucznej inteligencji w każdym regionie geograficznym i upewnij się, że aplikacje klienckie są kierowane do najbliższego dostępnego wystąpienia. Ta strategia wymaga, aby wszystkie aktualizacje zawartości z możliwością wyszukiwania zostały zreplikowane w odpowiednim czasie we wszystkich wystąpieniach usługi.

• Utwórz dwie warstwy wyszukiwania sztucznej inteligencji:

  • Usługa lokalna w każdym regionie, która zawiera dane najczęściej używane przez użytkowników w tym regionie. Użytkownicy mogą tutaj kierować żądania w celu uzyskania szybkich, ale ograniczonych wyników.
  • Globalna usługa obejmująca wszystkie dane. Użytkownicy mogą tutaj kierować żądania, aby uzyskać wolniejsze, ale bardziej kompletne wyniki.

Takie podejście jest najbardziej odpowiednie, gdy istnieje znaczna odmiana regionalna danych, które są przeszukiwane.

Partycjonowanie usługi Azure Cache for Redis

Usługa Azure Cache for Redis udostępnia udostępnioną usługę buforowania w chmurze opartą na magazynie danych klucz-wartość usługi Redis. Jak sama nazwa wskazuje, usługa Azure Cache for Redis jest przeznaczona jako rozwiązanie buforowania. Służy tylko do przechowywania danych przejściowych, a nie jako trwałego magazynu danych. Aplikacje korzystające z usługi Azure Cache for Redis powinny mieć możliwość kontynuowania działania, jeśli pamięć podręczna jest niedostępna. Usługa Azure Cache for Redis obsługuje replikację podstawową/pomocniczą w celu zapewnienia wysokiej dostępności, ale obecnie ogranicza maksymalny rozmiar pamięci podręcznej do 53 GB. Jeśli potrzebujesz więcej miejsca, musisz utworzyć dodatkowe pamięci podręczne. Aby uzyskać więcej informacji, zobacz Pamięć podręczna Azure Cache for Redis.

Partycjonowanie magazynu danych Usługi Redis obejmuje podzielenie danych między wystąpienia usługi Redis. Każde wystąpienie stanowi jedną partycję. Usługa Azure Cache for Redis abstruje usługi Redis za fasadą i nie udostępnia ich bezpośrednio. Najprostszym sposobem implementacji partycjonowania jest utworzenie wielu wystąpień usługi Azure Cache for Redis i rozłożenie na nie danych.

Każdy element danych można skojarzyć z identyfikatorem (kluczem partycji), który określa, która pamięć podręczna przechowuje element danych. Logika aplikacji klienckiej może następnie użyć tego identyfikatora do kierowania żądań do odpowiedniej partycji. Ten schemat jest bardzo prosty, ale jeśli schemat partycjonowania ulegnie zmianie (na przykład w przypadku utworzenia dodatkowych wystąpień usługi Azure Cache for Redis), aplikacje klienckie mogą wymagać ponownej konfiguracji.

Natywna usługa Redis (a nie usługa Azure Cache for Redis) obsługuje partycjonowanie po stronie serwera na podstawie klastrowania Usługi Redis. W tym podejściu można równomiernie podzielić dane między serwerami przy użyciu mechanizmu tworzenia skrótów. Każdy serwer Redis przechowuje metadane opisujące zakres kluczy skrótów przechowywanych przez partycję, a także informacje o tym, które klucze skrótu znajdują się w partycjach na innych serwerach.

Aplikacje klienckie po prostu wysyłają żądania do dowolnego z uczestniczących serwerów Redis (prawdopodobnie najbliższego). Serwer Redis sprawdza żądanie klienta. Jeśli można go rozpoznać lokalnie, wykonuje żądaną operację. W przeciwnym razie przekazuje żądanie do odpowiedniego serwera.

Ten model jest implementowany przy użyciu klastrowania Redis i opisano go bardziej szczegółowo na stronie samouczka klastra Redis w witrynie internetowej usługi Redis. Klastrowanie usługi Redis jest niewidoczne dla aplikacji klienckich. Dodatkowe serwery Redis można dodać do klastra (a dane można ponownie partycjonować) bez konieczności ponownego konfigurowania klientów.

Ważne

Usługa Azure Cache for Redis obecnie obsługuje klastrowanie usługi Redis tylko w warstwie Premium.

Strona Partycjonowanie: sposób dzielenia danych między wiele wystąpień usługi Redis w witrynie internetowej usługi Redis zawiera więcej informacji na temat implementowania partycjonowania za pomocą usługi Redis. W pozostałej części tej sekcji założono, że implementujesz partycjonowanie po stronie klienta lub oparte na serwerze proxy.

Podczas podejmowania decyzji o sposobie partycjonowania danych za pomocą usługi Azure Cache for Redis należy wziąć pod uwagę następujące kwestie:

• Usługa Azure Cache for Redis nie jest przeznaczona do działania jako trwały magazyn danych, dlatego niezależnie od wdrożonego schematu partycjonowania kod aplikacji musi mieć możliwość pobierania danych z lokalizacji, która nie jest pamięcią podręczną.

• Dane, do których często uzyskuje się dostęp, powinny być przechowywane w tej samej partycji. Redis to zaawansowany magazyn par klucz-wartość, który zapewnia kilka wysoce zoptymalizowanych mechanizmów do tworzenia struktur danych. Te mechanizmy mogą być jednym z następujących elementów:

  • Proste ciągi (dane binarne o długości do 512 MB)
  • Typy agregacji, takie jak listy (które mogą działać jako kolejki i stosy)
  • Zestawy (uporządkowane i nieurządzone)
  • Skróty (które mogą grupować powiązane pola, takie jak elementy reprezentujące pola w obiekcie)

• Typy agregacji umożliwiają skojarzenie wielu powiązanych wartości z tym samym kluczem. Klucz usługi Redis identyfikuje listę, zestaw lub skrót, a nie elementy danych, które zawiera. Wszystkie te typy są dostępne w usłudze Azure Cache for Redis i są opisane na stronie Typy danych w witrynie internetowej usługi Redis. Na przykład w części systemu handlu elektronicznego, który śledzi zamówienia złożone przez klientów, szczegóły każdego klienta mogą być przechowywane w skrótie usługi Redis, który jest kluczem przy użyciu identyfikatora klienta. Każdy skrót może przechowywać kolekcję identyfikatorów zamówień dla klienta. Oddzielny zestaw usługi Redis może przechowywać zamówienia, ponownie ustrukturyzowane jako skróty i kluczowane przy użyciu identyfikatora zamówienia. Rysunek 8 przedstawia tę strukturę. Należy pamiętać, że usługa Redis nie implementuje żadnej formy integralności referencyjnej, dlatego deweloper odpowiada za utrzymanie relacji między klientami i zamówieniami.

Rysunek 8. Sugerowana struktura w magazynie Redis na potrzeby rejestrowania zamówień klientów i ich szczegółów.

Uwaga / Notatka

W usłudze Redis wszystkie klucze są wartościami danych binarnych (takimi jak ciągi usługi Redis) i mogą zawierać do 512 MB danych. Teoretycznie klucz może zawierać prawie wszystkie informacje. Zalecamy jednak przyjęcie spójnej konwencji nazewnictwa kluczy opisowych typu danych i identyfikacji jednostki, ale nie jest zbyt długa. Typowym podejściem jest użycie kluczy formularza "entity_type:ID". Na przykład możesz użyć ciągu "customer:99", aby wskazać klucz klienta o identyfikatorze 99.

• Partycjonowanie pionowe można zaimplementować, przechowując powiązane informacje w różnych agregacjach w tej samej bazie danych. Na przykład w aplikacji do handlu elektronicznego można przechowywać często używane informacje o produktach w jednym skrótzie usługi Redis i rzadziej używane szczegółowe informacje w innym. Oba skróty mogą używać tego samego identyfikatora produktu w ramach klucza. Na przykład możesz użyć wartości "product: nn" (gdzie nn jest identyfikatorem produktu) dla informacji o produkcie i "product_details: nn" dla szczegółowych danych. Ta strategia może pomóc zmniejszyć ilość danych, które najprawdopodobniej będą pobierane przez większość zapytań.

• Magazyn danych usługi Redis można ponownie partycjonować, ale należy pamiętać, że jest to złożone i czasochłonne zadanie. Klastrowanie usługi Redis może automatycznie ponownie partycjonować dane, ale ta funkcja nie jest dostępna w usłudze Azure Cache for Redis. W związku z tym podczas projektowania schematu partycjonowania spróbuj pozostawić wystarczającą ilość wolnego miejsca w każdej partycji, aby umożliwić oczekiwany wzrost danych w czasie. Należy jednak pamiętać, że usługa Azure Cache for Redis jest przeznaczona do tymczasowego buforowania danych, a dane przechowywane w pamięci podręcznej mogą mieć ograniczony okres istnienia określony jako wartość czasu wygaśnięcia (TTL). W przypadku stosunkowo nietrwałych danych czas wygaśnięcia może być krótki, ale w przypadku danych statycznych czas wygaśnięcia może być znacznie dłuższy. Unikaj przechowywania dużych ilości danych długotrwałych w pamięci podręcznej, jeśli ilość tych danych może wypełnić pamięć podręczną. Możesz określić zasady eksmisji, które powodują, że usługa Azure Cache for Redis usuwa dane, jeśli miejsce jest w warstwie Premium.

  Uwaga / Notatka

  W przypadku korzystania z usługi Azure Cache for Redis należy określić maksymalny rozmiar pamięci podręcznej (od 250 MB do 53 GB), wybierając odpowiednią warstwę cenową. Jednak po utworzeniu usługi Azure Cache for Redis nie można zwiększyć (ani zmniejszyć) jej rozmiaru.

• Partie i transakcje usługi Redis nie mogą obejmować wielu połączeń, więc wszystkie dane, których dotyczy partia lub transakcja, powinny być przechowywane w tej samej bazie danych (fragment).

  Uwaga / Notatka

  Sekwencja operacji w transakcji redis nie musi być niepodzielna. Polecenia tworzące transakcję są weryfikowane i kolejkowane przed ich uruchomieniem. Jeśli w tej fazie wystąpi błąd, cała kolejka zostanie odrzucona. Jednak po pomyślnym przesłaniu transakcji kolejkowane polecenia są uruchamiane w sekwencji. Jeśli jakiekolwiek polecenie zakończy się niepowodzeniem, tylko to polecenie przestanie działać. Wszystkie poprzednie i kolejne polecenia w kolejce są wykonywane. Aby uzyskać więcej informacji, przejdź do strony Transakcje w witrynie internetowej usługi Redis.

• Usługa Redis obsługuje ograniczoną liczbę operacji niepodzielnych. Jedynymi operacjami tego typu, które obsługują wiele kluczy i wartości, są operacje MGET i MSET. Operacje MGET zwracają kolekcję wartości dla określonej listy kluczy, a operacje MSET przechowują kolekcję wartości dla określonej listy kluczy. Jeśli chcesz użyć tych operacji, pary klucz-wartość, do których odwołują się polecenia MSET i MGET, muszą być przechowywane w tej samej bazie danych.

Partycjonowanie usługi Azure Service Fabric

Azure Service Fabric to platforma mikrousług, która udostępnia środowisko uruchomieniowe dla aplikacji rozproszonych w chmurze. Usługa Service Fabric obsługuje pliki wykonywalne gościa platformy .NET, usługi stanowe i bezstanowe oraz kontenery. Usługi stanowe zapewniają niezawodną kolekcję do trwałego przechowywania danych w kolekcji klucz-wartość w klastrze usługi Service Fabric. Aby uzyskać więcej informacji na temat strategii partycjonowania kluczy w niezawodnej kolekcji, zobacz Wytyczne i zalecenia dotyczące niezawodnych kolekcji w usłudze Azure Service Fabric.

Dalsze kroki

• Omówienie usługi Azure Service Fabric to wprowadzenie do usługi Azure Service Fabric.

• Partycjonowanie niezawodnych usług usługi Service Fabric zawiera więcej informacji na temat niezawodnych usług w usłudze Azure Service Fabric.

Partycjonowanie usługi Azure Event Hubs

Usługa Azure Event Hubs jest przeznaczona do przesyłania strumieniowego danych na dużą skalę, a partycjonowanie jest wbudowane w usługę w celu umożliwienia skalowania w poziomie. Każdy odbiorca odczytuje tylko określoną partycję strumienia komunikatów.

Wydawca zdarzeń ma informacje tylko o kluczu partycji, a nie o partycji, do której publikowane są zdarzenia. To oddzielenie klucza od partycji powoduje, że nadawca nie musi wiedzieć zbyt dużo o przetwarzaniu podrzędnym. (Istnieje również możliwość wysyłania zdarzeń bezpośrednio do danej partycji, ale zazwyczaj nie jest to zalecane).

Podczas wybierania liczby partycji należy rozważyć długoterminową skalę. Po utworzeniu centrum zdarzeń nie można zmienić liczby partycji.

Dalsze kroki

Aby uzyskać więcej informacji na temat używania partycji w usłudze Event Hubs, zobacz Co to jest usługa Event Hubs?.

Aby zapoznać się z zagadnieniami dotyczącymi kompromisów między dostępnością a spójnością, zobacz Dostępność i spójność w usłudze Event Hubs.