Queryoptimalisatie met primaire-sleutelbeperkingen

Primaire-sleutelbeperkingen, waarmee relaties tussen velden in tabellen worden vastgelegd, kunnen gebruikers en hulpprogramma's helpen relaties in uw gegevens te begrijpen. Dit artikel bevat voorbeelden die laten zien hoe u primaire sleutels kunt gebruiken met de RELY optie om een aantal veelvoorkomende typen query's te optimaliseren.

Notitie

Voor queryoptimalisaties die zijn gekoppeld aan de RELY opdracht, moeten query's worden uitgevoerd op berekeningen met Photon-functionaliteit. Zie Wat is Photon? Photon wordt standaard uitgevoerd op SQL-magazijnen en serverloze berekeningen voor notebooks en werkstromen. Zie Wat is Photon?voor meer informatie over Photon.

Beperkingen voor primaire sleutels toevoegen

U kunt een primaire-sleutelbeperking toevoegen aan de instructie voor het maken van tabellen, zoals in het volgende voorbeeld, of een beperking toevoegen aan een tabel met behulp van de ADD CONSTRAINT component.

CREATE TABLE customer (
  c_customer_sk int,
  PRIMARY KEY (c_customer_sk)
  ...
  )

In dit voorbeeld c_customer_sk is dit de sleutel van de klant-id. De primaire-sleutelbeperking geeft aan dat elke klant-id-waarde uniek moet zijn in de tabel. Azure Databricks dwingt geen belangrijke beperkingen af. Ze kunnen worden gevalideerd via uw bestaande gegevenspijplijn of ETL. Zie Gegevenskwaliteit beheren met pijplijnverwachtingen om meer te weten te komen over werkverwachtingen voor streamingtabellen en gematerialiseerde weergaven. Zie Beperkingen voor Azure Databricks voor meer informatie over het werken met beperkingen voor Delta-tabellen.

Notitie

Het is de verantwoordelijkheid van de gebruiker om te controleren of aan een beperking wordt voldaan. Het vertrouwen op een beperking die niet is voldaan, kan leiden tot onjuiste queryresultaten.

Gebruiken RELY om optimalisaties in te schakelen

Wanneer u weet dat een primaire-sleutelbeperking geldig is, kunt u optimalisaties inschakelen op basis van de beperking door deze op te geven met de RELY optie. Zie ADD CONSTRAINT clausule voor de volledige syntaxis.

Met de RELY optie kan Azure Databricks gebruikmaken van de beperking om query's te herschrijven. De volgende optimalisaties kunnen alleen worden uitgevoerd als de RELY optie is opgegeven in een ADD CONSTRAINT component of ALTER TABLE instructie.

Met behulp van ALTER TABLEkunt u de primaire sleutel van een tabel wijzigen om de RELY optie op te nemen, zoals wordt weergegeven in het volgende voorbeeld.

ALTER TABLE
  customer DROP PRIMARY KEY;
ALTER TABLE
  customer
ADD
  PRIMARY KEY (c_customer_sk) RELY;

Voorbeelden van optimalisatie

In de volgende voorbeelden wordt het vorige voorbeeld uitgebreid waarmee een customer tabel wordt gemaakt waarin c_customer_sk een geverifieerde unieke id wordt genoemd als een PRIMARY KEY door te specificeren de RELY optie.

Voorbeeld 1: Overbodige aggregaties elimineren

Hieronder ziet u een query die een DISTINCT bewerking toepast op een primaire sleutel.

SELECT
  DISTINCT c_customer_sk
FROM
  customer;

Omdat de c_customer_sk kolom een geverifieerde PRIMARY KEY beperking is, zijn alle waarden in de kolom uniek. Met de RELY optie is opgegeven, kan Azure Databricks de query optimaliseren door de DISTINCT bewerking niet uit te voeren.

Voorbeeld 2: Onnodige joins elimineren

In het volgende voorbeeld ziet u een query waarin Azure Databricks een onnodige join kan elimineren.

Met de query wordt een feitentabel samengevoegd, store_sales met een dimensietabel. customer Er wordt een left outer join uitgevoerd, zodat het queryresultaat alle records uit de store_sales tabel en overeenkomende records uit de customer tabel bevat. Als er geen overeenkomende record in de customer tabel staat, wordt in het queryresultaat een NULL waarde voor de c_customer_sk kolom weergegeven.

SELECT
  SUM(ss_quantity)
FROM
  store_sales ss
  LEFT JOIN customer c ON ss.customer_sk = c.c_customer_sk;

Om te begrijpen waarom deze join niet nodig is, bekijk de queryverklaring. Hiervoor is alleen de ss_quantity kolom uit de store_sales tabel vereist. De customer-tabel wordt samengevoegd op de primaire sleutel, zodat elke rij van store_sales maximaal overeenkomt met één rij in customer. Omdat de bewerking een outer join is, blijven alle records uit de store_sales tabel behouden, zodat de join geen gegevens uit die tabel wijzigt. De SUM aggregatie is hetzelfde, ongeacht of deze tabellen zijn gekoppeld.

Het gebruik van de primaire sleutel beperking met RELY geeft de query-optimalisator de informatie die nodig is om de join te elimineren. De geoptimaliseerde query ziet er ongeveer als volgt uit:

SELECT
  SUM(ss_quantity)
FROM
  store_sales ss

Volgende stappen

Zie Het entiteitsrelatiediagram weergeven voor meer informatie over het verkennen van relaties tussen primaire sleutels en refererende sleutels in de gebruikersinterface van Catalog Explorer.