Vad är Azure Cosmos DB-analysarkiv?

Artikel
04/18/2023

GÄLLER FÖR: Nosql Mongodb Gremlin

Azure Cosmos DB-analysarkivet är ett helt isolerat kolumnlager för att aktivera storskalig analys mot driftdata i Azure Cosmos DB, utan att påverka dina transaktionsarbetsbelastningar.

Utmaningar med storskalig analys av driftdata

Driftdata för flera modeller i en Azure Cosmos DB-container lagras internt i ett indexerat radbaserat "transaktionslager". Radlagringsformatet är utformat för att tillåta snabba transaktionsläsningar och skrivningar i svarstiderna för millisekunder och driftsfrågor. Om datauppsättningen blir stor kan komplexa analysfrågor vara dyra när det gäller etablerat dataflöde för de data som lagras i det här formatet. Hög förbrukning av etablerat dataflöde i sin tur påverkar prestandan för transaktionsarbetsbelastningar som används av dina realtidsprogram och -tjänster.

För att analysera stora mängder data extraheras driftdata traditionellt från Azure Cosmos DB:s transaktionslager och lagras i ett separat datalager. Data lagras till exempel i ett informationslager eller en datasjö i lämpligt format. Dessa data används senare för storskalig analys och analyseras med beräkningsmotorer som Apache Spark-kluster. Separationen av analysdata från driftdata resulterar i fördröjningar för analytiker som vill använda de senaste data.

ETL-pipelines blir också komplexa när du hanterar uppdateringar av driftdata jämfört med att endast hantera nyligen inmatade driftdata.

Kolumnorienterat analysarkiv

Azure Cosmos DB-analysarkivet hanterar de komplexa och svarstidsutmaningar som uppstår med traditionella ETL-pipelines. Azure Cosmos DB-analysarkivet kan automatiskt synkronisera dina driftdata till ett separat kolumnlager. Kolumnlagringsformatet är lämpligt för storskaliga analysfrågor som ska utföras på ett optimerat sätt, vilket förbättrar svarstiden för sådana frågor.

Med Azure Synapse Link kan du nu skapa HTAP-lösningar utan ETL genom att länka direkt till Azure Cosmos DB-analysarkivet från Azure Synapse Analytics. Det gör att du kan köra storskaliga analyser i nästan realtid på dina driftdata.

Funktioner i analysarkivet

När du aktiverar analysarkiv i en Azure Cosmos DB-container skapas ett nytt kolumnlager internt baserat på driftdata i containern. Det här kolumnarkivet sparas separat från det radorienterade transaktionsarkivet för containern, i ett lagringskonto som hanteras helt av Azure Cosmos DB, i en intern prenumeration. Kunder behöver inte ägna tid åt lagringsadministration. Infogningar, uppdateringar och borttagningar till dina driftdata synkroniseras automatiskt till analysarkivet. Du behöver inte ändra feed eller ETL för att synkronisera data.

Kolumnlager för analytiska arbetsbelastningar på driftdata

Analytiska arbetsbelastningar omfattar vanligtvis aggregeringar och sekventiella genomsökningar av valda fält. Genom att lagra data i en kolumn-större ordning tillåter analysarkivet att en grupp värden för varje fält serialiseras tillsammans. Det här formatet minskar det IOPS som krävs för att genomsöka eller beräkna statistik över specifika fält. Det förbättrar frågesvarstiderna dramatiskt för genomsökningar över stora datamängder.

Om dina drifttabeller till exempel har följande format:

Exempel på drifttabell

Radlagret bevarar ovanstående data i serialiserat format, per rad, på disken. Det här formatet möjliggör snabbare transaktionsläsningar, skrivningar och driftsfrågor, till exempel "Returnera information om Product1". Men eftersom datauppsättningen blir stor och om du vill köra komplexa analysfrågor på data kan det bli dyrt. Om du till exempel vill få "försäljningstrenderna för en produkt under kategorin Utrustning" för olika affärsenheter och månader måste du köra en komplex fråga. Stora genomsökningar på den här datauppsättningen kan bli dyra när det gäller etablerat dataflöde och kan också påverka prestandan för transaktionsarbetsbelastningar som driver dina realtidsprogram och -tjänster.

Analysarkivet, som är ett kolumnlager, passar bättre för sådana frågor eftersom det serialiserar liknande datafält tillsammans och minskar diskens IOPS.

Följande bild visar transaktionellt radlager jämfört med analyskolumnarkiv i Azure Cosmos DB:

Transaktionsradslager Jämfört med analyskolumnarkiv i Azure Cosmos DB

Frikopplade prestanda för analytiska arbetsbelastningar

Det påverkar inte prestandan för dina transaktionsarbetsbelastningar på grund av analysfrågor, eftersom analysarkivet är separat från transaktionslagret. Analysarkivet behöver inte separata enheter för programbegäran (RU:er) som ska allokeras.

Synkronisera automatiskt

Automatisk synkronisering avser den fullständigt hanterade funktionen i Azure Cosmos DB där infogningar, uppdateringar, borttagningar till driftdata automatiskt synkroniseras från transaktionslager till analysarkiv i nära realtid. Svarstiden för automatisk synkronisering är vanligtvis inom 2 minuter. Vid delad dataflödesdatabas med ett stort antal containrar kan svarstiden för automatisk synkronisering av enskilda containrar vara högre och ta upp till 5 minuter.

I slutet av varje körning av den automatiska synkroniseringsprocessen blir dina transaktionsdata omedelbart tillgängliga för Azure Synapse Analytics-körning:

Azure Synapse Analytics Spark-pooler kan läsa alla data, inklusive de senaste uppdateringarna, via Spark-tabeller, som uppdateras automatiskt eller via spark.read kommandot, som alltid läser det sista tillståndet för data.
Azure Synapse Analytics SQL Serverless pooler kan läsa alla data, inklusive de senaste uppdateringarna, via vyer, som uppdateras automatiskt eller via SELECT tillsammans med OPENROWSET kommandon, som alltid läser den senaste statusen för data.

Anteckning

Dina transaktionsdata synkroniseras till analysarkivet även om TTL (TransactionAl Time To Live) är mindre än 2 minuter.

Anteckning

Observera att om du tar bort containern tas även analysarkivet bort.

Elasticitet för skalbarhet &

Genom att använda horisontell partitionering kan Azure Cosmos DB-transaktionsarkivet elastiskt skala lagringen och dataflödet utan avbrott. Horisontell partitionering i transaktionslagret ger elasticitet för skalbarhet & vid automatisk synkronisering för att säkerställa att data synkroniseras till analysarkivet nästan i realtid. Datasynkroniseringen sker oavsett transaktionstrafikens dataflöde, oavsett om det är 1 000 åtgärder per sekund eller 1 miljon åtgärder/sek och det påverkar inte det etablerade dataflödet i transaktionslagret.

Hantera schemauppdateringar automatiskt

Azure Cosmos DB-transaktionsarkivet är schemaberoende och gör att du kan iterera i dina transaktionsprogram utan att behöva hantera schema- eller indexhantering. Till skillnad från detta schematiseras Azure Cosmos DB-analysarkivet för att optimera prestanda för analytiska frågor. Med funktionen för automatisk synkronisering hanterar Azure Cosmos DB schemainferensen för de senaste uppdateringarna från transaktionsarkivet. Den hanterar även schemarepresentationen i analysarkivet, vilket inkluderar hantering av kapslade datatyper.

När schemat utvecklas och nya egenskaper läggs till över tid, visar analysarkivet automatiskt ett unioniserat schema över alla historiska scheman i transaktionsarkivet.

Anteckning

I samband med analysarkivet betraktar vi följande strukturer som egenskap:

JSON "element" eller "string-value pairs avgränsade med " : .
JSON-objekt avgränsade av { och }.
JSON-matriser avgränsade med [ och ].

Schemabegränsningar

Följande begränsningar gäller för driftdata i Azure Cosmos DB när du aktiverar analysarkivet för att automatiskt härleda och representera schemat korrekt:

Du kan ha högst 1 000 egenskaper på alla kapslade nivåer i dokumentschemat och ett maximalt kapslingsdjup på 127.
- Endast de första 1 000 egenskaperna representeras i analysarkivet.
- Endast de första 127 kapslade nivåerna representeras i analysarkivet.
- Den första nivån i ett JSON-dokument är dess / rotnivå.
- Egenskaper på den första nivån i dokumentet representeras som kolumner.
Exempelscenarier:
- Om dokumentets första nivå har 2 000 egenskaper representerar synkroniseringsprocessen de första 1 000.
- Om dina dokument har fem nivåer med 200 egenskaper i var och en representerar synkroniseringsprocessen alla egenskaper.
- Om dina dokument har 10 nivåer med 400 egenskaper i varje, representerar synkroniseringsprocessen de två första nivåerna och bara hälften av den tredje nivån.
Det hypotetiska dokumentet nedan innehåller fyra egenskaper och tre nivåer.
- Nivåerna är root, myArrayoch den kapslade strukturen i myArray.
- Egenskaperna är id, myArray, myArray.nested1och myArray.nested2.
- Representationen av analysarkivet har två kolumner, id, och myArray. Du kan använda Spark- eller T-SQL-funktioner för att även exponera de kapslade strukturerna som kolumner.

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

Även om JSON-dokument (och Azure Cosmos DB-samlingar/containrar) är skiftlägeskänsliga ur unikhetsperspektiv är inte analysarkivet det.
- I samma dokument: Egenskapsnamn på samma nivå bör vara unika när de jämförs skiftlägesokänsligt. Följande JSON-dokument har till exempel "Namn" och "namn" på samma nivå. Även om det är ett giltigt JSON-dokument uppfyller det inte unikhetsbegränsningen och visas därför inte helt i analysarkivet. I det här exemplet är "Namn" och "namn" desamma när de jämförs på ett skiftlägesokänsligt sätt. Endast "Name": "fred" representeras i analysarkivet, eftersom det är den första förekomsten. Och "name": "john" kommer inte att representeras alls.
```
{"id": 1, "Name": "fred", "name": "john"}
```
- I olika dokument: Egenskaper på samma nivå och med samma namn, men i olika fall, representeras i samma kolumn med namnformatet för den första förekomsten. Följande JSON-dokument har "Name" till exempel och "name" på samma nivå. Eftersom det första dokumentformatet är "Name"används det här för att representera egenskapsnamnet i analysarkivet. Kolumnnamnet i analysarkivet blir "Name"med andra ord . Både "fred" och "john" kommer att representeras i "Name" kolumnen.
```
{"id": 1, "Name": "fred"}
{"id": 2, "name": "john"}
```
Det första dokumentet i samlingen definierar det första analysarkivschemat.
- Dokument med fler egenskaper än det ursprungliga schemat genererar nya kolumner i analysarkivet.
- Det går inte att ta bort kolumner.
- Borttagningen av alla dokument i en samling återställer inte schemat för analysarkivet.
- Det finns ingen schemaversionering. Den senaste versionen som härleds från transaktionsarkivet är det du ser i analysarkivet.
För närvarande kan Azure Synapse Spark inte läsa egenskaper som innehåller vissa specialtecken i deras namn, som anges nedan. Azure Synapse SQL-serverlös påverkas inte.
- :
- `
- ,
- ;
- {}
- ()
- \n
- \T
- =
- "

Anteckning

Blanksteg visas också i Spark-felmeddelandet som returneras när du når den här begränsningen. Men vi har lagt till en särskild behandling för blanksteg, kolla in mer information i objekten nedan.

Om du har egenskapsnamn med hjälp av tecknen som anges ovan är alternativen:
- Ändra datamodellen i förväg för att undvika dessa tecken.
- Eftersom vi för närvarande inte stöder schemaåterställning kan du ändra ditt program för att lägga till en redundant egenskap med ett liknande namn och undvika dessa tecken.
- Använd Ändringsflöde för att skapa en materialiserad vy av containern utan dessa tecken i egenskapsnamn.
- dropColumn Använd alternativet Spark för att ignorera de berörda kolumnerna och läsa in alla andra kolumner i en DataFrame. Syntax:

# 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()

Azure Synapse Spark stöder nu egenskaper med blanksteg i sina namn. För det måste du använda allowWhiteSpaceInFieldNames alternativet Spark för att läsa in de berörda kolumnerna i en DataFrame och behålla det ursprungliga namnet. Syntax:

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()

Följande BSON-datatyper stöds inte och visas inte i analysarkivet:
- Decimal 128
- Reguljärt uttryck
- DB-pekare
- JavaScript
- Symbol
- MinKey/MaxKey
När du använder DateTime-strängar som följer ISO 8601 UTC-standarden kan du förvänta dig följande beteende:
- Spark-pooler i Azure Synapse representerar dessa kolumner som string.
- SQL-serverlösa pooler i Azure Synapse representerar dessa kolumner som varchar(8000).
Egenskaper med UNIQUEIDENTIFIER (guid) typer representeras som string i analysarkivet och ska konverteras till VARCHAR i SQL eller till string i Spark för korrekt visualisering.
SQL-serverlösa pooler i Azure Synapse stöder resultatuppsättningar med upp till 1 000 kolumner, och att exponera kapslade kolumner räknas också mot den gränsen. Det är en bra idé att tänka på den här informationen i din transaktionsdataarkitektur och modellering.
Om du byter namn på en egenskap betraktas den i ett eller flera dokument som en ny kolumn. Om du kör samma namnbyte i alla dokument i samlingen migreras alla data till den nya kolumnen och den gamla kolumnen representeras med NULL värden.

Schemarepresentation

Det finns två metoder för schemarepresentation i analysarkivet, som är giltiga för alla containrar i databaskontot. De har kompromisser mellan enkelheten i frågeupplevelsen jämfört med bekvämligheten med en mer inkluderande kolumnrepresentation för polymorfiska scheman.

Väldefinierad schemarepresentation, standardalternativ för API för NoSQL- och Gremlin-konton.
Schemarepresentation med fullständig återgivning, standardalternativ för API för MongoDB-konton.

Väldefinierad schemarepresentation

Den väldefinierade schemarepresentationen skapar en enkel tabellrepresentation av schemaagnostiska data i transaktionslagret. Den väldefinierade schemarepresentationen har följande överväganden:

Det första dokumentet definierar basschemat och egenskaperna måste alltid ha samma typ i alla dokument. De enda undantagen är:
- Från NULL till någon annan datatyp. Den första icke-null-förekomsten definierar kolumndatatypen. Alla dokument som inte följer den första icke-null-datatypen visas inte i analysarkivet.
- Från float till integer. Alla dokument visas i analysarkivet.
- Från integer till float. Alla dokument visas i analysarkivet. Men om du vill läsa dessa data med Azure Synapse serverlösa SQL-pooler måste du använda en WITH-sats för att konvertera kolumnen till varchar. Och efter den här inledande konverteringen går det att konvertera den igen till ett tal. Kontrollera exemplet nedan, där num initialt värde var ett heltal och det andra var ett flyttal.

SELECT CAST (num as float) as num
FROM OPENROWSET(PROVIDER = 'CosmosDB',
                CONNECTION = '<your-connection',
                OBJECT = 'IntToFloat',
                SERVER_CREDENTIAL = 'your-credential'
) 
WITH (num varchar(100)) AS [IntToFloat]

Egenskaper som inte följer basschemadatatypen visas inte i analysarkivet. Tänk till exempel på dokumenten nedan: det första definierade basschemat för analysarkivet. Det andra dokumentet, där id är "2", har inget väldefinierat schema eftersom egenskapen "code" är en sträng och det första dokumentet har "code" som tal. I det här fallet registrerar analysarkivet datatypen "code" som integer containerns livslängd. Det andra dokumentet kommer fortfarande att ingå i analysarkivet, men dess "code" egenskap kommer inte att göra det.
- {"id": "1", "code":123}
- {"id": "2", "code": "123"}

Anteckning

Villkoret ovan gäller inte för NULL egenskaper. Är till exempel {"a":123} and {"a":NULL} fortfarande väldefinierat.

Anteckning

Villkoret ovan ändras inte om du uppdaterar "code" dokumentet "1" till en sträng i transaktionsarkivet. I analysarkivet "code" behålls som integer eftersom vi för närvarande inte stöder schemaåterställning.

Matristyper måste innehålla en enda upprepad typ. Är till exempel {"a": ["str",12]} inte ett väldefinierat schema eftersom matrisen innehåller en blandning av heltal och strängtyper.

Anteckning

Om Azure Cosmos DB-analysarkivet följer den väldefinierade schemarepresentationen och specifikationen ovan överträds av vissa objekt tas dessa objekt inte med i analysarkivet.

Förvänta dig olika beteende när det gäller olika typer i väldefinierade scheman:
- Spark-pooler i Azure Synapse representerar dessa värden som undefined.
- SQL-serverlösa pooler i Azure Synapse representerar dessa värden som NULL.
Förvänta dig ett annat beteende när det gäller explicita NULL värden:
- Spark-pooler i Azure Synapse läsa dessa värden som 0 (noll) och undefined så snart kolumnen har ett värde som inte är null.
- SQL-serverlösa pooler i Azure Synapse läsa dessa värden som NULL.
Förvänta dig ett annat beteende när det gäller kolumner som saknas:
- Spark-pooler i Azure Synapse representerar dessa kolumner som undefined.
- SQL-serverlösa pooler i Azure Synapse representerar dessa kolumner som NULL.

Lösningar på representationsutmaningar

Det är möjligt att ett gammalt dokument, med ett felaktigt schema, användes för att skapa containerns basschema för analysarkivet. Baserat på alla regler som visas ovan kan du få NULL för vissa egenskaper när du frågar analysarkivet med hjälp av Azure Synapse Link. Om du vill ta bort eller uppdatera de problematiska dokumenten hjälper det inte eftersom återställning av basschemat inte stöds för närvarande. Möjliga lösningar är följande:

Om du vill migrera data till en ny container kontrollerar du att alla dokument har rätt schema.
Om du vill överge egenskapen med fel schema och lägga till ett nytt med ett annat namn som har rätt schema i alla dokument. Exempel: Du har miljarder dokument i containern Beställningar där statusegenskapen är en sträng. Men det första dokumentet i containern har status definierat med heltal. Ett dokument har alltså statusen korrekt representerad och alla andra dokument har NULL. Du kan lägga till egenskapen status2 i alla dokument och börja använda den i stället för den ursprungliga egenskapen.

Schemarepresentation med fullständig återgivning

Schemarepresentationen för fullständig återgivning är utformad för att hantera hela bredden av polymorfiska scheman i schemaoberoende driftdata. I den här schemarepresentationen tas inga objekt bort från analysarkivet även om de väldefinierade schemabegränsningarna (som inte är några fält av blandad datatyp eller matriser av blandad datatyp) överträds.

Detta uppnås genom att översätta lövegenskaperna för driftdata till analysarkivet som JSON-par key-value , där datatypen är key och egenskapsinnehållet valueär . Den här JSON-objektrepresentationen tillåter frågor utan tvetydighet, och du kan analysera varje datatyp individuellt.

Med andra ord genererar varje datatyp för varje egenskap i varje dokument ett key-valuepar i ett JSON-objekt för den egenskapen i den fullständiga återgivningsschemarepresentationen. Var och en av dem räknas som en av maxgränsen på 1 000 egenskaper.

Vi tar till exempel följande exempeldokument i transaktionsarkivet:

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

Det kapslade objektet address är en egenskap i dokumentets rotnivå och representeras som en kolumn. Varje lövegenskap i address objektet representeras som ett JSON-objekt: {"object":{"streetNo":{"int32":15850},"streetName":{"string":"NE 40th St."},"zip":{"int32":98052}}}.

Till skillnad från den väldefinierade schemarepresentationen tillåter metoden fullständig återgivning variation i datatyper. Om nästa dokument i den här samlingen av exemplet ovan har streetNo som en sträng representeras det i analysarkivet som "streetNo":{"string":15850}. I en väldefinierad schemametod skulle den inte representeras.

Datatypes-karta för fullständigt återgivningsschema

Här är en karta över MongoDB-datatyper och deras representationer i analysarkivet i en fullständig återgivningsschemarepresentation. Kartan nedan är inte giltig för NoSQL API-konton.

Ursprunglig datatyp	Suffix	Exempel
Double	".float64"	24.99
Matris	".array"	["a", "b"]
Binär	".binary"	0
Boolesk	".bool"	Sant
Int32	".int32"	123
Int64	".int64"	255486129307
NULL	". NULL"	NULL
Sträng	".string"	"ABC"
Timestamp	".timestamp"	Tidsstämpel(0, 0)
ObjectId	".objectId"	ObjectId("5f3f7b59330ec25c132623a2")
Dokument	".object"	{"a": "a"}

Förvänta dig ett annat beteende när det gäller explicita NULL värden:
- Spark-pooler i Azure Synapse läser dessa värden som 0 (noll).
- SQL-serverlösa pooler i Azure Synapse läser dessa värden som NULL.
Förvänta dig ett annat beteende när det gäller kolumner som saknas:
- Spark-pooler i Azure Synapse representerar dessa kolumner som undefined.
- SQL-serverlösa pooler i Azure Synapse representerar dessa kolumner som NULL.
Förvänta dig ett annat beteende när det gäller timestamp värden:
- Spark-pooler i Azure Synapse läser dessa värden som TimestampType, DateTypeeller Float. Det beror på intervallet och hur tidsstämpeln genererades.
- SQL Serverless-pooler i Azure Synapse läser dessa värden som DATETIME2, från 0001-01-01 och med 9999-12-31. Värden utanför det här intervallet stöds inte och orsakar ett körningsfel för dina frågor. Om så är fallet kan du:
  - Ta bort kolumnen från frågan. Om du vill behålla representationen kan du skapa en ny egenskap som speglar kolumnen men inom det intervall som stöds. Och använd det i dina frågor.
  - Använd Change Data Capture från analysarkivet utan kostnad för RU:er för att transformera och läsa in data i ett nytt format inom en av de mottagare som stöds.

Använda fullständigt återgivningsschema med Spark

Spark hanterar varje datatyp som en kolumn när den läses in i en DataFrame. Vi antar en samling med dokumenten nedan.

{
	"_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"
}

Det första dokumentet har rating som tal och timestamp utc-format, men det andra dokumentet har rating och timestamp som strängar. Förutsatt att den här samlingen lästes in utan DataFrame någon datatransformering är utdata från df.printSchema() :

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)

I en väldefinierad schemarepresentation skulle både rating och timestamp för det andra dokumentet inte representeras. I schemat för fullständig återgivning kan du använda följande exempel för att individuellt komma åt varje värde för varje datatyp.

I exemplet nedan kan vi använda PySpark för att köra en aggregering:

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

I exemplet nedan kan vi använda PySQL för att köra en annan aggregering:

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()

Använda fullständigt återgivningsschema med SQL

Med tanke på samma dokument i Spark-exemplet ovan kan kunderna använda följande syntaxexempel:

SELECT rating,timestamp_string,timestamp_utc
FROM OPENROWSET(PROVIDER = 'CosmosDB',
                CONNECTION = 'Account=<your-database-account-name';Database=<your-database-name>',
                OBJECT = '<your-collection-name>',
                SERVER_CREDENTIAL = '<your-synapse-sql-server-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

Från och med frågan ovan kan kunder implementera transformeringar med hjälp av cast, convert eller någon annan T-SQL-funktion för att manipulera dina data. Kunder kan också dölja komplexa datatypsstrukturer med hjälp av vyer.

create view MyView as
SELECT MyRating=rating,MyTimestamp = convert(varchar(50),timestamp_utc)
FROM OPENROWSET(PROVIDER = 'CosmosDB',
                CONNECTION = 'Account=<your-database-account-name';Database=<your-database-name>',
                OBJECT = '<your-collection-name>',
                SERVER_CREDENTIAL = '<your-synapse-sql-server-credential-name>')
WITH ( 
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=<your-database-account-name';Database=<your-database-name>',
                OBJECT = '<your-collection-name>',
                SERVER_CREDENTIAL = '<your-synapse-sql-server-credential-name>')
WITH ( 
rating_string varchar(50) '$.rating.string',    
timestamp_string varchar(50) '$.timestamp.string' 
) as HTAP 
WHERE  timestamp_string is not null

Arbeta med MongoDB-fältet `_id`

MongoDB-fältet _id är grundläggande för varje samling i MongoDB och har ursprungligen en hexadecimal representation. Som du ser i tabellen ovan bevarar schemat för fullständig återgivning dess egenskaper, vilket skapar en utmaning för dess visualisering i Azure Synapse Analytics. För korrekt visualisering måste du konvertera _id datatypen enligt nedan:

Arbeta med MongoDB-fältet `_id` i Spark

Exemplet nedan fungerar på Spark 2.x- och 3.x-versioner:

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)

Arbeta med MongoDB-fältet `_id` i SQL

SELECT TOP 100 id=CAST(_id as VARBINARY(1000))
FROM OPENROWSET('CosmosDB',
                'Your-account;Database=your-database;Key=your-key',
                HTAP) WITH (_id VARCHAR(1000)) as HTAP

Fullständigt återgivningsschema för API för NoSQL- eller Gremlin-konton

Det går att använda fullständigt återgivningsschema för API för NoSQL-konton i stället för standardalternativet genom att ange schematypen när du aktiverar Synapse Link på ett Azure Cosmos DB-konto för första gången. Här är några saker att tänka på när du ändrar standardschemarepresentationstypen:

Om du aktiverar Synapse Link i ditt NoSQL API-konto med Azure Portal aktiveras det för närvarande som ett väldefinierat schema.
Om du för närvarande vill använda ett fullständigt återgivningsschema med NoSQL- eller Gremlin API-konton måste du ange det på kontonivå i samma CLI- eller PowerShell-kommando som aktiverar Synapse Link på kontonivå.
För närvarande är Azure Cosmos DB for MongoDB inte kompatibelt med den här möjligheten att ändra schemarepresentationen. Alla MongoDB-konton har en fullständig återgivningsschemarepresentationstyp.
Karta över schemadatatyper för fullständig återgivning som nämns ovan är inte giltig för NoSQL API-konton som använder JSON-datatyper. Till exempel floatinteger representeras värden som num i analysarkivet.
Det går inte att återställa schemarepresentationstypen, från väldefinierad till fullständig återgivning eller tvärtom.
För närvarande definieras containerscheman i analysarkivet när containern skapas, även om Synapse Link inte har aktiverats i databaskontot.
- Containrar eller grafer som skapades innan Synapse Link aktiverades med fullständigt återgivningsschema på kontonivå har ett väldefinierat schema.
- Containrar eller grafer som skapats efter att Synapse Link har aktiverats med fullständigt återgivningsschema på kontonivå har ett fullständigt återgivningsschema.

Beslutet om schemarepresentationstyp måste fattas samtidigt som Synapse Link är aktiverat för kontot med hjälp av Azure CLI eller PowerShell.

Med Azure CLI:

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

Anteckning

I kommandot ovan ersätter du create med update för befintliga konton.

Med PowerShell:

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

Anteckning

I kommandot ovan ersätter du New-AzCosmosDBAccount med Update-AzCosmosDBAccount för befintliga konton.

TTL (Time to Live) för analys

TTL -analys (ATTL) anger hur länge data ska behållas i analysarkivet för en container.

Analysarkiv aktiveras när ATTL anges med ett annat värde än NULL och 0. När det är aktiverat synkroniseras infogningar, uppdateringar, borttagningar till driftdata automatiskt från transaktionsarkivet till analysarkivet, oavsett TTTL-konfigurationen (transactional TTL). Kvarhållningen av dessa transaktionsdata i analysarkivet kan styras på containernivå av AnalyticalStoreTimeToLiveInSeconds egenskapen .

Möjliga ATTL-konfigurationer är:

Om värdet är inställt på 0 eller inställt på NULL: analysarkivet är inaktiverat och inga data replikeras från transaktionsarkivet till analysarkivet
Om värdet är inställt på -1: analysarkivet behåller alla historiska data, oavsett kvarhållning av data i transaktionslagret. Den här inställningen anger att analysarkivet har oändlig kvarhållning av dina driftdata
Om värdet är inställt på ett positivt heltalsnummer n : objekt upphör att gälla från analysarkivet n sekunder efter den senaste ändrade tiden i transaktionsarkivet. Den här inställningen kan användas om du vill behålla dina driftdata under en begränsad tidsperiod i analysarkivet, oavsett kvarhållning av data i transaktionslagret

Några saker att tänka på:

När analysarkivet har aktiverats med ett ATTL-värde kan det uppdateras till ett annat giltigt värde senare.
TTTL kan anges på container- eller objektnivå, men ATTL kan bara anges på containernivå för närvarande.
Du kan uppnå längre kvarhållning av dina driftdata i analysarkivet genom att ange ATTL >= TTTL på containernivå.
Analysarkivet kan göras för att spegla transaktionsarkivet genom att ange ATTL = TTTL.
Om du har ATTL som är större än TTTL har du någon gång data som bara finns i analysarkivet. Dessa data är skrivskyddade.
För närvarande tar vi inte bort några data från analysarkivet. Om du ställer in din ATTL på något positivt heltal inkluderas inte data i dina frågor och du debiteras inte för det. Men om du ändrar ATTL tillbaka till -1visas alla data igen, du börjar debiteras för all datavolym.

Så här aktiverar du analysarkiv på en container:

Från Azure Portal är ATTL-alternativet, när det är aktiverat, inställt på standardvärdet -1. Du kan ändra det här värdet till n sekunder genom att gå till containerinställningarna under Data Explorer.
Från Azure Management SDK, Azure Cosmos DB SDK:er, PowerShell eller Azure CLI kan ATTL-alternativet aktiveras genom att ställa in det på -1 eller 'n' sekunder.

Mer information finns i hur du konfigurerar TTL för analys på en container.

Kostnadseffektiv analys av historiska data

Datanivåindelning avser separation av data mellan lagringsinfrastrukturer som är optimerade för olika scenarier. Förbättra därmed den övergripande prestandan och kostnadseffektiviteten för datastacken från slutpunkt till slutpunkt. Med analysarkivet har Azure Cosmos DB nu stöd för automatisk nivåindelning av data från transaktionslagret till analysarkivet med olika datalayouter. Med analysarkivet optimerat i förhållande till lagringskostnaden jämfört med transaktionslagret kan du behålla mycket längre horisonter av driftdata för historisk analys.

När analysarkivet har aktiverats, baserat på datakvarhållningsbehoven för transaktionsarbetsbelastningarna, kan du konfigurera transactional TTL egenskapen så att poster tas bort automatiskt från transaktionslagret efter en viss tidsperiod. analytical TTL På samma sätt kan du hantera livscykeln för data som behålls i analysarkivet, oberoende av transaktionslagret. Genom att aktivera analysarkiv och konfigurera transaktions- och analysegenskaper TTL kan du sömlöst nivåindela och definiera datakvarhållningsperioden för de två arkiven.

Anteckning

När analytical TTL är större än transactional TTLhar containern data som bara finns i analysarkivet. Dessa data är skrivskyddade och för närvarande stöder vi inte dokumentnivå TTL i analysarkivet. Om dina containerdata kan behöva uppdateras eller tas bort någon gång i framtiden ska du inte använda analytical TTL större än transactional TTL. Den här funktionen rekommenderas för data som inte behöver uppdateringar eller borttagningar i framtiden.

Anteckning

Om ditt scenario inte kräver fysiska borttagningar kan du använda en logisk borttagnings-/uppdateringsmetod. Infoga i transaktionsarkivet en annan version av samma dokument som bara finns i analysarkivet men som behöver en logisk borttagning/uppdatering. Kanske med en flagga som anger att det är en borttagning eller en uppdatering av ett dokument som har upphört att gälla. Båda versionerna av samma dokument samexisterar i analysarkivet och ditt program bör bara ta hänsyn till den sista.

Motståndskraft

Analysarkivet förlitar sig på Azure Storage och erbjuder följande skydd mot fysiska fel:

Som standard allokerar Azure Cosmos DB-databaskonton analysarkiv i LRS-konton (Lokalt redundant lagring). LRS ger minst 99,99999999999% (11 nior) hållbarhet för objekt under ett visst år.
Om en geo-region för databaskontot har konfigurerats för zonredundans allokeras den i ZRS-konton (Zone-redundant Storage). Kunder måste aktivera Tillgänglighetszoner i en region i sitt Azure Cosmos DB-databaskonto för att ha analysdata för den regionen lagrade i zonredundant lagring. ZRS erbjuder hållbarhet för lagringsresurser på minst 99,9999999999 % (12 9) under ett visst år.

Klicka här om du vill ha mer information om Hållbarhet i Azure Storage.

Backup

Även om analysarkivet har ett inbyggt skydd mot fysiska fel kan säkerhetskopiering vara nödvändig för oavsiktliga borttagningar eller uppdateringar i transaktionsarkivet. I dessa fall kan du återställa en container och använda den återställde containern för att fylla på data i den ursprungliga containern eller återskapa analysarkivet helt om det behövs.

Anteckning

För närvarande säkerhetskopieras inte analysarkivet, därför kan det inte återställas. Det går inte att planera säkerhetskopieringsprincipen.

Synapse Link och analysarkivet har därför olika kompatibilitetsnivåer med Azure Cosmos DB-säkerhetskopieringslägen:

Läget för periodisk säkerhetskopiering är helt kompatibelt med Synapse Link och dessa två funktioner kan användas i samma databaskonto.
För närvarande stöds inte kontinuerlig säkerhetskopiering och Synapse Link i samma databaskonto. Kunder måste välja en av dessa två funktioner och det här beslutet kan inte ändras.

Säkerhetskopieringsprinciper

Det finns två möjliga säkerhetskopieringsprinciper och för att förstå hur du använder dem är följande information om Azure Cosmos DB-säkerhetskopior mycket viktig:

Den ursprungliga containern återställs utan analysarkiv i båda säkerhetskopieringslägena.
Azure Cosmos DB stöder inte överskrivning av containrar från en återställning.

Nu ska vi se hur du använder säkerhetskopiering och återställningar ur analysarkivets perspektiv.

Återställa en container med TTTL >= ATTL

När transactional TTL är lika med eller större än analytical TTLfinns alla data i analysarkivet fortfarande i transaktionsarkivet. Vid en återställning har du två möjliga situationer:

Så här använder du den återställde containern som ersättning för den ursprungliga containern. Om du vill återskapa analysarkivet aktiverar du bara Synapse Link på kontonivå och containernivå.
Så här använder du den återställde containern som datakälla för att fylla på eller uppdatera data i den ursprungliga containern. I det här fallet återspeglar analysarkivet automatiskt dataåtgärderna.

Återställa en container med TTTL < ATTL

När transactional TTL är mindre än analytical TTLfinns vissa data bara i analysarkivet och finns inte i den återställde containern. Återigen har du två möjliga situationer:

Så här använder du den återställde containern som ersättning för den ursprungliga containern. I det här fallet, när du aktiverar Synapse Link på containernivå, inkluderas endast de data som fanns i transaktionsarkivet i det nya analysarkivet. Observera dock att analysarkivet för den ursprungliga containern förblir tillgängligt för frågor så länge den ursprungliga containern finns. Du kanske vill ändra programmet så att det frågar båda.
Så här använder du den återställde containern som datakälla för att fylla på eller uppdatera data i den ursprungliga containern:
Analysarkivet återspeglar automatiskt dataåtgärderna för de data som finns i transaktionsarkivet.
Om du återinfogar data som tidigare tagits bort från transaktionslagret på grund av transactional TTLdupliceras dessa data i analysarkivet.

Exempel:

Containern OnlineOrders har TTTL inställt på en månad och ATTL har angetts för ett år.
När du återställer det till OnlineOrdersNew och aktiverar analysarkivet för att återskapa det, kommer det bara att finnas en månads data i både transaktions- och analysarkivet.
Den ursprungliga containern OnlineOrders tas inte bort och analysarkivet är fortfarande tillgängligt.
Nya data matas bara in i OnlineOrdersNew.
Analysfrågor kommer att göra en UNION ALL från analyslager medan de ursprungliga data fortfarande är relevanta.

Om du vill ta bort den ursprungliga containern men inte vill förlora sina analyslagringsdata kan du spara analysarkivet för den ursprungliga containern i en annan Azure-datatjänst. Synapse Analytics har möjlighet att utföra kopplingar mellan data som lagras på olika platser. Ett exempel: En Synapse Analytics-fråga kopplar analyslagringsdata till externa tabeller som finns i Azure Blob Storage, Azure Data Lake Store osv.

Observera att data i analysarkivet har ett annat schema än det som finns i transaktionslagret. Även om du kan generera ögonblicksbilder av dina analyslagringsdata och exportera dem till valfri Azure Data-tjänst, utan kostnader för RU:er, kan vi inte garantera att den här ögonblicksbilden används för att mata tillbaka transaktionslagret. Den här processen stöds inte.

Global distribution

Om du har ett globalt distribuerat Azure Cosmos DB-konto blir det tillgängligt i alla regioner i kontot när du har aktiverat analysarkiv för en container. Ändringar av driftdata replikeras globalt i alla regioner. Du kan köra analysfrågor effektivt mot närmaste regionala kopia av dina data i Azure Cosmos DB.

Partitionering

Partitioneringen av analysarkivet är helt oberoende av partitionering i transaktionsarkivet. Som standard partitioneras inte data i analysarkivet. Om dina analysfrågor har filter som används ofta kan du partitionera baserat på dessa fält för bättre frågeprestanda. Mer information finns i introduktionen till anpassad partitionering och hur du konfigurerar anpassad partitionering.

Säkerhet

Autentisering med analysarkivet är samma som transaktionsarkivet för en viss databas. Du kan använda primära, sekundära eller skrivskyddade nycklar för autentisering. Du kan använda länkad tjänst i Synapse Studio för att förhindra att Azure Cosmos DB-nycklarna klistras in i Spark-notebook-filerna. För Azure Synapse SQL Serverless kan du använda SQL-autentiseringsuppgifter för att förhindra att Azure Cosmos DB-nycklarna klistras in i SQL-notebook-filerna. Åtkomsten till dessa länkade tjänster eller till dessa SQL-autentiseringsuppgifter är tillgänglig för alla som har åtkomst till arbetsytan. Observera att den skrivskyddade Azure Cosmos DB-nyckeln också kan användas.
Nätverksisolering med privata slutpunkter – Du kan styra nätverksåtkomsten till data i transaktions- och analysarkiven oberoende av varandra. Nätverksisolering görs med hjälp av separata hanterade privata slutpunkter för varje arkiv, i hanterade virtuella nätverk i Azure Synapse arbetsytor. Mer information finns i artikeln Konfigurera privata slutpunkter för analysarkiv .
Datakryptering i vila – Kryptering i analysarkivet är aktiverat som standard.
Datakryptering med kundhanterade nycklar – Du kan sömlöst kryptera data i transaktions- och analysarkiv med samma kundhanterade nycklar på ett automatiskt och transparent sätt. Azure Synapse Link stöder endast konfigurering av kundhanterade nycklar med hjälp av ditt Azure Cosmos DB-kontos hanterade identitet. Du måste konfigurera kontots hanterade identitet i din Azure Key Vault-åtkomstprincip innan du aktiverar Azure Synapse Link på ditt konto. Mer information finns i artikeln Konfigurera kundhanterade nycklar med hjälp av Hanterade identiteter för Azure Cosmos DB-konton .

Anteckning

Om du ändrar ditt databaskonto från Första part till System- eller Användartilldelad Identy och aktiverar Azure Synapse Länk i ditt databaskonto kan du inte återgå till identitet från första part eftersom du inte kan inaktivera Synapse Link från ditt databaskonto.

Stöd för flera Azure Synapse Analytics-körningar

Analysarkivet är optimerat för att ge skalbarhet, elasticitet och prestanda för analytiska arbetsbelastningar utan något beroende av beräkningskörningstiderna. Lagringstekniken är självhanterad för att optimera dina analysarbetsbelastningar utan manuella ansträngningar.

Genom att koppla bort analyslagringssystemet från analysberäkningssystemet kan data i Azure Cosmos DB-analysarkivet frågas samtidigt från de olika analyskörningar som stöds av Azure Synapse Analytics. Från och med idag stöder Azure Synapse Analytics Apache Spark och serverlös SQL-pool med Azure Cosmos DB-analysarkiv.

Anteckning

Du kan bara läsa från analysarkivet med hjälp av Azure Synapse Analytics-körningar. Och motsatsen är också sant, Azure Synapse Analytics-körningar kan bara läsa från analysarkivet. Endast processen för automatisk synkronisering kan ändra data i analysarkivet. Du kan skriva tillbaka data till Azure Cosmos DB-transaktionsarkivet med Azure Synapse Analytics Spark-pool med hjälp av den inbyggda Azure Cosmos DB OLTP SDK.

Prissättning

Analysarkivet följer en förbrukningsbaserad prismodell där du debiteras för:

Lagring: mängden data som behålls i analysarkivet varje månad, inklusive historiska data enligt definitionen i TTL för analys.
Analytiska skrivåtgärder: den fullständigt hanterade synkroniseringen av uppdateringar av driftdata till analysarkivet från transaktionsarkivet (automatisk synkronisering)
Läsåtgärder för analys: de läsåtgärder som utförs mot analysarkivet från Azure Synapse Analytics Spark-pool och serverlösa SQL-poolkörningstider.

Prissättningen för analysarkivet är separat från prismodellen för transaktionsarkivet. Det finns inget begrepp om etablerade RU:er i analysarkivet. Se prissättningssidan för Azure Cosmos DB för fullständig information om prismodellen för analysarkivet.

Data i analysarkivet kan bara nås via Azure Synapse Link, vilket görs i Azure Synapse Analytics-körningar: Azure Synapse Apache Spark-pooler och Azure Synapse serverlösa SQL-pooler. Se prissättningssidan för Azure Synapse Analytics för fullständig information om prismodellen för åtkomst till data i analysarkivet.

För att få en kostnadsuppskattning på hög nivå för att aktivera analysarkiv i en Azure Cosmos DB-container kan du från analysarkivets perspektiv använda Kapacitetsplaneraren för Azure Cosmos DB och få en uppskattning av dina kostnader för analyslagring och skrivåtgärder.

Uppskattningar av läsåtgärder i analysarkivet ingår inte i Kostnadskalkylatorn för Azure Cosmos DB eftersom de är en funktion i din analytiska arbetsbelastning. Men som en uppskattning på hög nivå resulterar genomsökning av 1 TB data i analysarkivet vanligtvis i 130 000 analytiska läsåtgärder och resulterar i en kostnad på 0,065 USD. Om du till exempel använder Azure Synapse serverlösa SQL-pooler för att utföra den här genomsökningen på 1 TB kostar det 5,00 USD enligt prissättningssidan för Azure Synapse Analytics. Den slutliga totala kostnaden för den här genomsökningen på 1 TB skulle vara 5,065 USD.

Även om ovanstående uppskattning är för genomsökning av 1 TB data i analysarkivet, minskar användningen av filter mängden data som genomsöks och detta avgör det exakta antalet analysläsningsåtgärder med tanke på förbrukningsprismodellen. Ett koncepttest kring den analytiska arbetsbelastningen skulle ge en finare uppskattning av analysläsningsåtgärder. Den här uppskattningen inkluderar inte kostnaden för Azure Synapse Analytics.

Nästa steg

Mer information finns i följande dokument:

Vad är Azure Cosmos DB-analysarkiv?

Utmaningar med storskalig analys av driftdata

Kolumnorienterat analysarkiv

Funktioner i analysarkivet

Kolumnlager för analytiska arbetsbelastningar på driftdata

Frikopplade prestanda för analytiska arbetsbelastningar

Synkronisera automatiskt

Elasticitet för skalbarhet &

Hantera schemauppdateringar automatiskt

Schemabegränsningar

Schemarepresentation

Väldefinierad schemarepresentation

Lösningar på representationsutmaningar

Schemarepresentation med fullständig återgivning

Datatypes-karta för fullständigt återgivningsschema

Använda fullständigt återgivningsschema med Spark

Använda fullständigt återgivningsschema med SQL

Arbeta med MongoDB-fältet `_id`

Arbeta med MongoDB-fältet `_id` i Spark

Arbeta med MongoDB-fältet `_id` i SQL

Fullständigt återgivningsschema för API för NoSQL- eller Gremlin-konton

TTL (Time to Live) för analys

Kostnadseffektiv analys av historiska data

Motståndskraft

Backup

Säkerhetskopieringsprinciper

Återställa en container med TTTL >= ATTL

Återställa en container med TTTL < ATTL

Global distribution

Partitionering

Säkerhet

Stöd för flera Azure Synapse Analytics-körningar

Prissättning

Nästa steg

Ytterligare resurser

Ytterligare resurser

Vad är Azure Cosmos DB-analysarkiv?

Utmaningar med storskalig analys av driftdata

Kolumnorienterat analysarkiv

Funktioner i analysarkivet

Kolumnlager för analytiska arbetsbelastningar på driftdata

Frikopplade prestanda för analytiska arbetsbelastningar

Synkronisera automatiskt

Elasticitet för skalbarhet &

Hantera schemauppdateringar automatiskt

Schemabegränsningar

Schemarepresentation

Väldefinierad schemarepresentation

Lösningar på representationsutmaningar

Schemarepresentation med fullständig återgivning

Datatypes-karta för fullständigt återgivningsschema

Använda fullständigt återgivningsschema med Spark

Använda fullständigt återgivningsschema med SQL

Arbeta med MongoDB-fältet _id

Arbeta med MongoDB-fältet _id i Spark

Arbeta med MongoDB-fältet _id i SQL

Fullständigt återgivningsschema för API för NoSQL- eller Gremlin-konton

TTL (Time to Live) för analys

Kostnadseffektiv analys av historiska data

Motståndskraft

Backup

Säkerhetskopieringsprinciper

Återställa en container med TTTL >= ATTL

Återställa en container med TTTL < ATTL

Global distribution

Partitionering

Säkerhet

Stöd för flera Azure Synapse Analytics-körningar

Prissättning

Nästa steg

Ytterligare resurser

Ytterligare resurser

Arbeta med MongoDB-fältet `_id`

Arbeta med MongoDB-fältet `_id` i Spark

Arbeta med MongoDB-fältet `_id` i SQL