Коннектор SQL Server#

Коннектор SQL Server позволяет запрашивать и создавать таблицы во внешней базе данных Microsoft SQL Server. Его можно использовать для объединения данных между разными системами, например SQL Server и Hive, или между двумя разными экземплярами SQL Server.

Требования#

Для подключения к SQL Server необходимо:

SQL Server 2019 или выше либо Azure SQL Database.
Сетевой доступ от координатора и workers Trino к SQL Server. Порт по умолчанию — 1433.

Конфигурация#

Коннектор может запрашивать одну базу данных в указанном экземпляре SQL Server. Создайте файл свойств каталога, который указывает коннектор SQL Server, задав connector.name равным sqlserver.

Например, чтобы обращаться к базе данных как к example, создайте файл etc/catalog/example.properties. Замените свойства подключения в соответствии с вашей средой:

connector.name=sqlserver
connection-url=jdbc:sqlserver://<host>:<port>;databaseName=<databaseName>;encrypt=false
connection-user=root
connection-password=secret

connection-url задает сведения о подключении и параметры, передаваемые JDBC-драйверу SQL Server. Поддерживаемые параметры URL доступны в документации JDBC-драйвера SQL Server.

connection-user и connection-password обычно обязательны и определяют учетные данные пользователя для подключения, часто сервисного пользователя. Можно использовать секреты, чтобы не хранить реальные значения в файлах свойств каталога.

Безопасность подключения#

JDBC-драйвер, а значит и коннектор, автоматически использует шифрование Transport Layer Security (TLS) и проверку сертификата. Для этого на хосте базы данных SQL Server должен быть настроен подходящий TLS-сертификат.

Если необходимая конфигурация не настроена, можно отключить шифрование в строке подключения с помощью свойства encrypt:

connection-url=jdbc:sqlserver://<host>:<port>;databaseName=<databaseName>;encrypt=false

Дополнительные параметры, такие как trustServerCertificate, hostNameInCertificate, trustStore и trustStorePassword, описаны в разделе TLS документации JDBC-драйвера SQL Server.

Аутентификация источника данных#

Коннектор может передавать учетные данные для подключения к источнику данных несколькими способами:

непосредственно в файле конфигурации коннектора;
в отдельном файле свойств;
в файле хранилища ключей;
как дополнительные учетные данные, заданные при подключении к Trino.

Можно использовать секреты, чтобы не хранить конфиденциальные значения в файлах свойств каталога.

В следующей таблице описаны свойства конфигурации для учетных данных подключения:

Имя свойства	Описание
`credential-provider.type`	Тип поставщика учетных данных. Должен быть одним из `INLINE`, `FILE` или `KEYSTORE`; по умолчанию — `INLINE`.
`connection-user`	Имя пользователя подключения.
`connection-password`	Пароль подключения.
`user-credential-name`	Имя свойства дополнительных учетных данных, значение которого используется как имя пользователя. См. `extraCredentials` в справочнике параметров.
`password-credential-name`	Имя свойства дополнительных учетных данных, значение которого используется как пароль.
`connection-credential-file`	Расположение файла свойств, в котором находятся учетные данные. Он должен содержать свойства `connection-user` и `connection-password`.
`keystore-file-path`	Расположение файла Java Keystore, из которого считываются учетные данные.
`keystore-type`	Формат файла хранилища ключей, например `JKS` или `PEM`.
`keystore-password`	Пароль для хранилища ключей.
`keystore-user-credential-name`	Имя сущности хранилища ключей, используемой как имя пользователя.
`keystore-user-credential-password`	Пароль для сущности хранилища ключей с именем пользователя.
`keystore-password-credential-name`	Имя сущности хранилища ключей, используемой как пароль.
`keystore-password-credential-password`	Пароль для сущности хранилища ключей с паролем.

Несколько баз данных или серверов SQL Server#

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

Чтобы добавить еще один каталог, просто добавьте еще один файл свойств в etc/catalog с другим именем, убедившись, что оно заканчивается на .properties. Например, если назвать файл свойств sales.properties, Trino создаст каталог sales с использованием настроенного коннектора.

Общие свойства конфигурации#

В следующей таблице описаны общие свойства конфигурации каталога для коннектора:

Имя свойства	Описание
`case-insensitive-name-matching`	Поддержка имен схем и таблиц без учета регистра. По умолчанию — `false`.
`case-insensitive-name-matching.cache-ttl`	Длительность, в течение которой кэшируются имена схем и таблиц при сопоставлении без учета регистра. По умолчанию — `1m`.
`case-insensitive-name-matching.config-file`	Путь к конфигурационному файлу сопоставления имен в формате JSON, который позволяет Trino различать схемы и таблицы с похожими именами в разных регистрах. По умолчанию — `null`.
`case-insensitive-name-matching.config-file.refresh-period`	Частота, с которой Trino проверяет конфигурационный файл сопоставления имен на изменения. Значение длительности по умолчанию — `0s` (обновление отключено).
`metadata.cache-ttl`	Длительность, в течение которой кэшируются метаданные, включая статистику таблиц и столбцов. По умолчанию — `0s` (кэширование отключено).
`metadata.cache-missing`	Кэшировать факт недоступности метаданных, включая статистику таблиц и столбцов. По умолчанию — `false`.
`metadata.schemas.cache-ttl`	Длительность, в течение которой кэшируются метаданные схем. По умолчанию равно значению `metadata.cache-ttl`.
`metadata.tables.cache-ttl`	Длительность, в течение которой кэшируются метаданные таблиц. По умолчанию равно значению `metadata.cache-ttl`.
`metadata.statistics.cache-ttl`	Длительность, в течение которой кэшируется статистика таблиц. По умолчанию равно значению `metadata.cache-ttl`.
`metadata.cache-maximum-size`	Максимальное число объектов, хранящихся в кэше метаданных. По умолчанию — `10000`.
`write.batch-size`	Максимальное число операторов в пакетном выполнении. Не меняйте это значение относительно значения по умолчанию. Нестандартные значения могут отрицательно повлиять на производительность. По умолчанию — `1000`.
`dynamic-filtering.enabled`	Проталкивать динамические фильтры в JDBC-запросы. По умолчанию — `true`.
`dynamic-filtering.wait-timeout`	Максимальная длительность, в течение которой Trino ожидает сбора динамических фильтров со стороны построения соединения перед запуском JDBC-запроса. Большой тайм-аут потенциально может дать более подробные динамические фильтры, но также может увеличить задержку некоторых запросов. По умолчанию — `20s`.

Добавление метаданных запроса#

Необязательный параметр query.comment-format позволяет настроить SQL-комментарий, который отправляется источнику данных с каждым запросом. Формат комментария может содержать любые символы и следующие метаданные:

$QUERY_ID: идентификатор запроса.
$USER: имя пользователя, отправившего запрос в Trino.
$SOURCE: идентификатор клиентского инструмента, использованного для отправки запроса, например trino-cli.
$TRACE_TOKEN: токен трассировки, настроенный в клиентском инструменте.

Комментарий может предоставить больше контекста о запросе. Эта дополнительная информация доступна в журналах источника данных. Чтобы включить в комментарий переменные окружения из кластера Trino, используйте синтаксис ${ENV:VARIABLE-NAME}.

Следующий пример задает простой комментарий, идентифицирующий каждый запрос, отправленный Trino:

query.comment-format=Query sent by Trino.

С такой конфигурацией запрос вроде SELECT * FROM example_table; отправляется источнику данных с добавленным комментарием:

SELECT * FROM example_table; /*Query sent by Trino.*/

Следующий пример улучшает предыдущий, используя метаданные:

query.comment-format=Query $QUERY_ID sent by user $USER from Trino.

Если Jane отправила запрос с идентификатором 20230622_180528_00000_bkizg, источнику данных отправляется следующая строка комментария:

SELECT * FROM example_table; /*Query 20230622_180528_00000_bkizg sent by user Jane from Trino.*/

Note

Некоторые настройки драйвера JDBC и конфигурации журналирования могут привести к удалению комментария.

Порог компактирования домена#

Проталкивание большого списка предикатов в источник данных может ухудшить производительность. По умолчанию Trino компактирует большие предикаты в более простой предикат диапазона, чтобы сохранить баланс между производительностью и проталкиванием предикатов. При необходимости порог такого компактирования можно увеличить, чтобы повысить производительность, когда источник данных способен эффективно использовать большие предикаты. Увеличение этого порога может улучшить проталкивание больших динамических фильтров. Свойство конфигурации каталога domain-compaction-threshold или свойство сеанса каталога domain_compaction_threshold можно использовать для изменения значения по умолчанию 256 для этого порога.

Специальные свойства конфигурации#

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

Имя свойства	Описание
`sqlserver.snapshot-isolation.disabled`	Управляет автоматическим использованием snapshot isolation для транзакций, выдаваемых Trino в SQL Server. По умолчанию `false`, что означает, что snapshot isolation включена.

Сопоставление без учета регистра#

Когда case-insensitive-name-matching установлено в true, Trino может запрашивать схемы и таблицы с именами не только в нижнем регистре, поддерживая сопоставление имени в нижнем регистре с фактическим именем в удаленной системе. Однако если две схемы и/или таблицы имеют имена, различающиеся только регистром, например “customers” и “Customers”, Trino не сможет запрашивать их из-за неоднозначности.

В таких случаях используйте свойство конфигурации каталога case-insensitive-name-matching.config-file, чтобы указать конфигурационный файл, сопоставляющий эти удаленные схемы и таблицы с соответствующими схемами и таблицами Trino. Кроме того, JSON-файл должен включать оба свойства, schemas и tables, даже если они заданы только как пустые массивы.

{
  "schemas": [
    {
      "remoteSchema": "CaseSensitiveName",
      "mapping": "case_insensitive_1"
    },
    {
      "remoteSchema": "cASEsENSITIVEnAME",
      "mapping": "case_insensitive_2"
    }],
  "tables": [
    {
      "remoteSchema": "CaseSensitiveName",
      "remoteTable": "tablex",
      "mapping": "table_1"
    },
    {
      "remoteSchema": "CaseSensitiveName",
      "remoteTable": "TABLEX",
      "mapping": "table_2"
    }]
}

Запросы к одной из таблиц или схем, заданных в атрибутах mapping, выполняются к соответствующей удаленной сущности. Например, запрос к таблицам в схеме case_insensitive_1 перенаправляется в схему CaseSensitiveName, а запрос к case_insensitive_2 — в схему cASEsENSITIVEnAME.

На уровне сопоставления таблиц запрос к case_insensitive_1.table_1 в приведенной выше конфигурации перенаправляется к CaseSensitiveName.tablex, а запрос к case_insensitive_1.table_2 — к CaseSensitiveName.TABLEX.

По умолчанию после изменения конфигурационного файла сопоставления Trino нужно перезапустить, чтобы загрузить изменения. При необходимости можно задать case-insensitive-name-matching.config-file.refresh-period, чтобы Trino обновлял свойства без перезапуска:

case-insensitive-name-matching.config-file.refresh-period=30s

Поддержка отказоустойчивого выполнения#

Коннектор поддерживает Fault-tolerant execution для обработки запросов. Операции чтения и записи поддерживаются с любой политикой повторных попыток.

Запросы к SQL Server#

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

Доступные схемы можно просмотреть, выполнив SHOW SCHEMAS:

SHOW SCHEMAS FROM example;

Если у вас есть схема с именем web, можно просмотреть таблицы в этой схеме, выполнив SHOW TABLES:

SHOW TABLES FROM example.web;

Список столбцов таблицы clicks в базе данных web можно просмотреть одним из следующих способов:

DESCRIBE example.web.clicks;
SHOW COLUMNS FROM example.web.clicks;

Наконец, можно запросить таблицу clicks в схеме web:

SELECT * FROM example.web.clicks;

Если вы использовали другое имя для файла свойств каталога, используйте это имя каталога вместо example в приведенных выше примерах.

Сопоставление типов#

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

Сопоставление типов SQL Server с типами Trino#

Коннектор сопоставляет типы SQL Server с соответствующими типами Trino согласно следующей таблице:

Сопоставление типов SQL Server с типами Trino#
Тип базы данных SQL Server	Тип Trino	Примечания
`BIT`	`BOOLEAN`
`TINYINT`	`SMALLINT`	`TINYINT` в SQL Server фактически является `unsigned TINYINT`
`SMALLINT`	`SMALLINT`
`INTEGER`	`INTEGER`
`BIGINT`	`BIGINT`
`DOUBLE PRECISION`	`DOUBLE`
`FLOAT[(n)]`	`REAL` или `DOUBLE`	См. Сопоставление числовых типов
`REAL`	`REAL`
`DECIMAL[(p[, s])]`, `NUMERIC[(p[, s])]`	`DECIMAL(p, s)`
`CHAR[(n)]`	`CHAR(n)`	`1 <= n <= 8000`
`NCHAR[(n)]`	`CHAR(n)`	`1 <= n <= 4000`
`VARCHAR[(n \| max)]`, `NVARCHAR[(n \| max)]`	`VARCHAR(n)`	`1 <= n <= 8000`, `max = 2147483647`
`TEXT`	`VARCHAR(2147483647)`
`NTEXT`	`VARCHAR(1073741823)`
`VARBINARY[(n \| max)]`	`VARBINARY`	`1 <= n <= 8000`, `max = 2147483647`
`DATE`	`DATE`
`TIME[(n)]`	`TIME(n)`	`0 <= n <= 7`
`DATETIME2[(n)]`	`TIMESTAMP(n)`	`0 <= n <= 7`
`SMALLDATETIME`	`TIMESTAMP(0)`
`DATETIMEOFFSET[(n)]`	`TIMESTAMP(n) WITH TIME ZONE`	`0 <= n <= 7`

Сопоставление типов Trino с типами SQL Server#

Коннектор сопоставляет типы Trino с соответствующими типами SQL Server согласно следующей таблице:

Сопоставление типов Trino с типами SQL Server#
Тип Trino	Тип SQL Server	Примечания
`BOOLEAN`	`BIT`
`TINYINT`	`TINYINT`	Trino поддерживает запись только значений из диапазона `[0, 127]`
`SMALLINT`	`SMALLINT`
`INTEGER`	`INTEGER`
`BIGINT`	`BIGINT`
`REAL`	`REAL`
`DOUBLE`	`DOUBLE PRECISION`
`DECIMAL(p, s)`	`DECIMAL(p, s)`
`CHAR(n)`	`NCHAR(n)` или `NVARCHAR(max)`	См. Сопоставление символьных типов
`VARCHAR(n)`	`NVARCHAR(n)` или `NVARCHAR(max)`	См. Сопоставление символьных типов
`VARBINARY`	`VARBINARY(max)`
`DATE`	`DATE`
`TIME(n)`	`TIME(n)`	`0 <= n <= 7`
`TIMESTAMP(n)`	`DATETIME2(n)`	`0 <= n <= 7`

Полный список типов данных SQL Server.

Сопоставление числовых типов#

Для SQL Server FLOAT[(n)]:

Если n не указан, сопоставляется с Trino Double
Если 1 <= n <= 24, сопоставляется с Trino REAL
Если 24 < n <= 53, сопоставляется с Trino DOUBLE

Сопоставление символьных типов#

Для Trino CHAR(n):

Если 1 <= n <= 4000, сопоставляется с SQL Server NCHAR(n)
Если n > 4000, сопоставляется с SQL Server NVARCHAR(max)

Для Trino VARCHAR(n):

Если 1 <= n <= 4000, сопоставляется с SQL Server NVARCHAR(n)
Если n > 4000, сопоставляется с SQL Server NVARCHAR(max)

Свойства конфигурации сопоставления типов#

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

Имя свойства

Описание

Значение по умолчанию

unsupported-type-handling

Настраивает обработку неподдерживаемых типов данных столбцов:

IGNORE — столбец недоступен.
CONVERT_TO_VARCHAR — столбец преобразуется в неограниченный VARCHAR.

Соответствующее свойство сеанса каталога — unsupported_type_handling.

IGNORE

jdbc-types-mapped-to-varchar

Позволяет принудительно сопоставлять списки типов данных, разделенные запятыми, с неограниченным VARCHAR.

Поддержка SQL#

Коннектор предоставляет доступ на чтение и запись к данным и метаданным в SQL Server. Помимо глобально доступных операторов и операторов чтения, коннектор поддерживает следующие возможности:

INSERT, см. также Нетранзакционный INSERT
UPDATE, см. также Ограничение UPDATE
DELETE, см. также Ограничение DELETE
TRUNCATE
Управление схемами и таблицами, см. также:
- ALTER TABLE RENAME TO limitation
Процедуры
Табличные функции

Нетранзакционный INSERT#

Коннектор поддерживает добавление строк с помощью операторов INSERT. По умолчанию вставка данных выполняется путем записи данных во временную таблицу. Этот шаг можно пропустить, чтобы повысить производительность и писать напрямую в целевую таблицу. Установите свойство каталога insert.non-transactional-insert.enabled или соответствующее свойство сеанса каталога non_transactional_insert в true.

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

Ограничение UPDATE#

Поддерживаются только операторы UPDATE с константными присваиваниями и предикатами. Например, следующий оператор поддерживается, потому что присваиваемые значения являются константами:

UPDATE table SET col1 = 1 WHERE col3 = 1

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

UPDATE table SET col1 = col2 + 2 WHERE col3 = 1

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

UPDATE table SET col1 = 1, col2 = 2, col3 = 3 WHERE col3 = 1

Ограничение DELETE#

Если указано предложение WHERE, операция DELETE работает только в том случае, если предикат в предложении может быть полностью протолкнут в источник данных.

ALTER TABLE RENAME TO limitation#

The connector does not support renaming tables across multiple schemas. For example, the following statement is supported:

ALTER TABLE example.schema_one.table_one RENAME TO example.schema_one.table_two

The following statement attempts to rename a table across schemas, and therefore is not supported:

ALTER TABLE example.schema_one.table_one RENAME TO example.schema_two.table_two

Процедуры#

`system.flush_metadata_cache()`#

Очищает кэши метаданных JDBC. Например, следующий системный вызов очищает кэши метаданных для всех схем в каталоге example:

USE example.example_schema;
CALL system.flush_metadata_cache();

`system.execute('query')`#

Процедура execute позволяет выполнить запрос напрямую в базовом источнике данных. Запрос должен использовать поддерживаемый синтаксис подключенного источника данных. Используйте процедуру для доступа к возможностям, которые недоступны в Trino, или для выполнения запросов, которые не возвращают набор результатов и поэтому не могут использоваться с транзитной табличной функцией query или raw_query. Типичные случаи применения — операторы, создающие или изменяющие объекты и требующие нативных возможностей, таких как ограничения, значения по умолчанию, автоматическое создание идентификаторов или индексы. Запросы также могут вызывать операторы, которые вставляют, обновляют или удаляют данные и не возвращают данных в результате.

Текст запроса не разбирается Trino, а только передается дальше, поэтому он подчиняется только правилам безопасности и контроля доступа базового источника данных.

В следующем примере текущая база данных устанавливается в example_schema каталога example. Затем в этой схеме вызывается процедура, чтобы удалить значение по умолчанию из your_column в таблице your_table с помощью стандартного SQL-синтаксиса в значении параметра query:

USE example.example_schema;
CALL system.execute(query => 'ALTER TABLE your_table ALTER COLUMN your_column DROP DEFAULT');

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

Табличные функции#

Коннектор предоставляет специальные табличные функции для доступа к SQL Server.

`query(varchar) -> table`#

Функция query позволяет напрямую запрашивать базовую базу данных. Она требует синтаксис, родной для SQL Server, поскольку весь запрос проталкивается вниз и обрабатывается в SQL Server. Это может быть полезно для доступа к нативным возможностям, не реализованным в Trino, или для повышения производительности запросов в ситуациях, когда выполнение запроса нативно может быть быстрее.

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

Например, запросите каталог example и выберите первые 10 процентов стран по населению:

SELECT
  *
FROM
  TABLE(
    example.system.query(
      query => 'SELECT
        TOP(10) PERCENT *
      FROM
        tpch.nation
      ORDER BY
        population DESC'
    )
  );

`procedure(varchar) -> table`#

Функция procedure позволяет напрямую запускать хранимые процедуры в базовой базе данных. Она требует синтаксис, родной для SQL Server, поскольку весь запрос проталкивается вниз и обрабатывается в SQL Server. Чтобы использовать эту табличную функцию, установите sqlserver.stored-procedure-table-function-enabled в true.

Note

Функция procedure не поддерживает запуск StoredProcedures, которые возвращают несколько операторов, используют не-select оператор, используют выходные параметры или условные операторы.

Warning

Эта возможность является экспериментальной. Функция имеет последствия для безопасности, а синтаксис может измениться с нарушением обратной совместимости.

Следующий пример запускает хранимую процедуру employee_sp в каталоге example и схеме example_schema в базовой базе данных SQL Server:

SELECT
  *
FROM
  TABLE(
    example.system.procedure(
      query => 'EXECUTE example_schema.employee_sp'
    )
  );

Если хранимая процедура employee_sp требует входные данные, добавьте значение параметра к оператору процедуры:

SELECT
  *
FROM
  TABLE(
    example.system.procedure(
      query => 'EXECUTE example_schema.employee_sp 0'
    )
  );

Note

Движок запросов не сохраняет порядок результатов этой функции. Если переданный запрос содержит предложение ORDER BY, результат функции может быть упорядочен не так, как ожидается.

Производительность#

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

Статистика таблиц#

Коннектор SQL Server может использовать статистику таблиц и столбцов для оптимизаций на основе стоимости, чтобы повышать производительность обработки запросов на основе фактических данных в источнике данных.

Статистика собирается SQL Server и извлекается коннектором.

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

CREATE STATISTICS example_statistics_name ON table_schema.table_name (column_name);

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

UPDATE STATISTICS table_schema.table_name;

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

Pushdown#

Коннектор поддерживает pushdown для ряда операций:

Aggregate pushdown для следующих функций:

Note

Коннектор выполняет проталкивание там, где это может повысить производительность, но ради сохранения корректности операция может не проталкиваться. Когда проталкивание операции может дать лучшую производительность, но создает риск для корректности, коннектор отдает приоритет корректности.

Проталкивание соединений на основе стоимости#

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

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

В следующей таблице описаны свойства конфигурации каталога для проталкивания соединений:

Имя свойства	Описание	Значение по умолчанию
`join-pushdown.enabled`	Включает проталкивание соединений. Эквивалентное свойство сеанса каталога — `join_pushdown_enabled`.	`true`
`join-pushdown.strategy`	Стратегия, используемая для оценки того, следует ли проталкивать операции соединения. Установите `AUTOMATIC`, чтобы включить проталкивание соединений на основе стоимости, или `EAGER`, чтобы проталкивать соединения всегда, когда это возможно. Обратите внимание, что `EAGER` может проталкивать соединения даже при отсутствии статистики таблиц, что может привести к ухудшению производительности запросов. Поэтому `EAGER` рекомендуется только для тестирования и диагностики.	`AUTOMATIC`

Поддержка predicate pushdown#

Коннектор поддерживает pushdown предикатов для столбцов VARCHAR и NVARCHAR, если базовые столбцы в SQL Server используют чувствительную к регистру collation.

Проталкиваются следующие операторы:

=
<>
IN
NOT IN

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

Массовая вставка#

Можно дополнительно использовать bulk copy API, чтобы значительно ускорить операции записи.

Включите bulk copying и блокировку целевой таблицы, чтобы выполнить минимальные требования к журналированию.

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

Свойства массовой загрузки#
Имя свойства	Описание	По умолчанию
`sqlserver.bulk-copy-for-write.enabled`	Использовать SQL Server bulk copy API для записей. Соответствующее свойство сеанса каталога — `bulk_copy_for_write`.	`false`
`sqlserver.bulk-copy-for-write.lock-destination-table`	Получать bulk update lock для целевой таблицы при операциях записи. Соответствующее свойство сеанса каталога — `bulk_copy_for_write_lock_destination_table`. Настройка используется только когда `bulk-copy-for-write.enabled=true`.	`false`

Ограничения:

Имена столбцов с начальными и конечными пробелами не поддерживаются.

Сжатие данных#

Можно указать политику сжатия данных для таблиц SQL Server с помощью свойства таблицы data_compression. Допустимые политики: NONE, ROW или PAGE.

Пример:

CREATE TABLE example_schema.scientists (
  recordkey VARCHAR,
  name VARCHAR,
  age BIGINT,
  birthday DATE
)
WITH (
  data_compression = 'ROW'
);

Коннектор SQL Server#

Требования#

Конфигурация#

Безопасность подключения#

Аутентификация источника данных#

Несколько баз данных или серверов SQL Server#

Общие свойства конфигурации#

Добавление метаданных запроса#

Порог компактирования домена#

Специальные свойства конфигурации#

Сопоставление без учета регистра#

Поддержка отказоустойчивого выполнения#

Запросы к SQL Server#

Сопоставление типов#

Сопоставление типов SQL Server с типами Trino#

Сопоставление типов Trino с типами SQL Server#

Сопоставление числовых типов#

Сопоставление символьных типов#

Свойства конфигурации сопоставления типов#

Поддержка SQL#

Нетранзакционный INSERT#

Ограничение UPDATE#

Ограничение DELETE#

ALTER TABLE RENAME TO limitation#

Процедуры#

system.flush_metadata_cache()#

system.execute('query')#

Табличные функции#

query(varchar) -> table#

procedure(varchar) -> table#

Производительность#

Статистика таблиц#

Pushdown#

Проталкивание соединений на основе стоимости#

Поддержка predicate pushdown#

Массовая вставка#

Сжатие данных#

`system.flush_metadata_cache()`#

`system.execute('query')`#

`query(varchar) -> table`#

`procedure(varchar) -> table`#