Оптимизация запросов с помощью ограничений первичного ключа

Ограничения первичного ключа, которые фиксируют связи между полями в таблицах, могут помочь пользователям и средствам понять связи в данных. В этой статье содержатся примеры, показывающие, как использовать первичные ключи с параметром RELY для оптимизации некоторых распространенных типов запросов.

:::

:::

Добавление ограничений первичного ключа

Вы можете добавить ограничение первичного ключа в инструкцию создания таблицы, как показано в следующем примере, или добавить ограничение в таблицу с помощью предложения ADD CONSTRAINT.

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

В этом примере c_customer_sk используется ключ идентификатора клиента. Ограничение первичного ключа указывает, что каждое значение идентификатора клиента должно быть уникальным в таблице. Azure Databricks не применяет ограничения ключей. Их можно проверить с помощью существующего конвейера данных или ETL. См. Управление качеством данных с помощью ожиданий конвейера, чтобы узнать об ожиданиях при работе с таблицами потоковой обработки и материализованными представлениями. Сведения об ограничениях в таблицах Delta в Azure Databricks см. в, чтобы узнать о работе с ними.

Использование RELY для включения оптимизации

Если вы знаете, что ограничение первичного ключа допустимо, вы можете включить оптимизацию, основанную на ограничении, указав его с параметром RELY. Полный синтаксис см. в предложении .

Параметр RELY позволяет Azure Databricks использовать ограничение для перезаписи запросов. Следующие оптимизации можно выполнить только в том случае, если RELY параметр указан в предложении ADD CONSTRAINT или ALTER TABLE инструкции.

С помощью ALTER TABLE можно изменить первичный ключ таблицы, чтобы включить параметр RELY, как показано в следующем примере.

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

Примеры оптимизации

Следующие примеры расширяют предыдущий пример, который создает таблицу customer, в которой c_customer_sk является проверенным уникальным идентификатором с именем PRIMARY KEY с указанным параметром RELY.

Пример 1. Устранение ненужных агрегатов

Ниже показан запрос, который применяет DISTINCT операцию к первичному ключу.

SELECT
  DISTINCT c_customer_sk
FROM
  customer;

Так как столбец c_customer_sk является проверенным ограничением PRIMARY KEY, все значения в столбце уникальны. Если указан параметр RELY, Azure Databricks может оптимизировать запрос, не выполняя операцию DISTINCT.

Пример 2. Устранение ненужных соединений

В следующем примере показан запрос, в котором Azure Databricks может исключить ненужное соединение.

Запрос присоединяет таблицу фактов, store_sales с таблицей измерений, customer. Он выполняет левое внешнее соединение, поэтому результат запроса включает все записи из таблицы store_sales и соответствующие записи из таблицы customer. Если в таблице customer отсутствует соответствующая запись, в результате запроса в столбце NULL отображается значение c_customer_sk.

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

Чтобы понять, почему это соединение не требуется, рассмотрите инструкцию запроса. Для этого требуется только столбец ss_quantity из таблицы store_sales. Таблица customer присоединена к первичному ключу, поэтому каждая строка store_sales соответствует не более одной строке в customer. Так как операция является внешним соединением, все записи из таблицы store_sales сохраняются, поэтому соединение не изменяет данные из этой таблицы. Агрегирование SUM не изменяется независимо от того, соединены ли эти таблицы или нет.

Использование ограничения первичного ключа с RELY дает оптимизатору запросов сведения, необходимые для устранения соединения. Оптимизированный запрос выглядит следующим образом:

SELECT
  SUM(ss_quantity)
FROM
  store_sales ss

Следующие шаги

См. просмотр схемы связей сущностей, чтобы узнать, как изучить связи первичного ключа и внешнего ключа в пользовательском интерфейсе обозревателя каталогов.