Определяемые пользователем схемы для выделенных пулов SQL в Azure Synapse Analytics

Эта статья посвящена предоставлению нескольких советов по использованию определяемых пользователем схем T-SQL для разработки решений в выделенном пуле SQL.

Схемы для границ приложений

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

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

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

Примечание

Пул SQL не поддерживает какие-либо перекрестные запросы к базам данных. Следовательно, реализации хранилища данных, использующих этот шаблон, будет необходимо пересмотреть.

Рекомендации

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

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

Если ранее определяемые пользователем схемы не использовались, следует начать с нуля. Используйте старое имя базы данных как основу в определяемых пользователем схемах в базе данных выделенного пула SQL.

Если схемы уже использовались, есть несколько вариантов:

  • Удалить прежние имена схем и создать новые.
  • Сохранить прежние имена схем, добавляя прежнее имя схемы к имени таблицы.
  • Сохранить прежние имена схем, реализовав представления таблицы в дополнительной схеме, чтобы воссоздать старую структуру схемы.

Примечание

На первый взгляд вариант 3 может показаться наиболее привлекательным. Однако черт прячется в деталях. В выделенном пуле SQL представления доступны только для чтения. Любое изменение данных или таблицы потребуется выполнять в базовой таблице. Кроме того, вариант 3 добавляет в систему уровень представлений. Вы можете обдумать это, если в вашей архитектуре уже используются представления.

Примеры:

Реализуйте определяемые пользователем схемы на основе имен баз данных:

CREATE SCHEMA [stg]; -- stg previously database name for staging database
GO
CREATE SCHEMA [edw]; -- edw previously database name for the data warehouse
GO
CREATE TABLE [stg].[customer] -- create staging tables in the stg schema
(       CustKey BIGINT NOT NULL
,       ...
);
GO
CREATE TABLE [edw].[customer] -- create data warehouse tables in the edw schema
(       CustKey BIGINT NOT NULL
,       ...
);

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

CREATE SCHEMA [stg]; -- stg defines the staging boundary
GO
CREATE SCHEMA [edw]; -- edw defines the data warehouse boundary
GO
CREATE TABLE [stg].[dim_customer] --pre-pend the old schema name to the table and create in the staging boundary
(       CustKey BIGINT NOT NULL
,       ...
);
GO
CREATE TABLE [edw].[dim_customer] --pre-pend the old schema name to the table and create in the data warehouse boundary
(       CustKey BIGINT NOT NULL
,       ...
);

Сохраните прежние имена схем, используя представления:

CREATE SCHEMA [stg]; -- stg defines the staging boundary
GO
CREATE SCHEMA [edw]; -- stg defines the data warehouse boundary
GO
CREATE SCHEMA [dim]; -- edw defines the legacy schema name boundary
GO
CREATE TABLE [stg].[customer] -- create the base staging tables in the staging boundary
(       CustKey    BIGINT NOT NULL
,       ...
)
GO
CREATE TABLE [edw].[customer] -- create the base data warehouse tables in the data warehouse boundary
(       CustKey    BIGINT NOT NULL
,       ...
)
GO
CREATE VIEW [dim].[customer] -- create a view in the legacy schema name boundary for presentation consistency purposes only
AS
SELECT  CustKey
,       ...
FROM    [edw].customer
;

Примечание

Любое изменение в стратегии схем влечет за собой пересмотр модели безопасности базы данных. Во многих случаях можно упростить модель безопасности, назначив разрешения на уровне схемы. Если требуются более детализированные разрешения, можно использовать роли базы данных.

Дальнейшие действия

Дополнительные советы по разработке приведены в обзоре разработки.