Co to jest magazyn analityczny usługi Azure Cosmos DB?

Artykuł
08/15/2024

DOTYCZY: NoSQL MongoDB Gremlin

Ważne

Dublowanie usługi Azure Cosmos DB w usłudze Microsoft Fabric jest teraz dostępne dla interfejsu API NoSql. Ta funkcja zapewnia wszystkie możliwości usługi Azure Synapse Link z lepszą wydajnością analityczną, możliwość ujednolicenia majątku danych za pomocą usługi Fabric OneLake i otwierania dostępu do danych w formacie Delta Parquet. Jeśli rozważasz usługę Azure Synapse Link, zalecamy wypróbowanie dublowania w celu oceny ogólnego dopasowania organizacji. Wprowadzenie do dublowania w usłudze Microsoft Fabric.

Aby rozpocząć pracę z usługą Azure Synapse Link, odwiedź stronę "Wprowadzenie do usługi Azure Synapse Link"

Magazyn analityczny usługi Azure Cosmos DB to w pełni izolowany magazyn kolumn umożliwiający analizowanie na dużą skalę danych operacyjnych w usłudze Azure Cosmos DB bez wpływu na obciążenia transakcyjne.

Wyzwania związane z analizą na dużą skalę na dane operacyjne

Wielomodelowe dane operacyjne w kontenerze usługi Azure Cosmos DB są przechowywane wewnętrznie w indeksowanym magazynie transakcyjnym opartym na wierszach. Format magazynu wierszy został zaprojektowany tak, aby umożliwić szybkie operacje odczytu i zapisu w czasie odpowiedzi w milisekundach i zapytaniach operacyjnych. Jeśli zestaw danych będzie duży, złożone zapytania analityczne mogą być kosztowne pod względem aprowizowanej przepływności danych przechowywanych w tym formacie. Z kolei wysokie użycie aprowizowanej przepływności wpływa na wydajność obciążeń transakcyjnych używanych przez aplikacje i usługi w czasie rzeczywistym.

Tradycyjnie, aby analizować duże ilości danych, dane operacyjne są wyodrębniane z transakcyjnego magazynu usługi Azure Cosmos DB i przechowywane w oddzielnej warstwie danych. Na przykład dane są przechowywane w magazynie danych lub usłudze Data Lake w odpowiednim formacie. Te dane są później używane do analizy na dużą skalę i analizowane przy użyciu aparatów obliczeniowych, takich jak klastry Platformy Apache Spark. Rozdzielenie danych analitycznych z danych operacyjnych powoduje opóźnienia dla analityków, którzy chcą korzystać z najnowszych danych.

Potoki ETL stają się również złożone podczas obsługi aktualizacji danych operacyjnych w porównaniu z obsługą tylko nowo pozyskanych danych operacyjnych.

Magazyn analityczny zorientowany na kolumnę

Magazyn analityczny usługi Azure Cosmos DB rozwiązuje problemy związane ze złożonością i opóźnieniami, które występują w przypadku tradycyjnych potoków ETL. Magazyn analityczny usługi Azure Cosmos DB może automatycznie synchronizować dane operacyjne z oddzielnym magazynem kolumn. Format magazynu kolumn nadaje się do wykonywania zapytań analitycznych na dużą skalę w zoptymalizowany sposób, co zwiększa opóźnienie takich zapytań.

Korzystając z usługi Azure Synapse Link, można teraz tworzyć rozwiązania HTAP no-ETL, łącząc się bezpośrednio z magazynem analitycznym usługi Azure Cosmos DB z usługi Azure Synapse Analytics. Umożliwia ona uruchamianie analizy na dużą skalę niemal w czasie rzeczywistym na danych operacyjnych.

Funkcje magazynu analitycznego

Po włączeniu magazynu analitycznego w kontenerze usługi Azure Cosmos DB nowy magazyn kolumn jest tworzony wewnętrznie na podstawie danych operacyjnych w kontenerze. Ten magazyn kolumn jest utrwalany oddzielnie od magazynu transakcyjnego zorientowanego na wiersz dla tego kontenera w ramach konta magazynu w pełni zarządzanego przez usługę Azure Cosmos DB w ramach subskrypcji wewnętrznej. Klienci nie muszą poświęcać czasu na administrowanie magazynem. Operacje wstawiania, aktualizacji i usuwania danych operacyjnych są automatycznie synchronizowane z magazynem analitycznym. Nie potrzebujesz zestawienia zmian ani etL, aby zsynchronizować dane.

Magazyn kolumn dla obciążeń analitycznych na danych operacyjnych

Obciążenia analityczne zwykle obejmują agregacje i sekwencyjne skanowania wybranych pól. Magazyn analityczny danych jest przechowywany w kolejności głównej kolumny, dzięki czemu wartości każdego pola mają być serializowane razem, jeśli ma to zastosowanie. Ten format zmniejsza liczbę operacji we/wy na sekundę wymaganą do skanowania lub obliczania statystyk dotyczących określonych pól. Znacznie poprawia czas odpowiedzi zapytań na potrzeby skanowania dużych zestawów danych.

Jeśli na przykład tabele operacyjne mają następujący format:

Przykładowa tabela operacyjna

Magazyn wierszy utrwala powyższe dane w formacie serializowanym na dysku. Ten format umożliwia szybsze operacje odczytu, zapisu i zapytań operacyjnych, takich jak "Zwracanie informacji o produkcie 1". Jednak w miarę wzrostu dużego zestawu danych i uruchamiania złożonych zapytań analitycznych na danych może to być kosztowne. Jeśli na przykład chcesz uzyskać "trendy sprzedaży dla produktu w kategorii o nazwie "Sprzęt" w różnych jednostkach biznesowych i miesiącach", musisz uruchomić złożone zapytanie. Duże skanowania w tym zestawie danych mogą być kosztowne pod względem aprowizowanej przepływności i mogą również mieć wpływ na wydajność obciążeń transakcyjnych obsługujących aplikacje i usługi w czasie rzeczywistym.

Magazyn analityczny, który jest magazynem kolumn, lepiej nadaje się do takich zapytań, ponieważ serializuje podobne pola danych razem i zmniejsza liczbę operacji we/wy na sekundę dysku.

Na poniższej ilustracji przedstawiono transakcyjny magazyn wierszy a magazyn kolumn analitycznych w usłudze Azure Cosmos DB:

Transakcyjny magazyn wierszy vs magazyn kolumn analitycznych w usłudze Azure Cosmos DB

Oddzielenie wydajności obciążeń analitycznych

Nie ma wpływu na wydajność obciążeń transakcyjnych ze względu na zapytania analityczne, ponieważ magazyn analityczny jest oddzielony od magazynu transakcyjnego. Magazyn analityczny nie wymaga przydzielenia oddzielnych jednostek żądań (RU).

Automatyczna synchronizacja

Automatyczna synchronizacja odnosi się do w pełni zarządzanej funkcji usługi Azure Cosmos DB, w której operacje wstawiania, aktualizacji, usuwania danych operacyjnych są automatycznie synchronizowane z magazynu transakcyjnego do magazynu analitycznego niemal w czasie rzeczywistym. Opóźnienie automatycznej synchronizacji trwa zwykle w ciągu 2 minut. W przypadku udostępnionej bazy danych przepływności z dużą liczbą kontenerów opóźnienie automatycznej synchronizacji poszczególnych kontenerów może być wyższe i potrwać do 5 minut.

Po zakończeniu każdego wykonywania procesu automatycznej synchronizacji dane transakcyjne będą natychmiast dostępne dla środowisk uruchomieniowych usługi Azure Synapse Analytics:

Pule platformy Spark usługi Azure Synapse Analytics mogą odczytywać wszystkie dane, w tym najnowsze aktualizacje, za pośrednictwem tabel platformy Spark, które są aktualizowane automatycznie lub za pomocą spark.read polecenia, które zawsze odczytuje ostatni stan danych.
Pule bezserwerowe usługi Azure Synapse Analytics mogą odczytywać wszystkie dane, w tym najnowsze aktualizacje, za pośrednictwem widoków, które są aktualizowane automatycznie lub za pomocą SELECT OPENROWSET poleceń, które zawsze odczytują najnowszy stan danych.

Uwaga

Dane transakcyjne zostaną zsynchronizowane z magazynem analitycznym, nawet jeśli czas wygaśnięcia transakcji (TTL) jest mniejszy niż 2 minuty.

Uwaga

Należy pamiętać, że w przypadku usunięcia kontenera magazyn analityczny również zostanie usunięty.

Skalowalność i elastyczność

Magazyn transakcyjny usługi Azure Cosmos DB używa partycjonowania poziomego do elastycznego skalowania magazynu i przepływności bez żadnych przestojów. Partycjonowanie w poziomie w magazynie transakcyjnym zapewnia skalowalność i elastyczność automatycznej synchronizacji w celu zapewnienia synchronizacji danych z magazynem analitycznym niemal w czasie rzeczywistym. Synchronizacja danych odbywa się niezależnie od przepływności ruchu transakcyjnego, niezależnie od tego, czy jest to 1000 operacji na sekundę, czy 1 mln operacji na sekundę i nie ma wpływu na aprowizowaną przepływność w magazynie transakcyjnym.

Automatyczne obsługa aktualizacji schematu

Magazyn transakcyjny usługi Azure Cosmos DB jest niezależny od schematu i umożliwia iterowanie aplikacji transakcyjnych bez konieczności zarządzania schematami lub indeksami. W przeciwieństwie do tego magazyn analityczny usługi Azure Cosmos DB jest schematyzowany w celu optymalizacji pod kątem wydajności zapytań analitycznych. Dzięki funkcji automatycznej synchronizacji usługa Azure Cosmos DB zarządza wnioskowaniem schematu za pośrednictwem najnowszych aktualizacji z magazynu transakcyjnego. Zarządza również reprezentacją schematu w wbudowanym magazynie analitycznym, który obejmuje obsługę zagnieżdżonych typów danych.

W miarę rozwoju schematu, a nowe właściwości są dodawane wraz z upływem czasu, magazyn analityczny automatycznie przedstawia połączony schemat we wszystkich schematach historycznych w magazynie transakcyjnym.

Uwaga

W kontekście magazynu analitycznego uważamy następujące struktury za właściwość:

Pary JSON "elements" lub "string-value" oddzielone znakami : ".
Obiekty JSON rozdzielane wartościami { i }.
Tablice JSON rozdzielane przez [ i ].

Ograniczenia schematu

Następujące ograniczenia dotyczą danych operacyjnych w usłudze Azure Cosmos DB po włączeniu automatycznego wnioskowania magazynu analitycznego i poprawnego reprezentowania schematu:

Można mieć maksymalnie 1000 właściwości na wszystkich poziomach zagnieżdżonych w schemacie dokumentu i maksymalną głębokość zagnieżdżania 127.
- Tylko pierwsze 1000 właściwości są reprezentowane w magazynie analitycznym.
- Tylko pierwsze 127 zagnieżdżonych poziomów jest reprezentowanych w magazynie analitycznym.
- Pierwszym poziomem dokumentu JSON jest jego / poziom główny.
- Właściwości pierwszego poziomu dokumentu będą reprezentowane jako kolumny.
Przykładowe scenariusze:
- Jeśli pierwszy poziom dokumentu ma 2000 właściwości, proces synchronizacji będzie reprezentować pierwsze 1000 z nich.
- Jeśli dokumenty mają pięć poziomów z 200 właściwościami w każdym z nich, proces synchronizacji będzie reprezentować wszystkie właściwości.
- Jeśli dokumenty mają 10 poziomów z 400 właściwościami w każdym z nich, proces synchronizacji będzie w pełni reprezentować dwa pierwsze poziomy i tylko połowę trzeciego poziomu.
Hipotetyczny dokument poniżej zawiera cztery właściwości i trzy poziomy.
- Poziomy to root, myArrayi struktura zagnieżdżona w obiekcie myArray.
- Właściwości to id, , myArraymyArray.nested1, i myArray.nested2.
- Reprezentacja magazynu analitycznego będzie zawierać dwie kolumny, idi myArray. Za pomocą funkcji Spark lub T-SQL można również uwidocznić zagnieżdżone struktury jako kolumny.

{
  "id": "1",
  "myArray": [
    "string1",
    "string2",
    {
      "nested1": "abc",
      "nested2": "cde"
    }
  ]
}

Chociaż dokumenty JSON (i kolekcje/kontenery usługi Azure Cosmos DB) są wrażliwe na wielkość liter z perspektywy unikatowości, magazyn analityczny nie jest.
- W tym samym dokumencie: nazwy właściwości na tym samym poziomie powinny być unikatowe w porównaniu bez uwzględniania wielkości liter. Na przykład poniższy dokument JSON ma wartość "Name" i "name" na tym samym poziomie. Chociaż jest to prawidłowy dokument JSON, nie spełnia on ograniczeń unikatowości, dlatego nie będzie w pełni reprezentowany w magazynie analitycznym. W tym przykładzie wartości "Name" i "name" są takie same w porównaniu w sposób bez uwzględniania wielkości liter. Tylko "Name": "fred" będzie reprezentowana w magazynie analitycznym, ponieważ jest to pierwsze wystąpienie. I "name": "john" w ogóle nie będzie reprezentowany.
```
{"id": 1, "Name": "fred", "name": "john"}
```
- W różnych dokumentach: właściwości na tym samym poziomie i o tej samej nazwie, ale w różnych przypadkach będą reprezentowane w tej samej kolumnie przy użyciu formatu nazwy pierwszego wystąpienia. Na przykład następujące dokumenty JSON mają "Name" i "name" na tym samym poziomie. Ponieważ pierwszy format dokumentu to "Name", będzie on używany do reprezentowania nazwy właściwości w magazynie analitycznym. Innymi słowy, nazwa kolumny w magazynie analitycznym będzie mieć wartość "Name". Obie "fred" wartości "john" i będą reprezentowane w kolumnie "Name" .
```
{"id": 1, "Name": "fred"}
{"id": 2, "name": "john"}
```
Pierwszy dokument kolekcji definiuje początkowy schemat magazynu analitycznego.
- Dokumenty z większą ilością właściwości niż początkowy schemat będą generować nowe kolumny w magazynie analitycznym.
- Nie można usunąć kolumn.
- Usunięcie wszystkich dokumentów w kolekcji nie powoduje zresetowania schematu magazynu analitycznego.
- Nie ma przechowywania wersji schematu. Ostatnia wersja wywnioskowana z magazynu transakcyjnego jest tym, co zobaczysz w magazynie analitycznym.
Obecnie platforma Azure Synapse Spark nie może odczytać właściwości zawierających kilka znaków specjalnych w nazwach wymienionych poniżej. Nie ma to wpływu na bezserwerowe usługi Azure Synapse SQL.
- :
- `
- ,
- ;
- {}
- ()
- \n
- \t
- =
- "

Uwaga

Białe spacje są również wyświetlane w komunikacie o błędzie platformy Spark zwracanym po osiągnięciu tego ograniczenia. Ale dodaliśmy specjalne traktowanie białych spacji, zapoznaj się z bardziej szczegółowymi informacjami w poniższych elementach.

Jeśli masz nazwy właściwości używające znaków wymienionych powyżej, alternatywy to:
- Zmień model danych z wyprzedzeniem, aby uniknąć tych znaków.
- Ponieważ obecnie nie obsługujemy resetowania schematu, możesz zmienić aplikację, aby dodać nadmiarową właściwość o podobnej nazwie, unikając tych znaków.
- Użyj zestawienia zmian, aby utworzyć zmaterializowany widok kontenera bez tych znaków w nazwach właściwości.
- dropColumn Użyj opcji Spark, aby zignorować kolumny, których dotyczy problem, i załadować wszystkie inne kolumny do ramki danych. Składnia jest następująca:

# Removing one column:
df = spark.read\
     .format("cosmos.olap")\
     .option("spark.synapse.linkedService","<your-linked-service-name>")\
     .option("spark.synapse.container","<your-container-name>")\
     .option("spark.cosmos.dropColumn","FirstName,LastName")\
     .load()
     
# Removing multiple columns:
df = spark.read\
     .format("cosmos.olap")\
     .option("spark.synapse.linkedService","<your-linked-service-name>")\
     .option("spark.synapse.container","<your-container-name>")\
     .option("spark.cosmos.dropColumn","FirstName,LastName;StreetName,StreetNumber")\
     .option("spark.cosmos.dropMultiColumnSeparator", ";")\
     .load()

Usługa Azure Synapse Spark obsługuje teraz właściwości z białymi spacjami w nazwach. W tym celu należy użyć allowWhiteSpaceInFieldNames opcji Spark, aby załadować kolumny, których dotyczy problem, do ramki danych, zachowując oryginalną nazwę. Składnia jest następująca:

df = spark.read\
     .format("cosmos.olap")\
     .option("spark.synapse.linkedService","<your-linked-service-name>")\
     .option("spark.synapse.container","<your-container-name>")\
     .option("spark.cosmos.allowWhiteSpaceInFieldNames", "true")\
    .load()

Następujące typy danych BSON nie są obsługiwane i nie będą reprezentowane w magazynie analitycznym:
- Liczba dziesiętna128
- Wyrażenie regularne
- Wskaźnik bazy danych
- JavaScript
- Symbol
- MinKey/MaxKey
W przypadku używania ciągów typu DateTime, które są zgodne ze standardem ISO 8601 UTC, należy oczekiwać następującego zachowania:
- Pule platformy Spark w usłudze Azure Synapse reprezentują te kolumny jako string.
- Pule bezserwerowe SQL w usłudze Azure Synapse reprezentują te kolumny jako varchar(8000).
Właściwości z typami UNIQUEIDENTIFIER (guid) są reprezentowane jako string w magazynie analitycznym i powinny być konwertowane na VARCHAR w języku SQL lub string na platformę Spark w celu uzyskania poprawnej wizualizacji.
Pule bezserwerowe SQL w usłudze Azure Synapse obsługują zestawy wyników z maksymalnie 1000 kolumnami i uwidaczniają zagnieżdżone kolumny również są liczone w kierunku tego limitu. Dobrym rozwiązaniem jest rozważenie tych informacji w architekturze danych transakcyjnych i modelowaniu.
Jeśli zmienisz nazwę właściwości w jednym lub wielu dokumentach, zostanie ona uznana za nową kolumnę. Jeśli wykonasz tę samą nazwę we wszystkich dokumentach w kolekcji, wszystkie dane zostaną zmigrowane do nowej kolumny, a stara kolumna będzie reprezentowana wartościami NULL .

Reprezentacja schematu

Istnieją dwie metody reprezentacji schematu w magazynie analitycznym, prawidłowe dla wszystkich kontenerów na koncie bazy danych. Mają one kompromisy między prostotą środowiska zapytań a wygodą bardziej inkluzywnej reprezentacji kolumnowej dla schematów polimorficznych.

Dobrze zdefiniowana reprezentacja schematu, domyślna opcja interfejsu API dla kont NoSQL i Gremlin.
Reprezentacja schematu pełnej wierności, domyślna opcja interfejsu API dla kont bazy danych MongoDB.

Dobrze zdefiniowana reprezentacja schematu

Dobrze zdefiniowana reprezentacja schematu tworzy prostą tabelaryczną reprezentację danych niezależnego od schematu w magazynie transakcyjnym. Dobrze zdefiniowana reprezentacja schematu ma następujące zagadnienia:

Pierwszy dokument definiuje podstawowy schemat i właściwości muszą zawsze mieć ten sam typ we wszystkich dokumentach. Jedynymi wyjątkami są:
- Z NULL do dowolnego innego typu danych. Pierwsze wystąpienie inne niż null definiuje typ danych kolumny. Żaden dokument, który nie jest przestrzegany pierwszego typu danych o wartości innej niż null, nie będzie reprezentowany w magazynie analitycznym.
- Od float do integer. Wszystkie dokumenty są reprezentowane w magazynie analitycznym.
- Od integer do float. Wszystkie dokumenty są reprezentowane w magazynie analitycznym. Aby jednak odczytywać te dane za pomocą pul bezserwerowych usługi Azure Synapse SQL, należy użyć klauzuli WITH, aby przekonwertować kolumnę na varchar. Po tej początkowej konwersji można przekonwertować ją ponownie na liczbę. Sprawdź poniższy przykład, gdzie wartość początkowa liczby była liczbą całkowitą, a druga była zmiennoprzecinkowa.

SELECT CAST (num as float) as num
FROM OPENROWSET( 
       PROVIDER = 'CosmosDB',
       CONNECTION = 'Account=<account-name>;Database=<database-name>;Region=<region-name>',
       OBJECT = '<container-name>',
       [ CREDENTIAL | SERVER_CREDENTIAL ] = '<credential-name>'
) 
WITH (num varchar(100)) AS [IntToFloat]

Właściwości, które nie są zgodne z podstawowym typem danych schematu, nie będą reprezentowane w magazynie analitycznym. Rozważmy na przykład poniższe dokumenty: pierwszy z nich zdefiniował podstawowy schemat magazynu analitycznego. Drugi dokument, gdzie to , nie ma dobrze zdefiniowanego schematu, ponieważ właściwość "code" jest ciągiem, a pierwszy dokument ma "code" jako liczbę. "2"id W takim przypadku magazyn analityczny rejestruje typ "code" danych jako integer okres istnienia kontenera. Drugi dokument będzie nadal zawarty w magazynie analitycznym, ale jego "code" właściwość nie będzie.
- {"id": "1", "code":123}
- {"id": "2", "code": "123"}

Uwaga

Powyższy warunek nie ma zastosowania do NULL właściwości. Na przykład {"a":123} and {"a":NULL} jest nadal dobrze zdefiniowany.

Uwaga

Powyższy warunek nie zmienia się, jeśli zaktualizujesz "code" dokument "1" do ciągu w magazynie transakcyjnym. W magazynie "code" analitycznym będą przechowywane tak, integer ponieważ obecnie nie obsługujemy resetowania schematu.

Typy tablic muszą zawierać jeden powtarzany typ. Na przykład nie jest dobrze zdefiniowanym schematem, {"a": ["str",12]} ponieważ tablica zawiera kombinację typów liczb całkowitych i ciągów.

Uwaga

Jeśli magazyn analityczny usługi Azure Cosmos DB jest zgodny z dobrze zdefiniowaną reprezentacją schematu, a powyższa specyfikacja zostanie naruszona przez niektóre elementy, te elementy nie zostaną uwzględnione w magazynie analitycznym.

Oczekiwano różnych zachowań w odniesieniu do różnych typów w dobrze zdefiniowanym schemacie:
- Pule platformy Spark w usłudze Azure Synapse reprezentują te wartości jako undefined.
- Pule bezserwerowe SQL w usłudze Azure Synapse reprezentują te wartości jako NULL.
Oczekiwano różnych zachowań w odniesieniu do jawnych NULL wartości:
- Pule platformy Spark w usłudze Azure Synapse odczytują te wartości jako 0 (zero), a undefined gdy tylko kolumna ma wartość inną niż null.
- Pule bezserwerowe SQL w usłudze Azure Synapse odczytują te wartości jako NULL.
Spodziewaj się różnych zachowań w odniesieniu do brakujących kolumn:
- Pule platformy Spark w usłudze Azure Synapse reprezentują te kolumny jako undefined.
- Pule bezserwerowe SQL w usłudze Azure Synapse reprezentują te kolumny jako NULL.

Wyzwania związane z reprezentacją : obejścia

Istnieje możliwość, że stary dokument z nieprawidłowym schematem został użyty do utworzenia schematu podstawowego magazynu analitycznego kontenera. Na podstawie wszystkich przedstawionych powyżej reguł podczas wykonywania zapytań dotyczących magazynu analitycznego przy użyciu usługi Azure Synapse Link może być odbierane NULL dane dla niektórych właściwości. Usunięcie lub zaktualizowanie problematycznych dokumentów nie pomoże, ponieważ resetowanie schematu podstawowego nie jest obecnie obsługiwane. Możliwe rozwiązania są następujące:

Aby przeprowadzić migrację danych do nowego kontenera, upewnij się, że wszystkie dokumenty mają poprawny schemat.
Aby porzucić właściwość z niewłaściwym schematem i dodać nowy z inną nazwą, która ma prawidłowy schemat we wszystkich dokumentach. Przykład: masz miliardy dokumentów w kontenerze Orders , w którym właściwość status jest ciągiem. Jednak pierwszy dokument w tym kontenerze ma stan zdefiniowany z liczbą całkowitą. Dlatego jeden dokument będzie miał prawidłowy stan reprezentowany, a wszystkie inne dokumenty będą miały wartość NULL. Właściwość status2 można dodać do wszystkich dokumentów i zacząć jej używać, zamiast oryginalnej właściwości.

Reprezentacja schematu pełnej wierności

Reprezentacja schematu o pełnej wierności została zaprojektowana tak, aby obsługiwała pełny zakres schematów polimorficznych w danych operacyjnych niezależnego od schematu. W tej reprezentacji schematu żadne elementy nie są usuwane z magazynu analitycznego, nawet jeśli nie zostaną naruszone ograniczenia dobrze zdefiniowanego schematu (nie są to pola typu danych mieszanych ani tablice typów danych mieszanych).

Jest to osiągane przez tłumaczenie właściwości liści danych operacyjnych na magazyn analityczny jako pary JSON key-value , gdzie typ danych jest key wartością , a zawartość właściwości to value. Ta reprezentacja obiektu JSON umożliwia wykonywanie zapytań bez niejednoznaczności i można indywidualnie analizować każdy typ danych.

Innymi słowy, w reprezentacji schematu o pełnej wierności każdy typ danych każdej właściwości każdego dokumentu wygeneruje key-valueparę w obiekcie JSON dla tej właściwości. Każdy z nich liczy się jako jeden z 1000 maksymalnych limitów właściwości.

Na przykład użyjemy następującego przykładowego dokumentu w magazynie transakcyjnym:

{
name: "John Doe",
age: 32,
profession: "Doctor",
address: {
  streetNo: 15850,
  streetName: "NE 40th St.",
  zip: 98052
},
salary: 1000000
}

Zagnieżdżony obiekt address jest właściwością na poziomie głównym dokumentu i będzie reprezentowana jako kolumna. Każda właściwość liścia address w obiekcie będzie reprezentowana jako obiekt JSON: {"object":{"streetNo":{"int32":15850},"streetName":{"string":"NE 40th St."},"zip":{"int32":98052}}}.

W przeciwieństwie do dobrze zdefiniowanej reprezentacji schematu metoda pełnej wierności umożliwia zmianę typów danych. Jeśli następny dokument w tej kolekcji powyższego przykładu ma streetNo jako ciąg, będzie reprezentowany w magazynie analitycznym jako "streetNo":{"string":15850}. W dobrze zdefiniowanej metodzie schematu nie będzie ona reprezentowana.

Mapa typów danych dla schematu pełnej wierności

Oto mapa typów danych bazy danych MongoDB i ich reprezentacji w magazynie analitycznym w pełnej wierności reprezentacji schematu. Poniższa mapa nie jest prawidłowa dla kont interfejsu API NoSQL.

Oryginalny typ danych	Przyrostek	Przykład
Liczba rzeczywista	".float64"	24.99
Tablica	".array"	["a", "b"]
Plik binarny	".binary"	0
Wartość logiczna	".bool"	Prawda
Int32	".int32"	123
Int64	".int64"	255486129307
NULL	". NULL"	NULL
String	".string"	"ABC"
Sygnatura czasowa	".timestamp"	Sygnatura czasowa (0, 0)
ObjectId	".objectId"	ObjectId("5f3f7b59330ec25c132623a2")
Dokument	".object"	{"a": "a"}

Oczekiwano różnych zachowań w odniesieniu do jawnych NULL wartości:
- Pule platformy Spark w usłudze Azure Synapse będą odczytywać te wartości jako 0 (zero).
- Pule bezserwerowe SQL w usłudze Azure Synapse odczytują te wartości jako NULL.
Spodziewaj się różnych zachowań w odniesieniu do brakujących kolumn:
- Pule platformy Spark w usłudze Azure Synapse będą reprezentować te kolumny jako undefined.
- Pule bezserwerowe SQL w usłudze Azure Synapse będą reprezentować te kolumny jako NULL.
Oczekiwano różnych zachowań w odniesieniu do timestamp wartości:
- Pule platformy Spark w usłudze Azure Synapse odczytują te wartości jako TimestampType, DateTypelub Float. Zależy to od zakresu i sposobu generowania znacznika czasu.
- Pule bezserwerowe SQL w usłudze Azure Synapse odczytują te wartości jako DATETIME2, od 0001-01-01 do .9999-12-31 Wartości wykraczające poza ten zakres nie są obsługiwane i spowodują niepowodzenie wykonywania zapytań. Jeśli tak jest, możesz:
  - Usuń kolumnę z zapytania. Aby zachować reprezentację, możesz utworzyć nową właściwość dublowania tej kolumny, ale w obsługiwanym zakresie. I użyj go w zapytaniach.
  - Użyj funkcji Przechwytywanie zmian danych z magazynu analitycznego, bez kosztów jednostek RU, aby przekształcić i załadować dane do nowego formatu w jednym z obsługiwanych ujściów.

Używanie schematu pełnej wierności z platformą Spark

Platforma Spark będzie zarządzać poszczególnymi typami danych jako kolumną podczas ładowania do elementu DataFrame. Załóżmy, że kolekcja z poniższymi dokumentami.

{
	"_id" : "1" ,
	"item" : "Pizza",
	"price" : 3.49,
	"rating" : 3,
	"timestamp" : 1604021952.6790195
},
{
	"_id" : "2" ,
	"item" : "Ice Cream",
	"price" : 1.59,
	"rating" : "4" ,
	"timestamp" : "2022-11-11 10:00 AM"
}

Podczas gdy pierwszy dokument ma rating wartość liczbową i timestamp w formacie utc, drugi dokument ma rating ciągi i timestamp jako ciągi. Zakładając, że ta kolekcja została załadowana do DataFrame bez żadnych przekształceń danych, dane wyjściowe elementu df.printSchema() to:

root
 |-- _rid: string (nullable = true)
 |-- _ts: long (nullable = true)
 |-- id: string (nullable = true)
 |-- _etag: string (nullable = true)
 |-- _id: struct (nullable = true)
 |    |-- objectId: string (nullable = true)
 |-- item: struct (nullable = true)
 |    |-- string: string (nullable = true)
 |-- price: struct (nullable = true)
 |    |-- float64: double (nullable = true)
 |-- rating: struct (nullable = true)
 |    |-- int32: integer (nullable = true)
 |    |-- string: string (nullable = true)
 |-- timestamp: struct (nullable = true)
 |    |-- float64: double (nullable = true)
 |    |-- string: string (nullable = true)
 |-- _partitionKey: struct (nullable = true)
 |    |-- string: string (nullable = true)

W dobrze zdefiniowanej reprezentacji schematu zarówno, jak rating i timestamp drugiego dokumentu nie byłyby reprezentowane. W schemacie pełnej wierności można użyć poniższych przykładów, aby indywidualnie uzyskać dostęp do każdej wartości każdego typu danych.

W poniższym przykładzie możemy użyć PySpark polecenia , aby uruchomić agregację:

df.groupBy(df.item.string).sum().show()

W poniższym przykładzie możemy użyć PySQL polecenia , aby uruchomić kolejną agregację:

df.createOrReplaceTempView("Pizza")
sql_results = spark.sql("SELECT sum(price.float64),count(*) FROM Pizza where timestamp.string is not null and item.string = 'Pizza'")
sql_results.show()

Używanie schematu pełnej wierności z bazą danych SQL

Możesz użyć następującego przykładu składni z tymi samymi dokumentami przykładu platformy Spark powyżej:

SELECT rating,timestamp_string,timestamp_utc
FROM OPENROWSET( 
       PROVIDER = 'CosmosDB',
       CONNECTION = 'Account=<account-name>;Database=<database-name>;Region=<region-name>',
       OBJECT = '<container-name>',
       [ CREDENTIAL | SERVER_CREDENTIAL ] = '<credential-name>'
) WITH ( 
rating integer '$.rating.int32',    
timestamp varchar(50) '$.timestamp.string',
timestamp_utc float '$.timestamp.float64' 
) as HTAP 
WHERE timestamp is not null or timestamp_utc is not null

Przekształcenia można zaimplementować przy użyciu funkcji cast, convert lub dowolnej innej funkcji języka T-SQL w celu manipulowania danymi. Można również ukryć złożone struktury typów danych przy użyciu widoków.

create view MyView as
SELECT MyRating=rating,MyTimestamp = convert(varchar(50),timestamp_utc)
FROM OPENROWSET( 
       PROVIDER = 'CosmosDB',
       CONNECTION = 'Account=<account-name>;Database=<database-name>;Region=<region-name>',
       OBJECT = '<container-name>',
       [ CREDENTIAL | SERVER_CREDENTIAL ] = '<credential-name>'
) ( 
rating integer '$.rating.int32',    
timestamp_utc float '$.timestamp.float64' 
) as HTAP 
WHERE  timestamp_utc is not null
union all 
SELECT MyRating=convert(integer,rating_string),MyTimestamp = timestamp_string
FROM OPENROWSET( 
       PROVIDER = 'CosmosDB',
       CONNECTION = 'Account=<account-name>;Database=<database-name>;Region=<region-name>',
       OBJECT = '<container-name>',
       [ CREDENTIAL | SERVER_CREDENTIAL ] = '<credential-name>'
) WITH ( 
rating_string varchar(50) '$.rating.string',    
timestamp_string varchar(50) '$.timestamp.string' 
) as HTAP 
WHERE  timestamp_string is not null

Praca z polem bazy danych MongoDB `_id`

Pole Bazy danych MongoDB _id ma podstawowe znaczenie dla każdej kolekcji w bazie MongoDB i pierwotnie ma reprezentację szesnastkową. Jak widać w powyższej tabeli, schemat pełnej wierności zachowa swoje cechy, tworząc wyzwanie dla wizualizacji w usłudze Azure Synapse Analytics. Aby uzyskać poprawną wizualizację, należy przekonwertować _id typ danych w następujący sposób:

Praca z polem Bazy danych MongoDB `_id` na platformie Spark

Poniższy przykład działa w wersjach platform Spark 2.x i 3.x:

val df = spark.read.format("cosmos.olap").option("spark.synapse.linkedService", "xxxx").option("spark.cosmos.container", "xxxx").load()

val convertObjectId = udf((bytes: Array[Byte]) => {
    val builder = new StringBuilder

    for (b <- bytes) {
        builder.append(String.format("%02x", Byte.box(b)))
    }
    builder.toString
}
 )

val dfConverted = df.withColumn("objectId", col("_id.objectId")).withColumn("convertedObjectId", convertObjectId(col("_id.objectId"))).select("id", "objectId", "convertedObjectId")
display(dfConverted)

Praca z polem Bazy danych MongoDB `_id` w języku SQL

SELECT TOP 100 id=CAST(_id as VARBINARY(1000))
FROM OPENROWSET( 
       PROVIDER = 'CosmosDB',
       CONNECTION = 'Account=<account-name>;Database=<database-name>;Region=<region-name>',
       OBJECT = '<container-name>',
       [ CREDENTIAL | SERVER_CREDENTIAL ] = '<credential-name>'
HTAP) WITH (_id VARCHAR(1000)) as HTAP

Praca z polem bazy danych MongoDB `id`

Właściwość id w kontenerach bazy danych MongoDB jest automatycznie zastępowana reprezentacją base64 właściwości "_id" zarówno w magazynie analitycznym. Pole "id" jest przeznaczone do użytku wewnętrznego przez aplikacje MongoDB. Obecnie jedynym obejściem jest zmiana nazwy właściwości "id" na inną niż "id".

Schemat pełnej wierności dla interfejsu API dla kont NoSQL lub Gremlin

Zamiast opcji domyślnej można użyć schematu pełnej wierności dla kont interfejsu API noSQL, ustawiając typ schematu podczas włączania usługi Synapse Link na koncie usługi Azure Cosmos DB po raz pierwszy. Poniżej przedstawiono zagadnienia dotyczące zmiany domyślnego typu reprezentacji schematu:

Obecnie jeśli włączysz usługę Synapse Link na koncie interfejsu API NoSQL przy użyciu witryny Azure Portal, zostanie on włączony, jak również zdefiniowany schemat.
Obecnie, jeśli chcesz użyć schematu pełnej wierności z kontami interfejsu API NoSQL lub Gremlin, musisz ustawić go na poziomie konta w tym samym interfejsie wiersza polecenia lub w programie PowerShell, które włączy usługę Synapse Link na poziomie konta.
Obecnie usługa Azure Cosmos DB dla bazy danych MongoDB nie jest zgodna z tą możliwością zmiany reprezentacji schematu. Wszystkie konta bazy danych MongoDB mają pełny typ reprezentacji schematu wierność.
Mapa danych schematu Full Fidelity wymieniona powyżej nie jest prawidłowa dla kont interfejsu API NoSQL korzystających z typów danych JSON. Na przykład float wartości i integer są reprezentowane jako num w magazynie analitycznym.
Nie można zresetować typu reprezentacji schematu z dobrze zdefiniowanej do pełnej wierności lub odwrotnie.
Obecnie schematy kontenerów w magazynie analitycznym są definiowane podczas tworzenia kontenera, nawet jeśli usługa Synapse Link nie została włączona na koncie bazy danych.
- Kontenery lub wykresy utworzone przed włączeniem usługi Synapse Link ze schematem pełnej wierności na poziomie konta będą miały dobrze zdefiniowany schemat.
- Kontenery lub wykresy utworzone po włączeniu usługi Synapse Link ze schematem pełnej wierności na poziomie konta będą miały schemat pełnej wierności.

Decyzja o typie reprezentacji schematu musi być podjęta w tym samym czasie, gdy usługa Synapse Link jest włączona na koncie przy użyciu interfejsu wiersza polecenia platformy Azure lub programu PowerShell.

Za pomocą interfejsu wiersza polecenia platformy Azure:

az cosmosdb create --name MyCosmosDBDatabaseAccount --resource-group MyResourceGroup --subscription MySubscription --analytical-storage-schema-type "FullFidelity" --enable-analytical-storage true

Uwaga

W powyższym poleceniu zastąp ciąg create ciągiem update dla istniejących kont.

Za pomocą programu PowerShell:

 New-AzCosmosDBAccount -ResourceGroupName MyResourceGroup -Name MyCosmosDBDatabaseAccount  -EnableAnalyticalStorage true -AnalyticalStorageSchemaType "FullFidelity"

Uwaga

W powyższym poleceniu zastąp ciąg New-AzCosmosDBAccount ciągiem Update-AzCosmosDBAccount dla istniejących kont.

Analityczny czas wygaśnięcia (TTL)

Analityczny czas wygaśnięcia (ATTL) wskazuje, jak długo dane powinny być przechowywane w magazynie analitycznym dla kontenera.

Magazyn analityczny jest włączony, gdy właściwość ATTL jest ustawiana z wartością inną niż NULL i 0. Po włączeniu wstawiania, aktualizacji, usuwania do danych operacyjnych są automatycznie synchronizowane z magazynu transakcyjnego do magazynu analitycznego, niezależnie od konfiguracji transakcyjnego czasu wygaśnięcia (TTTL). Przechowywanie tych danych transakcyjnych w magazynie analitycznym może być kontrolowane na poziomie kontenera AnalyticalStoreTimeToLiveInSeconds przez właściwość .

Możliwe konfiguracje ATTL to:

Jeśli wartość jest ustawiona na 0: magazyn analityczny jest wyłączony i żadne dane nie są replikowane z magazynu transakcyjnego do magazynu analitycznego. Otwórz zgłoszenie do pomocy technicznej, aby wyłączyć magazyn analityczny w kontenerach.
Jeśli pole zostanie pominięte, nic się nie stanie, a poprzednia wartość zostanie zachowana.
Jeśli wartość jest ustawiona na -1: magazyn analityczny zachowuje wszystkie dane historyczne, niezależnie od przechowywania danych w magazynie transakcyjnym. To ustawienie wskazuje, że magazyn analityczny ma nieskończone przechowywanie danych operacyjnych
Jeśli wartość jest ustawiona na dowolną dodatnią liczbę całkowitą n : elementy wygasną z magazynu n analitycznego w sekundach po ostatniej modyfikacji w magazynie transakcyjnym. To ustawienie może być używane, jeśli chcesz przechowywać dane operacyjne przez ograniczony czas w magazynie analitycznym, niezależnie od przechowywania danych w magazynie transakcyjnym

Oto niektóre ważne kwestie:

Po włączeniu magazynu analitycznego z wartością ATTL można ją później zaktualizować do innej prawidłowej wartości.
Czas wygaśnięcia TTTL można ustawić na poziomie kontenera lub elementu, ale attl można ustawić tylko na poziomie kontenera.
Możesz osiągnąć dłuższy czas przechowywania danych operacyjnych w magazynie analitycznym, ustawiając wartość ATTL >= TTTL na poziomie kontenera.
Magazyn analityczny można wykonać w celu dublowania magazynu transakcyjnego, ustawiając wartość ATTL = TTTL.
Jeśli masz wartość ATTL większą niż TTTL, w pewnym momencie będziesz mieć dane, które istnieją tylko w magazynie analitycznym. Te dane są tylko do odczytu.
Obecnie nie usuwamy żadnych danych z magazynu analitycznego. Jeśli ustawisz wartość ATTL na dowolną dodatnią liczbę całkowitą, dane nie zostaną uwzględnione w zapytaniach i nie zostaną naliczone opłaty. Jeśli jednak zmienisz wartość ATTL z powrotem na -1, wszystkie dane zostaną ponownie wyświetlone, zaczniesz naliczać opłaty za cały wolumin danych.

Jak włączyć magazyn analityczny w kontenerze:

W witrynie Azure Portal opcja ATTL po włączeniu jest ustawiona na wartość domyślną -1. Tę wartość można zmienić na "n" sekund, przechodząc do ustawień kontenera w obszarze Eksplorator danych.
Z poziomu zestawu Azure Management SDK, zestawów SDK usługi Azure Cosmos DB, programu PowerShell lub interfejsu wiersza polecenia platformy Azure można włączyć opcję ATTL, ustawiając ją na wartość -1 lub "n".

Aby dowiedzieć się więcej, zobacz jak skonfigurować analityczny czas wygaśnięcia w kontenerze.

Ekonomiczne analizy danych historycznych

Obsługa warstw danych odnosi się do rozdzielenia danych między infrastrukturami magazynu zoptymalizowanymi pod kątem różnych scenariuszy. W ten sposób poprawia ogólną wydajność i efektywność kosztową kompleksowego stosu danych. W przypadku magazynu analitycznego usługa Azure Cosmos DB obsługuje teraz automatyczne warstwy danych z magazynu transakcyjnego do magazynu analitycznego z różnymi układami danych. Dzięki magazynowi analitycznemu zoptymalizowanemu pod względem kosztów magazynu w porównaniu z magazynem transakcyjnym można zachować znacznie dłuższe horyzonty danych operacyjnych na potrzeby analizy historycznej.

Po włączeniu magazynu analitycznego na podstawie potrzeb związanych z przechowywaniem danych obciążeń transakcyjnych można skonfigurować transactional TTL właściwość tak, aby rekordy zostały automatycznie usunięte z magazynu transakcyjnego po określonym czasie. analytical TTL Podobnie program umożliwia zarządzanie cyklem życia danych przechowywanych w magazynie analitycznym niezależnie od magazynu transakcyjnego. Włączając magazyn analityczny i konfigurując właściwości transakcyjne i analityczne TTL , można bezproblemowo warstwować i definiować okres przechowywania danych dla dwóch magazynów.

Uwaga

W analytical TTL przypadku ustawienia wartości większej niż transactional TTL wartość kontener będzie miał dane, które istnieją tylko w magazynie analitycznym. Te dane są tylko do odczytu i obecnie nie obsługujemy poziomu TTL dokumentów w magazynie analitycznym. Jeśli dane kontenera mogą wymagać aktualizacji lub usunięcia w pewnym momencie w przyszłości, nie używaj analytical TTL wartości większej niż transactional TTL. Ta funkcja jest zalecana w przypadku danych, które nie będą potrzebować aktualizacji ani usunięcia w przyszłości.

Uwaga

Jeśli twój scenariusz nie wymaga usunięcia fizycznego, możesz zastosować podejście do usuwania logicznego/aktualizacji. Wstaw w magazynie transakcyjnym inną wersję tego samego dokumentu, która istnieje tylko w magazynie analitycznym, ale wymaga logicznego usuwania/aktualizacji. Może z flagą wskazującą, że jest to usunięcie lub aktualizacja wygasłego dokumentu. Obie wersje tego samego dokumentu będą współistnieć w magazynie analitycznym, a aplikacja powinna uwzględniać tylko ostatnie.

Odporność

Magazyn analityczny opiera się na usłudze Azure Storage i oferuje następującą ochronę przed awariami fizycznymi:

Domyślnie konta bazy danych usługi Azure Cosmos DB przydzielają magazyn analityczny na kontach magazynu lokalnie nadmiarowego (LRS). Magazyn LRS zapewnia co najmniej 99,9999999999% (11 dziewiątek) trwałość obiektów w danym roku.
Jeśli dowolny region geograficzny konta bazy danych jest skonfigurowany pod kątem nadmiarowości strefy, zostanie przydzielony na kontach magazynu strefowo nadmiarowego (ZRS). Musisz włączyć Strefy dostępności w regionie konta bazy danych usługi Azure Cosmos DB, aby mieć dane analityczne tego regionu przechowywane w magazynie strefowo nadmiarowym. Magazyn ZRS oferuje trwałość zasobów magazynu z co najmniej 99,9999999999999% (12 9 w danym roku).

Aby uzyskać więcej informacji na temat trwałości usługi Azure Storage, zobacz ten link.

Wykonywanie kopii zapasowej

Mimo że magazyn analityczny ma wbudowaną ochronę przed awariami fizycznymi, tworzenie kopii zapasowej może być konieczne w przypadku przypadkowego usunięcia lub aktualizacji w magazynie transakcyjnym. W takich przypadkach można przywrócić kontener i użyć przywróconego kontenera, aby wypełnić dane w oryginalnym kontenerze lub w razie potrzeby ponownie skompilować magazyn analityczny.

Uwaga

Obecnie magazyn analityczny nie jest kopią zapasową, dlatego nie można go przywrócić. Nie można zaplanować zasad tworzenia kopii zapasowych, opierając się na tym.

Usługa Synapse Link i magazyn analityczny w konsekwencji mają różne poziomy zgodności z trybami tworzenia kopii zapasowych usługi Azure Cosmos DB:

Tryb okresowej kopii zapasowej jest w pełni zgodny z usługą Synapse Link, a te 2 funkcje mogą być używane na tym samym koncie bazy danych.
Usługa Synapse Link dla kont bazy danych korzystających z trybu ciągłej kopii zapasowej jest ogólnie dostępna.
Tryb ciągłej kopii zapasowej dla kont z obsługą usługi Synapse Link jest w publicznej wersji zapoznawczej. Obecnie nie można przeprowadzić migracji do ciągłej kopii zapasowej, jeśli usługa Synapse Link została wyłączona na żadnym z Twoich kolekcji na koncie usługi Cosmos DB.

Zasady kopii zapasowych

Istnieją dwie możliwe zasady tworzenia kopii zapasowych i aby zrozumieć, jak ich używać, bardzo ważne są następujące szczegóły dotyczące kopii zapasowych usługi Azure Cosmos DB:

Oryginalny kontener jest przywracany bez magazynu analitycznego w obu trybach tworzenia kopii zapasowych.
Usługa Azure Cosmos DB nie obsługuje zastępowania kontenerów z przywracania.

Teraz zobaczmy, jak używać kopii zapasowych i przywracania z perspektywy magazynu analitycznego.

Przywracanie kontenera z funkcją TTTL >= ATTL

Gdy transactional TTL wartość jest równa lub większa niż analytical TTL, wszystkie dane w magazynie analitycznym nadal istnieją w magazynie transakcyjnym. W przypadku przywracania istnieją dwie możliwe sytuacje:

Aby użyć przywróconego kontenera jako zamiennika oryginalnego kontenera. Aby ponownie skompilować magazyn analityczny, wystarczy włączyć usługę Synapse Link na poziomie konta i na poziomie kontenera.
Aby użyć przywróconego kontenera jako źródła danych do wypełniania kopii zapasowych lub aktualizowania danych w oryginalnym kontenerze. W takim przypadku magazyn analityczny będzie automatycznie odzwierciedlać operacje danych.

Przywracanie kontenera za pomocą funkcji TTTL < ATTL

Gdy transactional TTL wartość jest mniejsza niż analytical TTL, niektóre dane istnieją tylko w magazynie analitycznym i nie będą znajdować się w przywróconym kontenerze. Ponownie istnieją dwie możliwe sytuacje:

Aby użyć przywróconego kontenera jako zamiennika oryginalnego kontenera. W takim przypadku po włączeniu usługi Synapse Link na poziomie kontenera tylko dane, które znajdowały się w magazynie transakcyjnym, zostaną uwzględnione w nowym magazynie analitycznym. Należy jednak pamiętać, że magazyn analityczny oryginalnego kontenera pozostaje dostępny dla zapytań, o ile oryginalny kontener istnieje. Możesz zmienić aplikację tak, aby wysyłała zapytania do obu.
Aby użyć przywróconego kontenera jako źródła danych do wypełniania kopii zapasowych lub aktualizowania danych w oryginalnym kontenerze:
Magazyn analityczny będzie automatycznie odzwierciedlać operacje danych dla danych przechowywanych w magazynie transakcyjnym.
Jeśli ponownie wstawisz dane, które zostały wcześniej usunięte z magazynu transakcyjnego z powodu transactional TTL, te dane zostaną zduplikowane w magazynie analitycznym.

Przykład:

Kontener OnlineOrders ma wartość TTTL ustawioną na jeden miesiąc, a wartość ATTL ustawiona przez jeden rok.
Po przywróceniu go do OnlineOrdersNew magazynu analitycznego i włączeniu go do ponownego skompilowania będzie tylko jeden miesiąc danych zarówno w magazynie transakcyjnym, jak i analitycznym.
Oryginalny kontener OnlineOrders nie został usunięty, a jego magazyn analityczny jest nadal dostępny.
Nowe dane są pozyskiwane tylko do elementu OnlineOrdersNew.
Zapytania analityczne będą wykonywać wszystkie działania UNII z magazynów analitycznych, podczas gdy oryginalne dane są nadal istotne.

Jeśli chcesz usunąć oryginalny kontener, ale nie chcesz utracić danych magazynu analitycznego, możesz utrwalyć magazyn analityczny oryginalnego kontenera w innej usłudze danych platformy Azure. Usługa Synapse Analytics umożliwia wykonywanie sprzężeń między danymi przechowywanymi w różnych lokalizacjach. Przykład: zapytanie usługi Synapse Analytics łączy dane magazynu analitycznego z tabelami zewnętrznymi znajdującymi się w usłudze Azure Blob Storage, Azure Data Lake Store itp.

Należy pamiętać, że dane w magazynie analitycznym mają inny schemat niż to, co istnieje w magazynie transakcyjnym. Chociaż można wygenerować migawki danych magazynu analitycznego i wyeksportować je do dowolnej usługi Azure Data, bez kosztów jednostek RU, nie możemy zagwarantować użycia tej migawki do zwrotnego źródła danych magazynu transakcyjnego. Ten proces nie jest obsługiwany.

Globalne rozproszenie

Jeśli masz globalnie rozproszone konto usługi Azure Cosmos DB, po włączeniu magazynu analitycznego dla kontenera będzie ono dostępne we wszystkich regionach tego konta. Wszelkie zmiany danych operacyjnych są globalnie replikowane we wszystkich regionach. Zapytania analityczne można skutecznie uruchamiać względem najbliższej regionalnej kopii danych w usłudze Azure Cosmos DB.

Partycjonowanie

Partycjonowanie magazynu analitycznego jest całkowicie niezależne od partycjonowania w magazynie transakcyjnym. Domyślnie dane w magazynie analitycznym nie są partycjonowane. Jeśli zapytania analityczne często używały filtrów, możesz podzielić je na partycje na podstawie tych pól w celu uzyskania lepszej wydajności zapytań. Aby dowiedzieć się więcej, zobacz wprowadzenie do partycjonowania niestandardowego i sposób konfigurowania partycjonowania niestandardowego.

Zabezpieczenia

Uwierzytelnianie za pomocą magazynu analitycznego jest takie samo jak magazyn transakcyjny dla danej bazy danych.
Izolacja sieci przy użyciu prywatnych punktów końcowych — można niezależnie kontrolować dostęp sieciowy do danych w magazynach transakcyjnych i analitycznych. Izolacja sieci odbywa się przy użyciu oddzielnych zarządzanych prywatnych punktów końcowych dla każdego magazynu w zarządzanych sieciach wirtualnych w obszarach roboczych usługi Azure Synapse. Aby dowiedzieć się więcej, zobacz artykuł Konfigurowanie prywatnych punktów końcowych dla magazynu analitycznego.
Szyfrowanie danych magazynowanych — szyfrowanie magazynu analitycznego jest domyślnie włączone.
Szyfrowanie danych przy użyciu kluczy zarządzanych przez klienta — można bezproblemowo szyfrować dane w magazynach transakcyjnych i analitycznych przy użyciu tych samych kluczy zarządzanych przez klienta w sposób automatyczny i przezroczysty. Usługa Azure Synapse Link obsługuje tylko konfigurowanie kluczy zarządzanych przez klienta przy użyciu tożsamości zarządzanej konta usługi Azure Cosmos DB. Przed włączeniem usługi Azure Synapse Link na koncie należy skonfigurować tożsamość zarządzaną konta w zasadach dostępu usługi Azure Key Vault. Aby dowiedzieć się więcej, zobacz artykuł Konfigurowanie kluczy zarządzanych przez klienta przy użyciu tożsamości zarządzanych kont usługi Azure Cosmos DB.

Uwaga

Jeśli zmienisz konto bazy danych z aplikacji First Party na System lub User Assigned Identy i włączysz usługę Azure Synapse Link na koncie bazy danych, nie będzie można powrócić do tożsamości pierwszej firmy, ponieważ nie możesz wyłączyć usługi Synapse Link z konta bazy danych.

Obsługa wielu środowisk uruchomieniowych usługi Azure Synapse Analytics

Magazyn analityczny jest zoptymalizowany pod kątem skalowalności, elastyczności i wydajności obciążeń analitycznych bez zależności od czasu wykonywania obliczeń. Technologia magazynowania jest zarządzana samodzielnie w celu zoptymalizowania obciążeń analitycznych bez konieczności ręcznego działania.

Zapytania dotyczące danych w magazynie analitycznym usługi Azure Cosmos DB można wykonywać jednocześnie z różnych środowisk uruchomieniowych analizy obsługiwanych przez usługę Azure Synapse Analytics. Usługa Azure Synapse Analytics obsługuje platformę Apache Spark i bezserwerową pulę SQL z magazynem analitycznym usługi Azure Cosmos DB.

Uwaga

Magazyn analityczny można odczytywać tylko z magazynu analitycznego przy użyciu środowisk uruchomieniowych usługi Azure Synapse Analytics. A odwrotnie jest również prawdą, środowiska uruchomieniowe usługi Azure Synapse Analytics mogą odczytywać tylko z magazynu analitycznego. Tylko proces automatycznej synchronizacji może zmieniać dane w magazynie analitycznym. Dane można zapisywać z powrotem do magazynu transakcyjnego usługi Azure Cosmos DB przy użyciu puli Spark usługi Azure Synapse Analytics przy użyciu wbudowanego zestawu SDK OLTP usługi Azure Cosmos DB.

Cennik

Magazyn analityczny jest zgodny z modelem cen opartym na użyciu, w którym są naliczane opłaty:

Magazyn: ilość danych przechowywanych w magazynie analitycznym co miesiąc, w tym dane historyczne zdefiniowane przez analityczny czas wygaśnięcia.
Operacje zapisu analitycznego: w pełni zarządzana synchronizacja aktualizacji danych operacyjnych z magazynu analitycznego z magazynu transakcyjnego (automatyczna synchronizacja)
Operacje odczytu analitycznego: operacje odczytu wykonywane względem magazynu analitycznego z puli Spark usługi Azure Synapse Analytics i bezserwerowej puli SQL.

Cennik magazynu analitycznego jest oddzielony od modelu cen magazynu transakcji. W magazynie analitycznym nie ma pojęcia aprowizowania jednostek RU. Zobacz stronę cennika usługi Azure Cosmos DB, aby uzyskać szczegółowe informacje na temat modelu cenowego magazynu analitycznego.

Dostęp do danych w magazynie analitycznym można uzyskać tylko za pośrednictwem usługi Azure Synapse Link, która jest wykonywana w środowiskach uruchomieniowych usługi Azure Synapse Analytics: pule azure Synapse Apache Spark i pule SQL bezserwerowe usługi Azure Synapse. Zobacz stronę cennika usługi Azure Synapse Analytics, aby uzyskać szczegółowe informacje na temat modelu cen w celu uzyskania dostępu do danych w magazynie analitycznym.

Aby uzyskać oszacowanie kosztów wysokiego poziomu w celu włączenia magazynu analitycznego w kontenerze usługi Azure Cosmos DB, z perspektywy magazynu analitycznego, możesz użyć planisty pojemności usługi Azure Cosmos DB i oszacować koszty magazynu analitycznego i operacji zapisu.

Oszacowania operacji odczytu magazynu analitycznego nie są uwzględniane w kalkulatorze kosztów usługi Azure Cosmos DB, ponieważ są one funkcją obciążenia analitycznego. Jednak zgodnie z ogólnym oszacowaniem skanowanie 1 TB danych w magazynie analitycznym zwykle powoduje 130 000 operacji odczytu analitycznego i powoduje koszt 0,065 USD. Jeśli na przykład użyjesz bezserwerowych pul SQL usługi Azure Synapse do wykonania tego skanowania o pojemności 1 TB, koszt będzie kosztować 5,00 USD zgodnie ze stroną cennika usługi Azure Synapse Analytics. Ostateczny całkowity koszt tego skanowania o pojemności 1 TB wynosi 5,065 USD.

Chociaż powyższe oszacowanie dotyczy skanowania 1 TB danych w magazynie analitycznym, zastosowanie filtrów zmniejsza ilość skanowanych danych i określa dokładną liczbę analitycznych operacji odczytu, biorąc pod uwagę model cen zużycia. Weryfikacja koncepcji wokół obciążenia analitycznego zapewni bardziej precyzyjne oszacowanie operacji odczytu analitycznego. To oszacowanie nie obejmuje kosztów usługi Azure Synapse Analytics.

Następne kroki

Aby dowiedzieć się więcej, zobacz następujące dokumenty:

Udostępnij za pośrednictwem

Co to jest magazyn analityczny usługi Azure Cosmos DB?

Wyzwania związane z analizą na dużą skalę na dane operacyjne

Magazyn analityczny zorientowany na kolumnę

Funkcje magazynu analitycznego

Magazyn kolumn dla obciążeń analitycznych na danych operacyjnych

Oddzielenie wydajności obciążeń analitycznych

Automatyczna synchronizacja

Skalowalność i elastyczność

Automatyczne obsługa aktualizacji schematu

Ograniczenia schematu

Reprezentacja schematu

Dobrze zdefiniowana reprezentacja schematu

Wyzwania związane z reprezentacją : obejścia

Reprezentacja schematu pełnej wierności

Mapa typów danych dla schematu pełnej wierności

Używanie schematu pełnej wierności z platformą Spark

Używanie schematu pełnej wierności z bazą danych SQL

Praca z polem bazy danych MongoDB `_id`

Praca z polem Bazy danych MongoDB `_id` na platformie Spark

Praca z polem Bazy danych MongoDB `_id` w języku SQL

Praca z polem bazy danych MongoDB `id`

Schemat pełnej wierności dla interfejsu API dla kont NoSQL lub Gremlin

Analityczny czas wygaśnięcia (TTL)

Ekonomiczne analizy danych historycznych

Odporność

Wykonywanie kopii zapasowej

Zasady kopii zapasowych

Przywracanie kontenera z funkcją TTTL >= ATTL

Przywracanie kontenera za pomocą funkcji TTTL < ATTL

Globalne rozproszenie

Partycjonowanie

Zabezpieczenia

Obsługa wielu środowisk uruchomieniowych usługi Azure Synapse Analytics

Cennik

Następne kroki

Opinia

Dodatkowe zasoby

Udostępnij za pośrednictwem

Co to jest magazyn analityczny usługi Azure Cosmos DB?

Wyzwania związane z analizą na dużą skalę na dane operacyjne

Magazyn analityczny zorientowany na kolumnę

Funkcje magazynu analitycznego

Magazyn kolumn dla obciążeń analitycznych na danych operacyjnych

Oddzielenie wydajności obciążeń analitycznych

Automatyczna synchronizacja

Skalowalność i elastyczność

Automatyczne obsługa aktualizacji schematu

Ograniczenia schematu

Reprezentacja schematu

Dobrze zdefiniowana reprezentacja schematu

Wyzwania związane z reprezentacją : obejścia

Reprezentacja schematu pełnej wierności

Mapa typów danych dla schematu pełnej wierności

Używanie schematu pełnej wierności z platformą Spark

Używanie schematu pełnej wierności z bazą danych SQL

Praca z polem bazy danych MongoDB _id

Praca z polem Bazy danych MongoDB _id na platformie Spark

Praca z polem Bazy danych MongoDB _id w języku SQL

Praca z polem bazy danych MongoDB id

Schemat pełnej wierności dla interfejsu API dla kont NoSQL lub Gremlin

Analityczny czas wygaśnięcia (TTL)

Ekonomiczne analizy danych historycznych

Odporność

Wykonywanie kopii zapasowej

Zasady kopii zapasowych

Przywracanie kontenera z funkcją TTTL >= ATTL

Przywracanie kontenera za pomocą funkcji TTTL < ATTL

Globalne rozproszenie

Partycjonowanie

Zabezpieczenia

Obsługa wielu środowisk uruchomieniowych usługi Azure Synapse Analytics

Cennik

Następne kroki

Opinia

Dodatkowe zasoby

Praca z polem bazy danych MongoDB `_id`

Praca z polem Bazy danych MongoDB `_id` na platformie Spark

Praca z polem Bazy danych MongoDB `_id` w języku SQL

Praca z polem bazy danych MongoDB `id`