Неограниченно долгое хранение данных с технологией Stretch Database в SQL Server 2016

Дата публикации: 02.06.2016

Технология Stretch Database, входящая в состав СУБД SQL Server 2016, дает возможность хранить любой объем данных столько, сколько потребуется, без нарушения соглашения об уровне обслуживания бизнеса и высоких затрат на приобретение систем хранения данных уровня предприятия. В отличие от обычных решений, применяемых для хранения «холодных» данных, Stretch Database обеспечивает постоянный доступ к вашим данным за счет использования неисчерпаемых облачных ресурсов Azure, а также не требует модификации большинства приложений. Администраторам баз данных лишь нужно активировать хранение «холодных» данных в облаке.

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


Однако возможность мгновенного доступа даже к «холодным» данным тоже необходима, что обусловлено задачами бизнеса и требованиями законодательных норм. Системные администраторы и ИТ-директора постоянно ищут способы достижения бизнес-целей в условиях ограниченного ИТ-бюджета. Администраторы баз данных, в свою очередь, вынуждены сдерживать разрастание конфликта: производительность и доступность постоянно увеличивающейся базы данных им приходится поддерживать в тех пределах, которые указаны в соглашении об уровне обслуживания бизнеса, хотя бюджет и время, отведенные на операции сопровождения, продолжают уменьшаться.


Основные сценарии

  • Перенос в облако всей таблицы: уже имеющуюся выделенную таблицу для «холодных» данных можно перенести целиком. Допустим, у вас есть таблицы Order_details и Order_details_history, последняя из которых содержит только «холодные» данные, переносимые из первой.
  • Перенос «холодных» строк: если в одной и той же таблице есть и «горячие», и «холодные» данные, можно перенести в Azure только «холодные». Для этого достаточно указать, какие именно строки являются таковыми (обычно это определяется по дате или состоянию), а SQL Server позаботится о переносе.


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

Azure SQL Stretch Database дает возможность пользоваться Azure на ваших условиях.

  • Получите пространство хранения корпоративного класса — сколько и когда нужно. Автоматизированное резервное копирование и георепликация включены по умолчанию.
  • При необходимости масштабируйте вычислительные ресурсы и пространство хранения с учетом требований рабочей задачи и платите только за используемый объем.
  • При помощи встроенного механизма безопасности централизованно управляйте доступом для заказчиков, объединивших локальный Active Directory с Azure Active Directory.
  • Пользуйтесь имеющимися знаниями и инструментами, такими как SQL Server Management Studio, SQL Server Data Tools, T-SQL и PowerShell, и расширяйте доступные возможности посредством портала Azure.


Еще раз напомним, что для использования Stretch Database вносить изменения в код большинства приложений не нужно.


Основные требования

Stretch Database доступна только в SQL Server 2016, так что пользователям других версий сначала необходимо обновить СУБД. Кроме того, понадобится подписка на облако Azure для создания новой базы данных SQL Server Stretch Database. Право создать такую базу предоставляется пользователям с ролями администратора, соадминистратора, владельца подписки и участника. Если у вас еще нет подписки Azure, зарегистрируйтесь для получения бесплатной пробной подписки. Использование Stretch Database обычно не вызывает сложностей, если в базе данных отсутствуют неподдерживаемые объекты или функции.


Принцип действия

Для начала нужно выбрать либо таблицу, которую вы хотите перенести в облако целиком, либо отдельные строки, подлежащие переносу. Процесс активации Stretch Database несложен: это можно сделать с помощью мастера в SQL ServerManagement Studio или посредством T-SQL. Подробности и пошаговое руководство доступны на странице документации.

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

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

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


Запросы к Stretch Database не требуют изменений. Если нужно извлечь данные из удаленной базы, обработчик автоматически переадресует запрос к ней, передавая соответствующие фильтры, заданные модификатором WHERE. При этом возвращаются только требуемые строки; они соединяются с локальными данными (при их наличии) и предоставляются приложению или пользователю. Если для выполнения запроса данные из удаленной базы не нужны, обработчик не выполняет запрос удаленно; тем самым исключается задержка и накладные затраты, обусловленные взаимодействием с Azure.

Для мониторинга удаленной базы и процесса переноса, можно использовать различные подходы. В частности, функция Dynamic Management Views позволяет отобразить текущую процедуру миграции и прогресс обновления схемы. Обзорный отчет о состоянии системы помещается в раздел Stretch Database Monitor в SSMS (см. скриншот). Подробности о способах мониторинга можно узнать здесь.


После того как в Azure будет перенесена большая часть «холодных» данных, вы заметите, что важные операции сопровождения, например резервное копирование и восстановление, отнимают меньше времени и ресурсов. Это происходит потому, что перенесенные «холодные» данные уже не влияют на ход их выполнения.

Насколько значительными окажутся последствия миграции в целом? Это зависит от размера таблицы с «холодными» данными, а также от характера имеющихся соглашений об уровне обслуживания бизнеса. Самая крупная таблица, которая встречалась нам при работе с клиентами, содержала 45 миллиардов строк (и продолжала расти), причем примерно 99% содержащихся в ней данных были «холодными». И хотя требовалось поддерживать возможность оперативного доступа к ним в любое время, в действительности такие обращения происходили редко. Представьте, что вы администратор базы данных и должны выполнять обслуживание индексов для такой огромной таблицы. Если подобный объем вас не впечатлил, отметим, что самая большая секционированная таблица, с которой нам пришлось работать, содержала 1,3 триллиона строк (и быстро росла).

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


Дальнейшие шаги

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

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


Узнайте больше

Чтобы получить больше информации и узнать, как приступить к работе с Stretch Database, ознакомьтесь с материалами, доступными по следующим ссылкам: