Wat is Azure Cosmos DB analytische opslag?

VAN toepassing op: SQL api Azure Cosmos DB API voor MongoDb

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

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

Uitdagingen met grootschalige analyses van operationele gegevens

De operationele gegevens met meerdere modellen in Azure Cosmos DB container worden intern opgeslagen in een geïndexeerd, op rij gebaseerd 'transactioneel opslag'. De rijopslagindeling is ontworpen om snelle transactionele lees- en schrijf schrijftijden in de reactietijden van milliseconden en operationele query's toe te staan. Als uw gegevensset groter wordt, kunnen complexe analytische query's kostbaar zijn wat betreft inrichten van doorvoer op de gegevens die in deze indeling zijn opgeslagen. Een hoog verbruik van inrichtende doorvoer heeft op zijn beurt invloed op de prestaties van transactionele workloads die worden gebruikt door uw realtime toepassingen en services.

Normaal gezien worden voor het analyseren van grote hoeveelheden gegevens operationele gegevens geëxtraheerd uit Azure Cosmos DB transactionele opslag 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 een berekeningsen engine zoals de Apache Spark clusters. Deze scheiding van analytische opslag- en rekenlagen van operationele gegevens resulteert in extra latentie, omdat de ETL-pijplijnen (Extraheren, Transformeren, Laden) minder vaak worden uitgevoerd om de mogelijke impact op uw transactionele workloads te minimaliseren.

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

Kolomgeoriënteerde analytische opslag

Azure Cosmos DB analytische opslag is een oplossing voor de complexiteit en latentie-uitdagingen die zich voordoen bij de traditionele ETL-pijplijnen. Azure Cosmos DB analytische opslag kunt u uw operationele gegevens automatisch synchroniseren naar een afzonderlijke kolomopslag. Kolomopslagindeling is geschikt voor grootschalige analytische query's die op een geoptimaliseerde manier kunnen worden uitgevoerd, waardoor de latentie van dergelijke query's wordt verbeterd.

Met Azure Synapse Link kunt u nu no-ETL HTAP-oplossingen bouwen door rechtstreeks te koppelen aan Azure Cosmos DB analytische opslag vanuit Azure Synapse Analytics. Hiermee kunt u bijna realtime grootschalige analyses uitvoeren op uw operationele gegevens.

Functies van analytische opslag

Wanneer u analytische opslag in een Azure Cosmos DB inschakelen, wordt intern een nieuwe kolomopslag gemaakt op basis van de operationele gegevens in uw container. Deze kolomopslag wordt afzonderlijk van het rijgeoriënteerde transactionele opslag voor die container bewaard. De invoegingen, updates en verwijderen van uw operationele gegevens worden automatisch gesynchroniseerd met de analytische opslag. U hebt de wijzigingsfeed 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-grote volgorde, kan de analytische opslag een groep waarden voor elk veld samen serialiseren. Deze indeling vermindert de IOPS die nodig is om statistieken te scannen of te berekenen 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:

De bovenstaande gegevens worden in de rijopslag opgeslagen in een geseraliseerde indeling, per rij, op de schijf. Deze indeling maakt snellere transactionele lees-, schrijf- en operationele query's mogelijk, zoals 'Retourinformatie over Product1'. Als de gegevensset echter groter wordt en u complexe analytische query's op de gegevens wilt uitvoeren, kan dit kostbaar zijn. Als u bijvoorbeeld 'de verkooptrends voor een product onder de categorie Apparatuur' in verschillende bedrijfseenheden en maanden wilt zien, moet u een complexe query uitvoeren. Grote scans op deze gegevensset kunnen kostbaar worden in termen van inrichtende doorvoer en kunnen ook van invloed zijn op de prestaties van de transactionele workloads die uw realtime toepassingen en services aanstijven.

Analytische opslag, een kolomopslag, is beter geschikt voor dergelijke query's omdat deze vergelijkbare gegevensvelden samen serialiseert en de schijf-IOPS vermindert.

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

Losgekoppelde prestaties voor analytische workloads

Analytische query's hebben geen invloed op de prestaties van uw transactionele workloads, omdat de analytische opslag gescheiden is van de transactionele opslag. Voor analytische opslag hoeven geen afzonderlijke aanvraageenheden (AANVRAAGeenheden) te worden toegewezen.

Automatisch synchroniseren

Automatische synchronisatie verwijst naar de volledig beheerde mogelijkheid van Azure Cosmos DB waar de invoegingen, updates en verwijderen van operationele gegevens automatisch in bijna realtime vanuit een transactionele opslag worden gesynchroniseerd naar analytische opslag. Latentie voor automatische synchronisatie is doorgaans binnen twee minuten. In het geval van een gedeelde doorvoerdatabase met een groot aantal containers kan de latentie voor automatische synchronisatie van afzonderlijke containers hoger zijn en kan dit tot vijf minuten duren. We willen graag meer weten over hoe deze latentie in uw scenario's past. Neem dan contact op met het Azure Cosmos DB team.

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 lezen, met inbegrip van de meest recente updates, via Spark-tabellen die automatisch worden bijgewerkt of via de opdracht waarmee altijd de laatste status van de gegevens wordt spark.read gelezen.

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

Schaalbaarheid & elasticiteit

Door horizontale partitionering te gebruiken, Azure Cosmos DB transactionele opslag de opslag en doorvoer elastisch schalen zonder uitvaltijd. Horizontale partitionering in de transactionele opslag biedt schaalbaarheid & elasticiteit 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, ongeacht of het 1000 bewerkingen per seconde of 1 miljoen bewerkingen per seconde is, en heeft geen invloed op de inrichtende doorvoer in de transactionele opslag.

Automatisch schema-updates verwerken

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

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

Schemabeperkingen

De volgende beperkingen zijn van toepassing op de operationele gegevens in Azure Cosmos DB als u analytische opslag in staat stelt om automatisch het schema af te afleiden en weer te geven:

• U kunt maximaal 1000 eigenschappen hebben op elk nestniveau in het schema 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, worden alleen de eerste 1000 weergegeven.
  • Als uw documenten 5 niveaus hebben met 200 eigenschappen in elk van deze niveaus, worden alle eigenschappen weergegeven.
  • Als uw documenten 10 niveaus met elk 400 eigenschappen hebben, worden alleen de 2 eerste niveaus volledig weergegeven in de analytische opslag. De helft van het derde niveau wordt ook weergegeven.

• Het onderstaande hypothetische document bevat 4 eigenschappen en 3 niveaus.

  • De niveaus zijn root myArray , en de geneste structuur binnen de myArray .
  • De eigenschappen id zijn , en myArray myArray.nested1 myArray.nested2 .
  • De analytische opslagweergave heeft 2 kolommen, id en myArray . U kunt Spark- of T-SQL gebruiken om de geneste structuren ook als kolommen weer te geven.

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

• Hoewel JSON-documenten (en Cosmos DB verzamelingen/containers) hoofd- en hoofd- en uniek zijn, is analytische opslag dat niet.

  • In hetzelfde document: Eigenschappennamen op hetzelfde niveau moeten uniek zijn wanneer ze niet-case-ongevoelig zijn 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 uniekheidsbeperking 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-casegevoelige manier. Alleen "Name": "fred" worden weergegeven in de analytische opslag, omdat dit de eerste keer is. En "name": "john" worden helemaal niet weergegeven.

  {"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 de eerste instantie. De volgende JSON-documenten hebben "Name" bijvoorbeeld en op hetzelfde "name" niveau. Aangezien de eerste documentindeling is, wordt dit gebruikt om de eigenschapsnaam "Name" in de analytische opslag weer te geven. Met andere woorden, de kolomnaam in de analytische opslag is "Name" . Zowel "fred" als worden weergegeven in de kolom "john" "Name" .

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

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

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

• Momenteel Azure Synapse Spark geen eigenschappen lezen die een aantal speciale tekens in hun naam bevatten. Deze worden hieronder vermeld. Azure Synapse SQL serverloos wordt niet beïnvloed.

  • : (dubbele punt)
  • ' (grafaccent)
  • , (komma)
  • ; (Puntkomma's)
  • {}
  • ()
  • \n
  • \t
  • = (gelijkteken)
  • " (aanhalingsteken)

• Als u eigenschappennamen hebt met behulp van de bovenstaande tekens, zijn de alternatieven:

  • Wijzig uw gegevensmodel van tevoren om deze tekens te voorkomen.
  • Omdat schema opnieuw instellen momenteel niet wordt ondersteund, kunt u uw toepassing wijzigen om een redundante eigenschap met een vergelijkbare naam toe te voegen, zodat deze tekens worden vermeden.
  • Gebruik De feed Wijzigen om een ge materialiseerde weergave van uw container te maken zonder deze tekens in eigenschappennamen.
  • Gebruik de dropColumn spark-optie om de betrokken kolommen te negeren en alle andere kolommen in een DataFrame te laden. 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.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 ondersteunt nu eigenschappen met witruimten in hun naam. Daarom moet u de spark-optie gebruiken om de betrokken kolommen in een DataFrame te allowWhiteSpaceInFieldNames 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 DateTime-tekenreeksen gebruikt die voldoen aan de ISO 8601 UTC-standaard, moet u het volgende gedrag verwachten:

  • Spark-pools in Azure Synapse worden deze kolommen weergegeven als string .
  • SQL serverloze pools in Azure Synapse worden deze kolommen weergegeven als varchar(8000) .

• SQL groepen in Azure Synapse ondersteuningsresultaatsets met maximaal 1000 kolommen, en het blootstellen van geneste kolommen telt ook mee voor die limiet. Houd rekening met deze informatie bij het ontwerpen van uw gegevensarchitectuur en het modelleren van uw transactionele gegevens.

Schemaweergave

Er zijn twee typen schemaweergaven in de analytische opslag. Deze typen definiëren de schemaweergavemethode voor alle containers in het databaseaccount en hebben een afweging tussen de eenvoud van query-ervaring en het gemak van een meer inclusieve kolomweergave voor polymorfe schema's.

• Goed gedefinieerde schemaweergave, standaardoptie voor SQL API-accounts (CORE).
• Schemaweergave van volledige betrouwbaarheid, standaardoptie voor Azure Cosmos DB API voor MongoDB-accounts.

Volledig betrouwbaarheidsschema voor SQL API-accounts

Het is mogelijk om full fidelity Schema te gebruiken voor SQL (Core) API-accounts, in plaats van de standaardoptie, door het schematype in te stellen wanneer Synapse Link voor de eerste keer wordt ingeschakeld voor een Cosmos DB-account. Hier zijn de overwegingen voor het wijzigen van het standaardtype voor schemaweergave:

• Deze optie is alleen geldig voor accounts die nog geen Synapse Link ingeschakeld.
• Het is niet mogelijk om het type schemaweergave opnieuw in te stellen, van goed gedefinieerd naar volledige betrouwbaarheid of vice versa.
• Momenteel Azure Cosmos DB API voor MongoDB-accounts niet compatibel met deze mogelijkheid om de schemaweergave te wijzigen. Alle MongoDB-accounts hebben altijd het type schemaweergave van volledige betrouwbaarheid.
• Deze wijziging kan momenteel niet worden aangebracht via de Azure Portal. Alle databaseaccounts waarin Synapse LinK is ingeschakeld door de Azure Portal hebben het standaardtype voor schemaweergave, duidelijk gedefinieerd schema.

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

Met de PowerShell:

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

Goed gedefinieerde schemaweergave

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

• Het eerste document definieert het basisschema en de eigenschap moet altijd hetzelfde type hebben voor alle documenten. De enige uitzonderingen zijn:
  • Van null naar een ander gegevenstype. De eerste niet-null-instantie definieert het kolomgegevenstype. Elk document dat niet het eerste niet-null-gegevenstype volgt, wordt niet weergegeven in de analytische opslag.
  • Van float naar integer . Alle documenten worden weergegeven in de analytische opslag.
  • Van integer naar float . Alle documenten worden weergegeven in de analytische opslag. Als u deze gegevens echter wilt lezen Azure Synapse SQL serverloze pools, moet u een WITH-component gebruiken om de kolom te converteren naar varchar . En na deze initiële conversie is het mogelijk om deze opnieuw te converteren naar een getal. Bekijk het onderstaande voorbeeld, waarbij de initiële waarde van num een geheel getal is 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 twee onderstaande documenten en dat de eerste het basisschema van de analytische opslag heeft gedefinieerd. Het tweede document, waarbij is, heeft geen goed gedefinieerd schema, omdat de eigenschap een tekenreeks is en het eerste id document als een getal 2 "a" "a" heeft. In dit geval registreert de analytische opslag het gegevenstype "a" van als voor de levensduur van de integer container. Het tweede document wordt nog steeds opgenomen in de analytische opslag, maar de "a" eigenschap ervan niet.

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

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

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

  • Spark-pools in Azure Synapse vertegenwoordigen deze waarden als undefined .
  • SQL serverloze pools in Azure Synapse worden deze waarden weergegeven als NULL .

• Verwacht ander gedrag met betrekking tot expliciete null waarden:

  • Spark-pools in Azure Synapse lezen deze waarden als 0 (nul). En deze wordt gewijzigd undefined in zodra de kolom een niet-null-waarde heeft.
  • SQL serverloze pools in Azure Synapse worden deze waarden gelezen als NULL .

• Verwacht ander gedrag met betrekking tot ontbrekende kolommen:

  • Spark-pools in Azure Synapse worden deze kolommen weergegeven als undefined .
  • SQL serverloze pools in Azure Synapse worden deze kolommen weergegeven als NULL .

Schemaweergave van volledige betrouwbaarheid

De schemaweergave van volledige betrouwbaarheid is ontworpen voor het afhandelen van de volledige breedte van polymorfe schema's in de schema-agnostische operationele gegevens. In deze schemaweergave worden geen items uit de analytische opslag weggeslagen, zelfs niet als de goed gedefinieerde schemabeperkingen (dat wil zeggen geen velden van het gegevenstype gemengd of matrices van het gegevenstype) worden geschonden.

Dit wordt bereikt door de leaf-eigenschappen van de operationele gegevens om te zetten in de analytische opslag met afzonderlijke kolommen op basis van het gegevenstype van waarden in de eigenschap . De leaf-eigenschapsnamen worden uitgebreid met gegevenstypen als achtervoegsel in het schema van de analytische opslag, zodat ze zonder dubbelzinnigheid query's kunnen zijn.

In de schemaweergave voor volledige betrouwbaarheid genereert elk gegevenstype van elke eigenschap een kolom voor dat gegevenstype. Elk van deze eigenschappen telt als een van de maximaal 1000 eigenschappen.

Laten we bijvoorbeeld het volgende voorbeelddocument in de transactionele opslag nemen:

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

De leaf-eigenschap binnen het geneste object wordt in het schema van de analytische opslag weergegeven streetNo address als een kolom address.object.streetNo.int32 . Het gegevenstype wordt toegevoegd als achtervoegsel aan de kolom. Op deze manier, als er een ander document wordt toegevoegd aan het transactionele opslag, waarbij de waarde van de leaf-eigenschap '123' is (let op dat het een tekenreeks is), verandert het schema van de analytische opslag automatisch zonder het type van een eerder geschreven kolom te streetNo wijzigen. Er wordt een nieuwe kolom toegevoegd aan de analytische opslag, waarbij deze waarde address.object.streetNo.string '123' wordt opgeslagen.

Gegevenstype naar achtervoegselkaart

Hier ziet u een overzicht van alle eigenschapsgegevenstypen en de weergaven van het achtervoegsel in de analytische opslag:

• Verwacht ander gedrag met betrekking tot expliciete null waarden:

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

• Verwacht ander gedrag met betrekking tot ontbrekende kolommen:

  • Spark-pools in Azure Synapse worden deze kolommen weergegeven als undefined .
  • SQL serverloze pools in Azure Synapse worden deze kolommen weergegeven als NULL .

Rendabele archivering van historische gegevens

Gegevenslagen verwijst naar de scheiding van gegevens tussen opslaginfrastructuren die zijn geoptimaliseerd voor verschillende scenario's. Hierdoor worden de algehele prestaties en kosteneffectiviteit van de end-to-end gegevensstack verbeterd. Met analytische opslag biedt Azure Cosmos DB nu ondersteuning voor het automatisch in lagen opslaan van gegevens van de transactionele opslag naar analytische opslag met verschillende gegevensindelingen. Met analytische opslag geoptimaliseerd in termen van opslagkosten in vergelijking met de transactionele opslag, kunt u veel langere horizonken van operationele gegevens bewaren voor historische analyse.

Nadat de analytische opslag is ingeschakeld, kunt u op basis van de gegevensretentiebehoeften van de transactionele workloads de eigenschap Transactional Store Time to Live (Transactional TTL) configureren om records na een bepaalde periode automatisch te laten verwijderen uit het transactionele archief. Op dezelfde manier kunt u met 'Analytical Store Time To Live (Analytical TTL)' de levenscyclus beheren van gegevens die in de analytische opslag worden bewaard, onafhankelijk van de transactionele opslag. Door analytische opslag in te stellen en TTL-eigenschappen te configureren, kunt u de gegevensretentieperiode voor de twee winkels naadloos in lagen opslaan en definiëren.

Wereldwijde distributie

Als u een wereldwijd gedistribueerd Azure Cosmos DB account hebt en u analytische opslag voor een container hebt ingeschakeld, is deze 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 analytische opslag niet gepartitief. Als uw analytische query's veelgebruikte filters hebben, hebt u de mogelijkheid om te partitioneren op basis van deze velden voor betere queryprestaties. Zie de inleiding tot aangepaste partitionering en artikelen over het configureren van aangepaste partitionering 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-lezen sleutels gebruiken voor verificatie. U kunt gebruikmaken van gekoppelde service in Synapse Studio te voorkomen dat de sleutels Azure Cosmos DB in de Spark-notebooks. Voor Azure Synapse SQL serverloos kunt u de referenties SQL gebruiken om te voorkomen dat de Azure Cosmos DB sleutels in de SQL notebooks. Toegang tot deze gekoppelde services of deze SQL zijn beschikbaar voor iedereen die toegang heeft tot de werkruimte.

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

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

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 rekenrun times. 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 Azure Cosmos DB Analytical Store tegelijkertijd worden opgevraagd uit de verschillende analyseruntimes die door Azure Synapse Analytics. Vanaf nu biedt Azure Synapse Analytics ondersteuning Apache Spark serverloze SQL met Azure Cosmos DB analytische opslag.

Prijzen

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

• Storage: het volume van de gegevens dat elke maand in de analytische opslag wordt 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 serverloze SQL van de pool.

Prijzen voor analytische opslag staan los van het prijsmodel voor een transactieopslag. Er is geen concept van inrichtende RUs in de analytische opslag. Zie Azure Cosmos DB pagina met prijzen voor meer informatie over het prijsmodel voor analytische opslag.

Gegevens in de analyseopslag zijn alleen toegankelijk via Azure Synapse Link, dat wordt uitgevoerd in de Azure Synapse Analytics-runtimes: Azure Synapse Apache Spark pools en Azure Synapse serverloze SQL pools. Zie Azure Synapse Analytics pagina met prijzen voor meer informatie over het prijsmodel voor toegang tot gegevens in de analytische opslag.

Als u een kostenraming op hoog niveau wilt maken om analytische opslag op een Azure Cosmos DB-container mogelijk te maken, kunt u vanuit het perspectief van de analytische opslag de Azure Cosmos DB Capacity Planner gebruiken en een schatting krijgen van de kosten voor analytische opslag en schrijfbewerkingen. De kosten voor analytische leesbewerkingen zijn afhankelijk van de kenmerken van de analyseworkload, maar als een schatting op hoog niveau resulteert het scannen van 1 TB aan gegevens in de analytische opslag meestal in 130.000 analytische leesbewerkingen en resulteert dit in een kosten van $ 0,065.

Analytische time-to-live (TTL)

Analytical TTL geeft aan hoe lang gegevens voor een container moeten worden bewaard in uw analytische opslag.

Als analytische opslag is ingeschakeld, worden invoegen, updates en verwijderen van operationele gegevens automatisch gesynchroniseerd van transactionele opslag naar analytische opslag, ongeacht de transactionele TTL-configuratie. De retentie van deze operationele gegevens in de analytische opslag kan worden beheerd door de analytische TTL-waarde op containerniveau, zoals hieronder wordt aangegeven:

Analytische TTL voor een container wordt ingesteld met behulp van de AnalyticalStoreTimeToLiveInSeconds eigenschap :

• Als de waarde is ingesteld op '0', ontbreekt (of is ingesteld op null): de analytische opslag is uitgeschakeld en er worden geen gegevens gerepliceerd van transactionele opslag naar analytische opslag

• Indien aanwezig en de waarde is ingesteld op '-1': de analytische opslag bewaart alle historische gegevens, ongeacht de bewaarperiode van de gegevens in de transactionele opslag. Deze instelling geeft aan dat de analytische opslag een oneindige retentie van uw operationele gegevens heeft

• Als aanwezig is en de waarde is ingesteld op een positief getal 'n': items verlopen uit de analytische opslag 'n' seconden na de laatste wijziging in de transactionele opslag. Deze instelling kan worden gebruikt als u uw operationele gegevens voor 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 analytische TTL-waarde, kan deze later worden bijgewerkt naar een andere geldige waarde.
• Hoewel transactionele TTL kan worden ingesteld op container- of itemniveau, kan de analytische TTL momenteel alleen worden ingesteld op containerniveau.
• U kunt uw operationele gegevens langer bewaren in de analytische opslag door analytische TTL->= transactionele TTL op containerniveau in te stellen.
• De analytische opslag kan worden gemaakt om de transactionele opslag te spiegelen door analytische TTL = transactionele TTL in te stellen.

Analytische opslag inschakelen voor een container:

• Vanaf het Azure Portal is de optie analytische TTL, 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 CLI kan de analytische TTL-optie worden ingeschakeld door deze in te stellen op -1 of 'n' seconden.

Zie Analytische TTL configureren op een container voor meer informatie.

Volgende stappen

Zie de volgende documenten voor meer informatie:

• Azure Synapse Link voor Azure Cosmos DB

• Bekijk de learn-module 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