Ändra strömmar i Azure Azure Azure Dbs API för MongoDB

GÄLLER FÖR: Azure Azure Azures DB API för MongoDB

Stöd för ändringsfeed i Azure Azure Dbs API för MongoDB är tillgängligt via ändringsströms-API:t. Med hjälp av API:t för ändringsströmmar kan programmen hämta de ändringar som görs i samlingen eller till objekten i en enda fragment. Senare kan du vidta ytterligare åtgärder baserat på resultatet. Ändringar av objekten i samlingen fångas så att de ändras och sorteringsordningen garanteras per fragmenterad nyckel.

Obs!

Om du vill använda ändringsströmmar skapar du Azure Hansson DB:s API för MongoDB-konto med serverversion 3.6 eller senare. Om du kör exemplen på ändringsström mot en tidigare version kan det okända namnet på pipelinesteget visas: vilket $changeStream versionen.

Exempel

I följande exempel visas hur du hämtar ändringsströmmar för alla objekt i samlingen. I det här exemplet skapas en markör för att se objekt när de infogas, uppdateras eller ersätts. Steget, $match scenen och alternativet krävs för att få $projectfullDocument ändringsströmmarna. Det finns för närvarande inte stöd för att titta efter borttagningsåtgärder med hjälp av ändringsströmmar. Som en lösning kan du lägga till en mjuk markör på de objekt som tas bort. Du kan till exempel lägga till ett attribut i objektet som kallas "borttagna". När du vill ta bort objektet kan du ange "borttagna" och true ange TTL för objektet. Eftersom uppdatering av "borttagna" true till är en uppdatering, kommer denna ändring att visas i ändringsströmmen.

var cursor = db.coll.watch(
    [
        { $match: { "operationType": { $in: ["insert", "update", "replace"] } } },
        { $project: { "_id": 1, "fullDocument": 1, "ns": 1, "documentKey": 1 } }
    ],
    { fullDocument: "updateLookup" });

while (!cursor.isExhausted()) {
    if (cursor.hasNext()) {
        printjson(cursor.next());
    }
}

Ändringar inom en enstaka fragment

I följande exempel visas hur du får ändringar av objekt inom en enstaka fragment. I det här exemplet får du ändringar av objekt som har en fragmentnyckel som är lika med "a" och det fragmenterade nyckelvärdet som är lika med "1". Det går att ha olika klienter som läser ändringar från olika fragmenter parallellt.

var cursor = db.coll.watch(
    [
        { 
            $match: { 
                $and: [
                    { "fullDocument.a": 1 }, 
                    { "operationType": { $in: ["insert", "update", "replace"] } }
                ]
            }
        },
        { $project: { "_id": 1, "fullDocument": 1, "ns": 1, "documentKey": 1} }
    ],
    { fullDocument: "updateLookup" });

Skalning av ändringsströmmar

När du använder ändra strömmar i skala är det bäst att sprida belastningen jämnt. Använd det anpassade kommandot GetChangeStreamTokens för att sprida belastningen över fysiska fragmenter/partitioner.

Aktuella begränsningar

Följande begränsningar är tillämpliga när du använder ändringsströmmar:

  • Egenskaperna operationType och stöds inte ännu i updateDescription utdatadokumentet.
  • Typer insert av , och åtgärder stöds för updatereplace närvarande. Borttagningsåtgärden eller andra händelser stöds dock inte ännu.

På grund av dessa begränsningar krävs $match steg, $project och fullDocument-alternativ, enligt föregående exempel.

Till skillnad från ändringsfeeden i Azure Azure Azure Dbs SQL API finns det inte något separat bibliotek för ändringsfeedprocessorer som använder ändringsströmmar eller ett behov av en behållare för leasning. Det finns för närvarande inget stöd för Azure-funktioner som utlöser processändringsströmmar.

Felhantering

Följande felkoder och felmeddelanden stöds när du använder ändringsströmmar:

  • HTTP-felkod 16500 – När ändringsströmmen begränsas returneras en tom sida.

  • NamespaceNotFound (OperationType Invalidate) – Om du kör en ändringsström i samlingen som inte finns eller om samlingen släpps returneras ett fel. Eftersom operationType egenskapen inte kan returneras i utdatadokumentet returneras felet i stället operationType Invalidate för NamespaceNotFound felet.

Nästa steg