Dela via

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

I den här artikeln diskuteras tips för att uppnå bättre prestanda för skrivgenomströmning när du laddar in data i Azure SQL Database med hjälp av Azure Stream Analytics.

SQL-utdata i Azure Stream Analytics har stöd för att skriva parallellt som ett alternativ. Det här alternativet möjliggör helt parallella jobbtopologier, där flera utdatapartitioner skrivs parallellt till måltabellen. 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 Prestandavägledning för SQL Database. Ordningen på skrivningar garanteras inte när du skriver parallellt med SQL Database.

Här följer några konfigurationer inom 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 kan du skriva till en diskbaserad tabell och ha en helt parallell topologi för ditt jobb och förvänta dig bättre dataflöden. Den här partitioneringen sker redan automatiskt för många andra utdata. Tabellåsning (TABLOCK) inaktiveras också för massinfogningar som görs med det här alternativet.

    Anmärkning

    Om det finns fler än 8 indatapartitioner kanske det inte är 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 din fråga för att uttryckligen ange antalet utdataskrivare. Baserat på ditt schema och val av index kan dina observationer variera.

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

  • Indatameddelandejustering – Om du har optimerat med ärvd partitionering och batchstorlek kan du öka antalet inputhändelser per meddelande per partition för att ytterligare öka din skrivgenomströmning. Med indatameddelandejustering kan batchstorlekar i Azure Stream Analytics 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

  • In-Memory Tabell som temporär tabell – In-Memory tabeller 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 direkt massinföring med hjälp av en enkel skrivaranslutning i den diskbaserade tabellen som har identitetskolumnen och ett grupperat index. Om du vill använda den här massinfogningsprestandan konfigurerar du ett kopieringsjobb med hjälp av Azure Data Factory som kopierar data från den minnesbaserade tabellen till den diskbaserade tabellen.

Undvika prestandafällor

Massinfogning av data är mycket snabbare än att läsa in data med enkla 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 effektivare sökväg till lagringsmotorn för att strömma data. Installationskostnaden för den här processen är dock mycket högre än en enda insättningsinstruktion i en diskbaserad tabell. Brytpunkten är vanligtvis cirka 100 rader, utöver vilken massinläsning nästan alltid är effektivare.

Om den inkommande händelsefrekvensen ä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. Om du vill kringgå den här begränsningen kan du 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 partitionerad 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. Om du använder Azure Data Factory för att orkestrera dataflytt från en In-Memory tabell till Diskbaserade tabeller kan det ge dataflödesvinster i storleksordning. Om det är 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

  • Last updated on