Нереляционные данные в Windows Azure: компонент Storage

| Вторник, 12 марта, 2013

Метки: Windows Azure Комментарии: 0

Windows Azure предоставляет разработчикам различные способы хранения данных. Нереляционные хранилища данных - это BLOB-объекты, таблицы и очереди и реляционное хранилище в виде SQL Database. Рассмотрим основные три типа нереляционных способов хранения данных.

BLOB-объекты - это самый простой способ хранения данных в Windows Azure. Эти объекты содержат бинарные данные, и как видно на картинке, они организованы в виде простой иерархии. Каждый контейнер может содержать один или несколько BLOB-объектов. Объекты могут быть большими по объему – до одного терабайта, а также они могут иметь ассоциированные метаданные, например информация о том, где была сделана фотография, или кто исполнитель mp3-файла. BLOB-объекты также предоставляют место для размещения, как бы, файловых систем Windows Azure. Это механизм, который позволяет ролям Windоws Azure работать с постоянными хранилищами, как будто, это файловая система NTFS.

BLOB-объекты - весьма полезная штука, но они слишком плохо структурированы для некоторых ситуаций. Для работы с более организованными данными Windows Azure предоставляет таблицы. Но сразу нужно предупредить, это не реляционные таблицы данных. Здесь каждая таблица хранит сущности с определенным набором свойств. И подобно SQL-запросам, приложения могут запрашивать данные из таблиц, используя протокол OData (открытый веб-протокол для запроса и обновления данных). Такой подход позволяет масштабировать хранилище, распределяя данные на многих машинах. Это более эффективно, чем стандартные реляционные базы данных. Фактически, одна таблица Windows Azure может содержать миллиарды сущностей и хранить терабайты данных.

BLOB-объекты и таблицы предназначены для хранения данных и доступа к ним. Третий вид данных – очереди имеют совершенно другое назначение. Главная задача очередей – это реализовать асинхронное взаимодействие объектов web-роли с объектами worker-роли. Например, пользователь через веб-интерфейс может задать некую долгую операцию объекту worker-роли. Web-роль записывает задание, которое нужно сделать, в очередь. Объект worker-роли считывает задание из очереди, выполняет его и результат может тоже записать обратно в очередь.

Независимо от типа хранимых данных, будь то BLOB-объекты, таблицы, или очереди – вся хранимая информация трижды реплицируется. Такое копирование позволяет минифицировать ущерб от сбоев и потери данных не являются фатальными. Система обеспечивает строгую согласованность, то есть данные, помещенные в хранилище, гарантированно считываются обратно в приложение. Дополнительно Windows Azure еще хранит резервную копию всех данных в той же части мира, что и оригинал. Если центр данных, хранящий главную копию не может предоставить данные, то резервная копия остается доступной и выполнит свою задачу.

Хранилище Windows Azure доступно приложениям, размещенным на Windows Azure, а также приложениям на других операционных системах, хостингах и облачных платформах. Для всех случаев все три типа хранилищ используют стиль построения архитектуры распределенного приложения REST (Representational State Transfer - передача репрезентативного состояния). BLOB-объекты, таблицы и очереди имеют свой url-адрес и доступны через стандартные HTTP-запросы. Клиенты .NET могут использовать специальную библиотеку от Windows Azure, но и это не обязательно, приложение может делать обычные HTTP-запросы.

Использование BLOB-объектов, таблиц и очередей открывает большие возможности в приложениях Windows Azure. Но если приложения зависят от реляционных данных, то можно использовать еще один компонент – SQL Database (прежнее название SQL Azure). Приложения использующие этот компонент, могут получать доступ к данным в облаке через SQL запросы.