Gegevensopname wijzigen in analytische opslag van Azure Cosmos DB
VAN TOEPASSING OP: 
Nosql MongoDB
Als u gegevensopname (CDC) wijzigt in de analytische opslag van Azure Cosmos DB, kunt u efficiënt een continue en incrementele feed gebruiken van gewijzigde (ingevoegde, bijgewerkte en verwijderde) gegevens uit de analytische opslag. Naadloos geïntegreerd met Azure Synapse en Azure Data Factory biedt het u een schaalbare ervaring zonder code voor een hoog gegevensvolume. Omdat de functie voor het vastleggen van wijzigingengegevens is gebaseerd op analytische opslag, verbruikt deze geen ingerichte RU's, heeft dit geen invloed op uw transactionele workloads, biedt een lagere latentie en heeft een lagere TCO.
De functie voor het vastleggen van wijzigingsgegevens in de analytische opslag van Azure Cosmos DB kan schrijven naar verschillende sinks met behulp van een Azure Synapse- of Azure Data Factory-gegevensstroom.
Zie ondersteunde sinktypen voor gegevensstromen voor meer informatie over ondersteunde sinktypen in een toewijzingsgegevensstroom.
Naast het bieden van incrementele gegevensfeed van analytische opslag tot diverse doelen, biedt wijzigingsgegevens vastleggen de volgende mogelijkheden:
- Ondersteunt het vastleggen van verwijderingen en tussenliggende updates
- Mogelijkheid om de wijzigingenfeed te filteren op een specifiek type bewerking (TTL bijwerken | verwijderen | invoegen) |
- Ondersteunt het toepassen van filters, projecties en transformaties op de wijzigingenfeed via de bronquery
- Meerdere wijzigingenfeeds op dezelfde container kunnen tegelijkertijd worden gebruikt
- Elke wijziging in de container wordt precies eenmaal weergegeven in de feed voor het vastleggen van wijzigingengegevens en de controlepunten worden intern voor u beheerd
- Wijzigingen kunnen worden gesynchroniseerd 'vanaf het begin' of 'vanaf een bepaalde tijdstempel' of 'vanaf nu'
- Er is geen beperking rond de vaste bewaarperiode voor gegevens waarvoor wijzigingen beschikbaar zijn
Efficiënte incrementele gegevensopname met intern beheerde controlepunten
Elke wijziging in de Cosmos DB-container wordt precies één keer weergegeven in de CDC-feed en de controlepunten worden intern voor u beheerd. Dit helpt bij het oplossen van de onderstaande nadelen van het algemene patroon van het gebruik van aangepaste controlepunten op basis van de waarde '_ts':
Het filter '_ts' wordt toegepast op de gegevensbestanden die niet altijd minimale gegevensscan garanderen. De intern beheerde controlepunten op basis van GLSN in de nieuwe CDC-functie zorgen ervoor dat de incrementele gegevensidentificatie wordt uitgevoerd, alleen op basis van de metagegevens en garandeert zo minimale scan van gegevens in elke stream.
Het synchronisatieproces voor analytische opslag garandeert geen '_ts' op basis van volgorde, wat betekent dat er gevallen kunnen zijn waarin de '_ts' van een incrementele record kleiner is dan het laatste controlepunt '_ts' en kan worden gemist in de incrementele stroom. De nieuwe CDC beschouwt geen '_ts' om de incrementele records te identificeren en garandeert dus dat geen van de incrementele records wordt gemist.
Functies
Het vastleggen van gegevens wijzigen in de analytische opslag van Azure Cosmos DB ondersteunt de volgende belangrijke functies.
Wijzigingen vanaf het begin vastleggen
Wanneer de optie is geselecteerd, bevat de Start from beginning eerste belasting een volledige momentopname van containergegevens in de eerste uitvoering en worden gewijzigde of incrementele gegevens vastgelegd in volgende uitvoeringen. Dit wordt beperkt door de analytical TTL eigenschap en documenten die door TTL zijn verwijderd uit de analytische opslag, worden niet opgenomen in de wijzigingenfeed. Voorbeeld: Stel dat een container is analytical TTL ingesteld op 31536000 seconden, wat gelijk is aan 1 jaar. Als u een CDC-proces voor deze container maakt, worden alleen documenten die hoger zijn dan 1 jaar opgenomen in de eerste belasting.
Wijzigingen van een bepaalde tijdstempel vastleggen
Wanneer de Start from timestamp optie is geselecteerd, verwerkt de eerste belasting de gegevens uit de opgegeven tijdstempel en worden incrementele of gewijzigde gegevens vastgelegd in volgende uitvoeringen. Dit proces wordt ook beperkt door de analytical TTL eigenschap.
Vanaf nu wijzigingen vastleggen
Wanneer de Start from timestamp optie is geselecteerd, worden alle eerdere bewerkingen van de container niet vastgelegd.
Verwijderingen, tussenliggende updates en TTU's vastleggen
Met de functie voor het vastleggen van wijzigingen voor de analytische opslag worden verwijderingen, tussenliggende updates en TTL-bewerkingen verwijderd. De vastgelegde verwijderingen en updates kunnen worden toegepast op Sinks die ondersteuning bieden voor verwijderings- en updatebewerkingen. De waarde {_rid} identificeert de records op unieke wijze, dus door {_rid} op te geven als sleutelkolom aan de sinkzijde, worden de update- en verwijderbewerkingen weergegeven in de Sink.
Houd er rekening mee dat TTL-bewerkingen worden beschouwd als verwijderingen. Controleer de sectie met broninstellingen om de modusdetails en de ondersteuning voor tussenliggende updates en verwijderingen in sinks te controleren.
De wijzigingenfeed filteren voor een specifiek type bewerking
U kunt de gegevensopnamefeed voor wijzigingen filteren voor een specifiek type bewerking. U kunt bijvoorbeeld selectief de invoeg- en updatebewerkingen vastleggen, waardoor de bewerkingen voor het verwijderen van gebruikers en TTL-delete worden genegeerd.
Filters, projecties en transformaties toepassen op de wijzigingenfeed via de bronquery
U kunt eventueel een bronquery gebruiken om filters, projectie(en) en transformaties op te geven, die allemaal naar de analytische opslag in de kolom worden gepusht. Hier volgt een voorbeeld van een bronquery die alleen incrementele records met het filter Category = 'Urban'zou vastleggen. Deze voorbeeldquery projecteert slechts vijf velden en past een eenvoudige transformatie toe:
SELECT ProductId, Product, Segment, concat(Manufacturer, '-', Category) as ManufacturerCategory
FROM c
WHERE Category = 'Urban'
Meerdere CDC-processen
U kunt meerdere processen maken om CDC te gebruiken in analytische opslag. Deze aanpak biedt flexibiliteit om verschillende scenario's en vereisten te ondersteunen. Hoewel één proces mogelijk geen gegevenstransformaties en meerdere sinks heeft, kan een andere proces gegevens platmaken en één sink. En ze kunnen parallel worden uitgevoerd.
Isolatie van doorvoer, lagere latentie en lagere TCO
Bewerkingen in de analytische opslag van Cosmos DB verbruiken de ingerichte RU's niet en hebben dus geen invloed op uw transactionele workloads. Wijzigingsgegevens vastleggen met analytische opslag heeft ook een lagere latentie en lagere TCO. De lagere latentie wordt toegeschreven aan analytische opslag, waardoor een betere parallelle uitvoering voor gegevensverwerking mogelijk is en de totale TCO wordt verminderd, zodat u kostenefficiënties kunt stimuleren in deze snel veranderende economische omstandigheden.
Scenario's
Hier volgen veelvoorkomende scenario's waarin u het vastleggen van gegevens en de analytische opslag kunt gebruiken.
Incrementele gegevens uit Cosmos DB gebruiken
U kunt de gegevensopname van wijzigingen in analytische opslag gebruiken als u momenteel gebruikmaakt van of van plan bent om het volgende te gebruiken:
- Incrementele gegevens vastleggen met azure Data Factory-Gegevensstroom s of Copy-activiteit.
- Eenmalige batchverwerking met behulp van Azure Data Factory.
- Cosmos DB-gegevens streamen
- De analytische opslag heeft een latentie van maximaal 2 minuten om transactionele opslaggegevens te synchroniseren. U kunt elke minuut Gegevensstroom s plannen in Azure Data Factory.
- Als u wilt streamen zonder de bovenstaande latentie, raden we u aan de functie wijzigingenfeed van het transactionele archief te gebruiken.
- Het vastleggen van verwijderingen, incrementele wijzigingen, het toepassen van filters op Cosmos DB-gegevens.
- Als u Azure Functions-triggers of een andere optie met wijzigingenfeed gebruikt en verwijderingen, incrementele wijzigingen wilt vastleggen, transformaties wilt toepassen, enzovoort; we raden u aan gegevensopname te wijzigen via analytische opslag.
Incrementele feed naar analytische platform van uw keuze
Met de mogelijkheid voor het vastleggen van gegevens wijzigen kunt u een end-to-end analytische oplossing gebruiken die u de flexibiliteit biedt om Azure Cosmos DB-gegevens te gebruiken met een van de ondersteunde sinktypen. Zie ondersteunde sinktypen voor gegevensstromen voor meer informatie over ondersteunde sinktypen. Met change data capture kunt u Ook Azure Cosmos DB-gegevens overbrengen naar een gecentraliseerde data lake en de gegevens samenvoegen met gegevens uit andere verschillende bronnen. U kunt de gegevens platmaken, partitioneren en meer transformaties toepassen in Azure Synapse Analytics of Azure Data Factory.
Gegevensopname wijzigen in Azure Cosmos DB voor MongoDB-containers
De gekoppelde service-interface voor de API voor MongoDB is nog niet beschikbaar in Azure Data Factory-gegevensstromen. U kunt uw API voor het accounteindpunt van MongoDB gebruiken met de gekoppelde Service-interface van Azure Cosmos DB for NoSQL als een tijdelijke oplossing totdat de gekoppelde Mongo-service rechtstreeks wordt ondersteund.
Selecteer In de interface voor een nieuwe gekoppelde NoSQL-service de optie Handmatig invoeren om de azure Cosmos DB-accountgegevens op te geven. Gebruik hier het NoSQL-documenteindpunt van het account (voorbeeld: https://<account-name>.documents.azure.com:443/) in plaats van het Mongo DB-eindpunt (voorbeeld: mongodb://<account-name>.mongo.cosmos.azure.com:10255/)