Разработка приложений под Windows Azure. Хранилища данных. Часть №1. Блобы и диски.

Итак мы продолжаем в Вами знакомиться с платформой Windows Azure. В данном посте я постараюсь описать способы хранения данных в облаке. Я думаю все согласятся со мной, что более или менее серьезные современные приложения не могут обходиться без хранения различного рода данных. На сегодняшний день существует 2 основных подхода к хранению данных – это реляционный и нереляционный. Оба подхода реализованы в Windows Azure. К реляционному
относится SQLAzure, о котором я расскажу в последующих постах, а к нереляционному Windows Azure Storage, о котором и пойдет сегодня речь.
В первую очередь для того, чтобы начать использовать все возможности WA Storage необходимо создать аккаунт с помощью dev-портала в подразделе Storage Accounts.После чего у нас появляется возможность использовать следующие способы хранения данных:

1. Blobs – простые именованные файлы, содержащие в себе кроме самих данных также некоторые метаданные
   
2. Tables – структурированное хранилище. Таблицы состоят из сущностей, каждая из которых содержит набор свойств.
   
3. Azure Queues – надежный механизм хранения и доставки сообщений, который может использоваться нашими приложениями.
   
4. Drives – надежные NTFS диски для наших Windows Azure приложений. Базируются на блобах.

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

Как видим на самом верхнем уровне иерархии располагается наш аккаунт. У каждого аккаунта может быть неограниченное количество контейнеров, которые в сущности являются способом логического объединения блобов. Каждый контейнер может содержать неограниченное количество блобов. И наконец, внутренняя структура самого блоба может быть представлена в виде блоков или страниц. Если проанализировать техническую реализацию 2-х видов, то получим следующую картину:

	Блочные блобы	Страничные блобы
Основное отличие от конкурента	Оптимизированы для последовательного доступа	Оптимизированы для случайного доступа
Внутренняя структура	Каждый блоб состоит из последовательности блоков, каждый из которых имеет свой внутренний идентификатор	Каждый блоб состоит из последовательности страниц, каждая страница идентифицируется сдвигом от начала блоба
Максимальный размер одного блоба	200 Gb	1 Tb
Контроль множественного доступа	Оптимистическая блокировка (посредством ETag-ов)	Оптимистическая и пессимистическая блокировки

Более подробно о сценариях применения тех или иных блобов я расскажу в последующих постах. Очень важная особенность, о которой я хотел бы сказать – это то, что мы не ограничены 2-х уровневой иерархией. С помощью специального механизма именования блобов можно построить более глубокую виртуальную иерархию, тем самым эмулируя дисковую подсистему. Альтернативой данному подходу является технология Windows Azure Drives. Фактически такой диск представляет собой виртуальный жесткий диск (VHD) построенный на базе страничного блоба. Основные преимущества данной технологии заключаются в следующем:

1. Возможность использования существующих классов BCL из пространства System.IO. Тем самым нет необходимости что либо менять при переносе существующих приложений в облако, если они основываются на файловой подсистеме и используют стандартное NTFS API.
   
2. Возможность монтирования и размонтирования таких дисков на лету
   
3. Устойчивы к падениям инстанса приложения и гарантируют сохранность данных в аварийных ситуациях
   
4. Локальный кеш на каждом инстансе приложения повышающий производительность операций чтения
   
5. Поддерживают удаленное монтирование посредством API.
   
6. Можно загрузить VHD в локальный файл и смонтировать локально. 

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

• Windows Azure. Жизненный цикл. Управление и обновление.
  
• Windows Azure. Жизненный цикл. Проектирование и разработка.