Share via

Opslaan in cache van resultatensets (preview)

Van toepassing op:✅ SQL Analytics-eindpunt en -magazijn in Microsoft Fabric

Resultaatsetcaching (preview) is een ingebouwde prestatieoptimalisatie voor Fabric Data Warehouse en analytische eindpunten van Lakehouse SQL die de leeslatentie verbetert.

Caching van resultatensets werkt door de uiteindelijke resultatensets voor toepasselijke SELECT T-SQL-query's te behouden, zodat volgende uitvoeringen die 'hit' cache alleen de uiteindelijke resultatenset verwerken. Dit kan complexe compilatie en gegevensverwerking van de oorspronkelijke query omzeilen en latere query's sneller retourneren.

Scenario's voor datawarehousing omvatten doorgaans analytische query's die grote hoeveelheden gegevens verwerken om een relatief klein resultaat te produceren. Een query die meerdere joins bevat en lees- en shuffles uitvoert op miljoenen rijen met gegevens, kan bijvoorbeeld SELECT resulteren in een aggregatie die slechts enkele rijen lang is. Voor workloads zoals rapporten of dashboards die vaak dezelfde analytische query's activeren, kan dezelfde zware berekening meerdere keren worden geactiveerd, ook al blijft het uiteindelijke resultaat hetzelfde. De cache van resultatensets verbetert de prestaties in deze en vergelijkbare scenario's voor ongeveer dezelfde kosten.

Belangrijk

Deze functie is beschikbaar als preview-versie.

Automatisch beheer van cache

De cache van resultatensets werkt transparant. Zodra deze optie is ingeschakeld, wordt het maken en hergebruik van de cache opportunistisch toegepast voor query's.

Caching van resultatensets is van toepassing op SELECT T-SQL-query's in magazijntabellen, snelkoppelingen naar OneLake-bronnen en snelkoppelingen naar niet-Azure-bronnen. Het beheer van de cache wordt automatisch afgehandeld, zodat de cache indien nodig regelmatig wordt verwijderd.

Als uw gegevens worden gewijzigd, wordt de consistentie van resultaten bovendien gegarandeerd door de cache die u eerder hebt gemaakt, ongeldig te maken.

Cacheopslag van resultatensets configureren

Caching van resultatensets kan worden geconfigureerd op itemniveau.

Zodra deze optie is ingeschakeld, kan deze indien nodig worden uitgeschakeld op itemniveau of voor afzonderlijke query's.

Tijdens de preview is de cache van resultatensets standaard uitgeschakeld voor alle items.

Configuratie op itemniveau

Gebruik de opdracht ALTER DATABASE SET T-SQL om caching van resultatensets in te schakelen voor een lakehouse of magazijn. Gebruik het SQL-analyse-eindpunt van een Lakehouse om T-SQL-query's te verbinden en uit te voeren.

ALTER DATABASE <Fabric_item_name>
SET RESULT_SET_CACHING ON;

De instellingswaarde kan worden gecontroleerd in sys.databases, bijvoorbeeld om de waarde voor de huidige context in Fabric Warehouse of Lakehouse SQL Analytics-eindpunt te bekijken:

SELECT name, is_result_set_caching_on 
FROM sys.databases
WHERE database_id = db_id();

De cache van resultatensets uitschakelen:

ALTER DATABASE <Fabric_item_name>
SET RESULT_SET_CACHING OFF;

Configuratie op queryniveau

Zodra caching van resultatensets is ingeschakeld voor een item, kan deze worden uitgeschakeld voor een afzonderlijke query.

Dit kan handig zijn voor foutopsporing of het testen van een query door A/B. Schakel het cachen van resultatensets voor een query uit door deze hint aan het einde van SELECT toe te voegen.

OPTION ( USE HINT ('DISABLE_RESULT_SET_CACHE') );

Cachegebruik van resultatenset controleren

Cachegebruik van resultatensets kan worden gecontroleerd op twee locaties: Berichtuitvoer en de queryinsights.exec_requests_history systeemweergave.

In de berichtuitvoer van een query (zichtbaar in de Fabric Query-editor of SQL Server Management Studio), wordt de instructie 'Cache van resultatenset is gebruikt' weergegeven na de uitvoering van de query als de query een bestaande cache voor resultatensets kon gebruiken.

Schermopname van de resultaten van een query die laat zien dat caching van resultatensets is gebruikt.

In queryinsights.exec_requests_history geeft de kolom result_cache_hit een waarde weer die het cachegebruik van de resultatenset aangeeft voor elke queryuitvoering:

  • 2: de query heeft de cache van de resultatenset gebruikt (cachetreffer)
  • 1: de query heeft de cache voor de resultatenset gemaakt
  • 0: de query was niet van toepassing op het maken of gebruiken van de cache voor de resultatenset

Voorbeeld:

SELECT result_cache_hit, command, *
FROM queryinsights.exec_requests_history
ORDER BY submit_time DESC;

Schermopname van de Fabric-queryeditor met een query in de queryinsights.exec_requests_history weergave.

In aanmerking komen voor caching van resultatensets

Wanneer een SELECT query wordt uitgegeven, wordt deze beoordeeld op resultaatsetcaching. Aan verschillende vereisten moet worden voldaan om in aanmerking te komen voor het maken en gebruiken van de cache voor resultatensets. Sommige van deze helpen cacheopslag onder interne limieten te houden, sommige helpen cacheopslag te reserveren voor complexe query's en andere helpen bij het behouden van resultaat correctheid bij terugkerende 'hits'. Een duidelijk voorbeeld is het beperken dat SELECT query's met GETDATE() hun resultaten niet cachen, maar er zijn ook andere genuanceerde gevallen waarin Fabric besluit resultaten niet te cachen.

De volgende lijst bevat algemene diskwalificaties voor het opslaan van resultatensets in Fabric Data Warehouse. Als u merkt dat een query niet van toepassing was op het maken van de cache voor resultatensets, kan dit een of meer van deze oorzaken hebben:

  • Caching van resultatensets is niet ingeschakeld voor het momenteel aangesloten item, of het is ingeschakeld voor het item, maar de query omvatte de DISABLE_RESULT_SET_CACHE hint.
  • Query is niet puur SELECT, bijvoorbeeld CREATE TABLE AS SELECT (CTAS), SELECT-INTO, andere gegevenswijzigingstalen
  • Query verwijst naar een systeemobject, een tijdelijke tabel, een metagegevensfunctie of verwijst niet naar gedistribueerde objecten
  • Query verwijst niet naar ten minste één tabel van ten minste 100.000 rijen
  • Query verwijst naar een object buiten het momenteel verbonden Fabric-item (bijvoorbeeld query voor meerdere databases)
  • Query bevindt zich binnen een expliciete transactie of een WHILE lus
  • Query-uitvoer bevat een niet-ondersteund gegevenstype en/of het VARCHAR(MAX) gegevenstype en/of het VARBINARY(MAX) gegevenstype. Zie Gegevenstypen in Fabric Data Warehouse voor ondersteunde gegevenstypen
  • Query bevat een CAST of CONVERT met een verwijzing naar datum of sql_variant gegevenstype
  • Query bevat runtimeconstanten (zoals CURRENT_USER of GETDATE())
  • Het queryresultaat wordt > geschat op 10.000 rijen
  • Query bevat niet-deterministische ingebouwde functies, statistische vensterfuncties of geordende functies, zoals PARTITION BY … ORDER BY. Zie Deterministische en niet-deterministische functies.
  • Query maakt gebruik van dynamische gegevensmaskering, beveiliging op rijniveau of andere beveiligingsfuncties
  • Query maakt gebruik van tijdreizen
  • Query past ORDER BY toe op een kolom of expressie die niet is opgenomen in de uitvoer van de query
  • Query bevindt zich in een sessie met instructies op sessieniveau SET met niet-standaardwaarden (bijvoorbeeld instellen op QUOTED_IDENTIFIEROFF)
  • Het systeem heeft interne limieten voor de cache bereikt. Verwijderingsprocessen voor de achtergrondcache maken ruimte vrij voordat er nieuwe cache wordt gemaakt.

Deze regels zijn ook van toepassing op het hergebruiken van cache bij volgende uitvoeringen van dezelfde query. Bovendien kan een cache niet worden gebruikt in de volgende scenario's:

  • Eventuele wijzigingen in de tabellen waarnaar wordt verwezen sinds de cache is gemaakt
  • De werkruimte is offline gegaan sinds het maken van een cache, vergelijkbaar met in-memory en schijfcaching
  • De gebruiker beschikt niet over voldoende machtigingen voor de objecten in de query
  • De query wordt aangeroepen vanuit een andere lakehouse- of magazijnverbinding dan waar de oorspronkelijke query is uitgegeven. (Query's tussen databases komen niet in aanmerking voor caching van resultatensets.)
  • De query maakt gebruik van verschillende uitvoerkolommen, kolomvolgorde of aliassen dan de oorspronkelijke query
  • De query in de cache is in 24 uur niet gebruikt

Opmerking

Omdat deze kwalificaties intern worden beoordeeld voor de beste toepassing van de resultatensetcaching, is het belangrijk om er rekening mee te houden dat ze in de toekomst kunnen worden bijgewerkt.

Verwante inhoud

  • Last updated on