Delen via

Optimaliseren voor hoge gelijktijdigheid met Azure Data Explorer

Zeer gelijktijdige toepassingen zijn nodig in scenario's met een grote gebruikersbasis, waarbij de toepassing tegelijkertijd veel aanvragen verwerkt met lage latentie en hoge doorvoer.

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 op grote hoeveelheden gegevensstreaming vanuit toepassingen, websites, IoT-apparaten en meer.

Opmerking

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

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

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

Gegevens optimaliseren

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

Best practices voor tabelschemaontwerp 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.
  • Koppel het gegevenstype van de kolom optimaal aan 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.
  • Denormaliseer gegevens om joins te voorkomen die relatief grote CPU-resources vragen.

Partitiegegevens

Gegevens worden opgeslagen in de vorm van extents (data shards) en worden standaard gepartitioneerd naar 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 bieden wanneer de meeste query's partitiesleutels gebruiken om te filteren, aggregeren of beide.

Opmerking

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

Uw gegevens vooraf aggregeren om CPU-resources aanzienlijk te verminderen tijdens de querytijd. Voorbeeldscenario's omvatten het samenvatten van gegevenspunten in een beperkt aantal tijdvakken, het bijhouden van het meest recente record van een bepaalde gegevensset, of het dedupliceren van de dataset. Gebruik gerealiseerde weergaven voor een eenvoudig te configureren geaggregeerde weergave over brontabellen. Deze functie vereenvoudigt het maken en onderhouden van deze samengevoegde weergaven.

Opmerking

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 voor de koude opslag of externe tabellen.

Een patroon voor een leidervolgerarchitectuur instellen

De volgdatabase is een functie die een database of een set tabellen in een database volgt vanuit een ander cluster dat zich in dezelfde regio bevindt. 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 opvragen of bedienen van dashboards of toepassingen en een cluster dat de data science-workloads bedient. Elke workload in dit geval heeft toegewezen rekenresources die onafhankelijk kunnen worden geschaald en verschillende cache- en beveiligingsconfiguraties. Alle clusters gebruiken dezelfde gegevens, waarbij de leider de gegevens schrijft en de volgers deze gebruiken in een alleen-lezenmodus.

Opmerking

Volgdatabases lopen meestal enkele seconden achter op de leider. Als uw oplossing de meest recente gegevens zonder latentie vereist, kan deze oplossing nuttig zijn. Gebruik een weergave op het volgcluster dat 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 van vooraf gedefinieerde gebieden inschakelen. Gebruik deze configuratie zorgvuldig, omdat deze van invloed kan zijn op de versheid 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 je query's zo efficiënt mogelijk zijn.

Een cache voor queryresultaten gebruiken

Wanneer meer dan één gebruiker hetzelfde dashboard tegelijkertijd laadt, kan het dashboard aan de tweede en volgende gebruikers worden geleverd 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 gegevensbronniveau, dus alle dashboards gebruiken deze instelling standaard en hoeven de query niet te wijzigen.

Queryconsistentie configureren

De standaardinstelling voor queryconsistentie is sterk. In deze modus beheert een beheerknooppunt metagegevens en opname voor het cluster, evenals het plannen en delegeren van uitvoering aan 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 groeien. Dit is echter mogelijk niet zichtbaar in het CPU-rapport van het cluster (Azure portal > {your_cluster} > Metrics > CPU Metric) waarin het gemiddelde CPU-gebruik voor het cluster wordt weergegeven.

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

U kunt de consistentiemodus instellen in een consistentiebeleid voor workloadgroepen, 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 voor aanvraagsnelheidslimiet , zodat het cluster niet overbelast raakt. U kunt dit beleid wijzigen voor situaties met een hoge mate van gelijktijdigheid. Dit beleid moet pas worden aangepast na strenge tests, bij voorkeur op productieachtige gebruikspatronen en gegevenssets. Testen bevestigen dat het cluster de gewijzigde waarde kan handhaven. Deze limiet kan worden geconfigureerd op basis van toepassingsbehoeften.

Azure Data Explorer-clusters bewaken

Door de status van uw clusterbronnen 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 uitgebreide weergave 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 Azure Portal.

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

  • Last updated on