Это вторая часть цикла про то, как устроена SQL Database. В первой части речь шла об архитектуре SQL Database, во второй части продолжим этот обзор с фокусом на масштабирование и некоторые особенности разработки для SQL Database.
Обеспечение масштабируемости в SQL Database
Одним из наиболее значимых преимуществ размещения баз данных в среде SQL Database являются встроенные функции обеспечения масштабируемости. При необходимости можно добавить дополнительные базы данных. Два компонента SQL Database обеспечивают масштабируемость за счет постоянного отслеживания рабочей нагрузки на каждом из узлов. Первый компонент — Engine Throttling (регулировщик нагрузки на ядро), который защищает сервер от перегрузки. Второй компонент — Load Balancer (балансировщик нагрузки), который следит за тем, чтобы сервер не работал постоянно в режиме повышенной производительности.
Регулирование производительности
Каждый из серверов SQL Server в ЦОДе используется несколькими клиентами одновременно. Существует вероятность того, что приложение подписчика вызовет перегрузку сервера и нарушит работоспособность целого экземпляра SQL Server. Например, в режиме полного восстановления операция вставки большого числа строк, особенно содержащих крупные объекты, способна заполнить журнал транзакций и весь диск, на котором размещен журнал. Кроме того, каждый экземпляр SQL Server совместно использует компьютер с другими критически важными системными процессами, которые нельзя лишать ресурсов. Важнейшим из них является процесс поддержки структуры, отслеживающий состояние системы и обеспечивающий доступ к среде SQL Database.
Для защиты ресурсов ЦОДа от излишней нагрузки, нарушающей работоспособность компьютеров, нагрузка на каждый компьютер отслеживается компонентом Engine Throttling (регулировщик нагрузки на ядро). Кроме того, отслеживается каждая реплика базы данных. Это позволяет контролировать статистические показатели, значения которых должны находиться в заданных пределах: размер журнала, длительность операций записи в журнал, уровень использования процессора, фактические ограничения на размер физической базы данных и размер пользовательской базы данных SQL Database. В случае превышения предельных значений база данных SQL Database может отклонять запросы на чтение и запись в течение 10 секунд подряд. Превышение ограничений на использование ресурсов может приводить к тому, что база данных SQL Database будет отклонять все запросы на чтение и запись (в зависимости от типа ресурса).
Балансировка нагрузки
В настоящее время нельзя гарантировать производительность среды SQL Database, несмотря гарантию ее доступности. Одной из причин является проблема поддержки многопользовательского доступа: множество клиентов со своими базами данных SQL Database совместно используют один и тот же экземпляр SQL Server и один и тот же компьютер. Невозможно предсказать уровень рабочей нагрузки, который будет затребован каждым из соединений подписчиков. Тем не менее обеспечение высокой производительности является критически важным аспектом, который учитывался при разработке инфраструктуры SQL Database. Службы балансировки нагрузки SQL Database оценивают загрузку каждого из компьютеров в центре обработки данных.
При добавлении новой базы данных SQL Database в кластер, балансировщик нагрузки определяет места размещения новых реплик (основной и дополнительной), учитывая текущий уровень рабочей нагрузки на компьютеры.
Если один из компьютеров перегружен, балансировщик нагрузки может переместить основную реплику на менее нагруженный компьютер. Простейший способ — переключение основной и дополнительной реплики базы данных SQL Database, производительность которой снижена. Это переключение способно мгновенно повысить производительность, так как все операции чтения и записи производятся в основной реплике.
Федерация базы данных
Федерация позволяет масштабировать слой баз данных аналогично принципам масштабирования middle-tier или front-end. Если просто, то федерация разбивает одну большую базу на несолько более маленьких по определенному принципу. Обычно этот принцип выбирается таким образом, чтобы сделать маленькие базы независимыми друг от друга (минимизировать кросс-обращения). Фактические федерация позволяет следующее:
- Преодолеть ограничение в 150 Гб на размер одной базы в SQL Database.
- Повысить общую производительность системы за счет того, что каждый член федерации обычно располагается на различных физических серверах.
- Реализовать мультитенантность (Мультитенантная архитектура для SaaS приложений).
Технические подробности федерации и шардинга выходят за рамки этой статьи (т.к. это отдельная большая тема), но для желающих приобщиться к прекрасному (федерации) в конце статьи привожу ссылки на русскоязычные посты по теме архитектуры федерации в SQL Database.
Безопасность
Большинство вопросов безопасности баз данных SQL Database решается на уровне. Как и при доступе к локальной базе данных, для подключения к базе данных SQL Database пользователь должен иметь учетную запись и пароль. SQL Database поддерживает только стандартные средства безопасности. Поэтому каждую учетную запись необходимо создавать в явной форме.
На каждом сервере SQL Database можно настроить брандмауэр так, чтобы он пропускал трафик только с указанных IP-адресов. По умолчанию список разрешенных IP-адресов пуст. Это позволяет сократить риск атак типа «отказ в обслуживании» (denial-of-service, DoS). Все данные, передаваемые между клиентами и SQL Database, необходимо шифровать с помощью SSL. Клиенты должны использовать для подключения параметр Encrypt = True, что позволяет устранить угрозу атак типа «злоумышленник в середине». Для дополнительного снижения риска DoS-атак можно воспользоваться службой DoSGuard, отслеживающей ошибки входа с одних и тех же IP-адресов за определенный период времени и блокирующей доступ ко всем ресурсам с этих IP-адресов.
Рекомендации для разработчиков в среде SQL Database
Несмотря на то что разработка приложений SQL Server для среды SQL Database весьма схожа с разработкой приложений для локального экземпляра SQL Server, существует несколько ключевых различий.
Подключение и отключение
При использовании облачной базы данных, в том числе и SQL Database, нужно быть готовым к обработке неожиданных разрывов соединения, включая обработку подобных ситуаций в программном коде. Лучший способ обработки разрыва соединения — повторное установление соединения и выполнение команд или запросов, которые завершились сбоем — это принцип retry logic.
Если причиной разрыва соединения являются неполадки сети, среда SQL Database не может вернуть приложению значащее сообщение об ошибке перед завершением сеанса. При попытке повторного использования этого соединения (аналогично созданию пула соединений с SQL Server) вы получите сообщение об ошибке протокола транспортного уровня.
Как и другие базы данных, среда SQL Database время от времени разрывает соединения по причине ошибок, нехватки системных ресурсов и прочих временных неполадок. В этих ситуациях среда SQL Database всегда пытается возвратить конкретное сообщение об ошибке, если со стороны клиентского соединения отправлен активный запрос. Однако не всегда возможно сообщить клиентскому приложению об ошибке, если с его стороны нет запросов, ожидающих выполнения. Например, если при работе с базой данных при помощи SQL Server Management Studio не отправлено ни одного активного запроса в течение 30 минут, время ожидания сеанса истечет. Так как активных запросов нет, среда SQL Database не может вернуть сообщение об ошибке.
Требование наличия кластерного индекса
В отличие от SQL Server каждая таблица базы данных SQL Database должна иметь кластерный индекс. При объявлении первичного ключа таблицы по умолчанию создается кластерный индекс столбца основного ключа (или нескольких столбцов, в зависимости от вида ключа). Кластерный индекс первичного ключа не является единственным способом создания кластерного индекса. Иногда это не лучшее решение. Кластеризованные индексы сортируют и хранят строки данных в таблице на основании значений их ключей. Для каждой таблицы может существовать лишь один кластерный индекс, так как сами строки данных можно сортировать только в одном порядке. Необходимо контролировать наличие кластерного индекса у каждой таблицы.
SQL Database не поддерживает создание HEAP-таблиц. HEAP-таблицей является любая таблица, у которой нет кластерного индекса. Это правило справедливо только для баз данных SQL Database. Временные таблицы располагаются в базе данных tempdb, которая входит в состав обслуживающих экземпляров SQL Server в центре обработке данных. Эти таблицы могут быть HEAP-таблицами.
При создании дополнительных некластерных индексов для таблиц, имеющих кластерные индексы, эти дополнительные индексы ссылаются на табличные данные с помощью кластерного ключа. В SQL Server некластерный индекс HEAP-данных использует для ссылки на эти данные их физические адреса. Несколько баз данных SQL Database могут храниться в одной базе данных SQL Server. Поэтому использование ссылок на физические адреса хранения данных заметно снизило бы гибкость системы SQL Database.
Все индексы в SQL Server и SQL Database хранятся в виде сбалансированных деревьев. Базовые технологии обеспечения высокой доступности и репликации в среде SQL Database основаны на репликации последовательностей сбалансированных деревьев. Эта структура позволяет проводить техническое обслуживание компьютеров независимо друг от друга. Система получает преимущества оптимизированного ввода-вывода, которые невозможно обеспечить при работе с HEAP-таблицами.
Управление транзакциями
Среда SQL Database поддерживает локальные транзакции с помощью обычных команд Transact-SQL, которые полностью соответствуют аналогичным командам SQL Server.
Параметры настройки баз данных SQL Database обеспечивают изоляцию моментальных снимков. Параметры READ_COMMITTED_SNAPSHOT и ALLOW_SNAPSHOT_ISOLATION имеют значение ON. По умолчанию в SQL Server и SQL Database установлен уровень изоляции READ COMMITTED. Так как параметр базы данных READ_COMMITTED_SNAPSHOT также используется, транзакции в среде SQL Database проходят в режиме оптимистического параллелизма. Нельзя изменить параметры базы данных SQL Database. Однако можно управлять уровнем изоляции, передавая команду SET TRANSACTION ISOLATION LEVEL перед началом транзакции. Пользователь не может изменить значение по умолчанию (READ COMMITTED) при использовании оптимистического параллелизма и задать значение SQL Server по умолчанию (READ COMMITTED) при использовании пессимистического параллелизма. Единственным способом реализации механизма работы, который применяется в SQL Server по умолчанию, является использование специального приема блокировки WITH (READCOMMITTEDLOCK) при работе с каждой таблицей в каждой из транзакций.
Устранение неполадок
Пользователь не может управлять физическим выделением ресурсов или конфигурацией используемых компьютеров и файлов баз данных. Поэтому система предъявляет минимальные требования к необходимости устранения неполадок. Может понадобиться устранять неполадки при обнаружении низкой производительности обработки запросов или проблем параллельной обработки (например, при блокировке). Уровень изоляции баз данных SQL Database по умолчанию установлен READ COMMITTED SNAPSHOT. Поэтому пользователю не придется решать серьезные проблемы блокировки.
Приемы устранения неполадок, связанных с блокировкой или неоптимальными планами выполнения, практически аналогичны в SQL Database и SQL Server. Как и в SQL Server, некоторые из основных инструментов устранения неисправностей доступны в виде представлений динамического управления (dynamic management view, DMV). Однако SQL Database поддерживает лишь некоторую часть представлений динамического управления, предоставляемых SQL Server, а некоторые из доступных представлений динамического управления имеют другой механизм работы. Например, в SQL Server для просмотра содержимого многих представлений пользователям требуется разрешение VIEW SERVER STATE, а в среде SQL Database пользователям необходимо разрешение VIEW DATABASE STATE. В SQL Server представления sys.dm_tran_locks, sys.dm_exec_requests и sys.dm_exec_query_stats отображают подробные сведения о процедурах и запросах всего экземпляра сервера. В среде SQL Database эти представления возвращают только информацию о базе данных SQL Database. Дополнительные сведения о поддерживаемых представлениях динамического управления см. в разделе «Метаданные».
Итого
Итого, получаем, что SQL Database — это специально спроектированная облачная реляционная база данных, рассчитанная на масштабирование, отказоустойчивость и использования в один клик (или совсем рядом с одним кликом). С точки зрения сравнения SQL Database и SQL Server, SQL Database не является точной копией SQL Server, но постепенно наиболее интересные возможности SQL Server становятся доступными и в SQL Database (например, облачный SQL Reporting).
PS. Ресурсы по шардингу и федерации:
- Шардинг с SQL Database — этот документ является руководством по построению приложений, в архитектуру которых заложено горизонтальное разбиение данных, называемое шардинг (sharding). Данные в нем разносятся между несколькими физическими базами данных, что обеспечивает масштабируемость приложения или сервиса по мере его роста и увеличения объема данных.
- Первое знакомство с федерациями SQL Database – это статья дает ответ на вопрос что же такое федерации в базах данных SQL Database и зачем необходима федерация.
- Федерации в SQL Database – подробное описание реализации федерации в SQL Database.
Автор: inatale
