SQL-lagertyper

  • Artikel

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.

Fotomotor Förutsägande I/O Intelligent arbetsbelastningshantering
Utan server 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.

  • 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

Viktigt!

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

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.

Kommentar

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

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.