Wat is de analytische opslag van Azure Cosmos DB?

VAN TOEPASSING OP: Nosql MongoDB Gremlin

De analytische opslag van Azure Cosmos DB is een volledig geïsoleerde kolomopslag voor het inschakelen van grootschalige analyses op basis van operationele gegevens in uw Azure Cosmos DB, zonder dat dit van invloed is op uw transactionele workloads.

Het transactionele archief van Azure Cosmos DB is schema-agnostisch en stelt u in staat om uw transactionele toepassingen te herhalen zonder dat u te maken hebt met schema- of indexbeheer. In tegenstelling tot dit wordt de analytische opslag van Azure Cosmos DB geschematiseerd om de prestaties van analytische query's te optimaliseren. In dit artikel wordt gedetailleerde informatie over analytische opslag beschreven.

Uitdagingen met grootschalige analyse van operationele gegevens

De operationele gegevens met meerdere modellen in een Azure Cosmos DB-container worden intern opgeslagen in een geïndexeerde, op rijen gebaseerde 'transactionele opslag'. De indeling rijopslag is ontworpen om snelle transactionele lees- en schrijfbewerkingen in de volgorde van milliseconden reactietijden en operationele query's mogelijk te maken. Als uw gegevensset groter wordt, kunnen complexe analytische query's duur zijn in termen van ingerichte doorvoer voor de gegevens die in deze indeling zijn opgeslagen. Een hoog verbruik van ingerichte doorvoer is op zijn beurt van invloed op de prestaties van transactionele workloads die worden gebruikt door uw realtime toepassingen en services.

Normaal gesproken worden operationele gegevens voor het analyseren van grote hoeveelheden gegevens geëxtraheerd uit de transactionele opslag van Azure Cosmos DB en opgeslagen in een afzonderlijke gegevenslaag. De gegevens worden bijvoorbeeld opgeslagen in een datawarehouse of data lake in een geschikte indeling. Deze gegevens worden later gebruikt voor grootschalige analyses en geanalyseerd met behulp van rekenengines zoals de Apache Spark-clusters. De scheiding van analytische en operationele gegevens leidt tot vertragingen voor analisten die de meest recente gegevens willen gebruiken.

De ETL-pijplijnen worden ook complex bij het verwerken van updates van de operationele gegevens in vergelijking met het verwerken van alleen nieuw opgenomen operationele gegevens.

Kolomgeoriënteerde analytische opslag

De analytische opslag van Azure Cosmos DB biedt een oplossing voor de complexiteit en latentie die zich voordoen bij de traditionele ETL-pijplijnen. Met de analytische opslag van Azure Cosmos DB kunt u uw operationele gegevens automatisch synchroniseren in een afzonderlijk kolomarchief. Kolomopslagindeling is geschikt voor grootschalige analytische query's die op een geoptimaliseerde manier moeten worden uitgevoerd, wat resulteert in een betere latentie van dergelijke query's.

Met Azure Synapse Link kunt u nu geen ETL HTAP-oplossingen bouwen door rechtstreeks vanuit Azure Synapse Analytics een koppeling te maken naar de analytische opslag van Azure Cosmos DB. Hiermee kunt u bijna in realtime grootschalige analyses uitvoeren op uw operationele gegevens.

Functies van analytische opslag

Wanneer u analytische opslag inschakelt voor een Azure Cosmos DB-container, wordt er intern een nieuwe kolomopslag gemaakt op basis van de operationele gegevens in uw container. Dit kolomarchief wordt afzonderlijk bewaard van de rijgeoriënteerde transactionele opslag voor die container, in een opslagaccount dat volledig wordt beheerd door Azure Cosmos DB, in een intern abonnement. Klanten hoeven geen tijd te besteden aan opslagbeheer. De invoegingen, updates en verwijderingen van uw operationele gegevens worden automatisch gesynchroniseerd met de analytische opslag. U hebt de wijzigingenfeed of ETL niet nodig om de gegevens te synchroniseren.

Kolomopslag voor analytische workloads op operationele gegevens

Analytische workloads omvatten doorgaans aggregaties en sequentiële scans van geselecteerde velden. Door de gegevens op te slaan in een kolom-primaire volgorde, kan de analytische opslag een groep waarden voor elk veld samen worden geserialiseerd. Deze indeling vermindert de IOPS die nodig zijn voor het scannen of berekenen van statistieken voor specifieke velden. Hiermee worden de reactietijden van query's voor scans voor grote gegevenssets aanzienlijk verbeterd.

Als uw operationele tabellen bijvoorbeeld de volgende indeling hebben:

Het rijarchief bewaart de bovenstaande gegevens in een geserialiseerde indeling, per rij, op de schijf. Deze indeling maakt snellere transactionele lees-, schrijf- en operationele query's mogelijk, zoals 'Retourinformatie over Product1'. Naarmate de gegevensset echter groter wordt en u complexe analytische query's op de gegevens wilt uitvoeren, kan dit duur zijn. Als u bijvoorbeeld 'de verkooptrends voor een product in de categorie Apparatuur' voor verschillende bedrijfseenheden en maanden wilt ophalen, moet u een complexe query uitvoeren. Grote scans op deze gegevensset kunnen duur worden in termen van ingerichte doorvoer en kunnen ook van invloed zijn op de prestaties van de transactionele workloads die uw realtime toepassingen en services mogelijk maken.

Analytische opslag, een kolomopslag, is beter geschikt voor dergelijke query's omdat het vergelijkbare velden met gegevens samen serialiseert en de IOPS van de schijf vermindert.

In de volgende afbeelding ziet u transactionele rijopslag versus analytische kolomopslag in Azure Cosmos DB:

Losgekoppelde prestaties voor analytische workloads

Er is geen invloed op de prestaties van uw transactionele workloads als gevolg van analytische query's, omdat de analytische opslag gescheiden is van de transactionele opslag. Analytische opslag heeft geen afzonderlijke aanvraageenheden (RU's) nodig om te worden toegewezen.

Automatisch synchroniseren

AutoSynchronisatie verwijst naar de volledig beheerde mogelijkheid van Azure Cosmos DB, waarbij de invoegingen, updates en verwijderingen naar operationele gegevens automatisch in bijna realtime worden gesynchroniseerd van de transactionele opslag naar de analytische opslag. De latentie van automatische synchronisatie is meestal binnen 2 minuten. In het geval van een gedeelde doorvoerdatabase met een groot aantal containers kan de latentie van automatische synchronisatie van afzonderlijke containers hoger zijn en tot 5 minuten duren.

Aan het einde van elke uitvoering van het automatische synchronisatieproces zijn uw transactionele gegevens onmiddellijk beschikbaar voor Azure Synapse Analytics-runtimes:

• Azure Synapse Analytics Spark-pools kunnen alle gegevens, inclusief de meest recente updates, lezen via Spark-tabellen, die automatisch worden bijgewerkt, of via de spark.read opdracht, die altijd de laatste status van de gegevens leest.

• Azure Synapse Analytics SQL serverloze pools kunnen alle gegevens lezen, inclusief de meest recente updates, via weergaven, die automatisch worden bijgewerkt, of via SELECT de OPENROWSET opdrachten, die altijd de meest recente status van de gegevens lezen.

Notitie

Uw transactionele gegevens worden gesynchroniseerd met analytische opslag, zelfs als uw transactionele time-to-live (TTL) kleiner is dan 2 minuten.

Notitie

Houd er rekening mee dat als u uw container verwijdert, ook analytische opslag wordt verwijderd.

Elasticiteit van schaalbaarheid &

Met behulp van horizontale partitionering kan azure Cosmos DB transactioneel archief de opslag en doorvoer elastisch schalen zonder downtime. Horizontale partitionering in de transactionele opslag biedt schaalbaarheidselasticiteit & bij automatische synchronisatie om ervoor te zorgen dat gegevens bijna in realtime worden gesynchroniseerd met de analytische opslag. De gegevenssynchronisatie vindt plaats ongeacht de doorvoer van transactioneel verkeer, of het nu 1000 bewerkingen per seconde of 1 miljoen bewerkingen per seconde is, en heeft geen invloed op de ingerichte doorvoer in de transactionele opslag.

Schema-updates automatisch verwerken

Het transactionele archief van Azure Cosmos DB is schema-agnostisch en stelt u in staat om uw transactionele toepassingen te herhalen zonder dat u te maken hebt met schema- of indexbeheer. In tegenstelling tot dit wordt de analytische opslag van Azure Cosmos DB geschematiseerd om de prestaties van analytische query's te optimaliseren. Met de mogelijkheid voor automatische synchronisatie beheert Azure Cosmos DB de schemadeductie via de meest recente updates uit de transactionele opslag. Het beheert ook de schemaweergave in de analytische opslag out-of-the-box, waaronder het verwerken van geneste gegevenstypen.

Naarmate uw schema zich ontwikkelt en er in de loop van de tijd nieuwe eigenschappen worden toegevoegd, presenteert de analytische opslag automatisch een samengevoegd schema voor alle historische schema's in de transactionele opslag.

Notitie

In de context van analytische opslag beschouwen we de volgende structuren als eigenschap:

• JSON -elementen' of 'tekenreeks-waardeparen gescheiden door een : '.
• JSON-objecten, gescheiden door { en }.
• JSON-matrices, gescheiden door [ en ].

Schemabeperkingen

De volgende beperkingen zijn van toepassing op de operationele gegevens in Azure Cosmos DB wanneer u de analytische opslag inschakelt om het schema automatisch af te stellen en correct weer te geven:

• U kunt maximaal 1000 eigenschappen hebben voor alle geneste niveaus in het documentschema en een maximale nestdiepte van 127.

  • Alleen de eerste 1000 eigenschappen worden weergegeven in de analytische opslag.
  • Alleen de eerste 127 geneste niveaus worden weergegeven in de analytische opslag.
  • Het eerste niveau van een JSON-document is het / hoofdniveau.
  • Eigenschappen op het eerste niveau van het document worden weergegeven als kolommen.

• Voorbeeldscenario's:

  • Als het eerste niveau van uw document 2000 eigenschappen heeft, vertegenwoordigt het synchronisatieproces de eerste 1000.
  • Als uw documenten vijf niveaus hebben met elk 200 eigenschappen, vertegenwoordigt het synchronisatieproces alle eigenschappen.
  • Als uw documenten 10 niveaus met 400 eigenschappen hebben, vertegenwoordigt het synchronisatieproces volledig de twee eerste niveaus en slechts de helft van het derde niveau.

• Het onderstaande hypothetische document bevat vier eigenschappen en drie niveaus.

  • De niveaus zijn root, myArrayen de geneste structuur binnen de myArray.
  • De eigenschappen zijn id, myArray, myArray.nested1en myArray.nested2.
  • De weergave van de analytische opslag heeft twee kolommen, iden myArray. U kunt spark- of T-SQL-functies gebruiken om de geneste structuren ook beschikbaar te maken als kolommen.

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

• Hoewel JSON-documenten (en Azure Cosmos DB-verzamelingen/-containers) hoofdlettergevoelig zijn vanuit het perspectief van uniekheid, is analytische opslag dat niet.

  • In hetzelfde document: Eigenschappennamen op hetzelfde niveau moeten uniek zijn wanneer ze niet hoofdlettergevoelig worden vergeleken. Het volgende JSON-document heeft bijvoorbeeld 'Naam' en 'naam' op hetzelfde niveau. Hoewel het een geldig JSON-document is, voldoet het niet aan de beperking voor uniekheid en wordt het daarom niet volledig weergegeven in de analytische opslag. In dit voorbeeld zijn 'Naam' en 'naam' hetzelfde wanneer ze worden vergeleken op een niet-hoofdlettergevoelige manier. Alleen "Name": "fred" wordt weergegeven in de analytische opslag, omdat dit het eerste exemplaar is. En "name": "john" zal helemaal niet vertegenwoordigd worden.

  {"id": 1, "Name": "fred", "name": "john"}
  

  • In verschillende documenten: Eigenschappen op hetzelfde niveau en met dezelfde naam, maar in verschillende gevallen, worden weergegeven in dezelfde kolom, met behulp van de naamindeling van het eerste exemplaar. De volgende JSON-documenten hebben "Name" bijvoorbeeld en "name" op hetzelfde niveau. Aangezien de eerste documentindeling is "Name", wordt dit gebruikt om de naam van de eigenschap in de analytische opslag weer te geven. Met andere woorden, de kolomnaam in de analytische opslag is "Name". Zowel als "fred""john" worden weergegeven in de "Name" kolom.

  {"id": 1, "Name": "fred"}
  {"id": 2, "name": "john"}
  

• Het eerste document van de verzameling definieert het initiële schema voor analytische opslag.

  • Documenten met meer eigenschappen dan het oorspronkelijke schema genereren nieuwe kolommen in de analytische opslag.
  • Kolommen kunnen niet worden verwijderd.
  • Als u alle documenten in een verzameling verwijdert, wordt het schema van de analytische opslag niet opnieuw ingesteld.
  • Er is geen schemaversiebeheer. De laatste versie die is afgeleid van de transactionele opslag, is wat u ziet in de analytische opslag.

• Op dit moment kunnen Azure Synapse Spark geen eigenschappen lezen die bepaalde speciale tekens in hun namen bevatten, zoals hieronder vermeld. Azure Synapse SQL serverloos wordt niet beïnvloed.

  • :
  • `
  • ,
  • ;
  • {}
  • ()
  • \n
  • \T
  • =
  • "

Notitie

Witruimten worden ook vermeld in het Spark-foutbericht dat wordt geretourneerd wanneer u deze beperking bereikt. Maar we hebben een speciale behandeling toegevoegd voor witruimtes, bekijk meer details in de onderstaande items.

• Als u eigenschappennamen hebt met behulp van de bovenstaande tekens, zijn de alternatieven:
  • Wijzig uw gegevensmodel van tevoren om deze tekens te voorkomen.
  • Omdat we momenteel geen ondersteuning bieden voor het opnieuw instellen van schema's, kunt u uw toepassing wijzigen om een redundante eigenschap met een vergelijkbare naam toe te voegen, waardoor deze tekens worden vermeden.
  • Gebruik wijzigingenfeed om een gerealiseerde weergave van uw container te maken zonder deze tekens in eigenschappennamen.
  • Gebruik de dropColumn optie Spark om de betrokken kolommen te negeren en alle andere kolommen in een DataFrame te laden. De syntaxis is:

# 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 ondersteunt nu eigenschappen met spaties in hun naam. Hiervoor moet u de allowWhiteSpaceInFieldNames optie Spark gebruiken om de betrokken kolommen in een DataFrame te laden, waarbij de oorspronkelijke naam behouden blijft. De syntaxis is:

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

• De volgende BSON-gegevenstypen worden niet ondersteund en worden niet weergegeven in de analytische opslag:

  • Decimal128
  • Reguliere expressie
  • DB-aanwijzer
  • JavaScript
  • Symbool
  • MinKey/MaxKey

• Wanneer u Datum/tijd-tekenreeksen gebruikt die voldoen aan de ISO 8601 UTC-standaard, verwacht u het volgende gedrag:

  • Spark-pools in Azure Synapse deze kolommen weergeven als string.
  • Serverloze SQL-pools in Azure Synapse deze kolommen vertegenwoordigen als varchar(8000).

• Eigenschappen met UNIQUEIDENTIFIER (guid) typen worden weergegeven als string in de analytische opslag en moeten worden geconverteerd naar VARCHAR in SQL of naar string in Spark voor de juiste visualisatie.

• SERVERloze SQL-pools in Azure Synapse resultatensets ondersteunen met maximaal 1000 kolommen en het weergeven van geneste kolommen telt ook mee voor die limiet. Het is een goede gewoonte om deze informatie te overwegen in uw transactionele gegevensarchitectuur en modellering.

• Als u de naam van een eigenschap wijzigt in een of meer documenten, wordt deze beschouwd als een nieuwe kolom. Als u dezelfde naam wijzigt in alle documenten in de verzameling, worden alle gegevens gemigreerd naar de nieuwe kolom en wordt de oude kolom weergegeven met NULL waarden.

Schemarepresentatie

Er zijn twee methoden voor schemaweergave in de analytische opslag, die geldig zijn voor alle containers in het databaseaccount. Ze hebben een compromis tussen de eenvoud van de query-ervaring en het gemak van een meer inclusieve kolomweergave voor polymorfe schema's.

• Goed gedefinieerde schemaweergave, standaardoptie voor API voor NoSQL- en Gremlin-accounts.
• Schemaweergave met volledige betrouwbaarheid, standaardoptie voor API voor MongoDB-accounts.

Goed gedefinieerde schemaweergave

De goed gedefinieerde schemaweergave maakt een eenvoudige tabellaire weergave van de schema-agnostische gegevens in het transactionele archief. De goed gedefinieerde schemaweergave heeft de volgende overwegingen:

• Het eerste document definieert het basisschema en eigenschappen moeten altijd hetzelfde type hebben voor alle documenten. De enige uitzonderingen zijn:
  • Van NULL naar een ander gegevenstype. De eerste niet-null-instantie definieert het gegevenstype van de kolom. Een document dat niet het eerste niet-null-gegevenstype volgt, wordt niet weergegeven in de analytische opslag.
  • Van float tot integer. Alle documenten worden weergegeven in de analytische opslag.
  • Van integer tot float. Alle documenten worden weergegeven in de analytische opslag. Als u deze gegevens echter wilt lezen met Azure Synapse serverloze SQL-pools, moet u een WITH-component gebruiken om de kolom te converteren naar varchar. En na deze eerste conversie is het mogelijk om deze opnieuw te converteren naar een getal. Bekijk het onderstaande voorbeeld, waarbij de beginwaarde van het getal een geheel getal was en de tweede een float.

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]

• Eigenschappen die niet het gegevenstype van het basisschema volgen, worden niet weergegeven in de analytische opslag. Bekijk bijvoorbeeld de onderstaande documenten: de eerste definieerde het basisschema van de analytische opslag. Het tweede document, waarbij id"2"is , heeft geen goed gedefinieerd schema omdat de eigenschap "code" een tekenreeks is en het eerste document een getal heeft "code" . In dit geval registreert de analytische opslag het gegevenstype van "code" voor integer de levensduur van de container. Het tweede document wordt nog steeds opgenomen in de analytische opslag, maar "code" de eigenschap niet.

  • {"id": "1", "code":123}
  • {"id": "2", "code": "123"}

Notitie

De bovenstaande voorwaarde is niet van toepassing op NULL eigenschappen. Is bijvoorbeeld {"a":123} and {"a":NULL} nog steeds goed gedefinieerd.

Notitie

De bovenstaande voorwaarde verandert niet als u een document "1" bijwerkt "code" naar een tekenreeks in uw transactionele opslag. In de analytische opslag "code" worden bewaard, omdat integer we momenteel geen ondersteuning bieden voor schemaherstel.

• Matrixtypen moeten één herhaald type bevatten. Is bijvoorbeeld {"a": ["str",12]} geen goed gedefinieerd schema omdat de matrix een combinatie van gehele getallen en tekenreekstypen bevat.

Notitie

Als de analytische opslag van Azure Cosmos DB de goed gedefinieerde schemaweergave volgt en de bovenstaande specificatie wordt geschonden door bepaalde items, worden deze items niet opgenomen in de analytische opslag.

• Verwacht ander gedrag met betrekking tot verschillende typen in een goed gedefinieerd schema:

  • Spark-pools in Azure Synapse vertegenwoordigen deze waarden als undefined.
  • Serverloze SQL-pools in Azure Synapse vertegenwoordigen deze waarden als NULL.

• Verwacht ander gedrag met betrekking tot expliciete NULL waarden:

  • Spark-pools in Azure Synapse deze waarden lezen als 0 (nul) en zodra undefined de kolom een niet-null-waarde heeft.
  • SERVERloze SQL-pools in Azure Synapse deze waarden lezen als NULL.

• Verwacht ander gedrag met betrekking tot ontbrekende kolommen:

  • Spark-pools in Azure Synapse deze kolommen weergeven als undefined.
  • Serverloze SQL-pools in Azure Synapse deze kolommen vertegenwoordigen als NULL.

Tijdelijke oplossingen voor representatieproblemen

Het is mogelijk dat een oud document met een onjuist schema is gebruikt om het basisschema voor analytische opslag van uw container te maken. Op basis van alle bovenstaande regels ontvangt NULL u mogelijk voor bepaalde eigenschappen wanneer u een query uitvoert op uw analytische opslag met behulp van Azure Synapse Link. Het verwijderen of bijwerken van de problematische documenten helpt niet omdat het opnieuw instellen van het basisschema momenteel niet wordt ondersteund. De mogelijke oplossingen zijn:

• Als u de gegevens wilt migreren naar een nieuwe container, moet u ervoor zorgen dat alle documenten het juiste schema hebben.
• Als u de eigenschap met het verkeerde schema wilt verlaten en een nieuwe wilt toevoegen met een andere naam met het juiste schema in alle documenten. Voorbeeld: u hebt miljarden documenten in de container Orders waarvan de eigenschap status een tekenreeks is. Maar voor het eerste document in die container is de status gedefinieerd met een geheel getal. Het ene document heeft dus de juiste status en alle andere documenten hebben NULL. U kunt de eigenschap status2 toevoegen aan alle documenten en deze gaan gebruiken in plaats van de oorspronkelijke eigenschap.

Schemaweergave met volledige betrouwbaarheid

De schemaweergave met volledige betrouwbaarheid is ontworpen om de volledige breedte van polymorfe schema's in de schema-agnostische operationele gegevens te verwerken. In deze schemaweergave worden er geen items verwijderd uit de analytische opslag, zelfs niet als de goed gedefinieerde schemabeperkingen (dat wil niet bestaan uit velden voor gemengde gegevenstypen of matrices van gemengde gegevenstypen) worden geschonden.

Dit wordt bereikt door de leaf-eigenschappen van de operationele gegevens als JSON-paren key-value te vertalen naar de analytische opslag, waarbij het gegevenstype de key is en de eigenschapsinhoud de value. Met deze JSON-objectweergave kunnen query's zonder dubbelzinnigheid worden uitgevoerd en kunt u elk gegevenstype afzonderlijk analyseren.

Met andere woorden, in de weergave van het full fidelity-schema genereert elk gegevenstype van elke eigenschap van elk document een key-valuepaar in een JSON-object voor die eigenschap. Elk van hen tellen als een van de limiet van 1000 maximale eigenschappen.

Laten we bijvoorbeeld het volgende voorbeelddocument nemen in het transactionele archief:

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

Het geneste object address is een eigenschap op het hoofdniveau van het document en wordt weergegeven als een kolom. Elke leaf-eigenschap in het address object wordt weergegeven als een JSON-object: {"object":{"streetNo":{"int32":15850},"streetName":{"string":"NE 40th St."},"zip":{"int32":98052}}}.

In tegenstelling tot de goed gedefinieerde schemaweergave, maakt de methode full fidelity variatie in gegevenstypen mogelijk. Als het volgende document in deze verzameling van het bovenstaande voorbeeld een tekenreeks heeft streetNo , wordt het in de analytische opslag weergegeven als "streetNo":{"string":15850}. In een goed gedefinieerde schemamethode zou deze niet worden weergegeven.

Toewijzing van gegevenstypen voor schema met volledige betrouwbaarheid

Hier volgt een overzicht van MongoDB-gegevenstypen en hun weergaven in de analytische opslag in schemaweergave met volledige betrouwbaarheid. De onderstaande kaart is niet geldig voor NoSQL API-accounts.

Oorspronkelijk gegevenstype	Achtervoegsel	Voorbeeld
Dubbel	".float64"	24.99
Matrix	".array"	["a", "b"]
Binair	".binary"	0
Booleaans	".bool"	Waar
Int32	".int32"	123
Int64	".int64"	255486129307
NULL	". NULL"	NULL
Tekenreeks	".string"	"ABC"
Tijdstempel	".timestamp"	Timestamp(0, 0)
ObjectId	".objectId"	ObjectId("5f3f7b59330ec25c132623a2")
Document	".object"	{"a": "a"}

• Verwacht ander gedrag met betrekking tot expliciete NULL waarden:

  • Spark-pools in Azure Synapse lezen deze waarden als 0 (nul).
  • Serverloze SQL-pools in Azure Synapse lezen deze waarden als NULL.

• Verwacht ander gedrag met betrekking tot ontbrekende kolommen:

  • Spark-pools in Azure Synapse vertegenwoordigen deze kolommen als undefined.
  • Serverloze SQL-pools in Azure Synapse vertegenwoordigen deze kolommen als NULL.

• Verwacht ander gedrag met betrekking tot timestamp waarden:

  • Spark-pools in Azure Synapse lezen deze waarden als TimestampType, DateTypeof Float. Dit is afhankelijk van het bereik en hoe de tijdstempel is gegenereerd.
  • Serverloze SQL-pools in Azure Synapse leest deze waarden als DATETIME2, variërend van 0001-01-019999-12-31. Waarden buiten dit bereik worden niet ondersteund en veroorzaken een uitvoeringsfout voor uw query's. Als dit het geval is, kunt u het volgende doen:
    • Verwijder de kolom uit de query. Als u de weergave wilt behouden, kunt u een nieuwe eigenschap maken die die kolom spiegelt, maar binnen het ondersteunde bereik. En gebruik het in uw query's.
    • Gebruik Change Data Capture uit analytische opslag, zonder kosten voor RU's, om de gegevens te transformeren en te laden in een nieuwe indeling, binnen een van de ondersteunde sinks.

Het volledige betrouwbaarheidsschema gebruiken met Spark

Spark beheert elk gegevenstype als een kolom bij het laden in een DataFrame. Laten we uitgaan van een verzameling met de onderstaande documenten.

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

Hoewel het eerste document een getal en utc-indeling heeftrating, heeft rating het tweede document en timestamp als tekenreeksen.timestamp Ervan uitgaande dat deze verzameling is geladen zonder DataFrame gegevenstransformatie, is de uitvoer van de 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)

In een goed gedefinieerde schemaweergave zouden zowel als ratingtimestamp van het tweede document niet worden weergegeven. In het full fidelity-schema kunt u de volgende voorbeelden gebruiken om afzonderlijke toegang te krijgen tot elke waarde van elk gegevenstype.

In het onderstaande voorbeeld kunnen we gebruiken PySpark om een aggregatie uit te voeren:

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

In het onderstaande voorbeeld kunnen we gebruiken PySQL om een andere aggregatie uit te voeren:

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

Volledig betrouwbaarheidsschema gebruiken met SQL

Rekening houdend met dezelfde documenten uit het bovenstaande Spark-voorbeeld, kunnen klanten het volgende syntaxisvoorbeeld gebruiken:

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

Vanaf de bovenstaande query kunnen klanten transformaties implementeren met behulp van cast, convert of een andere T-SQL-functie om uw gegevens te bewerken. Klanten kunnen ook complexe gegevenstypestructuren verbergen met behulp van weergaven.

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

Werken met het MongoDB-veld _id

het MongoDB-veld _id is fundamenteel voor elke verzameling in MongoDB en heeft oorspronkelijk een hexadecimale weergave. Zoals u in de bovenstaande tabel kunt zien, blijven de kenmerken van het schema behouden, wat een uitdaging voor de visualisatie in Azure Synapse Analytics creëert. Voor de juiste visualisatie moet u het _id gegevenstype converteren zoals hieronder:

Werken met het MongoDB-veld _id in Spark

Het onderstaande voorbeeld werkt op spark 2.x- en 3.x-versies:

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)

Werken met het MongoDB-veld _id in 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

Schema voor volledige betrouwbaarheid voor API voor NoSQL- of Gremlin-accounts

Het is mogelijk om een Volledig betrouwbaarheidsschema voor API voor NoSQL-accounts te gebruiken in plaats van de standaardoptie door het schematype in te stellen wanneer Synapse Link voor het eerst wordt ingeschakeld voor een Azure Cosmos DB-account. Dit zijn de overwegingen bij het wijzigen van het standaardschemaweergavetype:

• Als u momenteel Synapse Link inschakelt in uw NoSQL-API-account met behulp van de Azure Portal, wordt dit ingeschakeld als een goed gedefinieerd schema.
• Als u momenteel een volledig betrouwbaarheidsschema wilt gebruiken met NoSQL- of Gremlin-API-accounts, moet u dit op accountniveau instellen in dezelfde CLI- of PowerShell-opdracht waarmee Synapse Link op accountniveau wordt ingeschakeld.
• Momenteel is Azure Cosmos DB voor MongoDB niet compatibel met deze mogelijkheid om de schemaweergave te wijzigen. Alle MongoDB-accounts hebben het schematype Full Fidelity.
• De hierboven genoemde toewijzing van gegevenstypen van het Full Fidelity-schema is niet geldig voor NoSQL API-accounts die gebruikmaken van JSON-gegevenstypen. Als voorbeeld, float en integer waarden worden weergegeven als num in de analytische opslag.
• Het is niet mogelijk om het schemaweergavetype opnieuw in te stellen, van goed gedefinieerd naar volledige betrouwbaarheid of omgekeerd.
• Op dit moment worden containerschema's in analytische opslag gedefinieerd wanneer de container wordt gemaakt, zelfs als Synapse Link niet is ingeschakeld in het databaseaccount.
  • Containers of grafieken die zijn gemaakt voordat Synapse Link werd ingeschakeld met een volledig betrouwbaarheidsschema op accountniveau, hebben een goed gedefinieerd schema.
  • Containers of grafieken die zijn gemaakt nadat Synapse Link is ingeschakeld met een volledig betrouwbaarheidsschema op accountniveau, hebben een schema voor volledige betrouwbaarheid.

De beslissing over het type schemaweergave moet worden genomen op hetzelfde moment dat Synapse Link is ingeschakeld voor het account, met behulp van Azure CLI of PowerShell.

Met de Azure CLI:

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

Notitie

Vervang in de bovenstaande opdracht door createupdate voor bestaande accounts.

Met PowerShell:

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

Notitie

Vervang in de bovenstaande opdracht door New-AzCosmosDBAccountUpdate-AzCosmosDBAccount voor bestaande accounts.

Analytische time-to-live (TTL)

Analytische TTL (ATTL) geeft aan hoe lang gegevens moeten worden bewaard in uw analytische opslag, voor een container.

Analytische opslag is ingeschakeld wanneer ATTL is ingesteld met een andere waarde dan NULL en 0. Wanneer dit is ingeschakeld, worden invoegen, bijwerken en verwijderen naar operationele gegevens automatisch gesynchroniseerd van transactionele opslag naar analytische opslag, ongeacht de transactionele TTL-configuratie (TTTL). De retentie van deze transactionele gegevens in de analytische opslag kan op containerniveau worden beheerd door de AnalyticalStoreTimeToLiveInSeconds eigenschap .

De mogelijke ATTL-configuraties zijn:

• Als de waarde is ingesteld op 0 of ingesteld op NULL: de analytische opslag is uitgeschakeld en er worden geen gegevens gerepliceerd van transactionele opslag naar analytische opslag

• Als de waarde is ingesteld op -1: de analytische opslag behoudt alle historische gegevens, ongeacht de retentie van de gegevens in de transactionele opslag. Deze instelling geeft aan dat de analytische opslag oneindige retentie van uw operationele gegevens heeft

• Als de waarde is ingesteld op een positief geheel getal n : items verlopen uit de analytische opslag n seconden na de laatste wijzigingstijd in de transactionele opslag. Deze instelling kan worden gebruikt als u uw operationele gegevens gedurende een beperkte periode in de analytische opslag wilt bewaren, ongeacht de retentie van de gegevens in de transactionele opslag

Enkele punten om in overweging te nemen:

• Nadat de analytische opslag is ingeschakeld met een ATTL-waarde, kan deze later worden bijgewerkt naar een andere geldige waarde.
• Hoewel TTTL kan worden ingesteld op container- of itemniveau, kan ATTL momenteel alleen worden ingesteld op containerniveau.
• U kunt een langere retentie van uw operationele gegevens in de analytische opslag bereiken door ATTL >= TTTL in te stellen op containerniveau.
• De analytische opslag kan worden gemaakt om de transactionele opslag te spiegelen door ATTL = TTTL in te stellen.
• Als u ATTL groter hebt dan TTTL, hebt u op een bepaald moment gegevens die alleen in de analytische opslag aanwezig zijn. Deze gegevens zijn alleen-lezen.
• Momenteel verwijderen we geen gegevens uit de analytische opslag. Als u uw ATTL instelt op een positief geheel getal, worden de gegevens niet opgenomen in uw query's en worden er geen kosten in rekening gebracht. Maar als u ATTL weer wijzigt in -1, worden alle gegevens weer weergegeven. U wordt gefactureerd voor het hele gegevensvolume.

Analytische opslag inschakelen voor een container:

• In de Azure Portal wordt de optie ATTL, indien ingeschakeld, ingesteld op de standaardwaarde -1. U kunt deze waarde wijzigen in 'n' seconden door te navigeren naar containerinstellingen onder Data Explorer.

• Vanuit de Azure Management SDK, Azure Cosmos DB SDK's, PowerShell of Azure CLI kan de ATTL-optie worden ingeschakeld door deze in te stellen op -1 of 'n' seconden.

Zie Analytische TTL configureren voor een container voor meer informatie.

Kostenefficiënte analyse van historische gegevens

Gegevenslaag verwijst naar de scheiding van gegevens tussen opslaginfrastructuren die zijn geoptimaliseerd voor verschillende scenario's. Hierdoor worden de algehele prestaties en de kosteneffectiviteit van de end-to-end-gegevensstack verbeterd. Met analytische opslag biedt Azure Cosmos DB nu ondersteuning voor automatische opslaglagen van gegevens uit de transactionele opslag naar de analytische opslag met verschillende gegevensindelingen. Met de analytische opslag die is geoptimaliseerd in termen van opslagkosten in vergelijking met de transactionele opslag, kunt u veel langere horizonten met operationele gegevens behouden voor historische analyse.

Nadat de analytische opslag is ingeschakeld, kunt u, op basis van de gegevensretentiebehoeften van de transactionele workloads, de eigenschap zodanig configureren transactional TTL dat records na een bepaalde periode automatisch worden verwijderd uit de transactionele opslag. Op dezelfde manier kunt u met de analytical TTL de levenscyclus beheren van gegevens die worden bewaard in de analytische opslag, onafhankelijk van de transactionele opslag. Door analytische opslag in te schakelen en transactionele en analytische TTL eigenschappen te configureren, kunt u de gegevensretentieperiode voor de twee archieven naadloos tieren en definiëren.

Notitie

Wanneer analytical TTL groter is dan transactional TTL, bevat uw container gegevens die alleen aanwezig zijn in de analytische opslag. Deze gegevens zijn alleen-lezen en momenteel bieden we geen ondersteuning voor documentniveau TTL in analytische opslag. Als uw containergegevens mogelijk op een bepaald moment in de toekomst moeten worden bijgewerkt of verwijderd, moet u niet groter dan transactional TTLgebruikenanalytical TTL. Deze mogelijkheid wordt aanbevolen voor gegevens die in de toekomst geen updates of verwijderingen meer nodig hebben.

Notitie

Als voor uw scenario geen fysieke verwijderingen nodig zijn, kunt u een logische methode voor verwijderen/bijwerken gebruiken. Voeg in de transactionele opslag een andere versie van hetzelfde document in die alleen bestaat in de analytische opslag, maar waarvoor een logische verwijdering/update nodig is. Misschien met een vlag die aangeeft dat het een verwijdering of een update van een verlopen document is. Beide versies van hetzelfde document bestaan naast elkaar in de analytische opslag en uw toepassing moet alleen rekening houden met de laatste versie.

Veerkracht

Analytische opslag is afhankelijk van Azure Storage en biedt de volgende bescherming tegen fysieke storingen:

• Azure Cosmos DB-databaseaccounts wijzen standaard analytische opslag toe in LRS-accounts (Lokaal redundante opslag). LRS biedt ten minste 99,99999999999% (11 negens) duurzaamheid van objecten gedurende een bepaald jaar.
• Als een geografische regio van het databaseaccount is geconfigureerd voor zoneredundantie, wordt deze toegewezen in ZRS-accounts (Zone-redundant storage). Klanten moeten Beschikbaarheidszones inschakelen voor een regio van hun Azure Cosmos DB-databaseaccount om analytische gegevens van die regio op te slaan in zone-redundante opslag. ZRS biedt duurzaamheid voor opslagresources van ten minste 99,99999999999% (12 9's) gedurende een bepaald jaar.

Klik hier voor meer informatie over de duurzaamheid van Azure Storage.

Backup

Hoewel analytische opslag ingebouwde beveiliging tegen fysieke fouten heeft, kan back-up nodig zijn voor onbedoelde verwijderingen of updates in transactionele opslag. In dergelijke gevallen kunt u een container herstellen en de herstelde container gebruiken om de gegevens in de oorspronkelijke container te vullen of indien nodig de analytische opslag volledig te herbouwen.

Notitie

Momenteel is er geen back-up gemaakt van de analytische opslag en kan deze daarom niet worden hersteld. Uw back-upbeleid kan niet worden gepland op basis van dat beleid.

Synapse Link en analytische opslag hebben als gevolg hiervan verschillende compatibiliteitsniveaus met back-upmodi van Azure Cosmos DB:

• Periodieke back-upmodus is volledig compatibel met Synapse Link en deze 2 functies kunnen worden gebruikt in hetzelfde databaseaccount.
• Momenteel worden continue back-upmodus en Synapse Link niet ondersteund in hetzelfde databaseaccount. Klanten moeten een van deze twee functies kiezen en deze beslissing kan niet worden gewijzigd.

Back-upbeleid

Er zijn twee mogelijke back-upbeleidsregels en om te begrijpen hoe u deze kunt gebruiken, zijn de volgende details over Azure Cosmos DB-back-ups erg belangrijk:

• De oorspronkelijke container wordt hersteld zonder analytische opslag in beide back-upmodi.
• Azure Cosmos DB biedt geen ondersteuning voor het overschrijven van containers vanaf een herstelbewerking.

Laten we nu eens kijken hoe u back-ups en herstelbewerkingen kunt gebruiken vanuit het perspectief van de analytische opslag.

Een container herstellen met TTTL >= ATTL

Wanneer transactional TTL gelijk is aan of groter is dan analytical TTL, bevinden alle gegevens in de analytische opslag zich nog steeds in de transactionele opslag. In het geval van een herstelbewerking hebt u twee mogelijke situaties:

• Als u de herstelde container wilt gebruiken als vervanging voor de oorspronkelijke container. Als u de analytische opslag wilt herbouwen, schakelt u Synapse Link in op account- en containerniveau.
• Als u de herstelde container wilt gebruiken als gegevensbron om de gegevens in de oorspronkelijke container te backfillen of bij te werken. In dit geval weerspiegelt de analytische opslag automatisch de gegevensbewerkingen.

Een container herstellen met TTTL < ATTL

Wanneer transactional TTL kleiner is dan analytical TTL, bevinden sommige gegevens zich alleen in de analytische opslag en bevinden ze zich niet in de herstelde container. Nogmaals, u hebt twee mogelijke situaties:

• Als u de herstelde container wilt gebruiken als vervanging voor de oorspronkelijke container. Wanneer u in dit geval Synapse Link op containerniveau inschakelt, worden alleen de gegevens in de transactionele opslag opgenomen in de nieuwe analytische opslag. Houd er echter rekening mee dat de analytische opslag van de oorspronkelijke container beschikbaar blijft voor query's zolang de oorspronkelijke container bestaat. U kunt uw toepassing wijzigen om een query uit te voeren op beide.
• De herstelde container gebruiken als gegevensbron om de gegevens in de oorspronkelijke container te backfillen of bij te werken:
• Analytische opslag weerspiegelt automatisch de gegevensbewerkingen voor de gegevens die zich in de transactionele opslag bevinden.
• Als u gegevens die eerder uit de transactionele opslag zijn verwijderd, opnieuw invoegt vanwege transactional TTL, worden deze gegevens gedupliceerd in de analytische opslag.

Voorbeeld:

• Voor container OnlineOrders is TTTL ingesteld op één maand en ATTL ingesteld op één jaar.
• Wanneer u deze herstelt naar OnlineOrdersNew en analytische opslag inschakelt om deze opnieuw te bouwen, is er slechts één maand aan gegevens in zowel transactionele als analytische opslag.
• De oorspronkelijke container OnlineOrders wordt niet verwijderd en de analytische opslag is nog steeds beschikbaar.
• Nieuwe gegevens worden alleen opgenomen in OnlineOrdersNew.
• Met analytische query's wordt een UNION ALL uitgevoerd vanuit analytische opslag, terwijl de oorspronkelijke gegevens nog steeds relevant zijn.

Als u de oorspronkelijke container wilt verwijderen, maar de analytische opslaggegevens niet wilt verliezen, kunt u de analytische opslag van de oorspronkelijke container in een andere Azure-gegevensservice behouden. Synapse Analytics biedt de mogelijkheid om joins uit te voeren tussen gegevens die zijn opgeslagen op verschillende locaties. Een voorbeeld: Een Synapse Analytics-query koppelt analytische opslaggegevens aan externe tabellen in Azure Blob Storage, Azure Data Lake Store, enzovoort.

Het is belangrijk te weten dat de gegevens in de analytische opslag een ander schema hebben dan de gegevens in de transactionele opslag. Hoewel u momentopnamen van uw analytische opslaggegevens kunt genereren en deze kunt exporteren naar elke Azure Data-service, zonder ru's, kunnen we niet garanderen dat deze momentopname wordt gebruikt om de transactionele opslag terug te sturen. Dit proces wordt niet ondersteund.

Wereldwijde distributie

Als u een wereldwijd gedistribueerd Azure Cosmos DB-account hebt en u analytische opslag voor een container hebt ingeschakeld, is dit beschikbaar in alle regio's van dat account. Wijzigingen in operationele gegevens worden globaal gerepliceerd in alle regio's. U kunt analytische query's effectief uitvoeren op de dichtstbijzijnde regionale kopie van uw gegevens in Azure Cosmos DB.

Partitionering

Partitionering van analytische opslag is volledig onafhankelijk van partitionering in de transactionele opslag. Standaard worden gegevens in de analytische opslag niet gepartitioneerd. Als uw analytische query's vaak gebruikte filters bevatten, hebt u de mogelijkheid om te partitioneren op basis van deze velden voor betere queryprestaties. Zie inleiding tot aangepaste partitionering en aangepaste partitionering configureren voor meer informatie.

Beveiliging

• Verificatie met de analytische opslag is hetzelfde als de transactionele opslag voor een bepaalde database. U kunt primaire, secundaire of alleen-lezensleutels gebruiken voor verificatie. U kunt gebruikmaken van de gekoppelde service in Synapse Studio om te voorkomen dat de Azure Cosmos DB-sleutels in de Spark-notebooks worden geplakt. Voor Azure Synapse SERVERloze SQL kunt u SQL-referenties gebruiken om te voorkomen dat de Azure Cosmos DB-sleutels in de SQL-notebooks worden geplakt. De toegang tot deze gekoppelde services of deze SQL-referenties is beschikbaar voor iedereen die toegang heeft tot de werkruimte. Houd er rekening mee dat de alleen-lezensleutel van Azure Cosmos DB ook kan worden gebruikt.

• Netwerkisolatie met behulp van privé-eindpunten : u kunt de netwerktoegang tot de gegevens in de transactionele en analytische opslag onafhankelijk beheren. Netwerkisolatie wordt uitgevoerd met behulp van afzonderlijke beheerde privé-eindpunten voor elk archief, binnen beheerde virtuele netwerken in Azure Synapse werkruimten. Zie het artikel Privé-eindpunten configureren voor analytische opslag voor meer informatie.

• Gegevensversleuteling-at-rest : de versleuteling van uw analytische opslag is standaard ingeschakeld.

• Gegevensversleuteling met door de klant beheerde sleutels : u kunt de gegevens in transactionele en analytische archieven naadloos versleutelen met behulp van dezelfde door de klant beheerde sleutels op een automatische en transparante manier. Azure Synapse Link biedt alleen ondersteuning voor het configureren van door de klant beheerde sleutels met behulp van de beheerde identiteit van uw Azure Cosmos DB-account. U moet de beheerde identiteit van uw account configureren in uw Azure Key Vault-toegangsbeleid voordat u Azure Synapse Link inschakelt voor uw account. Zie het artikel Door de klant beheerde sleutels configureren met behulp van beheerde identiteiten van Azure Cosmos DB-accounts voor meer informatie.

Notitie

Als u uw databaseaccount wijzigt van First Party in System of User Assigned Identy en Azure Synapse Link inschakelt in uw databaseaccount, kunt u niet terugkeren naar de identiteit van de eerste partij omdat u Synapse Link niet kunt uitschakelen vanuit uw databaseaccount.

Ondersteuning voor meerdere Azure Synapse Analytics-runtimes

De analytische opslag is geoptimaliseerd om schaalbaarheid, elasticiteit en prestaties te bieden voor analytische workloads zonder afhankelijk te zijn van de rekenruntimes. De opslagtechnologie wordt zelf beheerd om uw analyseworkloads te optimaliseren zonder handmatige inspanningen.

Door het analytische opslagsysteem los te koppelen van het analytische rekensysteem, kunnen gegevens in de analytische opslag van Azure Cosmos DB tegelijkertijd worden opgevraagd vanuit de verschillende analyseruntimes die worden ondersteund door Azure Synapse Analytics. Vanaf vandaag ondersteunt Azure Synapse Analytics Apache Spark en een serverloze SQL-pool met de analytische opslag van Azure Cosmos DB.

Notitie

U kunt alleen lezen uit analytische opslag met behulp van Azure Synapse Analytics-runtimes. En het tegenovergestelde is ook waar, Azure Synapse Analytics-runtimes alleen kunnen lezen uit de analytische opslag. Alleen het proces voor automatische synchronisatie kan gegevens in de analytische opslag wijzigen. U kunt gegevens terugschrijven naar de transactionele opslag van Azure Cosmos DB met behulp van Azure Synapse Analytics Spark-pool, met behulp van de ingebouwde Azure Cosmos DB OLTP SDK.

Prijzen

Analytische opslag volgt een prijsmodel op basis van verbruik, waarbij kosten in rekening worden gebracht voor:

• Opslag: het volume van de gegevens die elke maand in de analytische opslag worden bewaard, inclusief historische gegevens zoals gedefinieerd door analytische TTL.

• Analytische schrijfbewerkingen: de volledig beheerde synchronisatie van updates van operationele gegevens naar de analytische opslag vanuit de transactionele opslag (automatische synchronisatie)

• Analytische leesbewerkingen: de leesbewerkingen die worden uitgevoerd op de analytische opslag van Azure Synapse Analytics Spark-pool en uitvoeringstijden van serverloze SQL-pools.

De prijzen van analytische winkels zijn gescheiden van het prijsmodel van het transactiearchief. Er is geen concept van ingerichte RU's in de analytische opslag. Zie de pagina met prijzen van Azure Cosmos DB voor meer informatie over het prijsmodel voor analytische opslag.

Gegevens in het analysearchief zijn alleen toegankelijk via Azure Synapse Link. Dit gebeurt in de Azure Synapse Analytics-runtimes: apache Spark-pools en Azure Synapse serverloze SQL-pools Azure Synapse. Zie de pagina met prijzen van Azure Synapse Analytics voor volledige informatie over het prijsmodel voor toegang tot gegevens in de analytische opslag.

Als u een schatting van de kosten op hoog niveau wilt maken om analytische opslag in een Azure Cosmos DB-container mogelijk te maken, kunt u vanuit het perspectief van de analytische opslag de Azure Cosmos DB-capaciteitsplanner gebruiken en een schatting maken van de kosten van uw analytische opslag en schrijfbewerkingen.

Schattingen van leesbewerkingen voor analytische opslag zijn niet opgenomen in de kostencalculator van Azure Cosmos DB, omdat ze een functie zijn van uw analytische workload. Maar zoals een schatting op hoog niveau resulteert een scan van 1 TB aan gegevens in analytische opslag meestal in 130.000 analytische leesbewerkingen en resulteert dit in een kosten van $ 0,065. Als u bijvoorbeeld Azure Synapse serverloze SQL-pools gebruikt om deze scan van 1 TB uit te voeren, kost dit $ 5,00 volgens Azure Synapse Analytics-prijspagina. De uiteindelijke totale kosten voor deze scan van 1 TB zijn $ 5,065.

Hoewel de bovenstaande schatting betrekking heeft op het scannen van 1 TB aan gegevens in analytische opslag, vermindert het toepassen van filters het aantal gescande gegevens en bepaalt dit het exacte aantal analytische leesbewerkingen op basis van het prijsmodel voor verbruik. Een proof-of-concept rond de analytische workload biedt een nauwkeurigere schatting van analytische leesbewerkingen. Deze schatting omvat niet de kosten van Azure Synapse Analytics.

Volgende stappen

Zie de volgende documenten voor meer informatie:

• Azure Synapse Link voor Azure Cosmos DB

• Bekijk de trainingsmodule over het ontwerpen van hybride transactionele en analytische verwerking met behulp van Azure Synapse Analytics

• Aan de slag met Azure Synapse Link voor Azure Cosmos DB

• Veelgestelde vragen over Synapse Link voor Azure Cosmos DB

• Use cases voor Azure Synapse Link voor Azure Cosmos DB