Опубликован: 30.05.2011 | Доступ: свободный | Студентов: 2366 / 213 | Оценка: 4.12 / 4.41 | Длительность: 12:00:00
Лекция 11:

Структурированное хранилище данных Windows Azure Table

Аннотация: В рамках данной лекции будут рассмотрены следующие вопросы: Windows Azure Table (в дальнейшем WAT), модель данных WAT, секционирование.

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

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

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

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

  • LINQ
  • ADO.Net Data Services
  • REST
  • неограниченное число таблиц и сущностей, без ограничения размеров
  • целостность каждой сущности
  • блокировку обновлений и удалений
  • возможность возврата частичных результатов запросов прерванных по времени ожидания, при этом имеется возможность продолжить дальнейшее выполнение запроса.

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

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

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

  • Таблица - содержит набор сущностей.
  • Сущность - логически является строкой в таблице. Основной элемент данных. хранящихся в таблице. Содержит набор свойств.
  • Свойство - Значение, хранимое в сущности.
    Как мы уже отмечали ранее, проводя аналогии с реляционным подходом, получим следующее: под таблицей понимается коллекция сущностей ( Entities ), подобных кортежам в реляционном подходе. Сущность же представляет собой набор свойств (Properties). Свойство же является парой "имя (name) - типизированное значение (typed value)". Сущности можно соотнести с полями в таблице в реляционном хранилище.
  • ключ секции - свойство ключа таблицы. Используется для распределения по узлам хранения сущностей таблицы.
  • ключ строки - свойство ключа таблицы, уникальный идентификатор сущности.
  • временная метка - система хранит различные версии одной и той же сущности, для их различения используется временна метка.
  • секция - набор сущностей с одинаковыми ключами секции.
    Таблица 13.1. Пример:
    Ключ секции Ключ строки Свойство 1 ... Свойство k
    Отчетность1 1 Значение свойства ... Значение свойства Секция 1
    Отчетность1 2 Значение свойства ... Значение свойства Секция 1
    Документ1 1 Значение свойства ... Значение свойства Секция 2
    Документ1 2 Значение свойства ... Значение свойства Секция 2
    Документ1 3 Значение свойства ... Значение свойства Секция 2
  • порядок сортировки - в CTP версии предоставлен только один индекс, сортирующий сначала по ключу секции, затем - по ключу строки.

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

  1. Имена свойств таблиц должны состоять только из букв и цифр.
  2. Имя таблицы не должно начинаться с цифры.
  3. Имена таблиц различают регистры.
  4. Длина имени таблицы должна быть в пределах от 3 до 63 символов
  5. Сущность может иметь не более 255 свойств
  6. Свойства "ключ секции" и "ключ строки" не могут быть больше 1Кб размером.
  7. Свойство "временная метка" является ReadOnly.
  8. Windows Azure Table не хранит схем, т.е. значения свойств сущностей одной таблицы могут относиться к разным типам данных.
  9. Суммарный объем всех данных не может превышать 1Мб
Таблица 13.2. Поддерживаемые WAT типы данных:
Тип Описание
Binary Массив байтов до 64Кб
Bool Булевское значение
Datetime 64-битное значение временного UTC - формата, от 1.1.1600 до 12.31.9999
Double 64-битное действительное число
GUID 128-битный уникальный идентификатор
Int 32-битное целочисленное значение
Int64 64-битное целочисленное значение
String Значение кодировки UTF-16, размером до 64Кб

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

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

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

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

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

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

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

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

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

Список дополнительных материалов для самостоятельного изучения

Обзор Windows Azure Table

  1. http://blogs.msdn.com/b/jnak/archive/2010/01/06/walkthrough-windows-azure-table-storage-nov-2009-and-later.aspx

Windwows Azure Table - подробный обзор

  1. http://msdn.microsoft.com/ru-ru/library/ee872426.aspx
  2. http://www.bandgap.cs.rice.edu/classes/comp410/resources/Using%20Azure/Using%20Azure%20Table%20Storage.aspx
Роза Мальцева
Роза Мальцева
Игнат Гринько
Игнат Гринько

Примерно месяц назад получил на сайте код Дримспарк, сегодня вводил его на сайте Дримспарк, пишет: Недействительный код проверки. Проверьте правильность введенного кода. Код вводил методом: скопировать-вставить.