Stretch Database

Stretch Database — это функция реляционной системы управления базами данных Microsoft SQL Server, позволяющая прозрачно и динамически перемещать «холодные» (редко используемые) данные из локальной базы данных в облачную базу данных Microsoft Azure SQL Database. Основное назначение технологии — экономия ресурсов локального хранилища и вычислительных мощностей за счёт выноса архивных или исторических данных в облако без изменения схемы базы данных, запросов и клиентских приложений. Stretch Database обеспечивает единую точку доступа к данным, которые физически располагаются частично на локальном сервере, а частично в облаке, при этом запросы выполняются так, как если бы все данные находились локально.

История

Функция Stretch Database была анонсирована корпорацией Microsoft в 2014 году в рамках развития платформы SQL Server 2016. Основной целью было создание гибридного решения, которое позволяло бы организациям, уже использующим локальные инсталляции SQL Server, снижать затраты на хранение данных за счёт облачных ресурсов Azure. В 2016 году Stretch Database стала доступна в финальной версии SQL Server 2016 (поддерживается в редакциях Enterprise и Standard). В 2018 году, с выходом SQL Server 2019, поддержка Stretch Database была прекращена; функция объявлена устаревшей (deprecated). В 2022 году Microsoft официально объявила о завершении поддержки Stretch Database, рекомендовав пользователям переходить на другие технологии гибридного хранения, в частности на Azure SQL Database с функциями уровня данных (Data Tier) и автоматического управления жизненным циклом данных.

Принцип работы

Stretch Database работает на уровне таблиц. Администратор базы данных включает функцию для конкретной таблицы (или её части) и задаёт условия перемещения строк. SQL Server автоматически отслеживает активность данных: строки, которые не обновлялись в течение заданного периода (например, 90 дней), считаются «холодными» и подлежат миграции в облако. Процесс перемещения происходит в фоновом режиме, без блокировок и остановки работы с таблицей.

Архитектура

Архитектурно Stretch Database состоит из двух компонентов:

• Локальный сервер SQL Server — содержит метаданные о растянутой таблице, а также активные («горячие») строки.
• Удалённая база данных в Azure — хранит перемещённые строки. Для связи используется зашифрованное соединение через интернет или Azure ExpressRoute.

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

Условия перемещения данных

Администратор может настроить два основных параметра:

• Фильтр по времени — перемещаются строки, которые не изменялись дольше указанного количества дней.
• Функция-фильтр — позволяет задать произвольное условие на основе значений столбцов (например, перемещать только строки с определённым статусом или датой).

После включения Stretch Database для таблицы любые изменения (UPDATE, DELETE) в перемещённых строках невозможны — они становятся доступными только для чтения. Это ограничение является принципиальным, так как Stretch Database ориентирована на архивные, неизменяемые данные.

Преимущества

Основные преимущества использования Stretch Database:

• Экономия локального хранилища — «холодные» данные хранятся в облаке, что позволяет сократить объём локальных дисков и затраты на их обслуживание.
• Прозрачность для приложений — не требуется изменять код, запросы или схему базы данных; все манипуляции с данными выполняются через стандартный T-SQL.
• Безопасность — передача данных шифруется (TLS/SSL), а для управления доступом используются те же механизмы аутентификации и авторизации, что и для локальной базы.
• Гибкость настройки — администратор может точно определить, какие данные и когда перемещать, используя фильтры.
• Интеграция с экосистемой Azure — данные, перемещённые в Azure, могут быть дополнительно использованы для аналитики, отчётности или резервного копирования.

Недостатки и ограничения

Stretch Database имеет ряд существенных ограничений, которые привели к её постепенному вытеснению другими решениями:

• Только чтение для перемещённых данных — строки, перенесённые в Azure, становятся неизменяемыми. Это делает функцию непригодной для таблиц, которые активно обновляются.
• Зависимость от сети — производительность запросов, затрагивающих облачные данные, сильно зависит от скорости и стабильности интернет-соединения. Задержки могут быть значительными.
• Ограниченный набор типов данных — не все типы данных SQL Server поддерживаются для перемещения (например, типы FILESTREAM, SQL_VARIANT, HIERARCHYID, SPATIAL и другие).
• Отсутствие поддержки индексов — на растянутых таблицах нельзя создавать индексы, которые бы охватывали облачные данные. Локальные индексы работают только для локальных строк.
• Сложность управления — процесс миграции данных не всегда предсказуем, а мониторинг состояния перемещения требует использования специальных системных представлений.
• Затраты на облачное хранение — хранение данных в Azure оплачивается отдельно, что для больших объёмов может быть дороже, чем локальное хранение на недорогих носителях.
• Прекращение поддержки — функция объявлена устаревшей, и новые версии SQL Server (начиная с 2019) не включают её. Это означает отсутствие обновлений и исправлений безопасности.

Сравнение с альтернативами

На смену Stretch Database пришли более современные и гибкие технологии управления жизненным циклом данных в экосистеме Microsoft:

Пример использования

Типичный сценарий применения Stretch Database — архивирование исторических данных в системах учёта, например, в бухгалтерских или CRM-системах. Предположим, что таблица Orders содержит записи о заказах за последние 10 лет. Заказы старше 1 года практически не изменяются и редко запрашиваются. Администратор включает Stretch Database для таблицы Orders и задаёт фильтр: перемещать строки, которые не обновлялись более 365 дней. В результате:

• Активные заказы (последнего года) остаются локально.
• Заказы старше года автоматически перемещаются в Azure.
• При выполнении отчёта по всем заказам за 10 лет SQL Server самостоятельно обращается и к локальным, и к облачным данным, возвращая единый результат.

Критика

Stretch Database подвергалась критике за недостаточную прозрачность стоимости. Пользователи отмечали, что затраты на хранение в Azure и на сетевой трафик могут превысить экономию от освобождения локального хранилища. Кроме того, невозможность изменять перемещённые данные делала функцию неприменимой во многих реальных сценариях, где требуется хотя бы редкая корректировка архивных записей. Отсутствие поддержки индексов на облачных данных приводило к деградации производительности запросов, затрагивающих большие объёмы архивных данных. В итоге, несмотря на оригинальную концепцию, Stretch Database не получила широкого распространения и была заменена более практичными решениями.

Источники

• Microsoft Docs: SQL Server 2016 Stretch Database (архивная документация).
• Microsoft Docs: Завершение поддержки Stretch Database в SQL Server 2019.
• Обзор гибридных решений хранения данных в Azure SQL Database.
• Статьи технического блога Microsoft о жизненном цикле данных в SQL Server (2014–2022).