Структурированное хранилище данных Windows Azure Table
Любое приложение вне зависимости от способа его размещения должно где-то хранить данные. При этом данные могут хранить локально, либо удаленно. "Облачный" способ хранения данных предлагает несколько иной способ. Обратив внимание на следующие особенности, которые необходимо учитывать при переносе традиционной реляционной структуры данных в 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 версии предоставлен только один индекс, сортирующий сначала по ключу секции, затем - по ключу строки.
Ограничения таблиц, сущностей и их свойств:
- Имена свойств таблиц должны состоять только из букв и цифр.
- Имя таблицы не должно начинаться с цифры.
- Имена таблиц различают регистры.
- Длина имени таблицы должна быть в пределах от 3 до 63 символов
- Сущность может иметь не более 255 свойств
- Свойства "ключ секции" и "ключ строки" не могут быть больше 1Кб размером.
- Свойство "временная метка" является ReadOnly.
- Windows Azure Table не хранит схем, т.е. значения свойств сущностей одной таблицы могут относиться к разным типам данных.
- Суммарный объем всех данных не может превышать 1Мб
Секционированиe
Частично секционирование было нами пояснено в предыдущей части настоящей лекции. Рассмотрим его более детально.
Масштабируемость системы хранения данных зависит от распределения секций по узлам хранения.
Система распределяет секции по узлам хранения по результатам истории использования секций, т.е. если ряд секций запрашивается чаще остальных, то система автоматически распределит их по нескольким узлам хранения, распределяя трафик между несколькими серверами. Важно помнить, что при этом объем секции не ограничен размерностью узла хранения.
Кроме того, хранение сущностей одной секции вместе позволяет повысить эффективность кэширования и других методов повышения производительности.
Приложение может осуществлять несколько операций создания, обновления и удаления для набора сущностей сформировав один пакетный запрос к системе, в случае, если операции осуществляются над сущностями одной таблицы и секции. При выполнении операции происходит изоляция моментального снимка, вне зависимости от исхода самой операции, т.о. все последующие операции, выполняющиеся в это же время, осуществляются над снимком, сделанным до начала операции. Результат транзакции становится доступным только после ее успешного завершения.
Особенности выбора ключа секции
Выбор ключа секции - задача, которая сложнее чем кажется. С одной стороны, размещение сущностей в одной секции позволяет оптимизировать выполнение запросов, с другой - чем больше секций в одной таблице, тем проще для WAT распределить сущности по местам хранения, обеспечивая масштабируемость таблицы.
- Если планируется использовать запросы над группами сущностей, необходимо подбирать ключ секции таким образом, чтобы все сущности участвующие в запросе находились в одной секции, т.е. необходимо группировать сущности, участвующие в одном запросе.
- В наиболее частых и важных запросах, помимо прочего следует указывать и ключ секции, поскольку при его отсутствии необходимые сущности будут отбираться просмотром всех секций таблицы.
- Проверка масштабируемости: нагрузочное тестирование секции таблицы с целью проверки возможности обеспечения секцией необходимой производительности.
Список дополнительных материалов для самостоятельного изучения
Обзор Windows Azure Table