SQL Azure и Windows Azure Table Storage

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

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

Я не стану никому диктовать, какую именно технологию предпочесть, но поясню некоторые принципы, которыми стоит руководствоваться, оценивая требования к решению и учитывая функциональность и ограничения как Windows Azure Table Storage, так и SQL Azure. Кроме того, в статье будут даны примеры кода, чтобы можно было прочувствовать, как работать с каждой из этих технологий.

Обработка данных

SQL Azure и другие реляционные базы данных обычно предоставляют средства обработки данных поверх системы хранения. В целом, пользователи реляционных СУБД в большей мере заинтересованы в обработке данных, а не в простом хранении информации в базе данных и выборке из нее информации.

Например, если бы вам нужно было найти совокупный доход компании за данный период, вам пришлось бы просканировать сотни мегабайтов данных по продажам и подсчитать сумму. В случае базы данных вы можете отправить ей единственный запрос (несколько байтов), который заставит ее извлечь данные (возможно, многие гигабайты) с диска в память, отфильтровать данные на основе указанного периода времени (что в большинстве случаев сокращает объем данных до нескольких сотен мегабайт), вычислить сумму показателей продаж и вернуть конечное значение клиентскому приложению (несколько байтов).

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

SQL Azure предоставляет средства обработки данных через запросы, транзакции и хранимые процедуры, выполняемые на серверной стороне, а приложению возвращаются лишь результаты. Если ваше приложение требует обработки больших наборов данных, тогда выбирайте SQL Azure. А если ваше приложение хранит и извлекает (сканирует/фильтрует) большие наборы данных, но не требует обработки данных, — Windows Azure Table Storage.

— Тони Петросян (Tony Petrossian), главный менеджер программ в группе Windows Azure

Обзор вариантов

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

• доступ к реляционным данным: SQL Azure;
• доступ к файлам и объектам: Windows Azure Storage;
• локальный кеш на диске: локальное хранилище на основе ролей.

Однако, чтобы сузить выбор, вы можете задать себе несколько простых вопросов, например:

• как сделать общими файлы, доступные для всех ролей?
• как сделать файлы доступными и легко обновлять их?
• как предоставить семантику структурированного доступа и в то же время обеспечить достаточную вместимость хранилища и его производительность?
• какой вариант дает максимальную производительность или максимальную масштабируемость?
• каковы требования к дополнительному обучению?
• что такое хронология управления (management story)?

Начиная тернистый путь к четкому решению, легко запутаться при сравнительном анализе преимуществ в функциональности и ограничений. Вновь фокусируясь на SQL Azure и Windows Azure Table Storage, я опишу некоторые идеальные шаблоны применения и дам несколько примеров кода, в которых они используются.

Основы SQL Azure

SQL Azure предоставляет базовую функциональность реляционной базы данных для использования приложениями. Если у вашего приложения есть данные, которые надо размещать в реляционной СУБД, вам лучше всего пойти по этому пути. SQL Azure позволяет применять привычную семантику для доступа к данным через SQL-выражения. Кроме того, SQL Server Management Studio (SSMS) можно напрямую подключать к SQL Azure и тем самым получать простые в использовании и хорошо известные средства для работы с базой данных вне вашего кода.

Например, подготовка новой базы данных проходит в несколько этапов, требующих использования как SQL Azure Web Management Console, так и SSMS. Вот эти этапы.

1. Создаем базу данных через веб-интерфейс.
2. Создаем правило, чтобы обращаться к ней с локального компьютера.
3. Подключаемся к этой базе данных через локальную SSMS.
4. Выполняем DDL в контексте контейнера базы данных.

Если приложение в настоящее время использует SQL Server или аналогичную реляционную СУБД, то SQL Azure будет самым простым способом перемещения ваших данных в облако.

SQL Azure также является лучшим выбором для доступа через облако к структурированным данным. Это справедливо независимо от того, размещено приложение в Windows Azure или нет. Если у вас есть мобильное или даже настольное приложение, SQL Azure позволяет поместить данные в облако и обращаться к ним из этих приложений.

Использование базы данных в облаке мало чем отличается от работы с таковой на локальном компьютере, но аутентификацию нужно обрабатывать соответствующими средствами SQL Server. Возможно, вы захотите взглянуть на проект Microsoft под кодовым названием «Houston», который является новой консолью управления, разрабатываемой для SQL Azure на основе Silverlight. Подробности об этом проекте см. по ссылке sqlazurelabs.cloudapp.net/houston.aspx.

Разработка для SQL Azure

Написать небольшое приложение-пример на основе Windows Forms с одной сеткой данных, которая отображает данные из базы данных Pubs, не сложнее, чем аналогичную программу, использующую локальную базу данных. Я запускаю мастер в Visual Studio для добавления нового источника данных, и он помогает мне создать строку подключения и набор данных. В нашем случае строка подключения в файле app.config выглядит так:

<add name="AzureStrucutredStorageAccessExample.Properties.Settings.pubsConnectionString"

     connectionString="Data Source=gfkdgapzs5.database.windows.net;Initial Catalog=pubs;Persist Security Info=True;User ID=jofultz;Password=[password]"

     providerName="System.Data.SqlClient" />

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

Вернемся к моему преднамеренно тривиальному примеру и извлечем представление TitleView из базы данных Pubs.При этом мы получим кое-какой сгенерированный код в наборе данных с именем по умолчанию — pubsDataSet (рис. 1).

Рис. 1. Автоматически сгенерированный код для доступа к SQL Azure

Я перетащил на форму DataGridView и сконфигурировал соединение. После этого запустил программу и в конечном счете получил представление данных в сетке, как показано на рис. 2.

Рис. 2. Данные SQL Azure в простой сетке

Я не пытаюсь продать идею, что вы можете создать корпоративное приложение с помощью мастеров в Visual Studio, а хочу показать, что доступ к данным более-менее эквивалентен SQL Server и что его поведение соответствует ожидаемому. Это означает, что вы можете генерировать модель сущностей и использовать LINQ так, будто она находится на локальной машине, а не в облаке (рис. 3).

Рис. 3. Использование модели сущностей и LINQ

Отличное нововведение, выходящее за рамки обычной локальной базы данных SQL Server, — вариант предоставления данных как OData-канала (в настоящее время доступен через sqlazurelabs.com). Вы получаете REST-запросы, например:

https://odata.sqlazurelabs.com/

  OData.svc/v0.1/gfkdgapzs5/pubs/

  authors?$top=10

И даете ответ в формате либо OData, либо JSON (при использовании параметра $format=JSON). Это потенциально важное преимущество для разработчика приложений, так как вы получаете не только стандартное поведение SQL Server, но и дополнительные методы доступа через конфигурационные файлы без написания кода. Это позволяет уделять основное внимание сервисному или прикладному уровню, создающему добавочную стоимость для бизнеса, а не программированию инфраструктуры для обмена данными с хранилищем по сети.

Если приложению нужен доступ к традиционным реляционным данным, SQL Azure скорее всего будет лучшим и самым простым вариантом. Но есть и другие причины рассматривать SQL Azure как главный вариант по сравнению с Windows Azure Table Storage.

Первая причина — высокая частота транзакций, подразумевающая частые запросы к хранилищу данных (все операции). При пользовании SQL Azure плата взимается без учета индивидуальных транзакций.

SQL Azure также позволяет задействовать SQL Azure Data Sync (sqlazurelabs.com/SADataSync.aspx) для синхронизации различных баз данных Windows Azure наряду с возможностью синхронизации между локальными базами и данных и хранилищами SQL Azure (microsoft.com/windowsazure/developers/sqlazure/datasync/). Я расскажу об архитектуре и применении SQL Azure синхронизации данных с локальным хранилищем в будущей статье, когда мы дойдем до архитектуры узлов ветвления (branch node), применяемой в SQL Azure.

Windows Azure Table Storage

К этому моменту вы увидели преимущества использования SQL Azure для своего хранилища. А когда же выгоднее опираться на Windows Azure Table Storage? Существует ряд случаев, где выбор SQL Azure может оказаться неподходящим.

Если приложение переделывается для перемещения в Интернет или реализация уровня хранения данных не закончена, то, вероятно, вы захотите присмотреться к Windows Azure Table Storage. Аналогично, применение Windows Azure Table Storage имеет смысл, если вам не требуется реляционное хранилище или если одновременный доступ ограничен рамками единственной таблицы и операции объединения (joins) не нужны. В этом случае ваши наборы данных невелики, и операции объединения можно было бы обрабатывать на клиентской стороне с помощью LINQ.

Вам также стоит подумать о Windows Azure Table Storage, если данных у вас больше, чем максимальный объем, поддерживаемый SQL Azure (который в настоящее время составляет 50 Гб на один экземпляр). Заметьте, что ограничение на объем можно преодолеть за счет разбиения данных на разделы, но это увеличит плату за пользование SQL Azure. То же пространство в Windows Azure Table Storage окажется, по-видимому, менее дорогим, а поддержка разбиения на разделы встроена в это хранилище и управляется на основе объявленного ключа раздела.

Кроме того, из-за оплаты каждой транзакции в случае использования Windows Azure Table Storage предпочтительнее работать с данными с меньшей частотой обращения или данными, которые можно легко кешировать.

К другим преимуществам Windows Azure Table Storage относятся случаи, когда приложению нужна та или иная форма структурированного доступа, например с поиском по индексу, но в хранилище содержатся главным образом большие двоичные объекты (Binary Large Objects, BLOB) или большие символьные объекты (Character Large Objects, CLOB).Также вы можете получить выигрыш, если ваше приложение должно поддерживать вариативность типов для данных, помещаемых в таблицу, или если существующая структура данных (либо ее отсутствие) в вашей системе SQL Server затрудняет миграцию в облако.

Применение Windows Azure Table Storage

Поначалу работа с Windows Azure Table Storage может показаться несколько неуклюжей из-за необходимости ряда допущений для сопоставления «хранилища таблиц» базе данных SQL. Слово «таблица» в названии здесь не помогает. Поэтому я предлагаю рассматривать Windows Azure Table Storage как хранилище объектов.

Вы (как разработчик) не должны фокусироваться на структуре или механизме хранилища; вместо этого основное внимание нужно уделять объекту и тому, что вы собираетесь с ним делать. Понимание объектной природы Windows Azure Table Storage зачастую является самой большой трудностью для разработчика, но обращение к Windows Azure Table Storage через объекты естественно, особенно если вы пользуетесь LINQ.

Для работы с Windows Azure Table Storage начните с добавления в свой проект ссылки на System.Data.Services.Client. Кроме того, добавьте ссылку на Microsoft.WindowsAzure.StorageClient.dll, если вы не используете шаблон Cloud в Visual Studio (где эта ссылка уже есть).

Далее создайте объект/сущность, с которой вы можете работать (стащите его/ее из таблицы Authors):

public class TableStorageAuthor:

  Microsoft.WindowsAzure.StorageClient.TableServiceEntity {

  public int Id {get; set;}

  public string LastName { get; set; }

  public string FirstName { get; set; }

  public string Phone { get; set; }

  public string Address { get; set; }

  public string City { get; set; }

  public string State { get; set; }

  public string Zip {get; set;}

}

Вы можете определить контекст клиента сервиса данных, используя TableServiceContext для обработки подключения к хранилищу и выполнения CRUD-операций (Create/Read/Update/Delete), как показано на рис. 4. TableStorageAuthor применяется как класс шаблона, чтобы объявить элемент AuthorData, для которого возвращается метод запроса таблицы Authors. Он также используется как тип параметра в реализованной операции Add.

Рис. 4. Доступ к Windows Azure Table Storage

public class AuthorDataServiceContext : TableServiceContext {

  public IQueryable<TableStorageAuthor> AuthorData {

    get {

      return this.CreateQuery<TableStorageAuthor>("Authors");

    }

  }



  public AuthorDataServiceContext (

    Uri baseAddress, StorageCredentials credentials)

    : base(baseAddress.AbsoluteUri, credentials) {}



  public void Add(TableStorageAuthor author) {

    this.AddObject("Authors", author);

    DataServiceResponse dsResponse = SaveChanges();

  }

}

Создайте целевую таблицу:

TableClient.CreateTableIfNotExist("Authors");

Используя привычную парадигму создания объекта и присваивания свойству, подготовьте какие-нибудь данные и добавьте их в таблицу, которая была создана в хранилище (рис. 5).

Рис. 5. Добавление данных в Windows Azure Table Storage

var TableClient = StorageAccount.CreateCloudTableClient();



TableStorageAuthor author = new TableStorageAuthor();

author.FirstName = "Joseph";

author.LastName = "Fultz";

author.RowKey = System.Guid.NewGuid().ToString();

author.Id = author.RowKey;

author.State = "TX";

author.PartitionKey = "TX";



AuthorDataServiceContext ctx =

  new AuthorDataServiceContext(

  StorageAccount.TableEndpoint,

  StorageAccount.Credentials);

ctx.Add(author);

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

AuthorDataServiceContext ctx =

  new AuthorDataServiceContext(

  StorageAccount.TableEndpoint,

  StorageAccount.Credentials);



var authors =

  from a in ctx.AuthorData

  select a;



foreach (TableStorageAuthor ta in authors) {

  Debug.WriteLine(ta.FirstName + " " + ta.LastName);

}

Я не реализовал обновление и удаление, но это делается аналогичным образом. Единственное небольшое отличие от операций, использовавших LINQ с Entity Framework, может заключаться в коде, который должен создавать TableServiceContext, и последующем коде, обеспечивающем конструирование и использование этого объекта. Если вы уже имели дело с REST и DataServiceContext, эта работа будет для вас вполне естественной.

Используя TableServiceContext, TableServiceEntity и LINQ, вы, возможно, почувствуете себя так, будто применяете Entity Framework и LINQ с SQL Azure, хотя работа с Windows Azure Table Storage требует писать вручную несколько больше кода.

Оценка на основе требований решения

Как упоминалось, если приложение уже использует реляционное хранилище, то, как правило, лучше всего переходить на SQL Azure с помощью какой-либо утилиты наподобие SQL Azure Migration Wizard. Однако, если это не так или если «облачная часть» приложения не требует полной функциональности реляционной СУБД, то просмотрите табл. 6 и подумайте, какие столбцы в ней в наибольшей мере отвечают требованиям и архитектуре вашего решения.

Табл. 6. Сравнение SQL Azure и Windows Azure Table Storage

Важно отметить, что для некоторых элементов в табл. 1 (например, относящихся к управлению и загрузке данных для Windows Azure Table Storage) уже существуют сторонние решения, обеспечивающие недостающую функциональность. Поэтому стоимость и функциональность таких решений нужно будет учитывать в крупных проектах.

Предполагаю, что во многих приложениях понадобится гибридный подход. Например, Windows Azure Table Storage использовалось бы для оптимизации времени выборки с сохранением высоких уровней масштабируемости для таких ресурсов, как документы, видеоролики, изображения и другие виды медийной информации. Но для упрощения поиска метаданных для какого-либо элемента релевантные данные и указатели на объекты хранились бы в SQL Azure. Такая архитектура также позволила бы уменьшить транзакционный трафик в Windows Azure Table Storage. Вы могли бы получить следующие преимущества:

• сохранять высокую пропускную способность для запросов поиска ресурсов;
• уменьшить размер базы данных SQL Azure, чтобы минимизировать оплату;
• сократить оплату за хранение, переместив большие файлы из SQL Azure в Windows Azure Table Storage (однако для файлов предпочтительнее хранилище BLOB);
• поддерживать высокую скорость извлечения данных, используя ключ и раздел;
• обеспечить автоматическое масштабирование для данных, хранящихся в Windows Azure Table Storage.

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