Fabric-rajoittamiskäytäntö

Rajoittamista tapahtuu, kun vuokraajan kapasiteetti kuluttaa enemmän kapasiteettiresursseja kuin se on ostanut. Jos rajoittamista on liikaa, loppukäyttäjän käyttökokemus voi heikentyä. Fabric-vuokraaja voi luoda useita kapasiteetteja ja määrittää työtiloja tiettyyn kapasiteettiin laskutusta ja koon muuttamista varten.

Rajoittamista käytetään kapasiteettitasolla, mikä tarkoittaa sitä, että vaikka yhden kapasiteetin tai työtilajoukon suorituskyky saattaa heikentyä ylikuormituksen vuoksi, muut kapasiteetit voivat jatkua normaalisti. Tapauksissa, joissa OneLake-artefaktin kaltaiset ominaisuudet tuotetaan yhdessä kapasiteetissa ja joita toinen käyttää, kulutuskapasiteetin rajoittava tila määrittää, rajoitetaanko artefaktin kutsuja.

Suorituskyvyn ja luotettavuuden välinen tasapaino

Fabric on suunniteltu tarjoamaan salamannopeaa suorituskykyä asiakkailleen mahdollistamalla sille enemmän CU (Capacity Units) -resursseja kuin kapasiteetille varataan. Tehtävät, joiden suorittaminen muissa ympäristöissä voi kestää useita minuutteja, voidaan suorittaa vain parissa sekunnissa Fabricissa. Jotta käyttäjien rankaisemista ei rangaista toiminnan kuormituksen kasvaessa, Fabric tasoittaa tai keskiarvon toiminnon CU-käytölle vähintään 5 minuutin ajan ja vielä kauemmin suuren CU:n mutta lyhyen suorituksenaikaisille pyynnöille. Tämä varmistaa, että voit nauttia johdonmukaisesti nopeasta suorituskyvystä ilman rajoittamista.

Taustatoiminnoissa, joilla on pitkäkestoinen suoritusaika ja jotka kuluttavat raskaita CU-kuormituksia, Fabric tasoittaa CU-käyttöään 24 tunnin aikana. Tasaaminen poistaa tietojenkäsittelytutkijoiden ja tietokantojen järjestelmänvalvojien tarpeen käyttää aikaa työaikataulujen luomiseen CU-kuormituksen jakamiseksi koko päivän ajan, jotta tilit eivät jäätyisi. 24 tunnin CU:n tasoittamisen ansiosta ajoitetut työt voidaan suorittaa samanaikaisesti aiheuttamatta piikkejä milloin tahansa päivän aikana, ja voit nauttia johdonmukaisesti nopeasta suorituskyvystä tuhlaamatta aikaa työaikataulujen hallintaan.

Lennonsijainnin toiminta ei ole rajoittanut

Kun kapasiteetti siirtyy rajoittamattomaan tilaan, se vaikuttaa vain toimintoihin, joita pyydetään sen jälkeen, kun kapasiteetti on alkanut rajoittaa. Kaikki toiminnot, mukaan lukien pitkäkestoiset toiminnot, jotka lähetettiin ennen rajoittamisen alkamista, saadaan suorittaa loppuun. Tällä tavalla voit varmistaa, että toiminnot on suoritettu myös CU-kaavojen aikana.

Rajoitetaan käynnistimiä ja rajoitetaan vaiheita

Tasoituksen jälkeen jotkin tilit saattavat edelleen kohdata piikkiä CU:n käytössä raportointihuippuina. Järjestelmänvalvojat voivat näiden piikkien hallinnan helpottamiseksi määrittää sähköposti-ilmoituksia, kun kapasiteetti kuluttaa 100 % sen valmistetystä CU:sta. Tämä malli osoittaa, että kapasiteetti voi hyötyä kuormituksen tasaamisestä, ja järjestelmänvalvojan tulisi harkita varastointiyksikön koon kasvattamista. On tärkeää huomata, että F-varastointiyksiköiden kohdalla voit suurentaa ja pienentää niitä manuaalisesti milloin tahansa järjestelmänvalvojan asetuksissa. Vaikka kapasiteetti toimisi täysin CU-potentiaalin mukaan, Fabric ei kuitenkaan käytä rajoittamista. Näin voit varmistaa, että käyttäjillä on jatkuvasti nopea suorituskyky ilman häiriöitä.

Rajoittamisen ensimmäinen vaihe alkaa, kun kapasiteetti on kuluttanut kaikki käytettävissä olevat CU-resurssinsa seuraavien 10 minuutin ajan. Jos esimerkiksi ostit 10 CU-yksikköä ja kulutit sitten 50 yksikköä minuutissa, luot 40 yksikön kantomatkan minuutissa. Kahden ja puolen minuutin jälkeen olisit kerännyt 100 yksikköä eteenpäin, jotka on lainattu tulevista ikkunoista. Tässä vaiheessa, kun kapasiteetti on käyttänyt kaiken kapasiteetin jo seuraavien 10 minuutin ajan, Fabric aloittaa ensimmäisen rajoittamistasonsa, ja kaikki uudet vuorovaikutteiset toiminnot viivästyvät 20 sekunnin kuluttua lähettämisestä. Jos kuljetuksen suorittaminen saavuttaa täyden tunnin, vuorovaikutteiset pyynnöt hylätään, mutta ajoitetut taustatoiminnot jatkavat suorittamistaan. Jos kapasiteettiin kertyy täydet 24 tuntia kuljetusta eteenpäin, koko kapasiteetti jäädytetään, kunnes kantolaikeri maksetaan.

Tuleva tasattu kulutus

Muistiinpano

Microsoft yrittää parantaa asiakkaan joustavuutta palvelun käyttämisessä ja tasapainottaa samalla tarvetta hallita asiakkaan kapasiteetin käyttöä. Tästä syystä Microsoft saattaa muuttaa tai päivittää Fabric-rajoittamiskäytäntöä.

Käyttö Käytännön rajoitukset Käyttöympäristökäytännön käyttökokemuksen vaikutus
Käyttö <= 10 minuuttia Ylityssuojaus Työt voivat käyttää 10 minuuttia tulevaa kapasiteetin käyttöä ilman rajoittamista.
Käyttö 10 minuuttia <<= 60 minuuttia Vuorovaikutteinen viive Käyttäjän pyytämät vuorovaikutteiset työt viivästyvät 20 sekuntia lähettämisen yhteydessä.
Käyttö <60 minuuttia < = 24 tuntia Vuorovaikutteinen hylkääminen Käyttäjän pyytämät vuorovaikutteiset työt hylätään.
Käyttö > 24 tuntia Taustan hylkääminen Kaikki pyynnöt hylätään.

Siirtokapasiteetin käytön vähentäminen eteenpäin

Aina, kun kapasiteetilla on käyttämättömyyskapasiteettia, järjestelmä maksaa kuljetuksen eteenpäin vievät tasot.

Jos sinulla on 100 CU minuuttia ja kuljetus eteenpäin 200 CU minuuttia, eikä sinulla ole mitään toimintoja käynnissä, kestää kaksi minuuttia, että maksat kuljetuksen eteenpäin. Tässä esimerkissä järjestelmä ei ole rajoittanut, sillä kantomatka on 2 minuuttia. Rajoituksen viiveet eivät ala, ennen kuin se on 10 minuutin kantomatkan päässä.

Jos haluat maksaa eteenpäin nopeammin, voit kasvattaa varastointiyksikön kokoa tilapäisesti, jotta saat lisää käyttämättömyyskapasiteettia, jota sovelletaan kuljetukseen eteenpäin.

Rajoitustoiminta on fabric-kohtainen

Vaikka useimmat Fabric-tuotteet noudattavat aiemmin mainittuja rajoittamissääntöjä, siihen liittyy joitakin poikkeuksia.

Esimerkiksi Fabric-tapahtumavirroissa on useita toimintoja, joita voidaan suorittaa vuosia niiden käynnistämisen jälkeen. Uusien tapahtumavirtatoimintojen rajoittaminen ei olisi järkevää, joten sen sijaan suoratoiston avaamiseen varatun CU:n määrä pienenee, kunnes kapasiteetti on taas hyvässä kunnossa.

Toinen poikkeus on reaaliaikainen analytiikka, joka ei olisi reaaliaikainen, jos toiminnot viivästyivät 20 sekunnilla. Tämän seurauksena reaaliaikainen analytiikka jättää huomiotta 20 sekunnin viiveillä 10 minuutin viiveillä ja odottaa hylkäämisvaiheeseen 60 minuutin välein rajoittamisen aloittamiseksi. Tällä tavalla varmistetaan, että käyttäjät voivat edelleenkin nauttia reaaliaikasesta suorituskyvystä myös silloin, kun kysyntä on suurta.

Vastaavasti lähes kaikki Warehouse-luokan toiminnot raportoidaan taustana, jotta voit hyödyntää toimintojen 24 tunnin tasoitusta joustavimpien käyttötapojen mahdollistamiseksi. Luokittelemalla kaiken tietovarastoinnin taustaksi estät CU:n käytön huiput käynnistämästä rajoittamista liian nopeasti. Jotkin pyynnöt voivat aiheuttaa eri tavalla rajoittavia operaatioita. Tämä voi tehdä taustatoiminnosta rajoittavan toiminnon vuorovaikutteisena toimintona.

Vuorovaikutteiset ja taustaluokitukset rajoittamista ja tasoittamista varten

Jotkin järjestelmänvalvojat saattavat huomata, että toiminnot luokitellaan joskus vuorovaikutteisiksi ja tasoitetaan taustaksi tai päinvastoin. Tämä ero johtuu siitä, että Fabricin rajoittamisjärjestelmien on sovellettava rajoittamissääntöjä ennen pyynnön suorittamista. Tasaantumista esiintyy sen jälkeen, kun työ on alkanut ja cu-kulutusta voidaan mitata.

Rajoittamisjärjestelmät pyrkivät luokittelemaan toiminnot tarkasti lähettämisen yhteydessä, mutta joskus toiminnon luokitus voi muuttua rajoittamisen jälkeen. Kun toiminto alkaa suorittaa, tarkempia tietoja pyynnöstä tulee saataville. Moniselitteisessä tilanteessa rajoittamisjärjestelmät yrittävät tehdä virheen toimintojen luokittelun taustaksi, mikä on käyttäjän edun mukaista.

Hylättyjen toimintojen seuraaminen

Microsoft Fabric Capacity Metrics -sovelluksen porautumisen avulla järjestelmänvalvojat näkevät toiminnot, jotka hylättiin rajoittamistapahtuman aikana. Näistä toiminnoista on rajoitettua tietoa, koska niiden ei sallittu käynnistyä. Järjestelmänvalvoja voi nähdä tuotteen, käyttäjän, toimintotunnuksen ja pyynnön lähettämisen ajan. Loppukäyttäjät saavat virheviestin, kun pyyntö hylätään ja häntä pyydetään yrittämään myöhemmin uudelleen.