SQL-lagertyper

Databricks SQL stöder följande SQL-lagertyper:

• Utan server
• Pro
• Klassisk

Varje SQL-lagertyp har olika prestandafunktioner. I följande tabell visas de prestandafunktioner som stöds av varje SQL-lagertyp.

I följande lista beskrivs varje prestandafunktion:

• Photon: Den inbyggda vektoriserade frågemotorn på Databricks. Det gör dina befintliga SQL- och DataFrame API-anrop snabbare och minskar din totala kostnad per arbetsbelastning.

• Förutsägande I/O: En uppsättning funktioner för att påskynda selektiva genomsökningsåtgärder i SQL-frågor. Förutsägande I/O kan ge en mängd olika hastigheter.

• Intelligent arbetsbelastningshantering (IWM): En uppsättning funktioner som förbättrar Databricks SQL Serverless förmåga att bearbeta ett stort antal frågor snabbt och kostnadseffektivt. Med hjälp av AI-baserade förutsägelse- och dynamiska hanteringstekniker arbetar IWM för att se till att arbetsbelastningarna snabbt får 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.

  Kommentar

  Priser för varje informationslagertyp och en detaljerad funktionsjämförelse finns i Databricks SQL. Mer information om de senaste Databricks SQL-funktionerna finns i Viktig information om Databricks SQL.

Prestandaskillnader mellan SQL-lagertyper

Varje SQL-lagertyp har olika prestandaegenskaper.

Serverlösa SQL-lager

Med hjälp av serverlös Arkitektur i Azure Databricks stöder ett serverlöst SQL-lager alla prestandafunktioner i Databricks SQL. Med ett serverlöst SQL-lager och dess prestandafunktioner får du:

• Snabb starttid (vanligtvis mellan 2 och 6 sekunder).
• 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åga intagning närmare maskinvarans begränsning snarare än den virtuella datorn.
• Snabb nedskalning för att minimera kostnaderna när efterfrågan är låg, vilket ger konsekventa prestanda med optimerade kostnader och resurser.

För bästa startprestanda, effektivaste I/O, smartare hantering av frågebehov som varierar kraftigt över tid och snabb autoskalning när frågeköer inträffar väljer du ett serverlöst SQL-lager. Se Serverlös autoskalning och frågeköer.

Ett serverlöst SQL-lager fungerar bra med dessa typer av arbetsbelastningar:

• ETL
• Affärsintelligens
• Explorativ analys

Pro SQL-lager

Ett pro SQL-lager har stöd för photon och förutsägande I/O, men stöder inte intelligent arbetsbelastningshantering. Med ett pro SQL-lager (till skillnad från ett serverlöst SQL-lager) finns beräkningslagret i ditt Azure-prenumerationskonto i stället för i ditt Azure Databricks-konto. Därför stöder ett pro SQL-lager inte intelligent arbetsbelastningshantering, vilket gör det mindre responsivt för frågebehov som varierar kraftigt över tid och som inte kan skalas automatiskt lika snabbt som ett serverlöst SQL-lager. Ett pro SQL-lager tar flera minuter att starta (vanligtvis cirka 4 minuter) och skalas upp och ned med mindre svarstider än ett serverlöst SQL-lager. Se Köa och autoskalning för pro- och klassiska SQL-lager.

Använd ett pro SQL-lager när:

• Serverlösa SQL-lager är inte tillgängliga i en region.
• Du har anpassade definierade nätverk och vill ansluta till databaser i nätverket i molnet eller lokalt för federation eller en hybridarkitektur. Du kan till exempel använda ett pro SQL-lager om du vill placera andra tjänster i nätverket, till exempel en händelsebuss eller databaser, eller om du vill ansluta nätverket till ditt lokala nätverk.

Klassiska SQL-lager

Ett klassiskt SQL-lager stöder Photon, men stöder inte förutsägande I/O eller intelligent arbetsbelastningshantering. Med ett klassiskt SQL-lager (till skillnad från ett serverlöst SQL-lager) finns beräkningslagret i ditt Azure-prenumerationskonto i stället för i ditt Azure Databricks-konto. Utan stöd för förutsägande I/O eller Intelligent arbetsbelastningshantering ger ett klassiskt SQL-lager endast prestanda på ingångsnivå och mindre prestanda än antingen ett serverlöst eller ett pro SQL-lager. Ett klassiskt SQL-lager tar också flera minuter att starta (vanligtvis cirka 4 minuter) och skalas upp och ned med mindre svarstider än ett serverlöst SQL-lager. Se Köa och autoskalning för pro- och klassiska SQL-lager.

Använd ett klassiskt SQL-lager för att köra interaktiva frågor för datautforskning med prestanda på ingångsnivå och Databricks SQL-funktioner.

Vilka är standardinställningarna för lagertyp?

För arbetsytor i regioner som stöder serverlösa SQL-lager och uppfyller kraven:

• Med hjälp av användargränssnittet är sql warehouse-standardtypen serverlös.
• Med HJÄLP av SQL Warehouses-API :et med standardparametrar är standardtypen för SQL-lager klassisk. Om du vill använda serverlös anger du parametern enable_serverless_compute till true och anger warehouse_type även till pro. Om den här arbetsytan använde SQL Warehouses-API:et för att skapa ett lager mellan 1 november 2022 och 19 maj 2023 och uppfyller kraven för serverlösa SQL-lager, förblir standardvärdet inställt på true. För att undvika tvetydighet, särskilt för organisationer med många arbetsytor, rekommenderar Databricks att du alltid anger det här fältet.
• Om arbetsytan använder ett äldre externt Hive-metaarkiv stöds inte serverlösa SQL-lager. Sql Warehouse-standardtypen är samma som om serverlös beräkning inaktiverades, vilket är proffs i användargränssnittet och klassiskt med hjälp av API:et. Kontakta även ditt Azure Databricks-kontoteam om du vill veta mer om Unity Catalog eller andra alternativ.

För arbetsytor som inte stöder serverlösa SQL-lager:

• Med hjälp av användargränssnittet är standardtypen för SQL-lager pro.
• Med HJÄLP av SQL Warehouses-API :et med standardparametrar är standardtypen för SQL-lager klassisk.