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

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

Заметка

Оптимизации запросов, связанные с командой RELY , требуют выполнения запросов на вычислительных ресурсах с поддержкой Photon. См. статью " Что такое Фотон?". Photon работает по умолчанию в SQL-хранилищах и использует бессерверные вычислительные ресурсы для записных книжек и рабочих процессов. Дополнительные сведения о Фотоне см. в статье "Что такое Photon?".

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

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

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

В этом примере c_customer_sk используется ключ идентификатора клиента. Ограничение первичного ключа указывает, что каждое значение идентификатора клиента должно быть уникальным в таблице. Уникальные ограничения следуют тому же шаблону, но с использованием UNIQUE вместо PRIMARY KEY.

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. Те же оптимизации могут применяться к ограничению UNIQUE с параметром RELY.

Пример 1: Устранение ненужных агрегаций

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

SELECT
  DISTINCT c_customer_sk
FROM
  customer;

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

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

Пример 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

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

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