Sdílet prostřednictvím

Procesor kanálu změn ve službě Azure Cosmos DB

PLATÍ PRO: NoSQL

Procesor změnového kanálu je součástí Azure Cosmos DB .NET V3 a Java V4 SDK, které zjednodušují proces načítání změnového kanálu a efektivně rozdělují zpracování událostí mezi více spotřebitelů.

Hlavní výhodou použití procesoru kanálu změn je návrh odolný proti chybám, který zajišťuje alespoň jedno doručení všech událostí v kanálu změn.

Podporované sady SDK

.NET V3 Java Node.JS Python
✓ ✓ ✕ ✕

Komponenty procesoru pro změnový kanál

Procesor kanálu změn má čtyři hlavní komponenty:

  • Monitorovaný kontejner: Monitorovaný kontejner obsahuje data, ze kterých se generuje záznam změn. Jakékoli vložení nebo aktualizace v monitorovaném kontejneru se projeví jako změny v kanálu změn kontejneru.

  • Kontejner pronájmu: Kontejner pronájmu funguje jako úložiště stavu a koordinuje zpracování změnové fronty napříč několika pracovními procesy. Kontejner zapůjčení může být uložený ve stejném účtu jako monitorovaný kontejner nebo v samostatném účtu.

  • Výpočetní instance: Výpočetní instance hostuje procesor kanálu změn, aby naslouchal změnám. V závislosti na platformě ho může reprezentovat virtuální počítač, pod Kubernetes, instance služby Aplikace Azure Service nebo skutečný fyzický počítač. Výpočetní instance má jedinečný identifikátor, který se v tomto článku nazývá název instance.

  • Delegát: Delegát je kód, který definuje, co vy jako vývojář chcete dělat s každou dávkou změn, které čte procesor změnového kanálu.

Abychom lépe pochopili, jak tyto čtyři prvky procesoru zdroje změn spolupracují, podívejme se na příklad v následujícím diagramu. Monitorovaný kontejner ukládá položky a jako klíč oddílu používá „Město“. Hodnoty klíče oddílu se distribuují v oblastech (každá oblast představuje fyzický oddíl), který obsahuje položky.

Diagram znázorňuje dvě výpočetní instance a procesor kanálu změn přiřadí jednotlivým instancím různé rozsahy, aby se maximalizovala distribuce výpočetních prostředků. Každá instance má jiný jedinečný název.

Každý rozsah se čte paralelně. Průběh rozsahu se udržuje odděleně od ostatních oblastí v kontejneru zapůjčení prostřednictvím dokumentu zapůjčení . Kombinovaný soubor pronájmů představuje aktuální stav procesoru toku změn.

Diagram znázorňující příklad procesoru zpracování změn

Implementovat procesor kanálu změn

Procesor kanálu změn v .NET je k dispozici pro režim nejnovější verze a režim všech verzí a odstranění. Všechny verze a režim odstranění jsou ve verzi Preview a podporuje se pro procesor kanálu změn počínaje verzí 3.40.0-preview.0. Vstupní bod pro oba režimy je vždy monitorovaný kontejner.

Pokud chcete číst pomocí režimu nejnovější verze, ve Container instanci zavoláte GetChangeFeedProcessorBuilder:

/// <summary>
/// Start the Change Feed Processor to listen for changes and process them with the HandleChangesAsync implementation.
/// </summary>
private static async Task<ChangeFeedProcessor> StartChangeFeedProcessorAsync(
    CosmosClient cosmosClient,
    IConfiguration configuration)
{
    string databaseName = configuration["SourceDatabaseName"];
    string sourceContainerName = configuration["SourceContainerName"];
    string leaseContainerName = configuration["LeasesContainerName"];

    Container leaseContainer = cosmosClient.GetContainer(databaseName, leaseContainerName);
    ChangeFeedProcessor changeFeedProcessor = cosmosClient.GetContainer(databaseName, sourceContainerName)
        .GetChangeFeedProcessorBuilder<ToDoItem>(processorName: "changeFeedSample", onChangesDelegate: HandleChangesAsync)
            .WithInstanceName("consoleHost")
            .WithLeaseContainer(leaseContainer)
            .Build();

    Console.WriteLine("Starting Change Feed Processor...");
    await changeFeedProcessor.StartAsync();
    Console.WriteLine("Change Feed Processor started.");
    return changeFeedProcessor;
}

Pokud chcete číst pomocí všech verzí a režimu mazání, zavolejte GetChangeFeedProcessorBuilderWithAllVersionsAndDeletes z instance Container.

Container leaseContainer = client.GetContainer(Program.databaseName, Program.leasesContainer);
Container monitoredContainer = client.GetContainer(Program.databaseName, containerName);
ChangeFeedProcessor changeFeedProcessor = monitoredContainer
    .GetChangeFeedProcessorBuilderWithAllVersionsAndDeletes<ToDoItem>(processorName: "changeFeedBasic", onChangesDelegate: Program.HandleChangesAsync)
        .WithInstanceName("consoleHost")
        .WithLeaseContainer(leaseContainer)
        .Build();

V obou režimech je prvním parametrem jedinečný název, který popisuje cíl tohoto procesoru. Druhým názvem je implementace delegáta, která zpracovává změny.

Tady je příklad delegáta pro nejnovější režim verze:

/// <summary>
/// The delegate receives batches of changes as they are generated in the change feed and can process them.
/// </summary>
static async Task HandleChangesAsync(
    ChangeFeedProcessorContext context,
    IReadOnlyCollection<ToDoItem> changes,
    CancellationToken cancellationToken)
{
    Console.WriteLine($"Started handling changes for lease {context.LeaseToken}...");
    Console.WriteLine($"Change Feed request consumed {context.Headers.RequestCharge} RU.");
    // SessionToken if needed to enforce Session consistency on another client instance
    Console.WriteLine($"SessionToken ${context.Headers.Session}");

    // We may want to track any operation's Diagnostics that took longer than some threshold
    if (context.Diagnostics.GetClientElapsedTime() > TimeSpan.FromSeconds(1))
    {
        Console.WriteLine($"Change Feed request took longer than expected. Diagnostics:" + context.Diagnostics.ToString());
    }

    foreach (ToDoItem item in changes)
    {
        Console.WriteLine($"Detected operation for item with id {item.id}, created at {item.creationTime}.");
        // Simulate some asynchronous operation
        await Task.Delay(10);
    }

    Console.WriteLine("Finished handling changes.");
}

Tady je příklad delegáta pro všechny verze a režim odstranění:

static async Task HandleChangesAsync(ChangeFeedProcessorContext context, IReadOnlyCollection<ChangeFeedItem<ToDoItem>> changes, CancellationToken cancellationToken)
{
    Console.WriteLine($"Started handling changes for lease {context.LeaseToken}...");
    Console.WriteLine($"Change Feed request consumed {context.Headers.RequestCharge} RU.");
    // SessionToken if needed to enforce Session consistency on another client instance
    Console.WriteLine($"SessionToken ${context.Headers.Session}");

    // We may want to track any operation's Diagnostics that took longer than some threshold
    if (context.Diagnostics.GetClientElapsedTime() > TimeSpan.FromSeconds(1))
    {
        Console.WriteLine($"Change Feed request took longer than expected. Diagnostics:" + context.Diagnostics.ToString());
    }

    foreach (ChangeFeedItem<ToDoItem> item in changes)
    {
        if (item.Metadata.OperationType == ChangeFeedOperationType.Delete)
        {
            Console.WriteLine($"\tDetected {item.Metadata.OperationType} operation for item.");
        }
        else
        {
            Console.WriteLine($"\tDetected {item.Metadata.OperationType} operation for item with id {item.Current.id}.");
        }
        // Simulate work
        await Task.Delay(1);
    }
}

Poté pomocí . definujete název výpočetní instance nebo jedinečný identifikátor .WithInstanceName Název výpočetní instance by měl být jedinečný a jiný pro každou výpočetní instanci, kterou nasazujete. Kontejner nastavíte tak, aby se zachoval stav zapůjčení pomocí WithLeaseContainer.

Volání Build poskytuje instanci procesoru, kterou můžete začít voláním StartAsync.

Důležité

Při vytváření kontejnerů pro zdroj dat a rezerva a inicializaci nové pracovní zátěže procesoru změnového kanálu:

Použití globálního koncového bodu

  • Vždy zadejte globální koncový bod (například contoso.documents.azure.com) místo regionálního koncového bodu (například contoso-westus.documents.azure.com).

Přepnutí oblastí pomocí ApplicationRegion nebo ApplicationPreferredRegions

  • Pokud chcete přesměrovat přenosy kanálu změn mezi oblastmi, spolehněte se na vlastnost ApplicationRegion nebo ApplicationPreferredRegions.
  • Procesor kanálu změn vytváří dokumenty zapůjčení, které jsou vymezeny na nakonfigurovaný koncový bod, takže změna koncových bodů vede k vytvoření nových nezávislých dokumentů zapůjčení.

✅ Postupujte takto: Použijte globální koncový bod s applicationRegion:

CosmosClient client = new CosmosClient(
    "https://contoso.documents.azure.com:443/",  // Global endpoint
    "<account-key>",
    new CosmosClientOptions()
    {
        ApplicationRegion = Regions.WestUS2  // Specify region here
    });

Container monitoredContainer = client.GetContainer("myDatabase", "myContainer");
Container leaseContainer = client.GetContainer("myDatabase", "leases");

✅ Proveďte následující: Použijte globální koncový bod s ApplicationPreferredRegions:

CosmosClient client = new CosmosClient(
    "https://contoso.documents.azure.com:443/",  // Global endpoint
    "<account-key>",
    new CosmosClientOptions()
    {
        ApplicationPreferredRegions = new List<string> { Regions.WestUS2, Regions.EastUS2 }
    });

Container monitoredContainer = client.GetContainer("myDatabase", "myContainer");
Container leaseContainer = client.GetContainer("myDatabase", "leases");

❌ Nedělejte to – vyhněte se oblastním koncovým bodům:

// DON'T: Using regional endpoint will create region-scoped lease documents
CosmosClient client = new CosmosClient(
    "https://contoso-westus.documents.azure.com:443/",  // Regional endpoint - AVOID
    "<account-key>");

Důležité

Vyhněte se asynchronnímu zpracování v metodách delegáta: Při použití asynchronních rozhraní API v rámci handleChanges() metody delegáta mějte na paměti, že procesor kanálu změn může uložit stav nájmu dříve, než se dokončí všechny asynchronní operace. To může vést k zmeškaným událostem, pokud má aplikace během obnovení problémy. Před povolením vrácení delegáta zvažte použití synchronního zpracování nebo implementaci správného sledování dokončení.

Poznámka:

Předchozí fragmenty kódu pocházejí z ukázek na GitHubu. Ukázku můžete získat pro režim nejnovější verze nebo režim všech verzí a mazání.

Životní cyklus zpracování

Normální životní cyklus instance hostitele je následující:

  1. Číst kanál změn.
  2. Pokud nedošlo k žádným změnám, přejděte do režimu spánku po předdefinovanou dobu (přizpůsobitelné pomocí WithPollInterval v Tvůrci) a přejděte ke kroku 1.
  3. Pokud dojde ke změnám, pošlete je delegátu.
  4. Jakmile delegát úspěšně dokončí zpracování změn, aktualizujte úložiště zápůjčky nejnovějším časovým bodem zpracování a přejděte ke kroku 1.

Zpracování chyb

Procesor kanálu změn je odolný chybám v uživatelském kódu. Pokud má implementace delegáta neošetřenou výjimku (krok 4), vlákno, které zpracovává konkrétní dávku změn, se zastaví a nakonec se vytvoří nové vlákno. Nové vlákno zkontroluje poslední časový bod, který obchod s leasingem uložil pro tento rozsah hodnot klíčů oddílu. Nové vlákno se odsud restartuje a efektivně odesílá stejnou dávku změn delegátovi. Toto chování pokračuje, dokud váš delegát nezpracuje změny správně, a je to důvod, proč procesor kanálu změn má záruku "alespoň jednou".

Poznámka:

V jediném scénáři se nezkouší znovu sada změn. Pokud k selhání dojde při prvním spuštění delegáta, úložiště pronájmu nemá žádný předchozí uložený stav pro opakování. V takových případech se při opakování použije počáteční spouštěcí konfigurace, která může nebo nemusí obsahovat poslední dávku.

Aby se procesor kanálu změn neustále nezablokoval při opakovaném zpracovávání stejné dávky změn, měli byste při výskytu výjimky přidat do kódu delegáta logiku pro zápis dokumentů do fronty chybových zpráv. Tento návrh zajistí, že budete moct sledovat nezpracované změny a zároveň i nadále zpracovávat budoucí změny. Fronta chybových zpráv může být dalším kontejnerem Azure Cosmos DB. Na přesném úložišti dat nezáleží. Chcete, aby se nezpracované změny zachovaly.

Pomocí estimátoru kanálu změn můžete také sledovat průběh instancí procesoru kanálu změn při čtení kanálu změn nebo můžete použít oznámení životního cyklu k detekci základních selhání.

Ujistěte se, že časový limit požadavku na síť klienta je delší než časový limit na straně serveru, aby se zabránilo neshodám časových limitů, které můžou vést ke zastavení zpracování. Výchozí časový limit na straně serveru je 5 sekund. Sledujte chyby související s vypršením časového limitu a odpovídajícím způsobem upravte konfigurace.

Oznámení životního cyklu

Procesor kanálu změn můžete připojit k libovolné relevantní události v jejím životním cyklu. Můžete se rozhodnout, že budete upozorněni na jednu nebo všechny z nich. Doporučuje se alespoň zaregistrovat oznámení o chybě:

  • Zaregistrujte obslužnou rutinu u WithLeaseAcquireNotification tak, aby byl obeznámen, když aktuální hostitel získá nájemní právo k jeho zpracování.
  • Zaregistrujte obslužnou rutinu pro WithLeaseReleaseNotification, která má být upozorněna, když aktuální hostitel uvolní pronájem a přestane jej zpracovávat.
  • Zaregistrujte obslužnou rutinu WithErrorNotification, která bude upozorněna, když aktuální hostitel během zpracování narazí na výjimku. Musíte být schopni rozlišit, jestli je zdrojem delegát uživatele (neošetřená výjimka) nebo chyba, se kterou se procesor setká při pokusu o přístup k monitorovanému kontejneru (například problémy se sítí).

Oznámení o životním cyklu jsou dostupná v obou režimech kanálu změn. Tady je příklad oznámení životního cyklu v nejnovějším režimu verze:

Container.ChangeFeedMonitorLeaseAcquireDelegate onLeaseAcquiredAsync = (string leaseToken) =>
{
    Console.WriteLine($"Lease {leaseToken} is acquired and will start processing");
    return Task.CompletedTask;
};

Container.ChangeFeedMonitorLeaseReleaseDelegate onLeaseReleaseAsync = (string leaseToken) =>
{
    Console.WriteLine($"Lease {leaseToken} is released and processing is stopped");
    return Task.CompletedTask;
};

Container.ChangeFeedMonitorErrorDelegate onErrorAsync = (string LeaseToken, Exception exception) =>
{
    if (exception is ChangeFeedProcessorUserException userException)
    {
        Console.WriteLine($"Lease {LeaseToken} processing failed with unhandled exception from user delegate {userException.InnerException}");
    }
    else
    {
        Console.WriteLine($"Lease {LeaseToken} failed with {exception}");
    }

    return Task.CompletedTask;
};

ChangeFeedProcessor changeFeedProcessor = monitoredContainer
    .GetChangeFeedProcessorBuilder<ToDoItem>("changeFeedNotifications", handleChanges)
        .WithLeaseAcquireNotification(onLeaseAcquiredAsync)
        .WithLeaseReleaseNotification(onLeaseReleaseAsync)
        .WithErrorNotification(onErrorAsync)
        .WithInstanceName("consoleHost")
        .WithLeaseContainer(leaseContainer)
        .Build();

Jednotka nasazení

Jedna jednotka nasazení procesoru kanálu změn se skládá z jedné nebo více výpočetních instancí, které mají stejnou hodnotu pro processorName a stejnou konfiguraci kontejneru zapůjčení, ale různé názvy instancí. Můžete mít mnoho jednotek nasazení, ve kterých má každá jednotka jiný obchodní tok pro změny a každá jednotka nasazení se skládá z jedné nebo více instancí.

Můžete mít například jednu jednotku nasazení, která aktivuje externí rozhraní API pokaždé, když v kontejneru dojde ke změně. Jiná jednotka nasazení může přesouvat data v reálném čase pokaždé, když dojde ke změně. Když dojde ke změně v monitorovaném kontejneru, zobrazí se oznámení o všech jednotkách nasazení.

Dynamické škálování

Jak už bylo zmíněno dříve, v rámci jednotky nasazení můžete mít jednu nebo více výpočetních instancí. Pokud chcete využít výhod distribuce výpočetních prostředků v rámci jednotky nasazení, jedinými klíčovými požadavky jsou tyto:

  • Všechny instance musí mít stejnou konfiguraci kontejneru zapůjčení.
  • Všechny instance by měly mít stejnou hodnotu pro processorName.
  • Každá instance musí mít jiný název instance (WithInstanceName).

Pokud se použijí tyto tři podmínky, procesor kanálu změn distribuuje všechna zapůjčení, která jsou v kontejneru zapůjčení, napříč všemi spuštěnými instancemi této jednotky nasazení a paralelizuje výpočetní prostředky pomocí algoritmu stejné distribuce. Nájem je vlastněn vždy jen jednou instancí, takže počet instancí by neměl přesahovat počet nájmů.

Počet instancí se může zvětšit a zmenšit. Procesor kanálu změn dynamicky upravuje zatížení systému tím, že ho odpovídajícím způsobem redistribuuje.

Procesor kanálu změn navíc může dynamicky upravit škálování kontejneru, pokud se zvýší propustnost nebo úložiště kontejneru. Když váš kontejner roste, procesor kanálu změn transparentně zpracovává scénář dynamickým zvýšením zapůjčení a distribucí nových zapůjčení mezi existující instance.

Počáteční čas

Ve výchozím nastavení se při prvním spuštění procesoru kanálu změn inicializuje kontejner zapůjčení a spustí jeho životní cyklus zpracování. Všechny změny, ke kterým došlo v monitorovaném kontejneru předtím, než se procesor kanálu změn inicializuje poprvé, se nezjistí.

Čtení z předchozího data a času

Procesor kanálu změn je možné inicializovat tak, aby četl změny počínaje konkrétním datem a časem předáním instance DateTime do rozšíření tvůrce WithStartTime:

Container leaseContainer = client.GetContainer(databaseId, Program.leasesContainer);
Container monitoredContainer = client.GetContainer(databaseId, Program.monitoredContainer);
ChangeFeedProcessor changeFeedProcessor = monitoredContainer
    .GetChangeFeedProcessorBuilder<ToDoItem>("changeFeedTime", Program.HandleChangesAsync)
        .WithInstanceName("consoleHost")
        .WithLeaseContainer(leaseContainer)
        .WithStartTime(particularPointInTime)
        .Build();

Procesor kanálu změn se inicializuje pro konkrétní datum a čas a začne číst změny, ke kterým došlo později.

Čtení od začátku

V jiných scénářích, jako jsou migrace dat nebo při analýze celé historie kontejneru, je potřeba číst informační kanál změn od začátku životnosti tohoto kontejneru. Jako v tomto příkladu, můžete použít WithStartTime v rozšíření pro tvůrce, ale předat DateTime.MinValue.ToUniversalTime(), který vytvoří reprezentaci minimální hodnoty DateTime ve formátu UTC.

Container leaseContainer = client.GetContainer(databaseId, Program.leasesContainer);
Container monitoredContainer = client.GetContainer(databaseId, Program.monitoredContainer);
ChangeFeedProcessor changeFeedProcessor = monitoredContainer
    .GetChangeFeedProcessorBuilder<ToDoItem>("changeFeedBeginning", Program.HandleChangesAsync)
        .WithInstanceName("consoleHost")
        .WithLeaseContainer(leaseContainer)
        .WithStartTime(DateTime.MinValue.ToUniversalTime())
        .Build();

Procesor změn se inicializuje a začne číst změny od začátku životnosti kontejneru.

Poznámka:

Tyto možnosti přizpůsobení fungují pouze pro nastavení výchozího bodu v čase procesoru změn. Po první inicializaci nájemního kontejneru nemá změna těchto možností žádný vliv.

Přizpůsobení výchozího bodu je dostupné pouze v režimu kanálu změn pro nejnovější verzi. Pokud používáte všechny verze a režim odstranění, musíte začít číst od okamžiku, kdy je procesor spuštěný, nebo pokračovat z předchozího stavu zapůjčení, který je v období nepřetržitého uchovávání záloh vašeho účtu.

Kanál změn a zřízená propustnost

Operace čtení kanálu změn u monitorovaných kontejnerů spotřebovávají jednotky žádostí. Ujistěte se, že u monitorovaného kontejneru nedochází k omezování výkonu. Omezování zvyšuje zpoždění při příjmu událostí z kanálu změn na zpracovatelích.

Operace s kontejnerem zapůjčení (aktualizace a údržba stavu) spotřebovávají jednotky žádostí. Čím vyšší je počet instancí, které používají stejný kontejner nájmu, tím vyšší je potenciální spotřeba jednotek žádostí. Ujistěte se, že váš pronajatý kontejner nezažívá škrcení. Omezování přidává zpoždění při přijímání událostí v kanálu změn. Škrcení výkonu může dokonce úplně ukončit zpracování.

Sdílení pronajatého kontejneru

Leasingový kontejner můžete sdílet napříč několika nasazovacími jednotkami. V kontejneru se sdíleným prostorem každá nasazovací jednotka naslouchá jinému monitorovanému kontejneru nebo má jinou hodnotu pro processorName. V této konfiguraci každá jednotka nasazení udržuje nezávislý stav v kontejneru vypůjčení. Zkontrolujte spotřebu jednotek žádosti v kontejneru pro pronájem a ujistěte se, že zajištěná propustnost stačí pro všechny jednotky nasazení.

Pokročilá konfigurace zapůjčení

Tři konfigurace klíčů můžou ovlivnit fungování procesoru kanálu změn. Každá konfigurace ovlivňuje spotřebu jednotek žádosti v kontejneru nájmu. Při vytváření procesoru kanálu změn můžete nastavit jednu z těchto konfigurací, avšak používejte je opatrně.

  • Převzetí nájmu: Ve výchozím nastavení každých 17 sekund. Hostitel pravidelně kontroluje stav úložiště pronájmů a v rámci procesu dynamického škálování zvažuje získání pronájmů. Tento proces se provádí vykonáním dotazu v kontejneru pronájmů. Snížením této hodnoty se urychlí vyrovnávání a získání leasingů, ale zvýší se spotřeba jednotek žádosti v kontejneru pro leasingy.
  • Vypršení platnosti zapůjčení: Ve výchozím nastavení 60 sekund. Definuje maximální dobu, po kterou může existovat pronájem bez jakékoli obnovovací aktivity, než jej získá jiný hostitel. Když dojde k chybovému ukončení hostitele, pronájmy, které vlastnil, převezmou ostatní hostitelé po uplynutí tohoto časového období a dále nakonfigurovaného intervalu obnovení. Snížením této hodnoty dojde k rychlejšímu obnovení po chybovém ukončení hostitele, ale hodnota vypršení platnosti by nikdy neměla být nižší než interval obnovení.
  • Prodloužení zapůjčení: Ve výchozím nastavení každých 13 sekund. Hostitel, který vlastní nájem, pravidelně obnovuje nájem, i když nejsou žádné nové změny k využití. Tento proces se provádí spuštěním funkce Nahradit v pronájmu. Snížením této hodnoty se zkrátí doba potřebná ke zjištění ztracených pronájmů v důsledku pádu hostitele, ale zvýší se spotřeba jednotek žádostí v kontejneru pro pronájmy.

Kde hostovat procesor změnového kanálu

Procesor kanálu změn je možné hostovat na libovolné platformě, která podporuje dlouhotrvající procesy nebo úlohy. Několik příkladů:

I když může procesor kanálu změn běžet v krátkodobých prostředích, protože leasingový kontejner udržuje stav, cyklus spuštění těchto prostředí přidává zpoždění k času potřebnému k přijetí oznámení (kvůli režii spojené s každým spuštěním procesoru).

Požadavky na přístup na základě role

Pokud jako ověřovací mechanismus používáte ID Microsoft Entra, ujistěte se, že identita má správná oprávnění:

  • V monitorovaném kontejneru:
    • Microsoft.DocumentDB/databaseAccounts/readMetadata
    • Microsoft.DocumentDB/databaseAccounts/sqlDatabases/containers/readChangeFeed
  • Na kontejneru pronájmu:
    • Microsoft.DocumentDB/databaseAccounts/sqlDatabases/containers/items/read
    • Microsoft.DocumentDB/databaseAccounts/sqlDatabases/containers/items/create
    • Microsoft.DocumentDB/databaseAccounts/sqlDatabases/containers/items/replace
    • Microsoft.DocumentDB/databaseAccounts/sqlDatabases/containers/items/delete
    • Microsoft.DocumentDB/databaseAccounts/sqlDatabases/containers/items/executeQuery

Další zdroje informací

Další kroky

Další informace o procesoru kanálu změn najdete v následujících článcích:

  • Last updated on