Vad är Azure Cosmos DB analysarkiv?

GÄLLER för: SQL API Azure Cosmos DB API för MongoDB

Azure Cosmos DB analysarkiv är ett helt isolerat kolumnlager för att möjliggöra storskalig analys mot driftdata i din Azure Cosmos DB, utan att påverka dina transaktionsarbetsbelastningar.

Azure Cosmos DB transaktionsarkiv är schemaoberoende och gör att du kan iterera i dina transaktionsprogram utan att behöva hantera schema- eller indexhantering. Till skillnad från detta Azure Cosmos DB schemat för analysarkiv för att optimera prestanda för analytiska frågor. Den här artikeln beskriver i detalj analyslagring.

Utmaningar med storskalig analys av driftdata

Driftdata för flera modeller i en Azure Cosmos DB lagras internt i ett indexerat radbaserat "transaktionslager". Radlagerformatet är utformat för att tillåta snabba transaktionsläsningar och skrivningar i svarstiderna för millisekunder och driftfrågor. Om datamängden växer kan komplexa analysfrågor bli 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 påverkar i sin tur prestandan för transaktionsarbetsbelastningar som används av dina realtidsprogram och tjänster.

För att analysera stora mängder data extraheras traditionellt driftdata från Azure Cosmos DB transaktionslager och lagras i ett separat datalager. Till exempel lagras data i ett informationslager eller en datasjö i ett lämpligt format. Dessa data används senare för storskalig analys och analyseras med hjälp av beräkningsmotorn, till exempel Apache Spark kluster. Den här uppdelningen av analytiska lagrings- och beräkningslager från driftdata resulterar i ytterligare svarstider eftersom pipelines för ETL(extrahering, transformering, inläsning) körs mindre ofta för att minimera den potentiella påverkan på dina transaktionsarbetsbelastningar.

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

Kolumnorienterat analysarkiv

Azure Cosmos DB analysarkiv hanterar de komplexitets- och svarstidsutmaningar som uppstår med traditionella ETL-pipelines. Azure Cosmos DB analysarkiv kan automatiskt synkronisera dina driftdata till ett separat kolumnlager. Kolumnlagerformat ä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 analysarkiv från Azure Synapse Analytics. Det gör att du kan köra storskalig analys i nära realtid på dina driftdata.

Funktioner i analysarkiv

När du aktiverar analysarkiv på Azure Cosmos DB container skapas ett nytt kolumnlager internt baserat på driftdata i containern. Det här kolumnarkivet bevaras separat från det radorienterade transaktionsarkivet för containern. Infogningar, uppdateringar och borttagningar av dina driftdata synkroniseras automatiskt till analysarkivet. Du behöver inte ändringsflödet 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 gör analysarkivet att en grupp med värden för varje fält kan serialiseras tillsammans. Det här formatet minskar den IOPS som krävs för att skanna eller beräkna statistik över specifika fält. Det förbättrar avsevärt frågesvarstiderna för genomsökningar över stora datamängder.

Till exempel om dina operativa tabeller har följande format:

Radlagret sparar ovanstående data i ett serialiserat format, per rad, på disken. Det här formatet möjliggör snabbare transaktionsläsningar, skrivningar och driftfrågor, till exempel "Returnera information om Produkt1". Men när datauppsättningen växer och om du vill köra komplexa analysfrågor på data kan det vara dyrt. Om du till exempel vill hämta "försäljningstrender 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 av den här datamängden kan bli dyra när det gäller etablerat dataflöde och kan även påverka prestandan för transaktionsarbetsbelastningar som driver dina realtidsprogram och tjänster.

Analysarkiv, 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 transaktionsradarkiv jämfört med analyskolumnarkiv i Azure Cosmos DB:

Fristående prestanda för analytiska arbetsbelastningar

Prestandan för dina transaktionsarbetsbelastningar påverkas inte på grund av analytiska frågor, eftersom analysarkivet är separat från transaktionslagret. Analysarkivet behöver inte allokera separata enheter för begäran (RU:er).

Automatisk synkronisering

Automatisk synkronisering syftar på den fullständigt hanterade funktionen i Azure Cosmos DB där infogningar, uppdateringar och borttagningar av driftdata automatiskt synkroniseras från transaktionslager till analysarkiv nästan i realtid. Svarstiden för automatisk synkronisering är vanligtvis inom 2 minuter. I fall med en databas med delat dataflöde med ett stort antal containrar kan svarstiden för automatisk synkronisering av enskilda containrar vara högre och ta upp till 5 minuter. Vi vill veta mer om hur den här svarstiden passar dina scenarier. För att göra det kan du kontakta Azure Cosmos DB team.

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

• Azure Synapse Analytics Spark-pooler kan läsa alla data, inklusive de senaste uppdateringarna, via Spark-tabeller som uppdateras automatiskt eller via kommandot som alltid läser det sista spark.read tillståndet för data.

• Azure Synapse Analytics SQL serverlösa pooler kan läsa alla data, inklusive de senaste uppdateringarna, via vyer, som uppdateras automatiskt eller via tillsammans med kommandona, som alltid läser den senaste SELECT OPENROWSET statusen för data.

Skalbarhet & elasticitet

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

Hantera schemauppdateringar automatiskt

Azure Cosmos DB transaktionsarkiv är schemaoberoende och gör att du kan iterera i dina transaktionsprogram utan att behöva hantera schema- eller indexhantering. Till skillnad från detta Azure Cosmos DB schemat för analysarkiv för att optimera prestanda för analytiska frågor. Med funktionen för automatisk synkronisering Azure Cosmos DB hanterar schemainferensen över de senaste uppdateringarna från transaktionslagret. Den hanterar även schemarepresentationen i analysarkivet out-of-the-box, vilket innefattar hantering av kapslade datatyper.

Allt eftersom ditt schema utvecklas och nya egenskaper läggs till över tid, visar analysarkivet automatiskt ett unioniserat schema för alla historiska scheman i transaktionslagret.

Schemabegränsningar

Följande begränsningar gäller för driftdata i Azure Cosmos DB du aktiverar analysarkiv för att automatiskt dra slutsatser om och representera schemat korrekt:

• Du kan ha högst 1 000 egenskaper på en kapslingsnivå i schemat 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 visas bara de första 1 000.
  • Om dina dokument har 5 nivåer med 200 egenskaper i var och en visas alla egenskaper.
  • Om dina dokument har 10 nivåer med 400 egenskaper i var och en, representeras endast de två första nivåerna fullständigt i analysarkivet. Hälften av den tredje nivån representeras också.

• Det hypotetiska dokumentet nedan innehåller 4 egenskaper och 3 nivåer.

  • Nivåerna är root , och den myArray kapslade strukturen i myArray .
  • Egenskaperna är id , myArray och myArray.nested1 myArray.nested2 .
  • Representationen av analysarkivet har 2 kolumner id och myArray . Du kan använda Spark- eller T-SQL för att även exponera de kapslade strukturerna som kolumner.

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

• JSON-dokument (och Cosmos DB samlingar/containrar) är fallkänsliga ur unikhetsperspektiv, men analysarkivet är det inte.

  • I samma dokument: Egenskapsnamn på samma nivå ska vara unika när det inte är känsligt för jämförelse. 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 representeras därför inte helt i analysarkivet. I det här exemplet är "Name" och "name" desamma när de jämförs på ett okänsligt sätt. Endast "Name": "fred" representeras i analysarkiv eftersom det är den första förekomsten. Och "name": "john" representeras inte 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 hjälp av namnformatet för den första förekomsten. Följande JSON-dokument har till exempel "Name" "name" och på samma nivå. Eftersom det första dokumentformatet "Name" är används detta för att representera egenskapsnamnet i analysarkivet. Kolumnnamnet i analysarkivet blir med andra ord "Name" . Både "fred" "john" och visas 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.
  • Kolumner kan inte tas bort.
  • Borttagningen av alla dokument i en samling återställer inte analysarkivschemat.
  • Det finns ingen schemaversionshantering. Den senaste versionen som här härledas från transaktionsarkivet är det som visas i analysarkivet.

• För Azure Synapse Spark inte läsa egenskaper som innehåller vissa specialtecken i sina namn, som anges nedan. Azure Synapse SQL serverlös påverkas inte.

  • : (Kolon)
  • ' (Accent accent)
  • , (kommatecken)
  • ; (Semikolon)
  • {}
  • ()
  • \n
  • \t
  • = (Likhetstecken)
  • " (citattecken)

• Om du har egenskapsnamn med de tecken 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, så att dessa tecken undviks.
  • Använd Ändringsflöde för att skapa en materialiserad vy av containern utan dessa tecken i egenskapsnamn.
  • Använd dropColumn alternativet Spark för att ignorera de berörda kolumnerna och läsa in alla andra kolumner i en DataFrame. Syntax:

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

df = spark.read\
    .format("cosmos.olap")\
    .option("spark.synapse.linkedService","<your-linked-service-name>")\
    .option("spark.synapse.container","<your-container-name>")\
    .option("spark.synapse.dropColumn","FirstName,LastName")\
    .option("spark.synapse.dropColumn","StreetName,StreetNumber")\
    .load()  

• Azure Synapse Spark stöder nu egenskaper med blanksteg i sina namn. För att göra det måste du använda allowWhiteSpaceInFieldNames Spark-alternativet 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 representeras inte i analysarkivet:

  • Decimal128
  • Reguljärt uttryck
  • DB-pekare
  • JavaScript
  • Symbol
  • MinKey/MaxKey

• När du använder DateTime-strängar som följer ISO 8601 UTC-standarden ska du förvänta dig följande beteende:

  • Spark-pooler Azure Synapse representerar dessa kolumner som string .
  • SQL serverlösa pooler i Azure Synapse dessa kolumner som varchar(8000) .

• SQL serverlösa pooler i Azure Synapse stöd för resultatuppsättningar med upp till 1 000 kolumner och exponera kapslade kolumner räknas också mot den gränsen. Tänk på den här informationen när du utformar din dataarkitektur och modellerar dina transaktionsdata.

Schemarepresentation

Det finns två typer av schemarepresentation i analysarkivet. Dessa typer definierar schemarepresentationsmetoden för alla containrar i databaskontot och har kompromisser mellan enkel frågeupplevelse och bekvämligheten med en mer inkluderande kolumnrepresentation för polymorfiska scheman.

• Väldefinierad schemarepresentation, standardalternativet för SQL(CORE) API-konton.
• Schemarepresentation med fullständig återgivning, standardalternativet för Azure Cosmos DB API för MongoDB-konton.

Fullständigt återgivningsschema för SQL API-konton

Du kan använda fullständigt återgivningsschema för SQL-API-konton (Core) i stället för standardalternativet genom att ange schematypen när du aktiverar Synapse Link på ett Cosmos DB-konto för första gången. Här är några saker att tänka på när du ändrar standardtypen för schemarepresentation:

• Det här alternativet är endast giltigt för konton som inte redan Synapse Link aktiverat.
• Det går inte att återställa schemarepresentationstypen, från väldefinierad till fullständig återgivning eller tvärtom.
• Api Azure Cosmos DB för MongoDB-konton är för närvarande inte kompatibelt med den här möjligheten att ändra schemarepresentationen. Alla MongoDB-konton har alltid en fullständig schemarepresentationstyp.
• Den här ändringen kan för närvarande inte göras via Azure Portal. Alla databaskonton som har Synapse LinK aktiverat av Azure Portal har en väldefinierad schemarepresentationstyp som är standard.

Beslutet om schemarepresentationstyp måste fattas samtidigt som Synapse Link aktiveras på 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

Med PowerShell:

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

Väldefinierad schemarepresentation

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

• Det första dokumentet definierar basschemat och egenskapen 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. Dokument som inte följer den första icke-null-datatypen representeras inte i analysarkivet.
  • Från float till integer . Alla dokument representeras i analysarkivet.
  • Från integer till float . Alla dokument representeras i analysarkivet. Men om du vill läsa dessa data Azure Synapse SQL serverlösa pooler måste du använda en WITH-sats för att konvertera kolumnen till varchar . Och efter den här inledande konverteringen är det möjligt 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 datatypen för basschemat visas inte i analysarkivet. Tänk dig till exempel de två dokumenten nedan och att det första definierade analysarkivbasschemat. Det andra dokumentet, där är , har inte ett väldefinierat schema eftersom egenskapen är en sträng och id det första dokumentet har som ett 2 "a" "a" tal. I det här fallet registrerar analysarkivet datatypen för "a" som integer för containern. Det andra dokumentet kommer fortfarande att ingå i analysarkivet, men dess "a" egenskap kommer inte att det.

  • {"id": "1", "a":123}
  • {"id": "2", "a": "str"}

• 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 heltals- och strängtyper.

• Förvänta dig olika beteende vad gäller olika typer i väldefinierade scheman:

  • Spark-pooler Azure Synapse representerar dessa värden som undefined .
  • SQL serverlösa pooler i Azure Synapse dessa värden som NULL .

• Förvänta dig olika beteende vad gäller explicita null värden:

  • Spark-pooler i Azure Synapse dessa värden som 0 (noll). Och den ändras till undefined så fort kolumnen har ett värde som inte är null.
  • SQL serverlösa pooler i Azure Synapse dessa värden som NULL .

• Förvänta dig olika beteende när det gäller saknade kolumner:

  • Spark-pooler Azure Synapse representerar dessa kolumner som undefined .
  • SQL serverlösa pooler i Azure Synapse dessa kolumner som NULL .

Fullständig återgivning av schema

Schemarepresentationen med 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 väldefinierade schemabegränsningar (det vill säga inga blandade datatypfält eller matriser med blandade datatyper) överträds.

Detta uppnås genom att översätta lövegenskaperna för driftdata till analysarkivet med distinkta kolumner baserat på datatypens värden i egenskapen . Lövegenskapsnamnen utökas med datatyper som suffix i analysarkivschemat så att de kan vara frågor utan tvetydighet.

I en fullständig återgivning av återgivningsschemat genererar varje datatyp för varje egenskap en kolumn för den datatypen. Var och en av dem räknas som en av de 1 000 högsta egenskaperna.

Vi kan till exempel ta följande exempeldokument i transaktionsarkivet:

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

streetNoLövegenskapen i det address kapslade objektet representeras i analysarkivschemat som en kolumn address.object.streetNo.int32 . Datatypen läggs till som ett suffix i kolumnen. På så sätt, om ett annat dokument läggs till i transaktionslagret där värdet för lövegenskapen är "123" (observera att det är en sträng), utvecklas schemat för analysarkivet automatiskt utan att ändra typen av en tidigare skriven streetNo kolumn. En ny kolumn läggs till i analysarkivet som address.object.streetNo.string där värdet "123" lagras.

Datatyp till suffixkarta

Här är en karta över alla egenskapsdatatyper och deras suffixrepresentationer i analysarkivet:

• Förvänta dig olika beteende vad gäller explicita null värden:

  • Spark-pooler i Azure Synapse dessa värden som 0 (noll).
  • SQL serverlösa pooler i Azure Synapse dessa värden som NULL .

• Förvänta dig olika beteende när det gäller saknade kolumner:

  • Spark-pooler Azure Synapse representerar dessa kolumner som undefined .
  • SQL serverlösa pooler i Azure Synapse dessa kolumner som NULL .

Kostnadseffektiv arkivering av historiska data

Datanivåindelning avser uppdelning av data mellan lagringsinfrastrukturer som är optimerade för olika scenarier. Därmed förbättras den övergripande prestandan och kostnadseffektiviteten för datastacken från slutet till slut. Med analysarkiv har Azure Cosmos DB nu stöd för automatisk nivåindelad data från transaktionslagret till analysarkiv med olika datalayouter. Med analysarkivet optimerat vad gäller lagringskostnader jämfört med transaktionslagret kan du behålla mycket längre horisonter för driftdata för historisk analys.

När analysarkivet har aktiverats kan du, baserat på datalagringsbehoven för transaktionsarbetsbelastningarna, konfigurera egenskapen "Transactional Store Time to Live (Transactional TTL)" så att poster tas bort automatiskt från transaktionslagret efter en viss tidsperiod. På samma sätt kan du med TTL-värdet (Time To Live för analysarkiv) hantera livscykeln för data som lagras i analysarkivet oberoende av transaktionslagret. Genom att aktivera analysarkiv och konfigurera TTL-egenskaper kan du sömlöst nivåindelad och definiera datalagringsperioden för de två arkiven.

Global distribution

Om du har ett globalt Azure Cosmos DB-konto kommer det efter att du aktiverar analysarkiv för en container att vara tillgängligt i alla regioner i det kontot. Ändringar i 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

Partitionering av analysarkiv är helt oberoende av partitionering i transaktionslagret. 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 anpassade partitioneringsartiklar.

Säkerhet

• Autentisering med analysarkivet är samma som transaktionslagret 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 i Spark-notebook-datorer. För Azure Synapse SQL serverlösa kan du använda SQL för att förhindra att Azure Cosmos DB klistras in i SQL notebook-fil. Åtkomsten till dessa länkade tjänster eller till dessa SQL är tillgänglig för alla som har åtkomst till arbetsytan.

• 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 butik i hanterade virtuella nätverk i Azure Synapse arbetsytor. Mer information finns i artikeln Konfigurera privata slutpunkter för analysarkiv.

• Datakryptering med kund hanterade nycklar – Du kan sömlöst kryptera data i transaktions- och analysarkiv med samma kund hanterade nycklar på ett automatiskt och transparent sätt. Azure Synapse Link stöder endast konfiguration av kund hanterade nycklar med Azure Cosmos DB-kontots hanterade identitet. Du måste konfigurera kontots hanterade identitet i din Azure Key Vault innan du aktiverar Azure Synapse Link på ditt konto. Mer information finns i artikeln Konfigurera kund hanterade nycklar med hjälp Azure Cosmos DB kontons hanterade identiteter.

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

Analysarkivet är optimerat för att ge skalbarhet, elasticitet och prestanda för analytiska arbetsbelastningar utan beroende av beräkningskörningstiderna. Lagringstekniken är själv hanterad för att optimera dina analysarbetsbelastningar utan manuella åtgärder.

Genom att frikoppla analyslagringssystemet från det analytiska berä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 Azure Synapse Analytics stöd Apache Spark serverlös SQL med Azure Cosmos DB analysarkiv.

Prissättning

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

• Storage: mängden data som lagras i analysarkivet varje månad, inklusive historiska data som definieras av TTL för analys.

• Analytiska skrivåtgärder: den fullständigt hanterade synkroniseringen av uppdateringar av driftdata till analysarkivet från transaktionslagret (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 och poolkörningstider.

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

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 Azure Synapse Analytics för fullständig information om prismodellen för att få åtkomst till data i analysarkivet.

För att få en kostnadsuppskattning på hög nivå för att möjliggöra analysarkiv på en Azure Cosmos DB-container kan du från analysarkivperspektivet använda kapacitetsplaneraren för Azure Cosmos DB och få en uppskattning av kostnaderna för analyslagring och skrivåtgärder. Kostnaderna för analysläsningsåtgärder beror på analysarbetsbelastningens egenskaper, men som en uppskattning på hög nivå resulterar genomsökning på 1 TB data i analysarkiv vanligtvis i 130 000 analytiska läsåtgärder och resulterar i en kostnad på 0,065 USD.

TTL (Time to Live) för analys

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

Om analysarkiv är aktiverat synkroniseras infogningar, uppdateringar och borttagningar av driftdata automatiskt från transaktionslager till analysarkiv, oavsett TTL-konfiguration för transaktioner. Kvarhållningen av dessa driftdata i analysarkivet kan styras av TTL-värdet för analys på containernivå, enligt beskrivningen nedan:

TTL-analys för en container anges med hjälp av AnalyticalStoreTimeToLiveInSeconds egenskapen :

• Om värdet är inställt på "0", saknas (eller anges till null): är analysarkivet inaktiverat och inga data replikeras från transaktionsarkivet till analysarkivet

• Om det finns och 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 obegränsad kvarhållning av dina driftdata

• Om det finns och värdet är inställt på något positivt tal "n": objekten upphör att gälla från analysarkivet "n" sekunder efter den senaste ändringstiden i transaktionslagret. 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 TTL-värde för analys kan det uppdateras till ett annat giltigt värde senare.
• Transaktions-TTL kan anges på container- eller objektnivå, men TTL för analys kan bara anges på containernivå för närvarande.
• Du kan uppnå längre kvarhållning av dina driftdata i analysarkivet genom att ange TTL-värdet >= transaktions-TTL på containernivå.
• Analysarkivet kan göras för att spegla transaktionslagret genom att ange TTL för analys = transaktions-TTL.

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

• Från Azure Portal anges TTL-alternativet för analys när det är aktiverat till standardvärdet -1. Du kan ändra det här värdet till "n" sekunder genom att gå till containerinställningarna under Datautforskaren.

• Från Azure Management SDK, Azure Cosmos DB SDK:er, PowerShell eller CLI kan du använda TTL-alternativet för analys genom att ange antingen -1 eller "n" sekunder.

Mer information finns i konfigurera TTL för analys på en container.

Nästa steg

Mer information finns i följande dokument:

• Azure Synapse Link för Azure Cosmos DB

• Läs learn-modulen om hur du utformar hybridtransaktions- och analysbearbetning med hjälp av Azure Synapse Analytics

• Kom igång med Azure Synapse Link för Azure Cosmos DB

• Vanliga frågor och svar om Synapse Link för Azure Cosmos DB

• Användningsfall för Azure Synapse Link för Azure Cosmos DB