Dela via

SQL-lagertyper

  • Artikel

Databricks SQL har stöd för serverlösa, pro- och klassiska typer. Den här artikeln beskriver de funktioner som är tillgängliga för varje typ och jämför prestanda och funktioner.

Prestandafunktioner efter typ

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

Lagertyp Fotomotor Förutsägande I/O Intelligent arbetsbelastningshantering
Serverlös X X X
PRO X X
Klassisk X

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.

  • Predictive IO: 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 prestandaförbättringar.

  • 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 snabbt kontrollera att arbetsbelastningarna 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.

    Notera

    Priser för varje informationslagertyp och en detaljerad funktionsjämförelse finns i Databricks SQL. För att lära sig om de senaste Databricks SQL-funktionerna, se Databricks SQL versionsanteckningar.

Prestandaskillnader mellan SQL-lagertyper

Varje SQL-lagertyp har olika prestandaegenskaper.

Serverlösa SQL-lager

Med hjälp av Azure Databricks serverlös arkitekturstö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ågeintagning ligger närmare maskinvarans begränsning ä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.

Välj ett serverlöst SQL-lager för bästa startprestanda, den mest effektiva I/O,smartare hanteringen av frågeefterfrågan som varierar kraftigt över tid och snabb autoskalning när frågeköer inträffar. Se Serverlös automatisk skalning och frågeköer.

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

  • ETL
  • Affärsanalys
  • Undersökande analys

Viktig

SQL-lager stöder inte vidarebefordran av autentiseringsuppgifter. Databricks rekommenderar att du använder Unity Catalog för datastyrning. Se även Vad är Unity Catalog?.

Pro SQL-datalager

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. Utan Intelligent Workload Management är lager mindre dynamiska 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ö och autoskaleringsfunktion för pro- och klassiska SQL-databaser.

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 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ö och autoskaleringsfunktion för pro- och klassiska SQL-databaser.

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.

Notera

Information om hur du ändrar storlek på ditt SQL-lager och hur det skalar som svar på frågeköer finns i Köa och autoskalning för pro- och klassiska SQL-lager.

Vad är standardinställningarna för lagertypen?

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

  • Med hjälp av användargränssnittet är sql warehouse-standardtypen serverlös.
  • Med api:et SQL Warehouses 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 warehouse_type till pro. Om den här arbetsytan använde SQL Warehouses API 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-metaarkivstöds inte serverlösa SQL-lager. Sql Warehouse-standardtypen är densamma som om serverlös databehandling var inaktiverad, vilket är pro i användargränssnittet och klassiskt via 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-datalager "pro".
  • Med api:et SQL Warehouses med standardparametrar är standardtypen för SQL-lager klassisk.