Структурированное хранилище данных Windows Azure Table - Введение в облачные решения Microsoft

Любое приложение вне зависимости от способа его размещения должно где-то хранить данные. При этом данные могут хранить локально, либо удаленно. "Облачный" способ хранения данных предлагает несколько иной способ. Обратив внимание на следующие особенности, которые необходимо учитывать при переносе традиционной реляционной структуры данных в Table Storage в "облаке":

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

Table Storage подходит для хранения реляционных данных, но само по себе данное хранилище реляционным не является. Это значит, то при переносе реляционной структуры данных в "облако", управлять ограничениями между субъектами хранения нужно будет пользователю.

Характеристики

Windows Azure Table поддерживает:

LINQ

ADO. Net Data Services

REST

Неограниченное число таблиц и сущностей, без ограничения размеров

Целостность каждой сущности

Блокировку обновлений и удалений

Возможность возврата частичных результатов запросов прерванных по времени ожидания, при этом имеется возможность продолжить дальнейшее выполнение запроса.

Модель данных

Для доступа к Windows Azure Table у приложения должна быть учетная запись. После создания учетной записи, пользователю предоставляется секретный ключ, используемый для аутентификации.

Ключевыми понятиями Table Storage являются:

Таблица - содержит набор сущностей.

Сущность - логически является строкой в таблице. Основной элемент данных. хранящихся в таблице. Содержит набор свойств.

Свойство - Значение, хранимое в сущности.

Как мы уже отмечали ранее, проводя аналогии с реляционным подходом, получим следующее: под таблицей понимается коллекция сущностей ( Entities ), подобных кортежам в реляционном подходе. Сущность же представляет собой набор свойств (Properties). Свойство же является парой "имя (name) - типизированное значение (typed value)". Сущности можно соотнести с полями в таблице в реляционном хранилище.

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

Ключ строки - свойство ключа таблицы, уникальный идентификатор сущности.

Временная метка - система хранит различные версии одной и той же сущности, для их различения используется временна метка.

Секция - набор сущностей с одинаковыми ключами секции.

Порядок сортировки - в CTP версии предоставлен только один индекс, сортирующий сначала по ключу секции, затем - по ключу строки.

Ограничения таблиц, сущностей и их свойств:

Имена свойств таблиц должны состоять только из букв и цифр.

Имя таблицы не должно начинаться с цифры.

Имена таблиц различают регистры.

Длина имени таблицы должна быть в пределах от 3 до 63 символов

Сущность может иметь не более 255 свойств

Свойства "ключ секции" и "ключ строки" не могут быть больше 1Кб размером.

Свойство "временная метка" является ReadOnly.

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

Суммарный объем всех данных не может превышать 1Мб

Секционированиe

Частично секционирование было нами пояснено в предыдущей части настоящей лекции. Рассмотрим его более детально.

Масштабируемость системы хранения данных зависит от распределения секций по узлам хранения.

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

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

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

Особенности выбора ключа секции

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

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

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

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

Запуск хранилища разработки

Рассмотрим более подробно работу с Storage Emulator. По умолчанию Storage Emulator устанавливается в папку devstore подкаталогаbin, папки Windows Azure SDK.

Увеличить изображение Рис. 14.1.

Здесь можно найти два. exe файла:

1. DSInit - инициализирует локальное хранилище и устанавливает права доступа к нему. Запустив этот файл, при отсутствии ошибок, должно появиться следующее окно:

Рис. 14.2.

Как видно, была создана локальная база данных для разработки, и зарезервированы порты 10000-10002. В том, что база создана можно также убедиться, запустив SQL Management Studio

Рис. 14.3.

2. DSService. exe - непосредственно запускает эмулятор облачного хранилища. Запустив его и подождав некоторое время, можно заметить, что в правом нижнем углу появился значок Windows Azure. Для того, чтобы открыть интерфейс эмулятора, нужно щелкнуть правой кнопкой мыши по значку Windows Azure и выбрать "Show Compute Emulator UI". При отсутствии ошибок, должно появиться следующее окно:

Рис. 14.4.

В окне Storage Emulator отображается состояние и конечные точки сервисов эмулятора: Blob, Queue и Table. Сервисы можно запустить, остановить, либо сбросить, с потерей данных, хранящихся в них.

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

Рис. 14.5.

Это скорее всего означает, что указанные порты "слушают" другие приложения. К примеру, как отмечалось в ряде источников и было проверено нами, клиент mtorrent, запущенный до старта эмулятора конфликтует с Blob - сервисом, из-за чего к последнему не удается получить доступ.

Подключение к хранилищу разработки

Для подключения к эмулятору хранилища при разработке приложения (в среде Visual Studio в нашем случае) после создания проекта необходимо перейти к свойствам роли

Рис. 14.6.

А затем во вкладке "Параметры" добавить параметр строки подключения и указать значение "UseDevelopmentStorage=true"

Рис. 14.7.

При работе непосредственно с хранилищем Windows Azure, в той же вкладке необходимо, при создании строки подключения, нажать кнопку "..."

Рис. 14.8.

И в появившемся окне задать параметры подключения и используемой учетной записи Windows Azure.

Рис. 14.9.

Запустив Обозреватель серверов (Меню "Вид" - Обозреватель серверов), увидим появившееся хранилище Windows Azure и хранилище"Разработка" - являющееся отображением эмулятора.

Рис. 14.10.

При помощи обозревателя серверов можно просматривать содержимое конкретных таблиц или контейнеров бинарных объектов.

Рис. 14.11.

Также при помощи обозревателя серверов можно подключиться к хранилищу Windows Azure, добавив данные учетной записи.

Рис. 14.12.

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

Задание. Создание хранилища с простой структурой данных.

1. Создадим проект облачной службы. SimpleDataStructure (Меню "Файл" - Создать - Проект). Добавим решению рабочую роль.

Рис. 14.13.

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

В свойствах рабочей роли определим строку подключения к эмулятору хранилища Azure.

Рис. 14.14.

Нам необходим класс, который будет описывать структуру сущности для нашей таблицы. Класс должен быть наследником Microsoft. WindowsAzure. StorageClient. TableServiceEntity

Class Address : TableServiceEntity

{

Public String address { get; set; }

Public String firm { get; set; }

Public String telephone { get; set; }

}

Для создания таблиц необходимо определить класс - контекст, при чем:

Класс должен быть наследником TableServiceContext

Для каждой таблицы необходимо определить свойство типа IQueryable, где значение параметра DataItemType - тип сущностей, хранимых в таблице, в нашем случае - Address.

Class AddressConext: TableServiceContext

{

Public IQueryable<Address> ContactData

{

Get

{

Return this. CreateQuery<Address>("Address");

}

Public AddressConext(Uri baseAddress, StorageCredentials credentials) : base(baseAddress. AbsoluteUri, credentials) { }

}

Теперь обратим внимание на методы Run и OnStart. Первый содержит код выполняемый в ходе работы роли, второй - при ее запуске.

Для того, чтобы добавить данные в таблицу нам необходимо в методе Run:

Создать экземпляр класса - учетной записи

Создать экземпляр класс - контекста

Создать экземпляр класса - сущности и задать его параметры

Создать таблицу Address, если она не существует

Добавить сущность в таблицу

Добавим следующий код:

CloudStorageAccount. SetConfigurationSettingPublisher(

(configName, configSettingPublisher) =>

{

Var connectionString =

RoleEnvironment. GetConfigurationSettingValue(configName);

ConfigSettingPublisher(connectionString);

}

);

//определение учетной записи

CloudStorageAccount account = CloudStorageAccount. FromConfiguration Setting("DataConnectionString");

//создание таблицы Windows Azure Table

CloudTableClient _tc = null;

_tc = account. CreateCloudTableClient();

_tc. CreateTableIfNotExist("Address");

/*определение сущности, в том числе свойств ключ строки и ключ секции, унаследованных от родительского TableServiceEntity*/

Address adrs = new Address();

Adrs. PartitionKey = "Firm";

Adrs. RowKey = "Test entity";

Adrs. telephone = "xxx-xx-xx";

Adrs. address = "Evergreen Terrace 247";

Adrs. firm = "My new firm";

//определение контекста

AddressConext context = new AddressConext(account. TableEndpoint, account. Credentials);

//добавление сущности таблице Address

Context. AddObject("Address", adrs);

//сохранение изменений

Context. SaveChanges();

Запустите приложение, убедитесь в том, что оно выполнилось без ошибок и остановите его.

В диспетчере серверов, во вкладке "Хранилище Windows Azure" обновите вкладку "Таблицы", вы увидите созданную нашим приложением таблицуAddress.

Рис. 14.15.

Щелкните на таблице правой кнопкой мыши и выберите "Просмотреть данные". Вы увидите, что определенная нами сущность добавлена в таблицу.

Рис. 14.16.

Более подробно работа с Хранилищем Windows Azure будет рассмотрена в последующих практических работах.

В случае, если выполнение задания вызвало сложности и затруднения, в приложениях к данной практической работе вы найдете итоговый программный код.

Приложение WorkerRole1.cs

Using System;

Using System. Collections. Generic;

Using System. Diagnostics;

Using System. Linq;

Using System. Net;

Using System. Threading;

Using Microsoft. WindowsAzure;

Using Microsoft. WindowsAzure. Diagnostics;

Using Microsoft. WindowsAzure. ServiceRuntime;

Using Microsoft. WindowsAzure. StorageClient;

Using System. Data. Services. Client;

Namespace WorkerRole1

{

Public class WorkerRole : RoleEntryPoint

{

Public override void Run()

{