Dela via

Öka dataflödesprestanda till Azure SQL Database från Azure Stream Analytics

  • Artikel

I den här artikeln beskrivs tips för att få bättre prestanda för skrivdataflöde när du läser in data i Azure SQL Database med Hjälp av Azure Stream Analytics.

SQL-utdata i Azure Stream Analytics stöder skrivning parallellt som ett alternativ. Det här alternativet möjliggör helt parallella jobbtopologier, där flera utdatapartitioner skriver till måltabellen parallellt. Att aktivera det här alternativet i Azure Stream Analytics kanske dock inte räcker för att uppnå högre dataflöden, eftersom det beror avsevärt på databaskonfigurationen och tabellschemat. Valet av index, klustringsnyckel, indexfyllningsfaktor och komprimering påverkar tiden för att läsa in tabeller. Mer information om hur du optimerar databasen för att förbättra fråge- och inläsningsprestanda baserat på interna prestandamått finns i SQL Database prestandavägledning. Ordningen på skrivningar garanteras inte när du skriver parallellt med SQL Database.

Här följer några konfigurationer i varje tjänst som kan hjälpa dig att förbättra det övergripande dataflödet för din lösning.

Azure Stream Analytics

  • Ärv partitionering – Med det här konfigurationsalternativet för SQL-utdata kan du ärva partitioneringsschemat för föregående frågesteg eller indata. När detta är aktiverat, skriver till en diskbaserad tabell och har en helt parallell topologi för ditt jobb, förväntar du dig att se bättre dataflöden. Den här partitioneringen sker redan automatiskt för många andra utdata. Tabelllåsning (TABLOCK) är också inaktiverat för massinfogningar som görs med det här alternativet.

    Anteckning

    Om det finns fler än 8 indatapartitioner ärver det kanske inte lämpligt att ärva indatapartitioneringsschemat. Den här övre gränsen observerades i en tabell med en enda identitetskolumn och ett grupperat index. I det här fallet bör du överväga att använda INTO 8 i frågan för att uttryckligen ange antalet utdataskrivare. Dina observationer kan variera beroende på schema och val av index.

  • Batchstorlek – Med SQL-utdatakonfigurationen kan du ange den maximala batchstorleken i azure Stream Analytics SQL-utdata baserat på måltabellens/arbetsbelastningens natur. Batchstorlek är det maximala antalet poster som skickas med varje massinfogningstransaktion. I grupperade kolumnlagringsindex möjliggör batchstorlekar runt 100 000 mer parallellisering, minimal loggning och låsningsoptimeringar. I diskbaserade tabeller kan 10 000 (standard) eller lägre vara optimalt för din lösning, eftersom högre batchstorlekar kan utlösa låseskalering under massinfogningar.

  • Justering av indatameddelanden – Om du har optimerat med ärvd partitionering och batchstorlek kan du öka antalet indatahändelser per meddelande per partition ytterligare för att öka ditt skrivdataflöde. Justering av indatameddelanden gör att batchstorlekarna i Azure Stream Analytics kan vara upp till den angivna Batch-storleken, vilket förbättrar dataflödet. Detta kan uppnås genom att använda komprimering eller öka storleken på indatameddelanden i EventHub eller Blob.

SQL Azure

  • Partitionerad tabell och index – Om du använder en partitionerad SQL-tabell och partitionerade index i tabellen med samma kolumn som partitionsnyckeln (till exempel PartitionId) kan du avsevärt minska konkurrensen mellan partitioner under skrivningar. För en partitionerad tabell måste du skapa en partitionsfunktion och ett partitionsschema i DEN PRIMÄRA filgruppen. Detta ökar också tillgängligheten för befintliga data medan nya data läses in. Logg-I/O-gränsen kan nås baserat på antalet partitioner, vilket kan ökas genom att uppgradera SKU:n.

  • Undvik unika nyckelöverträdelser – Om du får varningsmeddelanden om flera nyckelöverträdelser i Azure Stream Analytics-aktivitetsloggen kontrollerar du att ditt jobb inte påverkas av unika begränsningsöverträdelser som sannolikt kommer att inträffa under återställningsfall. Du kan undvika detta genom att ange alternativet IGNORE_DUP_KEY för dina index.

Azure Data Factory och In-Memory tabeller

  • Minnesintern tabell som temporär tabell – Minnesintern tabell tillåter mycket snabba datainläsningar, men data måste få plats i minnet. Benchmarks visar att massinläsning från en minnesintern tabell till en diskbaserad tabell är ungefär 10 gånger snabbare än att massinfoga direkt med hjälp av en enskild skrivare i den diskbaserade tabellen med en identitetskolumn och ett grupperat index. Om du vill använda den här massinfogningsprestandan konfigurerar du ett kopieringsjobb med Azure Data Factory som kopierar data från den minnesinterna tabellen till den diskbaserade tabellen.

Undvika prestandagropar

Massinfogning av data är mycket snabbare än att läsa in data med enskilda infogningar eftersom det upprepade arbetet med att överföra data, parsa insert-instruktionen, köra -instruktionen och utfärda en transaktionspost undviks. I stället används en mer effektiv sökväg till lagringsmotorn för att strömma data. Installationskostnaden för den här sökvägen är dock mycket högre än en enda insert-instruktion i en diskbaserad tabell. Brytpunkten är vanligtvis cirka 100 rader, och massinläsningen är nästan alltid effektivare.

Om hastigheten för inkommande händelser är låg kan den enkelt skapa batchstorlekar som är lägre än 100 rader, vilket gör massinfogning ineffektiv och använder för mycket diskutrymme. Du kan kringgå den här begränsningen genom att utföra någon av följande åtgärder:

  • Skapa en i stället för utlösare för att använda enkel infogning för varje rad.
  • Använd en In-Memory temporär tabell enligt beskrivningen i föregående avsnitt.

Ett annat sådant scenario inträffar när du skriver till ett icke-grupperat kolumnlagringsindex (NCCI), där mindre massinfogningar kan skapa för många segment, som kan krascha indexet. I det här fallet rekommenderar vi att du använder ett grupperat Columnstore-index i stället.

Sammanfattning

Sammanfattningsvis, med funktionen för partitionerade utdata i Azure Stream Analytics för SQL-utdata bör justerad parallellisering av jobbet med en partitionerad tabell i SQL Azure ge dig betydande förbättringar av dataflödet. Genom att använda Azure Data Factory för att samordna dataflytt från en In-Memory tabell till diskbaserade tabeller kan du få större genomflödesvinster i storleksordning. Om möjligt kan en förbättrad meddelandetäthet också vara en viktig faktor för att förbättra det totala dataflödet.

Nästa steg