Это руководство содержит пример для разработчиков, начинающих проект, который, возможно, будет использовать SQL Azure. Руководство предназначено для опытных архитекторов и разработчиков, имеющих опыт работы с SQL Server и, возможно, с .NET Framework. Подразумевается хорошее знание T-SQL, возможностей SQL Server, администрирования и архитектур приложений, основанных на стеке Microsoft. Руководство познакомит читателя с тем, что он должен знать, чтобы начать разработку и реализацию решений с использованием SQL Azure.
Содержание
Путь к эффективному решению с использованием SQL Azure начинается с серьезного планирования. Ранние архитектурные решения будут влиять на остальные части проекта и общий успех решения. Планирование платформы данных для вашей ситуации включает несколько ключевых решений, начиная с того решения, является ли локальный SQL Server или "облачный" SQL Azure лучшим выбором для выполнения работы. Подразумевая, что SQL Azure будет играть определенную роль в вашем проекте, можно выделить некоторые потенциальные архитектуры приложений, из которых можно выбирать. Обязательным к пониманию являются документ SQL Azure Service Level Agreement (SLA), влияние задержек в выбранной архитектуре, доступность, восстановление после сбоев и инструментарий разработчика.
В этой секции приведены более подробные сведения по этим темам для того, чтобы вы могли принять подходящее решение на ранней стадии.
Back to Top
Если вы разрабатываете проект, который будет использовать одну или несколько реляционных БД SQL Server, первым архитектурным решением должно быть определение, развертывать БД в "облако" SQL Azure либо в локальный экземпляр SQL Server. SQL Azure предоставляет очень простой в использовании движок реляционных баз данных, в архитектуру которого изначально заложены принципы высокомасштабируемого высокодоступного мультитенантного "облачного" сервиса. Присутствуют определенные экономические и оперативные аргументы для устранения локального аппаратного и программного обеспечения , и всего, что идет с ним. Расширения доступност базы данных и, возможно, других компонентов приложения за пределы корпоративного брандмауэра может дать множество новых сценариев использования. Как же решить, нужен ли SQL Azure, когда временами локальный SQL Server выглядит как наиболее приемлемое решение? Есть некоторые различия между функциональностью обоих продуктов. Это ограничения в объеме, некоторая функциональность ведет себя по-разному в SQL Azure и традиционнмы локальным SQL Server. В конце концов, наиболее важным является то, что ведет к успешному решению и удовлетворенному клиенту. Выбор между SQL Azure и локальный SQL Server должен совершаться с учетом этого критерия как основополагающего. Дерево решения на изображении 1 показывает некоторые из факторов, которые должны быть приняты в расчет при выборе между SQL Azure и SQL Server
Изображение 1 - Выбор между SQL Azure и SQL Server
Как показано на изображении 1, есть несколько аспектов, влияющих на решение (технический, экономический и связанный с политиками).
Необходимо упомянуть, что надобность в неструктурированном хранилище не рассматривается как решающий фактор в выборе. С локальным SQL Server у вас есть бинарные и large text типы данных, FILESTREAM и все ресурсы ОС Windows (файловая система, MSMQ, etc). В SQL Azure бинарные и large text типы данных также доступны, но недоступно хранилище FILESTREAM. Таблицы, блобы и очереди Windows Azure реализуют поддержку неструктурированного хранилища. Поэтому спрос в структурированном и неструктурированном хранилище встречает примерно одинаковое предложение как с локальным SQL Server, так и в случае платформы Azure. Решив, что SQL Azure - правильный выбор, вам необходимо выбрать редакцию( Web, Business), размер базы данных (от 1Гб до 150Гб), географическое расположение баз данных (так как данное руководство посвящено SQL Azure, в дальнейшем локальный SQL Server рассматриваться не будет).
На изображении 2 показан путь решения, какую редакцию и размер использовать для SQL Azure./
Изображение 2 - Выбор характеристик SQL Azure
Географическое расположение зависит от того, где находятся ваши пользователи, от того, есть ли какие-либо политические факторы, а также от того, насколько вы хотите использовать распределение по нескольким географическим точкам для поддержки устойчивости к сбоям. В списке перечислены географические точки, в которых может использоваться SQL Azure (на момент написания статья). Между датацентрами нет особо важных технический различий, кроме их расположения. Обратите внимание, что трафик из азиатских датацентров на данный момент стоит выше, чем из других.
Ключевым фактором в вынесении решения о платформе данных является соблюдение соответствующих политик или законов обработки данных. В зависимости от типа данных и страны, либо другой юрисдикции, могут присутствовать некие ограничения, накладываемые на то, где и как данные могут храниться. Этот шаг из дерева решений на изображении 1 приведен в более подробном виде на изображении 3.
Изображение 3 – Факторы соблюдения политик, относящиеся к SQL Azure и локальному расположению данных
Как показано на изображении, есть некоторое количество моментов, которые могут повлиять на хранение данных в вашем проекте. Дополнительная информация сведена в таблицу.
Важно ли расположение (например, страна), где расположены данные?
В некоторых ситуациях данные должны оставаться в пределах определенной страны. Обратите внимание, что правила использования
Azure не гарантируют расположение данных в пределах одной страны вне зависимости от выбранного датацентра.
Нарушает ли определенные законы или политики трансфер данных через политические/законные границы?
Может случиться так, что трансфер каких-либо данных нарушит новые политики. Например, в дело вступает
EU Data Protection Directive, если личные данные уходят из EU.
Защищены ли данные политиками индустрии/правительства?
(HIPAA, PCI, PII handling policies, etc.)?
Эти и другие политики имеют определенные ограничения по обработке данных. Если применяется какое-либо из них, вам необходимо оценить их влияние на выбор платформы данных
Содержат ли данные конфиденциальную информацию? Нарушит ли этот статус хранение данных в «облаке»?
Например, клиенты адвокатов или информация пациента и доктора. Помещение подобных данных в «третьи руки» (например, «облачному» провайдеру) может привести к ослаблению защиты. Другой пример – в США это информация по вопросам налогообложения. Тот, кто готовит налоговую документацию (например, бухгалтер) не может делиться ею с третьими лицами без согласия клиента.
Обязательное раскрытие данных для органов власти.
В зависимости от юрисдикции места хранения данных могут применяться различные законы, касающиеся возможностей «облачных» провайдеров в вопросах предоставления данных правоохранительным органам или органам государственной власти. В этом случае уведомление владельца может или не может быть разрешено/требоваться.
Дерево решений на изображении 1 также рассматривает безопасность как один из моментов при вынесении решения об использовании SQL Azure. Термин «безопасность» в данном контексте имеет исключительно технический контекст, необходимый для разграничения с соблюдением политик. На техническом уровне есть множество фич безопасности SQL Server, которые полностью поддерживаются в SQL Azure (или даже необходимы, например, использование SSL), однако есть те, которые не поддерживаются. Если используется одна база данных, большинство фич беопасности SQL Server доступны в SQL Azure, что включает в себя определение пользователей и ролей и контроля доступа с помощью запросов GRANT/DENY/REVOKE. На серверном уровне SQL Azure позволяет создавать логины (используя только SQL Serve authentification) и предоставляет набор ролей на серверном уровне, похожий на локальный SQL Server. Подключения к SQL Azure по умолчанию зашифрованы SSL, что не может быть выключено. Кроме этого, подключения к SQL Azure регулируются брандмауэром, и вы должны создать правила брандмауэра для предоставления доступа клиенту. Есть, однако, фичи локального SQL Server, которые не применяются в SQL Azure:: 1. Логирование успешных/неуспешных попыток входа 2. Триггеры попыток входа 3. Истечение срока жизни пароля или принудительная смена пароля. SQL Azure контролирует сложность пароля, что не настраивается. 4. Windows Integrated Authentication 5. SQL Server Audit 6. Key-based Encryption внутри БД 7. Transparent Data Encryption (TDE) Базы данных SQL Azure на диске не шифру��тся. Вы должны убедиться, что выбранная платформа соответствует требованиям, связанных с безопасностью, в вашем приложении.
Экономическое обоснование является важным аспектом выбора между SQL Azure и локальным SQL Server. Очень важно, чтобы оценка ROI сравнила расхода SQL Azure (главным образом, подписка / потребление ресурсов) и все расходы, связанные с развертыванием и использованием локального SQL Server. Расходы на локальный SQL Server включают в себя приобретение оборудования и лицензирование программног�� обеспечения, стоимость места в стойке, поддержку, электроэнергию и охлаждение серверов, сетевого оборудования, а также расходы по персоналу (администраторы баз данных и/или администраторы сервера).Полный анализ будет амортизировать затраты на жизненный цикл решения для сравнения ежегодных расходов на SQL Azure. В более широком плане, по предварительным данным, анализ рентабельности инвестиций склоняется в пользу SQL Azure в следующих условиях: - Клиенту придется покупать новое оборудование или заменить существующие аппаратные средства для поддержки решений с использованием локального SQL Server. - Новые базы данных могут быть легко перемещены в SQL Azure. - Решение будет существовать в течение короткого периода времени (например, сез��нные маркетинговые сайты). - Ценность решения для клиента не гарантирует кадровые ресурсы для управления, обновления и мониторинга локальных серверов. - Переходные процессы использования, такие как сайт заказа пиццы, которые обычно имеют от низкой до умеренной активности за исключением особых случаев, таких как спортивные мероприятия или акции, необходимо отметить, что приложения должны быть правильно спроектированы, чтобы воспользоваться преимуществами масштабирования SQL Azure . ROI часто выступает за локальный SQL Server в следующих условиях: Клиент имеет возможность использовать уже приобретенное оборудование. Базы данных или код приложения уже существует и требует сложных изменений и повторного тестирования для развертывания в SQL Azure.
SQL Azure в некоторых случаях полезно в качестве инструментария архитектора решения. В этом разделе представлено несколько общих архитектурных паттернов, использованных воспользовавшихся на ранней стадии SQL Azure.
SQL Azure – понятный и экономичный выбор в случае необходимости реляционного хранилища для приложения Windows Azure. Когда SQL Azure и другие компоненты Windows Azure развернуты в одном сайте, задержка между кодом и БД практически устраняется. Входящий и исходящий трафик SQL Azure бесплатен, если точка входа находится в том же датацентре, что и приложение Azure. Типичная архитектура с использованием Web/Worker ролей с одной или более БД SQL Azure приведена на изображении 4.
Изображение 4 – Типичная архитектура Windows Azure С недавним появлением поддержки Full IIS в Web-ролях и настраиваемых виртуальных машин, подобная архитектура может включать практически любой тип презентационной и бизнес-логики. Например, если у клиента имеется большой legacy-слой на COM+ с фронтендом на ASP.NET и обновление кода – не вариант, клиент все еще может развернуть приложение в Windows Azure как виртуальную машину со строками подключения SQL к одной или более БД SQL Azure. Подобный случай приведен на изображении 5. Конечно, это всего лишь простой пример – возможности виртуальных машин очень широки.
Изображение 5 – Развертывание COM+ и ASP.NET кода в виртуальной машине с использованием SQL Azure Примеры 1. «Облачные» бизнес-приложения или SaaS 2. Маркетинговый сайт или другие публичные веб-приложения с коротким жизненным циклом 3. Обмен или распространение данных
Ещё одним отличным случаем использования SQL Azure является гибридное приложение, которое содержит в себе компоненты, работающие в «облаке» и локальной инфраструктуре. Гибридная архитектура может быть полезна в случае необходимости совместного использования атрибутов SQL Azure и внутреннего кода. Например, использование SQL Azure может привнести преимущества высокой доступности и отсутствия необходимости администрирования, устраняя головную боль, связанную с поддержкой локального сервера БД. Часто попытка запустить сервер БД без соответствующей инфраструктуры приводят к плохому уровню сервиса. Хорошо спроектированная SQL Azure поможет избежать этого, предоставляя также хранилище, доступное из любого места мировой карты. Гибридная архитектура, кроме того, может оставить полную свободу от того, как собраны другие слои стека приложения. Приложение использует сборку Office, SharePoint и других компонентов, не подходящих для внешнего хостинга в «облаке»? Без проблем. Приложение, использующее мешанину мультивендорных технологий, нуждается в реляционном хранилище SQL в качестве бэкэнда? Нет проблем. Экземпляры приложения необходимо запускать в разных сетях с различными методами аутентификации и пользовательскими директориями, при этом подключаясь к одной БД с доверенной моделью? Нет проблем. Приложению нужно специальное оборудование или лицензирование, совместо со стандартным, экономичным и легкоуправляемым СУБД? Во всех этих случаях можно эффективно воспользоваться гибридной архитектурой. Примеры 1. Частичнооблачное бизнес-приложение 2. Приложение с данными подразделения или хранилище данных 3. Обмен/совместная работа над данными между организациями
Более простой и часто хороший способ использования SQL Azure – расширение локальной архитектуры, что отличается от гибридной архитектуры, в которой локальное приложение полностью самодостаточно. Однако с помощью этого подхода можно предоставить некоторую функциональность с помощью расширения в «облако». «Облако» затем хостит у себя некоторый spoke, поддерживаемый локальным хабом (hub). Пример этого подхода: БД в SQL Azure используется для предоставления части данных из локального бизнес-приложения для подключающихся пользователей. Например, часто обновляемый продукт и прайс-лист могут быть размещены в базе данных SQL Azure, при этом регулярно синхронизируясь с локаль��ым решением и быть доступным для пользователей с их ноутбуков или мобильных устройств.
Изображение 6 – Перенос части или полного набора данных для внешних пользователей Подобное может быть достигнуто ��спользованием VPN/DMZ серверов, что, однако, связано с определенными затратами и работой по настройке этого решения, обеспечения безопасности и дальнейшей поддержки. По сравнению с этим решением развертывание данных в БД SQL Azure выглядит проще в терминах затрат и стоимости. Пример 1. Локальные бизнес-приложения с некоторой «облачной» функциональностью 2. Обмен/совместная работа над данными и их распространение
Одним из ключевых положений для облачных вычислений является возможность масштабировать быстро и экономически эффективно. Некоторые бизнес-решения, испытывают большие пики нагрузки. Примеры: 1.Розничная организация с высокой сезонностью. Например, продавец цветов на День Святого Валентина, магазин игрушек на Рождество, фирма по вопросам налогообложения в течение налогового года. 2.Корпоративное приложение, которое испытывает скачки нагрузки во время определенных бизнес-мероприятий, таких, как конец квартала или финансового года. 3.Привязанные к событиям схемы использования, такие как маркетинговая кампания сайтов или продажа билетов на спортивные / развлекательные мероприятия. SQL Azure представляет собой прекрасный инструмент для оказания поддержки созданию очередей на уровне данных. Базы данных могут быть созданы и удалены на лету. Архитектура SQL Azure приводит базы данных в одном сервисе (т.е. логическом SQL Azure сервере) к распределению в большом пуле вычислительных ресурсов, что гарантирует отсутствие перегрузки сервера. Счета за использование SQL Azure накапливаются день за днем, так что своевременное добавление и удаление баз данных приводит к гибкому экономному планированию затрат. На изображении 7 приведена архитектура Windows Azure, в которой происходит масштабирование слоя данных сначала в сторону увеличения, потом в сторону уменьшения, в ответ на некую нагрузку.
Изображение 7 – Перед, во время и после пика загрузки SQL Azure Хотя SQL Azure и предоставляет инструментарий, позволяющий легко обрабатывать пики загрузки, все же необходимые некоторые архитектурные соображения, которые позволили бы приложению распределить данные по доступным БД SQL Azure. Обычным паттерном для этого является сознательное разделение данных между многими базами данных и обеспечение того, чтобы приложение знало, какую строку подключения использовать для конкретной информации. Обычно лучше всего разделять данные между базами данных горизонтально, с использованием шардинга. В шардинге большие или высоконагруженные таблицы логически партиционируются между базами данных. Например, в решении, ориентированном на клиента, 10% клиентов могут содержаться в 10 базах данных с идентичной структурой, связанные же данные могут находиться в других таблицах. Общие данные могут быть расположены в отдельных базах данных или дуплицироваться. Клиентский код должен иметь представление о том, как подключаться к подходящим базам данных. В SQL Azure была недавно представлена новая функциональность – федерации, которая может помочь с реализацией масштабирования. Примеры 1. Сезонная загрузка 2. Предсказуемые всплески загрузки 3. Ситуации с временным превышением размера одной БД SQL Azure
Перед вынесением решения о том, частично или полностью выполнять решение на платформе SQL Azure, важно понять предлагаемые Microsoft Service Level Agreement (SLA), являющиеся частью сервиса. Когда вы как клиент покупаете SQL Azure, вы покупаете уровень сервиса, определенный в данном документе. SLA для SQL Azure определяется как SLA по доступности, обещая определенный процент аптайма. Если сервис не удовлетворяет по аптайму этому проценту, соответствующим клиентам частично возмещается затраченная сумма за этот месяц. На данный момент не предлагается SLA по производительности или безопасности. Наиболее «свежую» версию SLA можно найти здесь. Текущее SLA для SQL Azure предоставляет 99.9% аптайма в месяц. Если процент доступности падает ниже 99.9%, клиенту возмещается 10% суммы и, если ниже 99%, возмещается 25%. Обратите внимание, что SLA допускает 10 часов запланированного времени недоступности в течение календарного года, которые отнимаются от вычислений доступности. Клиенты будут предупреждены о запланированной недоступности как минимум за пять дней. При выборе SQL Azure в качестве платформы данных и планировании операционных деталей вашего решения важно быть знакомым с этим SLA, что оно покрывает и что не покрывает. Малое количество клиентом нуждается в большем количестве гарантированного аптайма, чем предлагается. С другой стороны, много клиентов были бы очень счастливы иметь 99.9% аптайма..
SQL Azure имеет в свой основе высокодоступную архитектуру, при этом не предоставляя ничего для конфигурации этой высокой доступности. Концепция высокой доступности , исходящя из концепций локального SQL Server, таких как failover clustering, database mirroring и log shipping, недоступна в SQL Azure. Архитектура внутреннего хранилища SQL Azure заключается в репликации данных на три отдельных идентичных сервера, таким образом обеспечивая высокий уровень защиты данных. Тройная избыточность в датацентре Azure работает вкупе с SLA по доступности 99.9%. Как можно защититься от нежелательного сценария, когда целый датацентр будет недоступен или потерян? Пока нет решения удаленной репликации, встроенного в SQL Azure. Есть, однако, предложение, позволяющее частично или полностью синхронизировать данные между SQL Azure и локальным экземпляром SQL Server.
SQL Azure – движок реляционной базы данных, спроектированный специально для «облака». На стадиях планирования проекта, использующего SQL Azure, некоторые категории операций и планирования инфраструктуры могут быть пропущены. Неполный список проблем, избегаемых SQL Azure: 1. Планирование обновления оборудования и затраты 2. Контракты на поддержку оборудования 3. Лицензии на ПО ОС, СУБД, антивирусы и т.д. 4. Загрузка, тестирование и применение патчей для ОС и СУБД 5. Бэкапы сервера 6. Избыточность оборудования, охлаждение и электричество 7. Пространство для серверов 8. Кондиционирование 9. Персонал для бэкапов, мониторинга, обеспечения безопасности и управления БД, что является привлекательным выбором для небольших приложений. 10. Для предприятий: затраты на IT, связанные с загрузкой серверов БД.
Хотя SQL Azure избегает широкого спектра проблем, связанного с поддержкой локальных серверов, оно не обладает полной функциональностью локального SQL Server. Сперва необходимо отметить, что SQL Azure – грубая копия Database Engine в SQL Server. Другие компоненты SQL Server (Analysis Services и Integration Services) не под��ерживаются в SQL Azure. Windows Azure Reporting Services были анонсированы в конце 2010. Сл��дующая функциональность недоступна в SQL Azure: 1. Replication 2. Full-text Search 3. Backup/Restore 4. Database Attach/Detach 5. Service Broker 6. Linked Servers и four-part names 7. Table Partitioning 8. Distributed Transactions 9. Server and Database Level Collations (column- and expression-level are supported) 10. Audit 11. Encryption 12. Trace/Profiler 13. Logon Triggers and certain other server-level DDL triggers 14. Windows Authentication 15. Компрессия данных 16. Интеграция CLR 17. Расширенные хранимые процедуры 18. Change Data Capture 19. Extended Events 20. FILESTREAM Data 21. Resource Governor 22. Разреженные столбцы 23. SQL Server Agent 24. Управление на основе политик 25. Сбор данных производительности 26. “use” для смены контекста 27. Имена из трех частей, когда имя БД не является текущей БД или tempdb 28. Некоторые динамические представления управления Важно отметить, что SQL Azure постоянно изменяется и постоянно добавляется новая функциональность. Для последней информации по различиям в функциональности можно обратиться к Guidelines and Limitations и Transact-SQL Reference.
Поддержка SQL Azure включена в большинство последних продуктов для разработки от Microsoft. Следующий инструментарий рекомендуется для использования SQL Azure. 1. SQL Server Management Studio 2008 R2. Данный продукт поставляется с SQL Server 2008 R2 и свободно доступен (SQL Server Management Studio Express 2008 R2). Предыдущие версии SSMS позволяют запускать окна запросов к SQL Azure, но не позволяют подсоединить Object Explorer. В SSMS 2008 R2 все работает, и также присутствуют Generate Script специально для SQL Azure. 2. Windows Azure Platform Management Portal, https://windows.azure.com/. 3. Database Manager for SQL Azure https://manage-ch1.sql.azure.com/. Бывший проект “Houston”. 4. sqlcmd. 5. Visual Studio 2010. Visual Studio 2010 поддерживает SQL Azure в Server Explorer; предыдущие версии - нет. VS 2010 Data-tier applications (DAC) могут использоваться с SQL Azure; VS 2010 Database и Server не работают с SQL Azure
В большинстве аспектов построение реляционных БД для SQL Azure идентично построению в локальном SQL Server. Однако, также как и с любым ин��трументом, есть некоторые моменты, уникальные для SQL Azure. В этом разделе приведены многие из этих моментов, необходимых для эффективной разработки. Большинство концепций разработки под SQL Server подходят и для SQL Azure и это руководство не покрывает их. Есть вещи, которые отличны, или где вы можете выносить другие решения – они покрыты в этом разделе.
В широком смысле разработка моделей данных для SQL Azure ничем не отличается от такого же процесса для локального SQL Server. Есть некоторые низкоуровневые технические моменты, которые отличаются, но в целом они не меняют процесс разработки модели данных. Все таблицы должны иметь кластерный индекс. В локальном SQL Server таблицы могут быть созданы без кластерных индексов (такие таблицы называются кучами heap). По определенным соображениям, относящихся к внутренним особенностям избыточного реплицируемого хранилища SQL Azure таблицы-кучи недоступны. Запрос CREATE TABLE без указания кластерного индекса выполнится, но при выполнении запроса INSERT будет выброшена ошибка (до добавления кластерного индекса). Для таблиц или индексов нельзя использовать filegroup. Простой вывод из того факта, что SQL Azure устраняет физическое управление файлами БД. При создании таблицы SQL Azure управляет всем сама, в том числе тем, как и где файлы БД расположены на диске. Партиционирование таблиц не поддерживается. Не включайте партиционирование в архитектуру модели данных SQL Azure. Не все типы данных поддерживаются по сравнению с локальным SQL Server. Основные типы данных полностью поддерживаются. Типы данных geography и geometry также поддерживаются. Так как не поддерживается интеграция CLR, определенные пользователем типы CLR не разрешены. Тип данных XML поддерживается, но без схем. Uniqueidentifier поддерживается, также как и функция NEWID(). NEWSEQUENTIALID() не поддерживается. Типы больших объектов (text, ntext, image) поддерживаются. Устаревшие функции (READTEXT, WRITETEXT, UPDATETEXT) не поддерживаются. varchar(max), nvarchar(max), и varbinary являются предпочитаемыми типами данных для больших строк и бинарных данных. Подробнее Data Types, про поддерживаемые и неподдерживаемые функции - Transact-SQL Reference.
Одной из самых серьезных архитектурных проблем гибридных приложений, совмещающих локальный код с БД в Azure, являются задержки в сети. Для приложений, полностью находящихся в Windows Azure (хотя бы в одном сайте Azure), это по большей части не является проблемой. Для более же распределенных географически решений для предотвращения сетевых задержек необходимо применять меры. Для достижения этой цели обычно концентрируются на двух моментах. Первый – минимальное количество round trip calls к SQL Azure. Второй – минимальное количество передаваемых данных. Возьмем простой пример, показывающий три разных подхода к программированию и приводящих к одному результату. Допустим, у вас есть одна таблица с сообщениями, хранящаяся в БД SQL Azure. Пример 1 показывает DDL для этой таблицы и двух хранимых процедур, которые вставляют данные.
Пример 1 – Создание таблицы и хранимых процедур Первая хранимая процедура (usp_AddTweet) – простая вставка одной записи. Вторая хранимая процедура принимает параметр типа таблицы и вставляет все записи в параметре таблицы внутри одного вызова хранимой процедуры. Давайте рассмотрим три подхода к добавлению 100 сообщений в таблицу TweetLog. Пример 2 показывает метод C#, добавляющий 100 сообщений путем создания ADO.NET SqlCommand и выполнения этого метода в цикле.
Пример 2 – Код на C# для вставки 100 сообщений в цикле Как вы могли ожидать, будет много оверхеда, связанного с round trips, в связи с вызовом хранимой процедуры 100 раз. Еще одним подходом может быть создание пакета (batch) SQL и выполнение его в одном вызове. Код в примере 3 выполняет именно эту задачу, объединяя 100 запросов INSERT и выполняя пакет в одном вызове SqlCommand.
Пример 3 – Код на C# для вставки 100 сообщений в одном пакете Еще одним подходом яв��яется использование параметров таблицы, возможности, представленной в SQL Server 2008. В данном случае мы можем вызвать хранимую процедуру один раз с полностью переданными в одном структурированном параметре данными. В этом случае используется хранимая процедура usp_AddTweets. Ключевой частью выполнения этой работы является объект, назначаемый для ADO.NET SqlParameter для параметра таблицы, который может быть DataTable, DataReader, или каким-либо собственным классом C#, как приведено в примере 4. Также как и с пакетом, мы выполняем один вызов к БД SQL Azure.
Пример 4 – Код на C# для вставки 100 сообщений с типизированным параметром таблицы Таблицы показывает количество времени, затраченного этими примерами кода в случае запуска из Eastern United States для SQL Azure, находящегося в North Central US. Конечно, результаты могут отличаться в зависимости от вашего местоположения, сайта SQL Azure и условий сети. Однако, пропорция видна.
Плоха�� производительность выполнения 100 хранимых процедур неудивительна. Более информативна более совершенная производительность примера 4 над примером 3. Конечно, оба выигрывают от использования одного round trip. Однако, пример 4 выигрывает за счет более компактной загрузки и оптимизации, предоставляемой хранимой процедурой. Опытные разработчики увидят, что нет ничего нового. Минимизация количества round trips - это давняя хорошая практика в разработке клиент-серверных и распределенных архитектур. Работа через Интернет с «облачными» данными, однако, делает еще более важной эту практику. По факту, это может помочь или навредить жизнеспособности архитектуры. Несмотря на простоту примера разница между тремя подходами является иллюстрацией того, что можно выбрать при разработке вашего собственного кода. В частности, хранимые процедуры с параметрами таблиц – очень эффективная техника. Обратите внимание, что параметров для хранимой процедуры может быть много.
ADO.NET Entity Framework является частью.NET Framework, предоставляющей богатый набор классов для создания распределенных приложений. EF полностью поддерживает SQL Azure и является хорошим выбором для создания кода доступа к данным в SQL Azure. Обратите внимание, что при использовании EF с SQL Azure выбор между Lazy Loading и Eager Loading связанных объектов может иметь весьма серьезное влияние , если ваш код будет выполняться удаленно. Принуждение EF к минимизации round trips с Eager Loading может увеличить производительность. Конечно, лучший выбор будет варьироваться относительно количества данных в вашей БД и паттернах клиента. Подробнее про Eager Loading, EF и SQL Azure - здесь.
SQL Azure поддерживает подключения из PHP с использованием Microsoft Drivers for PHP for SQL Server. Подключение к SQL Azure нуждается в строке подключения, указывающей на источник данных SQL Azure. Подробнее про драйвер - MSDN. SQL Azure доступна также из кода на Java с использованием Microsoft JDBC driver. C февраля 2011 обновленная версия SQL Server JDBC 3.0 с полной поддержкой SQL Azure доступна здесь. Веб-сервисы также являются важной частью при вынесении решения о доступе к Azure с кроссплатформенных стеков. Возможно, лучше начать с WCF Data Services (a.k.a. OData). С Windows Azure вы можете размещать любой тип веб-сервисов (ASMX, WCF, например) для получения доступа к данным SQL Azure.
Ключевой особенностью SQL Azure является масштабирование – распределеные данных и нагрузки между множеством БД. Есть две причины, по которой масштабирование особенно актуально для SQL Azure. Первая – текущая версия SQL Azure поддерживает максимальный размер БД в 150 Гб. Для приложений, нуждающихся в большем количеством данных, решением является разделение данных между множеством БД. Вторая причина – эластичность, ключ к преимуществам облачных вычислений. Для того, что полно воспользоваться этим преимуществом, приложение, использующее SQL Azure, может быть спроектировано для распределения данных между нескольими физическими БД. При необходимости минимального количества хранилища и вычислительных мощностей количество БД может быть уменьшено, и наоборот. В идеале приложение может прозрачно взаимодействовать с данными вне зависимости от количества используемых БД. На данный момент для масштабирования между множеством БД SQL Azure является реализация шардинга
В «шардированной» архитектуре данные распределяются горизонтально между БД. Если вы знакомы с концепцией распределенных partitioned views, у вас есть базовое представление о шардинге. Подробнее про шардинг здесь.
Релиз SQL Azure Database November 2011 содержал Federations, предназначенные для предоставления поддержки горизонтально масштабируемых БД на уровне движка. Некоторые из задач, которые эта возможность упрощает: 1. Подключение к необходимой БД для работы с определенным куском данных. 2. Разделение шардов для обработки изменений в данных и нагрузке без влияния на доступность данных.
Инструменты по настройке и оптимизации нагрузки SQL Azure имеют несколько серьезных различий с локальным SQL Server. Эти инструменты более недоступны, так как СУБД расположены на управляемых Microsoft серверах в «облаке», поэтому нет необходимости в доступе к Windows perfmon для определения активности в БД. SQL Profiler недоступен с SQL Azure, и некоторые из DMV, связанных с производительностью, доступных в локальном SQL Server, недоступны в SQL Azure. Доступные DMV: sys.dm_exec_sql_text sys.dm_exec_query_stats sys.dm_exec_requests sys.dm_exec_sql_text Подробнее про DMV, Troubleshooting and Optimizing Queries with SQL Azure. SQL Server Management Studio можно использовать для просмотра примерных и актуальных планов выполнения для запросов в SQL Azure. Стандартная статистика IO и CPU также доступна. SET STATISTICS IO и SET STATISTICS TIME возвращают информацию о сервере. Client Statistics (Query > Include Client Statistics) предоставляют информацию по трафику и задержках.
Часто необходимо синхронизировать данные между локальной и «облачной» БД. В SQL Azure эта функциональность доступна с помощью Microsoft Sync Framework. Sync Framework является фреймворком на основе .NET для синхронизации между различными источниками данных. Sync Framework Developer Center – хорошее место для того, чтобы почитать про эту технологию. Sync Framework является рекомендуемым инструментов для синхронизации локальных данных с SQL Azure. Команды разработки также должны иметь навыки разработки под .NET для реализации функциональности синхронизации данных. Microsoft инвестирует в расширение и улучшение возможностей Sync Framework по использованию его с SQL Azure. Однако есть функциональность, не поддерживаемая в SQL Azure - SQL Replication Linked Servers или распределенные транзакции. В то время как DBA или SQL разработчики могут настроить репликацию и другие SQL технологий, Sync Framework в настоящее время напрямую связан с. NET разработчиками. Для синхронизации данных вы также можете использовать Bcp.exe или SSIS. Это может быть или не быть практичным в зависимости от характера синхронизации. Есть ситуации, когда данные в SQL Azure необходимо синхронизировать с SQL Server, после чего уничтожить все данные в SQL Azure. BCP и SSIS могут помочь в этих ситуациях. Пример 5 показывает пример кода для выполнения синхронизации между локальным SQL Server и SQL Azure с использованием текущей версии Microsoft Sync Framework. Два ключевых момента, на которые стоит сразу обратить внимание при использовании Sync Framework: 1. Все таблицы для синхронизации должны иметь первичные ключи 2. Некоторые типы данных SQL Server (например, определенные пользователем типы) не поддерживается для синхронизации. Больше примеров в Sync Framework Developer Center.
Пример 5 – Простая синхронизация с использованием Microsoft Sync Framework 2.1 Надо отметить, что Microsoft Sync-технология создает/добавляет некоторые таблицы для трекинга в ваши БД в SQL Azure в процессе с��нхронизации и таким образом «съедает» некоторое пространство. Поэтому вы должны, перед тем как использовать синхронизацию, протестировать свое решение.
Обычный вопрос, возникающий при развертывании БД в удаленные датацентры, особенно актуальный для корпоративных клиентов, это как проводить географическую репликацию данных между разными датацентрами. Мотивация здесь понятна – устойчивость к катастрофам и помещение данных поближе к пользователям разных регионов. Для SQL Azure в этом случае можно использовать Microsoft Sync Framework. В целом Sync Framework может синхронизировать данные между двумя БД в Azure, где бы они не были, также, как может синхронизировать данные между локальным SQL Server и БД в Azure. Разница только в строках подключения. Есть три подхода, различающиеся только в том, где работает код для Sync Framework. 1. Код синхронизации может работать локально и вызываться планировщиком или по наступлению какого-либо события. Код в примере 5, например, будет работать если обе строки подключения будут указывать на БД в Azure в разных датацентрах. 2. Код синхронизации может быть упакован вами для развертывания в Azure Worker-роль. 3. В CTP 1 “SQL Azure Data Sync” (http://www.sqlazurelabs.com/) можно настраивать и использовать планировщик синхронизации.
Большинство методов обработки ошибок SQL в SQL Azure не отличаются от обработки ошибок в локальном SQL Azure, однако есть несколько специфичных для SQL Azure моментов. Throttling: будучи мультитенантным сервисом платформы данных, SQL Azure следит за тем, чтобы предотвратить пики загрузки, которые могут задеть других пользователей. В случае пиков нагрузки на CPU, память, tempdb, большого количества транзакций в логе или IO SQL Azure ограничит (throttle) соответствующее подключение, выбросив ошибку 40501 и закрыв подключение. Текст сообщения об ошибке будет включать код причины ошибки, из которого можно будет получить источник проблемы. Закрытие подключения: SQL Azure может закрыть подключение с другим кодом ошибки из-за долгой неактивности, долговыполняемых транзакций и т.д. Ограничение по размеру БД: если БД достигает максимального сконфигурированного значения размера, любые операции по добалению данных в нее приведут к ошибку 40544. Вы можете решить эту проблему, ограничив количество данных в БД или используя запрос ALTER DATABASE для увеличения максимального размера (до 150Гб). Помните, что увеличение размера БД до следующего «слоя» увеличит дневную стоимость БД. Полный перечень ошибок Error Messages (SQL Azure Database).
Для разрешения ошибок и поддержки SQL Azure назначает каждому подключению собственный ID трейса сесси. Это GUID, который может быть получен с помощью функции Transact-SQL CONTEXT_INFO(). Например: SELECT CONVERT(NVARCHAR(36), CONTEXT_INFO()) Кроме пользы в вопросах отладки этот ID может быть предоставлен технической поддержке Microsoft для определения проблемы. Так что получать этот ID – хорошая идея. CONTEXT_INFO может быть также получен из DMV sys.dm_exec_sessions и sys.dm_exec_requests, которые могут реализовать видимость идентификатора трейса для других активных сессий.
Движок SQL Azure – отличный инструмент для хранения и управления данными в «облаке». Подключение SQL TDS, может и не являться идеальной моделью подключения. Во многих сценариях лучшим выходом будет являться использование веб-сервиса для предоставления данных клиентам, даже если данные хранятся в SQL Azure. Для веб-сервисов обычно лучшей платформой является Windows Azure. Любой из .NET веб-сервисов WCF и ASMX может быть размещен в Web-роли Windows Azure. Кроме гибкого протокола (например, HTTP vs. TDS) это может дать некоторые опции аутентификации типа логинов SQL. Open Data Protocol (Odata) – интересная опция для доступа веб-сервиса к данным SQL Azure. OData – основанный на стандартах протокол для получения и о��новления данных. OData поддерживается в.NET Framework в WCF Data Services, и доступ к данным может быть легко получен из кода на .NET Framework, Silverlight, JS, PHP, Obj-C и других языках.
Server Management Objects (в SQL Server 2008 R2) частично работают в использовании с SQL Azure. Команда разработки рекомендует пока не использовать SMO для приложений. SMO могут быть использованы для простого управления и скриптинга БД SQL Azure, о��нако они имеют ограничения в поддержке со стороны SQL Azure. Подробнее Tools and Utilities Support (SQL Azure Database).
Факт того, что SQL Azure расположено в «облаке» в датацентре Microsoft, меняет техники и соображения того, как развертывать и обеспечивать безопасность БД.
После создания сервера SQL Azure этот сервер недоступен для любых внешних подключений. Для разрешения подключения должны быть сконфигурированы правила брандмауэра, состоящие из имени правила и диапазона IP. Диапазон может покрывать несколько адресов (71.178.20.1 - 71.178.20.255) или состоять из одного адреса ( 71.178.20.32 - 71.178.20.32). Правила можно добавить на Windows Azure Management Portal или с помощью хранимой процедуры. Обратите внимание, что первое правило должно быть добавлено с портала, так как изначально ни один запрос не сможет быть выполнен на SQL Azure. Чтобы добавить правило на портале, выберите сервер и найдите кнопку Firewall Rules, находящуюся в секции информации о сервере (Изображение 8).
Изображение 8 – Управление правилами брандмауэра на Windows Azure Management Portal Нажмите на кнопку, чтобы раскрыть таблицу правил брандмауэра и нажмите Add. В появившемся диалоге (изображение 9) введите имя и диапазон IP, которому будет разрешен доступ к серверу, после чего нажмите OK.
Изображение 9 – Определение правила брандмауэра Перед тем, как правило будет задействовано, может пройти несколько минут. Правила могут быть добавлены, изменены или удалены с помощью T-SQL с использованием хранимых процедур типа sp_set_firewall_rule и sp_delete_firewall_rule. Например, следующая команда создаст правило брандмауэра для определ��нного диапазона IP: exec sp_set_firewall_rule 'PhoenixOffice', '123.123.123.1', '123.123.123.128' Обратите внимание, что доступ к вашему серверу из других сервисов Windows Azure (например, Web-роли), также выключен по умолчанию. Для разрешения доступа другим сервисам необходимо отметить поле “Allow other Windows Azure services to access this server” на портале (Изображение 8) или добавить правило с диапазоном адресов 0.0.0.0 – 0.0.0.0 : exec sp_set_firewall_rule 'Windows Azure', '0.0.0.0', '0.0.0.0'
authentification. Традиционная SQL authentification основана на использовании логина и пароля, и она является единственным поддерживаемым типом аутентификации, так как сервера SQL Azure в «облаке» не имеют доверенных отношений с доменами контроллеров. SQL authentification может быть в некоторых ситуациях неудобна, так что вы можете посмотреть на некий компонент в вашем решении, который использует AD single sign-on для предоставления клиенту SQL Azure логина и пароля. Роли уровня сервера. SQL Azure не имеет фиксированного набора серверных ролей, как в SQL Server, вместо этого в SQL Azure присутствует две роли базы данных в БД master, имеющих некоторые административные права.
Разрешения на создание и управлени БД, аналогично серверной роли dbcreator
Нет роли sysadmin, ближайшим аналогом в SQL Azure является “server level principal login”, аналог sa в локальном SQL Server. Это настраивается при развертывании аккаунта SQL Azure. Роли уровня БД Набор ролей БД идентичен набору в локальном SQL Server. Контроль доступа Для отдельной БД дискреционный контроль доступа для GRANT(DENY) разрешений на объекты или утверждения аналогичен SQL Server.
Подключаясь к SQL Azure с помощью ADO.NET, ODBC, или PHP, необходимо использовать стандартную строку подключения, используемую соответствующей библиотекой. Есть несколько хороших принципов создания строк подключения для SQL Azure.
Если не указано значение этого атрибута, подключение будет совершено к БД
master. Поэтому укажите имя БД, помня, что use не поддерживается в SQL Azure и переключиться после подключения на другой контекст БД нельзя
Из-за различий между реализациями
TDS в различных инструментах может быть необходимо добавить @servername к user id: ‘johnsmith@servername’
Windows Azure Management Portal позволяет удобно получать строку подключения для подключения к вашей БД SQL Azure. На портале выберите SQL Azure (иконка Database) и выберите БД. В свойствах справа (изображение 10) будет значение для “Connection Strings.” Нажмите на многоточие и в появившемся окне будут сформированные строки подключения для ADO.NET, ODBC, PHP.
Изображение 10 – Строки подключения на портале Необходимо обеспечивать безопасность строк подключения, так что только авторизованные пользователи могли получить к ним доступ. Кроме этого можно использовать шифрование.
В SQL Azure нельзя осуществлять аудит (не)успешных входов. SQL Server Audit, SQL Trace не поддерживаются. Стандартные триггеры DML на таблицах (INSERT, UPDATE, DELETE) могут использоваться для отслеживания изменений в данных. Поддерживается набо�� серверных и БД триггеров DDL.
Если необходимо изменить пароль для существующего логина, можно воспользоваться только T-SQL: ALTER LOGIN login_name WTH PASSWORD = new_password Данный запрос можно выполнять только на БД master.
Во многих случаях разработка решения сначала ведется для локального SQL Server, либо существующее решение должно быть портировано на SQL Azure. Перенос схемы и кода в SQL Azure можно осуществить с помощью скриптинга БД в SQL Server Management Studio 2008 R2 (SSMS). Однако, необходимо убедиться, что скрипт будет работать в SQL Azure, так как есть небольшие различия в синтаксисе T-SQL между локальным SQL Server и SQL Azure. Поэтому необходимо указать SSMS на генерацию совместимого с SQL Azure скрипта. На изображении 11 это сделано с помощью страницы Set Scripting Options в SSMS Generate Scripts. На этой странице нажмите Advanced и укажите опцию “Script for the database engine type” в “SQL Azure Database”. Данная опция доступна только в SQL Server 2008 Management Studio R2.
Изображение 11 – Создание совместимого с SQL Azure скрипта в SSMS Для скриптования данных для выгрузки их в БД SQL Azure можно использовать тот же Generate Scripts: в Advanced Scripting Options опция “Types of data to script” (Изображение 12).
Изображение 12 – Скрипт схемы и данных для переноса в SQL Azure Если значение этой опции выставлено в “Schema and data”, SSMS включит запросы INSERT для всех записей. Это удобно для маленьких БД, но неэффективно для больших. Для больших БД лучшим вариантом будет использование опций, описываемых в следующем разделе.
Часто необходимо загрузить большие объемы данных в БД SQL Azure, например, при первом развертывании БД. Для эффективной загрузки данных в БД SQL Azure поддерживает следующие инструменты: 1. Bulk Copy (bcp.exe) 2. SQL Server Integration Services (SSIS) 3. Программный код с использованием ADO.NET SqlBulkCopy API Best practices по использованию данных инструментов:
Демонстрация:
В SQL Server Migration Assistant 4.2 в 2010 году была добавлена функциональность переноса БД Microsoft Access (от 97 и выше) в SQL Azure и локальный SQL Server. Данный инструмент является мастером переноса структуры и данных из локальной БД Access в существующую БД SQL Azure. Для объектов Access, который нельзя перенести напрямую (например, некоторые из запросов) SSMA сгенерирует подробный отчет. SSMA 2008 for Access 4.2 – инструмент для переноса данных из маленьких приложений в SQL Azure. Можно скачать здесь. Только SSMA 2008 включает поддержку SQL Azure. Руководство по SSMA 22008 for Access с SQL Azure: Migrating Microsoft Access Applications to SQL Azure. Для MySQL есть другая версия SSMA 2008,позволяющая переносить данные из MySQL в SQL Azure. Можно скачать здесь.
Data Tier Applications (“DAC”) были представлены в SQL Server 2008 R2, с поддержкой разработки в Visual Studio 2010. Они полезны для упаковки схемы, кода и конфигурации БД для развертывания на другой сервер.
При нахождении БД в production, есть некоторые задачи, которые необходимо выполнять для поддержки. SQL Azure устраняет большинство традиционных задач по поддержке и управления, однако есть некоторые стандартные задачи типа поддержки индексов и статистики, которые нужно вы��олнять и с SQL Azure. В некоторых случаях есть совершенно новые задачи поддержки, актуальные для SQL Azure, например, отслеживание использование и оплаты с использованием Azure DMV.
В SQL Azure не поддерживается встроенное резервирование и восстановление.
SQL Azure по умолчанию поддерживает Database Copy. При этом создается новая БД в SQL Azure, которая транзакционно идентична существующей БД, что выполняется с использованием специального синтаксиса в запросе CREATE DATABASE: CREATE DATABASE destination_database_name AS COPY OF [source_server_name.]source_database_name Пользователь, выполняющий этот запрос, должен иметь роль dbmanager на удаленном сервере (для создания новой БД) и db_owner на сервере-источнике. Подробнее Copying Databases in SQL Azure.
Данные в БД SQL Azure могут резервироваться в локальную БД или БД в SQL Azure с использованием BCP, SSIS,.NET SqlBulkCopy API. Эти инструменты не резервируют структуру и объекты БД, поэтому вам необходимо сгенерировать скрипты для этого. Подробнее - здесь (©Microsoft SQL Customer Advisory Team), здесь (для BCP).
В SQL Azure индексы могут фрагментироваться с течением времени, поэтому необходимо периодически проверять их и, если необходимо, пересоздавать. Синтаксис для утверждения ALTER INDEX в SQL Azure по сравнению с локальным SQL Server ограничен, но синтаксис для пересоздания индексов идентичен. Реорганизация индексов в SQL Azure не поддерживается. Онлайн и оффлайн пересоздание индекс поддерживается. Еще одной рутинной работой является поддержание актуальной статистики. Особых различий в управлении статистикой между SQL Azure и локальным SQL Server нет. Поддерживаются: UPDATE STATISTICS sp_updatestats sp_autostats Утверждение ALTER DATABASE, однако, не может быть использовано для изменения настроек автоматическоого создания и обновления статистики на уровне БД. Эти настройки в SQL Azure имеют значение по умолчанию TRUE (ON) и не могут быть изменены. Если вам действительно необходимо это, используйте хранимую процедуру sp_autostats и контролируйте поведение на уровне таблицы/индекса. В большинстве ситуаций же вы можете не изменять стандартное состояние автообновления.
В зависимости от модели подписки, используемой вашим клиентом, SQL Azure может оплачиваться исходя из использования, что делает ценной задачу отслеживания потребления трафика и пространства в реальном времени. Хотя на портале Azure и доступны отчеты, клиенты часто нуждаются в некоторых собственных отчетах о затратах на использование. Для этого в SQL Azure есть DMV. Использование трафика вашего аккаунта SQL Azure доступно с помощью DMV sys.bandwidth_usage, доступного только в БД master. Для просмотра этого представления вы должны подключиться к БД master. Пример показан на изображении 13. Столбец quantity указан в килобайтах.
Изображение 13 – Набор результатов sys.bandwidth_usage. Quantity – в Кб Использование БД доступно с помощью DMV sys.database_usage, также доступного только в БД master. Пример – изображение 13. Обратите внимание, что quantity 1 – для одной БД 1Гб. Quantity 2 – отчет для двух БД 2Гб. Если в конкретный день будет использоваться одна БД 5Гб, DMV предоставит отчет для quantity 5 .
Изображение 14 – Набор результатов sys.database_usage Эти DMV полезны, однако они предоставляют отчет только по прошедшему времени. Если вы хотите проверить актуальный размер БД SQL Azure, вы можете использовать T-SQL. Однако хранимая sp_spaceused в SQL Azure недоступна. Может помочь DMV sys.dm_db_partition_stats. Следующий запрос T-SQL выведет примерный размер БД. SELECT (8.0 * SUM(reserved_page_count)) / 1024 AS 'Database Size (MB)'FROM sys.dm_db_partition_stats Этот запрос затронет только текущую БД, так что вам необходимо выполнить его, подключившись к необходимой БД. Обратите внимание, что разрешения на sys.dm_db_partition_stats в БД master отсутствует даже для администраторов.
Обычной задачей является обнаружение проблемы, вызывающей блокировку. В SQL Azure привычные для этого инструменты sp_who2, SSMS Activity Monitor недоступны. Однако можно использовать DMV. Здесь можно почитать про запрос DMV для обнаружения заблокированных процессов. Здесь перечислены доступные DMV по производительности и решению ошибок. Также - Monitoring SQL Azure Using Dynamic Management Views.
Запланированная поддержка (например, реорганизация индексов) может быть иногда нужна, особенно для больших или высоконагруженных БД SQL Azure. К сожалению, SQL Server Agent в SQL Azure недоступен, что значит, что в Azure нет способа для планировки задач. Временным решением может быть использование локального планировщика, например, локального экземпляра SQL Server Agent. Back to Top
Wiki: SQL Azure Delivery Guide