Storleks-, skalnings- och köbeteende för SQL-lager

I den här artikeln beskrivs hur SQL-informationslagrens storlek, köer och autoskalning fungerar.

Ändra storlek på ett serverlöst SQL-lager

Börja alltid med en större t-shirtstorlek för ditt serverlösa SQL-lager än du tror att du behöver och ändra storlek när du testar. Börja inte med en liten t-shirtstorlek för ditt serverlösa SQL-lager och gå upp. I allmänhet börjar du med ett enda serverlöst SQL-lager och förlitar dig på att Azure Databricks har rätt storlek med serverlösa kluster, prioriterar arbetsbelastningar och snabba dataläsningar. Se Serverlös autoskalning och frågeköer.

• Så här minskar du frågefördröjningen för ett visst serverlöst SQL-lager:
  • Om frågor spills till disk ökar du t-shirtstorleken.
  • Om frågorna är mycket parallella ökar du t-shirtstorleken.
  • Om du kör flera frågor åt gången lägger du till fler kluster för automatisk skalning.
• För att minska kostnaderna kan du försöka att avgå i t-shirtstorlek utan att spilla till disken eller avsevärt öka svarstiden.
• Använd följande verktyg för att få rätt storlek på ditt serverlösa SQL-lager:
  • Övervakningssida: titta på det högsta antalet frågor. Om den högsta köen vanligtvis är högre än en lägger du till kluster. Det maximala antalet frågor i en kö för alla SQL-lagertyper är 1 000. Se Övervaka ett SQL-lager.
  • Frågehistorik. Se Frågehistorik.
  • Frågeprofiler (leta efter byte som spillts till disken över 1). Se Frågeprofil.

Kommentar

För serverlösa SQL-lager kan klusterstorlekarna i vissa fall använda andra instanstyper än de som anges i dokumentationen för pro- och klassiska SQL-lager för en motsvarande klusterstorlek. I allmänhet liknar förhållandet mellan pris och prestanda för klusterstorlekar för serverlösa SQL-lager samma som för pro- och klassiska SQL-lager.

Serverlös autoskalning och frågeköer

Intelligent Workload Management (IWM) är en uppsättning funktioner som förbättrar möjligheten för serverlösa SQL-lager att bearbeta ett stort antal frågor snabbt och kostnadseffektivt. Med hjälp av AI-baserade förutsägelsefunktioner för att analysera inkommande frågor och fastställa den snabbaste och effektivare (förutsägande I/O) fungerar IWM för att säkerställa att arbetsbelastningarna snabbt har rätt mängd resurser. Den viktigaste skillnaden ligger i AI-funktionerna i Databricks SQL för att svara dynamiskt på arbetsbelastningskrav i stället för att använda statiska tröskelvärden.

Den här svarstiden säkerställer:

• Snabb uppskalning för att hämta mer beräkning när det behövs för att upprätthålla låg svarstid.
• Frågeintagning närmare maskinvarubegränsningen.
• Snabb nedskalning för att minimera kostnaderna när efterfrågan är låg, vilket ger konsekventa prestanda med optimerade kostnader och resurser.

När en fråga kommer till lagret förutsäger IWM kostnaden för frågan. Samtidigt övervakar IWM informationslagrets tillgängliga beräkningskapacitet i realtid. Med hjälp av maskininlärningsmodeller förutsäger IWM sedan om den inkommande frågan har den nödvändiga beräkningen tillgänglig för den befintliga beräkningen. Om den inte har den beräkning som behövs läggs frågan till i kön. Om den har den beräkning som behövs börjar frågan köras omedelbart.

IWM övervakar att kön övervakas ungefär var 10:e sekund. Om kön inte minskar tillräckligt snabbt startar automatisk skalning in för att snabbt skaffa mer beräkning. När ny kapacitet har lagts till tas köade frågor upp till de nya klustren. Med serverlösa SQL-lager kan nya kluster läggas till snabbt och fler än ett kluster i taget kan skapas. Det maximala antalet frågor i en kö för alla SQL-lagertyper är 1 000.

Klusterstorlekar för pro- och klassiska SQL-lager

Tabellen i det här avsnittet mappar SQL-lagerklusterstorlekar till Azure Databricks-klusterdrivrutinsstorlek och antal arbetare. Drivrutinsstorleken gäller endast för pro- och klassiska SQL-lager.

Klusterstorlek	Instanstyp för drivrutin (gäller endast för pro- och klassiska SQL-lager)	Antal arbetare
2X-Small	Standard_E8ds_v4	1 x Standard_E8ds_v4
X-Small	Standard_E8ds_v4	2 x Standard_E8ds_v4
Litet	Standard_E16ds_v4	4 x Standard_E8ds_v4
Medium	Standard_E32ds_v4	8 x Standard_E8ds_v4
Stort	Standard_E32ds_v4	16 x Standard_E8ds_v4
X-Large	Standard_E64ds_v4	32 x Standard_E8ds_v4
2X-stor	Standard_E64ds_v4	64 x Standard_E8ds_v4
3X-stor	Standard_E64ds_v4	128 x Standard_E8ds_v4
4X-stor	Standard_E64ds_v4	256 x Standard_E8ds_v4

Instansstorleken för alla arbetare är Standard_E8ds_v4.

Varje drivrutin och arbetare har åtta 128 GB Standard LRS-hanterade diskar anslutna. Anslutna diskar debiteras varje timme.

Obligatorisk Azure vCPU-kvot för klassiska och pro SQL-lager

Om du vill starta ett klassiskt eller pro SQL-lager måste du ha tillräcklig Azure vCPU-kvot för Standard_E8ds_v4 instanser i ditt Azure-konto. Använd följande riktlinjer för att fastställa vilken vCPU-kvot som krävs:

• Om du bara har ett eller två SQL-lager kontrollerar du att du har 8 Tillgängliga Azure vCPU:er för varje kärna i klustret. Detta säkerställer att du har tillräcklig Azure vCPU för att ta hänsyn till ometablering av ditt lager som sker ungefär var 24:e timme. Om dina SQL-lager använder automatisk skalning eller belastningsutjämning för flera kluster kan du behöva öka multiplikatorn.
• När antalet SQL-lager ökar kan du tillåta mellan 4 och 8 Azure vCPU för varje kärna i klustret. Databricks rekommenderar att du börjar med ett större antal och övervakning för stabilitet.
• Azure vCPU:er som används av SQL-lager är utöver Azure vCPU:er som används av kluster som används av Datavetenskap & Engineering eller av icke-Databricks-arbetsbelastningar.

Information om hur du begär ytterligare Azure vCPU-kvot finns i Standardkvot: Öka gränserna per VM-serie i Azure-dokumentationen.

Kommentar

Informationen i den här tabellen kan variera beroende på produkt- eller regionstillgänglighet och arbetsytetyp.

Köning och automatisk skalning för pro- och klassiska SQL-lager

Azure Databricks begränsar antalet frågor i ett kluster som tilldelats till ett SQL-lager baserat på kostnaden för att beräkna deras resultat. Uppskalning av kluster per lager baseras på frågedataflöde, antalet inkommande frågor och köstorleken. Azure Databricks rekommenderar ett kluster för varje 10 samtidiga frågor. Det maximala antalet frågor i en kö för alla SQL-lagertyper är 1 000.

Azure Databricks lägger till kluster baserat på den tid det tar att bearbeta alla frågor som körs, alla köade frågor och de inkommande frågor som förväntas under de kommande två minuterna.

• Om mindre än 2 minuter ska du inte skala upp.
• Om 2 till 6 minuter lägger du till ett kluster.
• Om 6 till 12 minuter lägger du till 2 kluster.
• Om 12 till 22 minuter lägger du till 3 kluster.

Annars lägger Azure Databricks till tre kluster plus ett kluster för varje ytterligare 15 minuter av förväntad frågebelastning.

Dessutom skalas ett lager alltid upp om en fråga väntar i 5 minuter i kön.

Om belastningen är låg i 15 minuter skalar Azure Databricks ned SQL-lagret. Det behåller tillräckligt med kluster för att hantera den högsta belastningen under de senaste 15 minuterna. Om den högsta belastningen till exempel var 25 samtidiga frågor behåller Azure Databricks tre kluster.

Frågeköer för pro- och klassiska SQL-lager

Azure Databricks köar frågor när alla kluster som tilldelats till lagret kör frågor med full kapacitet eller när lagret är i STARTING tillståndet. Det maximala antalet frågor i en kö för alla SQL-lagertyper är 1 000.

Metadatafrågor (till exempel DESCRIBE <table>) och tillstånds modifierande frågor (till exempel SET) placeras aldrig i kö, såvida inte lagret är i STARTING tillståndet.