Doorvoerprestaties verhogen naar Azure SQL Database vanuit Azure Stream Analytics

Artikel
06/01/2023

In dit artikel worden tips besproken voor betere schrijfdoorvoerprestaties wanneer u gegevens in Azure SQL Database laadt met behulp van Azure Stream Analytics.

SQL-uitvoer in Azure Stream Analytics biedt ondersteuning voor parallel schrijven als optie. Deze optie maakt volledig parallelle taaktopologieën mogelijk, waarbij meerdere uitvoerpartities parallel naar de doeltabel worden geschreven. Het inschakelen van deze optie in Azure Stream Analytics is echter mogelijk niet voldoende om een hogere doorvoer te bereiken, omdat dit aanzienlijk afhankelijk is van uw databaseconfiguratie en tabelschema. De keuze van indexen, clustersleutel, indexopvullingsfactor en compressie hebben invloed op de tijd die nodig is om tabellen te laden. Zie SQL Database prestatierichtlijnen voor meer informatie over het optimaliseren van uw database om query- en laadprestaties te verbeteren op basis van interne benchmarks. De volgorde van schrijfbewerkingen wordt niet gegarandeerd wanneer u parallel aan SQL Database schrijft.

Hier volgen enkele configuraties binnen elke service die kunnen helpen bij het verbeteren van de algehele doorvoer van uw oplossing.

Azure Stream Analytics

Partitionering overnemen : met deze configuratieoptie voor SQL-uitvoer kunt u het partitieschema van uw vorige querystap of invoer overnemen. Als dit is ingeschakeld, schrijven naar een schijftabel en een volledig parallelle topologie voor uw taak hebben, verwacht u betere doorvoer te zien. Deze partitionering vindt al automatisch plaats voor veel andere uitvoer. Tabelvergrendeling (TABLOCK) is ook uitgeschakeld voor bulksgewijs invoegen met deze optie.

Notitie

Wanneer er meer dan 8 invoerpartities zijn, is het overnemen van het invoerpartitioneringsschema mogelijk geen geschikte keuze. Deze bovengrens is waargenomen in een tabel met één identiteitskolom en een geclusterde index. In dit geval kunt u INTO 8 gebruiken in uw query om het aantal uitvoerschrijvers expliciet op te geven. Op basis van uw schema en de keuze van indexen kunnen uw waarnemingen variëren.
Batchgrootte : met sql-uitvoerconfiguratie kunt u de maximale batchgrootte opgeven in een Azure Stream Analytics SQL-uitvoer op basis van de aard van uw doeltabel/-workload. Batchgrootte is het maximum aantal records dat wordt verzonden bij elke bulkinvoegingstransactie. In geclusterde columnstore-indexen maken batchgrootten van ongeveer 100.000 meer parallellisatie, minimale logboekregistratie en vergrendelingsoptimalisaties mogelijk. In schijftabellen kan 10.000 (standaard) of lager optimaal zijn voor uw oplossing, omdat grotere batchgrootten escalatie van vergrendelingen kunnen activeren tijdens bulksgewijs invoegen.
Afstemmen van invoerberichten : als u hebt geoptimaliseerd met partitionering overnemen en batchgrootte, kunt u het aantal invoergebeurtenissen per bericht per partitie verhogen om uw schrijfdoorvoer verder te pushen. Bij het afstemmen van invoerberichten kunnen batchgrootten in Azure Stream Analytics worden ingesteld op de opgegeven batchgrootte, waardoor de doorvoer wordt verbeterd. Dit kan worden bereikt door compressie te gebruiken of de grootte van invoerberichten in EventHub of Blob te vergroten.

SQL Azure

Gepartitioneerde tabel en indexen : het gebruik van een gepartitioneerde SQL-tabel en gepartitioneerde indexen in de tabel met dezelfde kolom als uw partitiesleutel (bijvoorbeeld PartitionId) kan conflicten tussen partities tijdens schrijfbewerkingen aanzienlijk verminderen. Voor een gepartitioneerde tabel moet u een partitiefunctie en een partitieschema maken voor de bestandsgroep PRIMARY. Dit verhoogt ook de beschikbaarheid van bestaande gegevens terwijl nieuwe gegevens worden geladen. De logboek-IO-limiet kan worden bereikt op basis van het aantal partities, dat kan worden verhoogd door de SKU te upgraden.
Unieke sleutelschendingen voorkomen : als u meerdere waarschuwingsberichten voor sleutelschending krijgt in het Activiteitenlogboek van Azure Stream Analytics, moet u ervoor zorgen dat uw taak niet wordt beïnvloed door unieke beperkingsschendingen die waarschijnlijk optreden tijdens herstelgevallen. U kunt dit voorkomen door de optie IGNORE_DUP_KEY in te stellen op uw indexen.

tabellen Azure Data Factory en In-Memory

Tabel in het geheugen als tijdelijke tabel : in-memory tabellen kunnen gegevens zeer snel worden geladen, maar de gegevens moeten in het geheugen passen. Benchmarks tonen aan dat bulksgewijs laden van een tabel in het geheugen naar een tabel op schijf ongeveer 10 keer sneller is dan rechtstreeks bulksgewijs invoegen met behulp van één schrijver in de schijftabel met een identiteitskolom en een geclusterde index. Als u gebruik wilt maken van deze prestaties voor bulksgewijs invoegen, stelt u een kopieertaak in met behulp van Azure Data Factory waarmee gegevens uit de tabel in het geheugen naar de schijftabel worden gekopieerd.

Prestatie valkuilen vermijden

Het bulksgewijs invoegen van gegevens gaat veel sneller dan het laden van gegevens met enkele invoegingen, omdat de herhaalde overhead van het overdragen van de gegevens, het parseren van de invoeginstructie, het uitvoeren van de instructie en het uitgeven van een transactierecord wordt vermeden. In plaats daarvan wordt een efficiënter pad in de opslagengine gebruikt om de gegevens te streamen. De installatiekosten van dit pad zijn echter veel hoger dan één invoeginstructie in een tabel op basis van een schijf. Het break-evenpunt is meestal ongeveer 100 rijen, waarna bulksgewijs laden bijna altijd efficiënter is.

Als de snelheid van binnenkomende gebeurtenissen laag is, kunnen eenvoudig batchgrootten van minder dan 100 rijen worden gemaakt, waardoor bulksgewijs invoegen inefficiënt is en te veel schijfruimte wordt gebruikt. Als u deze beperking wilt omzeilen, kunt u een van de volgende acties uitvoeren:

Maak een in plaats van een trigger om een eenvoudige invoeging te gebruiken voor elke rij.
Gebruik een In-Memory tijdelijke tabel zoals beschreven in de vorige sectie.

Een ander scenario doet zich voor bij het schrijven naar een niet-geclusterde columnstore-index (NCCI), waarbij kleinere bulkinvoegingen te veel segmenten kunnen maken, waardoor de index kan vastlopen. In dit geval is het raadzaam om in plaats daarvan een geclusterde Columnstore-index te gebruiken.

Samenvatting

Kortom, met de functie voor gepartitioneerde uitvoer in Azure Stream Analytics voor SQL-uitvoer, wordt de parallelle uitvoering van uw taak afgestemd op een gepartitioneerde tabel in SQL Azure u aanzienlijke doorvoerverbeteringen zou moeten opleveren. Door gebruik te maken van Azure Data Factory voor het organiseren van gegevensverplaatsing van een In-Memory tabel naar tabellen op basis van schijven, kan de doorvoer orde worden gesorteerd. Indien mogelijk kan het verbeteren van de berichtdichtheid ook een belangrijke factor zijn bij het verbeteren van de algehele doorvoer.

Share via