Azure Stream Analytics-utdata till Azure Cosmos DB

Azure Cosmos DB-utdata i Azure Stream Analytics skriver strömbehandlingsresultat som JSON-dokument till en Azure Cosmos DB-container. Den stödjer dataarkivering och låglatensförfrågningar på ostrukturerad JSON-data. Att förstå hur detta resultat beter sig hjälper dig att konfigurera det för den genomströmning, konsistens och partitionering som ditt scenario kräver.

Grunderna i Azure Cosmos DB som mål för utdata

Azure Cosmos DB-utdata i Stream Analytics skriver dina strömbearbetningsresultat som JSON-utdata till dina Azure Cosmos DB-containrar. Om du inte är bekant med Azure Cosmos DB kan du läsa dokumentationen för Azure Cosmos DB för att komma igång.

Stream Analytics ansluter endast till Azure Cosmos DB via SQL API. Andra Azure Cosmos DB-API:er stöds ännu inte. Om du pekar Stream Analytics på Azure Cosmos DB-konton som skapats med andra API:er kanske data inte lagras korrekt. När du använder Azure Cosmos DB som utdata, sätt ditt jobb till kompatibilitetsnivå 1.2.

Stream Analytics skapar inte containrar i databasen. I stället måste du skapa dem i förväg. Du kan sedan styra faktureringskostnaderna för Azure Cosmos DB-containrar. Du kan också justera prestanda, konsekvens och kapacitet för dina containrar direkt med hjälp av Azure Cosmos DB-API:erna. I följande avsnitt beskrivs några av containeralternativen för Azure Cosmos DB.

Optimera konsekvens, tillgänglighet och svarstid

För att matcha dina applikationskrav, finjustera databasen och containrarna i Azure Cosmos DB och gör avvägningar mellan konsistens, tillgänglighet, latens och genomströmning.

Beroende på vilka nivåer av läskonsistens ditt scenario behöver mot läs- och skrivlatens, välj en konsistensnivå på ditt databaskonto. För att förbättra genomströmningen, skala upp Request Units (RU) på containern. Som standard möjliggör Azure Cosmos DB också synkron indexering på varje CRUD-åtgärd till din container. Detta alternativ är ett annat användbart sätt att styra läs- och skrivprestanda i Azure Cosmos DB. Mer information finns i artikeln Ändra databas- och frågekonsekvensnivåer .

Upserts från Stream Analytics

Genom att använda Stream Analytics-integration med Azure Cosmos DB kan du infoga eller uppdatera poster i din container baserat på en given Document ID-kolumn. Den här åtgärden kallas även för en upsert. Stream Analytics använder en optimistisk upsert-metod. Uppdateringar sker bara när en infogning misslyckas med en dokument-ID-konflikt.

Genom att använda kompatibilitetsnivå 1.0 utför Stream Analytics denna uppdatering som en PATCH-operation, vilket gör att den stöder partiella uppdateringar av dokumentet. Stream Analytics lägger till nya egenskaper eller ersätter en befintlig egenskap stegvis. Men ändringar i värdena för matrisegenskaper i JSON-dokumentet resulterar i att hela matrisen skrivs över. Matrisen är alltså inte sammanfogad.

Genom att använda kompatibilitetsnivå 1.2 ändras upsert-beteendet för att infoga eller ersätta dokumentet. I det senare avsnittet om kompatibilitetsnivå 1.2 beskrivs det här beteendet ytterligare.

Om det inkommande JSON-dokumentet har ett befintligt ID-fält använder Azure Cosmos DB automatiskt det fältet som kolumn för Dokument-ID. Stream Analytics hanterar alla efterföljande skrivningar som sådana, vilket leder till en av följande situationer:

• Unika ID:er leder till infogning.
• Duplicerade ID:er och dokument-ID som är inställda på ID leder till upsert.
• Dubbla ID:n och document-ID som inte setts leder till fel efter det första dokumentet.

Om du vill spara alla dokument, inklusive de som har ett duplicerat ID, byter du namn på ID-fältet i din fråga (med hjälp av nyckelordet AS ). Låt Azure Cosmos DB skapa ID-fältet eller ersätt ID:t med en annan kolumns värde (med hjälp av AS-nyckelordet eller med hjälp av inställningen Dokument-ID).

Datapartitionering i Azure Cosmos DB

Azure Cosmos DB skalar automatiskt partitioner baserat på din arbetsbelastning. Använd obegränsade containrar för att partitionera dina data. När Stream Analytics skriver till obegränsade containrar använder den lika många parallella skrivare som föregående frågesteg eller indatapartitioneringsschema.

Beroende på val av partitionsnyckel kan du få den här varningen:

CosmosDB Output contains multiple rows and just one row per partition key. If the output latency is higher than expected, consider choosing a partition key that contains at least several hundred records per partition key.

Välj en partitionnyckelegenskap som har många olika värden och fördelar din arbetsbelastning jämnt över dessa värden. Som en naturlig artefakt av partitionering begränsar den maximala genomströmningen av en enda partition förfrågningar som involverar samma partitionsnyckel.

Lagringsstorleken för dokument som tillhör samma partitionsnyckelvärde är begränsad till 20 GB (den fysiska partitionsstorleksgränsen är 50 GB). En idealisk partitionsnyckel är en som ofta förekommer som ett filter i dina frågor och har tillräcklig kardinalitet för att säkerställa att din lösning är skalbar.

Partitionsnycklar som används för Stream Analytics-frågor och Azure Cosmos DB behöver inte vara identiska. För helt parallella topologier, använd Input Partition-nyckeln, PartitionId, som partitionsnyckel för Stream Analytics-frågan, men det valet kanske inte är det rekommenderade för en Azure Cosmos DB-containers partitionsnyckel.

En partitionsnyckel är också gränsen för transaktioner i lagrade procedurer och utlösare för Azure Cosmos DB. Välj partitionsnyckeln så att dokument som sker tillsammans i transaktioner delar samma partitionsnyckelvärde. Artikeln Partitionering i Azure Cosmos DB innehåller mer information om hur du väljer en partitionsnyckel.

För fasta Azure Cosmos DB-containrar ger Stream Analytics inget sätt att skala upp eller ut efter att de är fulla. De har en övre gräns på 10 GB och 10 000 RU/s dataflöde. Om du vill migrera data från en fast container till en obegränsad container (till exempel en med minst 1 000 RU/s och en partitionsnyckel) använder du datamigreringsverktyget eller biblioteket för ändringsflöde.

Möjligheten att skriva till flera förutbestämda containrar håller på att fasas ut. Använd det inte för att skala ut ditt Stream Analytics-jobb.

Förbättrat dataflöde med kompatibilitetsnivå 1.2

Genom att använda kompatibilitetsnivå 1.2 stödjer Stream Analytics inbyggd integration för att massskriva i Azure Cosmos DB. Genom att använda denna integration skriver Stream Analytics effektivt till Azure Cosmos DB samtidigt som genomströmningen maximeras och strypförfrågningarna hanteras effektivt.

Den förbättrade skrivmekanismen är tillgänglig under en ny kompatibilitetsnivå på grund av skillnader i hur upsert-beteendet fungerar. Genom att använda nivåer före 1.2 är det uppåtgående beteendet att infoga eller slå ihop dokumentet. När du använder 1.2 ändras upsert-beteendet så att dokumentet infogas eller ersätts.

Genom att använda versioner före 1.2 använder Stream Analytics en anpassad lagrad procedur för att massuppdatera eller infoga dokument för varje partitionsnyckel i Azure Cosmos DB. Där skriver Stream Analytics en batch som en transaktion. Även när en enskild post får ett tillfälligt fel (strypning) måste Stream Analytics försöka om hela batchen. Detta beteende gör situationer med även rimlig strypning långsamma.

I följande exempel visas två identiska Stream Analytics-jobb som läser från samma Azure Event Hubs-indata. Båda Stream Analytics-jobben är helt partitionerade med en genomströmningsfråga och skriver till identiska Azure Cosmos DB-containrar. Måtten till vänster härstammar från den uppgift som konfigurerats med kompatibilitetsnivå 1.0. Måtten till höger kommer från jobbet konfigurerat med 1.2. En Azure Cosmos DB-containers partitionsnyckel är ett unikt GUID som hämtas från indatahändelsen.

Den inkommande händelsetakten i Event Hubs är dubbelt så hög som vad Azure Cosmos DB-containrar (20 000 RU) är konfigurerade för att kunna hantera, så du kan förvänta dig begränsning i Azure Cosmos DB. Jobbet med 1.2 skrivs dock konsekvent vid ett högre dataflöde (utdatahändelser per minut) och med en lägre genomsnittlig SU%-användning. I din miljö beror denna skillnad på några fler faktorer. Dessa faktorer inkluderar val av händelseformat, indatahändelse/meddelandestorlek, partitionsnycklar och fråga.

Med version 1.2 använder Stream Analytics på ett mer intelligent sätt 100 procent av den tillgängliga genomströmningen i Azure Cosmos DB, med få omförsök vid strypning eller hastighetsbegränsning. Det här beteendet skapar en bättre upplevelse för andra arbetsbelastningar, såsom databaskörningar som körs på containern samtidigt. Om du vill se hur Stream Analytics skalar ut med Azure Cosmos DB som mottagare för 1 000 till 10 000 meddelanden per sekund kan du prova det här Azure-exempelprojektet.

Genomströmningen av Azure Cosmos DB-utgången är identisk genom att använda 1.0 och 1.1. Vi rekommenderar starkt att du använder kompatibilitetsnivå 1.2 i Stream Analytics med Azure Cosmos DB.

Azure Cosmos DB-inställningar för JSON-utdata

När du konfigurerar Azure Cosmos DB som en utdata i Stream Analytics, definierar följande egenskaper utdatan.

När du har konfigurerat Azure Cosmos DB-utdata kan du använda det i frågan som mål för en INTO-instruktion. När du använder en Azure Cosmos DB-utdata på det sättet måste du uttryckligen sätta en partitionsnyckel.

Utdataposten måste innehålla en skiftlägeskänslig kolumn som är döpt efter partitionsnyckeln i Azure Cosmos DB. För att uppnå större parallellisering kan instruktionen kräva en PARTITION BY-sats som använder samma kolumn.

Här är en exempelfråga:

    SELECT TollBoothId, PartitionId
    INTO CosmosDBOutput
    FROM Input1 PARTITION BY PartitionId

Felhantering och återförsök

Om ett tillfälligt fel, tjänstens otillgänglighet eller begränsning inträffar när Stream Analytics skickar händelser till Azure Cosmos DB, försöker Stream Analytics på obestämd tid för att slutföra åtgärden. Men den gör inga nya försök för fel av typen Unauthorized (HTTP-felkod 401), NotFound (HTTP-felkod 404), Forbidden (HTTP-felkod 403) eller BadRequest (HTTP-felkod 400).

Vanliga problem som gör att Azure Cosmos DB-utdata misslyckas

Flera villkor kan orsaka att Azure Cosmos DB-utgången misslyckas. Utdatan från Stream Analytics kan bryta mot en unik indexbegränsning på containern, kolumnen PartitionKey kanske inte existerar, eller kolumnen Id kanske inte existerar. För mer information om unika indexbegränsningar, se Unika nyckelbegränsningar i Azure Cosmos DB.

Relaterat innehåll

• Förstå utdata från Azure Stream Analytics
• Azure Stream Analytics-utdata till Azure SQL Database
• Partitionering av anpassade blobutdata i Azure Stream Analytics