Delen via

Optimaliseren voor hoge gelijktijdigheid met Azure Data Explorer

  • Artikel

Er zijn zeer gelijktijdige toepassingen nodig in scenario's met een groot aantal gebruikers, waarbij de toepassing tegelijkertijd veel aanvragen met lage latentie en hoge doorvoer verwerkt.

Gebruiksvoorbeelden omvatten grootschalige bewakings- en waarschuwingsdashboards. Voorbeelden hiervan zijn Microsoft-producten en -services, zoals Azure Monitor, Azure Time Series Insights en Playfab. Al deze services maken gebruik van Azure Data Explorer voor het leveren van workloads met hoge gelijktijdigheid. Azure Data Explorer is een snelle, volledig beheerde big data-analyseservice voor realtime analyses van grote hoeveelheden gegevensstreaming van toepassingen, websites, IoT-apparaten en meer.

Notitie

Het werkelijke aantal query's dat gelijktijdig op een cluster kan worden uitgevoerd, is afhankelijk van factoren zoals cluster-SKU, gegevensvolumes, querycomplexiteit en gebruikspatronen.

Als u toepassingen met hoge gelijktijdigheid wilt instellen, ontwerpt u de back-endarchitectuur als volgt:

Dit artikel bevat aanbevelingen voor elk van de voorgaande onderwerpen die u kunt implementeren om een hoge gelijktijdigheid op een optimale, kosteneffectieve manier te bereiken. Deze functies kunnen alleen of in combinatie worden gebruikt.

Gegevens optimaliseren

Voor een hoge gelijktijdigheid moeten query's de minst mogelijke hoeveelheid CPU-resources verbruiken. U kunt een of meer van de volgende methoden gebruiken:

Aanbevolen procedures voor het ontwerpen van tabelschema's gebruiken

Gebruik de volgende ontwerpsuggesties voor tabelschema's om de gebruikte CPU-resources te minimaliseren:

  • Id-kolommen moeten worden gedefinieerd als tekenreeksgegevenstypen, ongeacht of de waarden numeriek zijn. Indexering voor tekenreekskolommen is geavanceerder dan voor numerieke kolommen en biedt betere filterprestaties.
  • Het gegevenstype van de kolom optimaal afstemmen op de werkelijke gegevens die in deze kolommen zijn opgeslagen. Sla bijvoorbeeld geen datum/tijd-waarden op in een tekenreekskolom.
  • Vermijd een grote sparse tabel met veel kolommen en gebruik dynamische kolommen om sparse-eigenschappen op te slaan.
  • Sla veelgebruikte eigenschappen op in hun eigen kolom met een niet-dynamisch gegevenstype.
  • Gegevens denormaliseren om joins te voorkomen die relatief grote CPU-resources vragen.

Partitiegegevens

Gegevens worden opgeslagen in de vorm van gebieden (gegevensshards) en worden standaard gepartitioneerd op opnametijd. U kunt het partitioneringsbeleid gebruiken om de gebieden opnieuw te partitioneren op basis van één tekenreekskolom of één datum/tijd-kolom in een achtergrondproces. Partitionering kan aanzienlijke prestatieverbeteringen opleveren wanneer de meeste query's partitiesleutels gebruiken om te filteren, aggregeren of beide.

Notitie

Het partitioneringsproces zelf maakt gebruik van CPU-resources. De CPU-reductie tijdens de querytijd moet echter opwegen tegen de CPU die wordt gebruikt voor partitionering.

Uw gegevens vooraf aggregeren met gerealiseerde weergaven

Voeg uw gegevens vooraf samen om de CPU-resources tijdens de query aanzienlijk te verminderen. Voorbeelden van scenario's zijn het samenvatten van gegevenspunten over een verminderd aantal tijdslocaties, het bijhouden van de meest recente record van een bepaalde record of het ontdubbelen van de gegevensset. Gebruik gerealiseerde weergaven voor een eenvoudig te configureren geaggregeerde weergave van brontabellen. Deze functie vereenvoudigt het maken en onderhouden van deze samengevoegde weergaven.

Notitie

Het aggregatieproces op de achtergrond maakt gebruik van CPU-resources. De CPU-reductie tijdens de querytijd moet echter opwegen tegen het CPU-verbruik voor aggregatie.

Het cachebeleid configureren

Configureer het cachebeleid zodat query's worden uitgevoerd op gegevens die zijn opgeslagen in de dynamische opslag, ook wel de schijfcache genoemd. Voer alleen beperkte, zorgvuldig ontworpen scenario's uit op de koude opslag of externe tabellen.

Een leader-follower-architectuurpatroon instellen

De volgdatabase is een functie die een database of een set tabellen volgt in een database van een ander cluster in dezelfde regio. Deze functie wordt weergegeven via Azure Data Share, Azure Resource Manager API's en een set clusteropdrachten.

Gebruik het patroon leader-follower om rekenresources in te stellen voor verschillende workloads. Stel bijvoorbeeld een cluster in voor opname, een cluster voor het uitvoeren van query's op dashboards of toepassingen of een cluster dat de data science-workloads bedient. Elke workload heeft in dit geval toegewezen rekenresources die onafhankelijk kunnen worden geschaald, en verschillende caching- en beveiligingsconfiguraties. Alle clusters gebruiken dezelfde gegevens, waarbij de leider de gegevens schrijft en de volgers deze gebruiken in een alleen-lezenmodus.

Notitie

Volgdatabases hebben een vertraging van de leider, meestal van een paar seconden. Als uw oplossing de meest recente gegevens zonder latentie vereist, kan deze oplossing nuttig zijn. Gebruik een weergave op het volgercluster die de gegevens van de leider en de volger samenvoegt en de meest recente gegevens van de leider en de rest van de gegevens van de volger opvraagt.

Als u de prestaties van query's op het volgcluster wilt verbeteren, kunt u de configuratie vooraf inschakelen. Gebruik deze configuratie zorgvuldig, omdat dit van invloed kan zijn op de nieuwheid van gegevens in de volgdatabase.

Query's optimaliseren

Gebruik de volgende methoden om uw query's te optimaliseren voor hoge gelijktijdigheid.

Volg best practices voor query's zodat uw query's zo efficiënt mogelijk zijn.

Een cache met queryresultaten gebruiken

Wanneer meer dan één gebruiker hetzelfde dashboard op een vergelijkbaar moment laadt, kunnen het dashboard aan de tweede en volgende gebruikers worden aangeboden vanuit de cache. Deze installatie biedt hoge prestaties met bijna geen CPU-gebruik. Gebruik de cachefunctie voor queryresultaten en verzend de cacheconfiguratie van queryresultaten met de query met behulp van de set -instructie.

Grafana bevat een configuratie-instelling voor de cache met queryresultaten op het niveau van de gegevensbron, zodat alle dashboards deze instelling standaard gebruiken en de query niet hoeven te wijzigen.

Queryconsistentie configureren

De standaardmodus voor queryconsistentie is sterk. In deze modus beheert een beheerknooppunt metagegevens en opname voor het cluster, evenals queryplanning en delegering van de uitvoering naar andere knooppunten.

In toepassingen met hoge gelijktijdigheid kan het beheer van query's ertoe leiden dat het CPU-gebruik van het beheerknooppunt hoog is, terwijl andere knooppunten minder druk zijn. Dit kan een knelpunt veroorzaken waarbij het aantal gelijktijdige query's niet kan toenemen. Dit is echter mogelijk niet duidelijk in het CPU-rapport van het cluster (Azure Portal > {your_cluster} > Metrics CPU Metrics>) waarin het gemiddelde CPU-gebruik voor het cluster wordt weergegeven.

Voor dit scenario raden we u aan de modus voor zwakke consistentie te gebruiken. In deze modus kunnen meer knooppunten query's beheren, waardoor het aantal gelijktijdige query's horizontaal kan worden geschaald. Knooppunten in deze modus vernieuwen periodiek hun kopie van metagegevens en nieuw opgenomen gegevens, wat leidt tot een latentie van doorgaans minder dan een minuut wanneer de gegevens worden gesynchroniseerd. Deze korte latentie heeft echter de voorkeur boven de knelpuntsituatie die zich kan voordoen bij het gebruik van de modus voor sterke consistentie.

U kunt de consistentiemodus instellen in het consistentiebeleid voor query's van een workloadgroep, in de eigenschappen van de clientaanvraag of in de configuratie van de Grafana-gegevensbron.

Clusterbeleid instellen

Het aantal gelijktijdige aanvragen wordt standaard beperkt en beheerd door het beleid Aanvraagfrequentielimiet , zodat het cluster niet overbelast raakt. U kunt dit beleid aanpassen voor situaties met hoge gelijktijdigheid. Dit beleid moet pas worden aangepast na grondige tests, bij voorkeur op productieachtige gebruikspatronen en gegevenssets. Testen zorgt ervoor dat het cluster de gewijzigde waarde kan ondersteunen. Deze limiet kan worden geconfigureerd op basis van de behoeften van de toepassing.

Azure Data Explorer-clusters bewaken

Door de status van uw clusterresources te bewaken, kunt u een optimalisatieplan maken met behulp van de functies die in de voorgaande secties worden voorgesteld. Azure Monitor voor Azure Data Explorer biedt een uitgebreid overzicht van de prestaties, bewerkingen, gebruik en fouten van uw cluster. Krijg inzicht in de prestaties van de query's, gelijktijdige query's, beperkte query's en verschillende andere metrische gegevens door het tabblad Inzichten (preview) te selecteren onder de sectie Bewaking van het Azure Data Explorer-cluster in de Azure Portal.

Zie Azure Monitor voor Azure Data Explorer voor informatie over het bewaken van clusters. Zie Metrische gegevens van Azure Data Explorer voor meer informatie over de afzonderlijke metrische gegevens.