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.

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. Den hanterar dynamiskt arbetsbelastningar med hjälp av maskininlärningsmodeller för att förutsäga resursbehoven för inkommande frågor samtidigt som informationslagrets tillgängliga beräkningskapacitet övervakas i realtid. Genom att spåra dessa och andra signaler i lagret kan IWM svara på ändringar i arbetsbelastningskrav.

Med den här dynamiska hanteringen kan IWM göra följande:

• Snabbt uppskalningsberäkning för att upprätthålla låg svarstid.
• Ange intagning av frågor till priser som ligger närmare maskinvarans begränsning.
• Snabbt nedskalning för att minimera kostnaderna när efterfrågan är låg.

När en fråga kommer till lagret förutsäger IWM kostnaden. 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 kön 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 beräkningsresurserna. Med serverlösa SQL-lager kan ny beräkning läggas till snabbt. 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.

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.

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.