Azure Services Platform

Azure Table Services

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

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

Рассмотрим модель данных таблицы Windows Azure Table:

• Учетная запись хранилища (Storage Account) – для доступа к Windows Azure Storage приложение должно использовать действительную учетную запись. Новую учетную запись можно создать через веб-интерфейс портала Windows Azure. Как только учетная запись создана, пользователь получает 256-разрядный секретный ключ, который впоследствии используется для аутентификации запросов этого пользователя к системе хранения. В частности, с помощью этого секретного ключа создается подпись HMAC SHA256 для запроса. Эта подпись передается с каждым запросом данного пользователя для обеспечения аутентификации. Имя учетной записи входит в состав имени хоста в URL. Для доступа к таблицам используется следующий формат имени хоста: .table.core.windows.net .
• Таблица (Table) – содержит набор сущностей. Область действия имен таблиц ограничена учетной записью. Приложение может создавать множество таблиц в рамках учетной записи хранилища.
• Сущность (строка) (Entity (Row)) – Сущности (сущность является аналогом «строки») – это основные элементы данных, хранящиеся в таблице. Сущность включает набор свойств. В каждой таблице имеется два свойства, которые образуют уникальный ключ для сущности.
• Свойство (столбец) (Property (Column)) – Представляет отдельное значение сущности. Имена свойств чувствительны к регистру. Для значений свойств поддерживается богатый набор типов.
• Ключ секции (PartitionKey) – Первое свойство ключа каждой таблицы. Эта система использует данный ключ для автоматического распределения сущностей таблицы по множеству узлов хранения.
• Ключ строки (RowKey) – Второе свойство ключа таблицы. Это уникальный ID сущности в рамках секции. PartitionKey в сочетании с RowKey уникально идентифицирует сущность в таблице.
• Временная метка (Timestamp) – Каждая сущность имеет версию, сохраняемую системой.
• Секция (Partition) – Набор сущностей в таблице с одинаковым значением ключа секции.
• Порядок сортировки (Sort Order) – Для CTP -версии предоставляется всего один индекс, в котором все сущности сортированы по PartitionKey и затем по RowKey. Это означает, что запросы с указанием этих ключей будут более эффективными, и все возвращаемые результаты будут сортированы по PartitionKey

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

Рассмотрим некоторые дополнительные сведения о сущностях:

• Сущность может иметь до 255 свойств, включая обязательные системные свойства: PartitionKey, RowKey и Timestamp. Имена всех остальных свойств сущностей определяются приложением.
• Свойства PartitionKey и RowKey строкового типа.
• Свойство Timestamp является доступным только для чтения обслуживаемым системой свойством, которое должно рассматриваться как непрозрачное свойство.
• Отсутствие фиксированной схемы – Windows Azure Table не сохраняет никакой схемы, поэтому все свойства хранятся как пары . Это означает, что свойства сущностей одной таблицы могут сильно отличаться. В таблице даже может быть две сущности, свойства которых имеют одинаковые имена, но разные типы значений.
• Суммарный объем всех данных сущности не может превышать 1 МБ. Сюда входит размер имен свойств, а также размер значений свойств или их типов, включая и два обязательных свойства ключей (PartitionKey и RowKey).
• Поддерживаются типы Binary, Bool, DateTime, Double, GUID, Int, Int64, String. Ограничения представлены в таблице ниже.

Таблица 6.1.

Тип свойства	Описание
Binary	Массив байтов размером до 64 КБ.
Bool	Булево значение.
DateTime	64-разрядное значение, представляющее время в формате UTC. Поддерживаемый диапазон значений: от 1/1/1600 до 12/31/9999.
Double	64-разрядное значение с плавающей точкой.
GUID	128-разрядный глобально уникальный идентификатор.
Int	32-разрядное целое значение.
Int64	64-разрядное целое значение.
String	16-разрядное UTF-кодированное значение. Размер строковых значений может быть до 64 КБ.

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

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

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

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

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

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

В примере выше секцию образуют все версии одного документа. Таким образом, для извлечения всех версий данного документа необходимо выполнить доступ всего к одной секции. Чтобы получить все версии документов, измененные до 5/30/2007, придется запрашивать несколько секций, что будет не так эффективно и более ресурсоемко, поскольку по запросу должны будут проверяться все секции, которые к тому же могут располагаться на разных узлах хранения.

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

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

Далее представлены некоторые советы и рекомендации по выбору PartitionKey для таблицы:

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

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

1. Исходя из статистических данных интенсивности использования приложения, определите, не приведет ли секционирование по выбранному выше PartitionKey к созданию слишком загруженных секций, которые не смогут эффективно обслуживаться одним сервером? Проверить это можно, применив нагрузочное тестирование секции таблицы . Для этого в тестовой таблице создается секция соответственно выбранным ключам. Она подвергается пиковой нагрузке, полученной исходя из предполагаемых полезной нагрузки и запросов. Это позволяет проверить, может ли секция таблицы обеспечить необходимую производительность приложения.
2. Если секция таблицы проходит нагрузочное тестирование , ключи выбраны правильно.
3. Если секция таблицы не проходит нагрузочного тестирования , найдите ключ секции, который обеспечил бы более узкое подразделение сущностей. Это можно сделать через объединение выбранного ключа секции со следующим свойством ключа, или выбрав в качестве ключа секции другое важное свойство. Целью этой операции должно быть создание большего количества секций, чтобы не возникало одной слишком большой или слишком загруженной секции.
4. Система спроектирована так, что обеспечивает необходимое масштабирование и обработку большого количества запросов. Но при чрезвычайно высокой интенсивности запросов ей приходится выполнять балансировку нагрузки, в результате чего некоторые из запросов могут завершаться ошибкой превышения времени ожидания. Сократить или устранить ошибки такого рода может снижение интенсивности запросов. Вообще говоря, такие ошибки возникают редко; однако если вы столкнулись с частыми или неожиданными ошибками превышения времени ожидания, свяжитесь с нами через сайт

MSDN, мы обсудим, как оптимизировать использование Windows Azure Table и предотвратить возникновение таких ошибок в вашем приложении.

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

Для таблиц и сущностей поддерживаются следующие базовые операции:

Что собой представляет табличное хранилище Azure? What is Azure Table storage ?

Сведения в этой статье применимы к обычному хранилищу таблиц Azure. The content in this article applies to the original Azure Table storage. Но теперь доступно альтернативное предложение для хранилища таблиц — API таблиц Azure Cosmos DB. However, there is now an alternative offering for table storage: the Azure Cosmos DB Table API. Этот API обеспечивает более высокую производительность и доступность, глобальное распределение и автоматические вторичные индексы. This API offers higher performance and availability, global distribution, and automatic secondary indexes. Он также доступен в бессерверном режиме, основанном на потреблении. It is also available in a consumption-based serverless mode. Есть некоторые различия в функциях между API таблиц в Azure Cosmos DB и хранилищем таблиц Azure. There are some feature differences between Table API in Azure Cosmos DB and Azure table storage. Дополнительные сведения см. в статье Знакомство со службой Azure Cosmos DB. API таблицы. For more information, see Azure Cosmos DB Table API.

Хранилище таблиц Azure — это служба, которая хранит нереляционные структурированные данные (также называются структурированными данными NoSQL) в облаке, предоставляя хранилище ключей и атрибутов с бессхемной структурой. Azure Table storage is a service that stores non-relational structured data (also known as structured NoSQL data) in the cloud, providing a key/attribute store with a schemaless design. Такая конструкция хранилища таблиц позволяет легко адаптировать данные по мере расширения приложения. Because Table storage is schemaless, it’s easy to adapt your data as the needs of your application evolve. Разным типам приложений может быть предоставлен быстрый и экономичный доступ к хранилищу таблиц. Такое хранилище обычно дешевле, чем традиционные хранилища SQL для похожих объемов данных. Access to Table storage data is fast and cost-effective for many types of applications, and is typically lower in cost than traditional SQL for similar volumes of data.

Хранилище таблиц можно использовать для хранения гибких наборов данных, например пользовательских данных для веб-приложений, адресных книг, сведений об устройстве или метаданных любого другого типа, которые требуются вашей службе. You can use Table storage to store flexible datasets like user data for web applications, address books, device information, or other types of metadata your service requires. В таблице можно хранить любое количество сущностей, а учетная запись хранения может содержать любое количество таблиц в пределах емкости учетной записи. You can store any number of entities in a table, and a storage account may contain any number of tables, up to the capacity limit of the storage account.

Что такое хранилище таблиц What is Table storage

В хранилище таблиц Azure содержатся большие объемы структурированных данных. Azure Table storage stores large amounts of structured data. Эта служба — хранилище данных NoSQL, которое принимает вызовы внутри и снаружи облака Azure с проверкой подлинности. The service is a NoSQL datastore which accepts authenticated calls from inside and outside the Azure cloud. Таблицы Azure идеально подходят для хранения нереляционных структурированных данных. Azure tables are ideal for storing structured, non-relational data. Самые распространенные способы использования хранилища таблиц: Common uses of Table storage include:

• Хранение терабайтов структурированных данных с возможностью обслуживания приложений с веб-масштабированием. Storing TBs of structured data capable of serving web scale applications
• Хранение наборов данных, которые не требуют сложных соединений, внешних ключей или хранимых процедур и могут быть денормализованы для обеспечения быстрого доступа. Storing datasets that don’t require complex joins, foreign keys, or stored procedures and can be denormalized for fast access
• Быстрый запрос данных с помощью кластерного индекса. Quickly querying data using a clustered index
• Доступ к данным с помощью протокола OData и запросов LINQ с библиотеками .NET службы данных WCF. Accessing data using the OData protocol and LINQ queries with WCF Data Service .NET Libraries

Хранилище таблиц можно использовать для хранения огромных наборов структурированных нереляционных данных и обращения к ним. Таблица масштабируется в соответствии с потребностями. You can use Table storage to store and query huge sets of structured, non-relational data, and your tables will scale as demand increases.

Основные понятия хранилища таблиц Table storage concepts

Хранилище таблиц состоит из следующих компонентов: Table storage contains the following components:

Формат URL-адреса. Учетные записи хранения таблиц Azure используют следующий формат: http:// .table.core.windows.net/

URL format: Azure Table Storage accounts use this format: http:// .table.core.windows.net/

Учетные записи API таблиц Azure Cosmos DB используют следующий формат: http:// .table.cosmosdb.azure.com/

Azure Cosmos DB Table API accounts use this format: http:// .table.cosmosdb.azure.com/

К таблицам Azure можно обратиться напрямую, используя этот адрес с протоколом OData. You can address Azure tables directly using this address with the OData protocol. Дополнительные сведения можно найти на веб-сайте OData.org. For more information, see OData.org.

Учетные записи. Весь доступ к службе хранилища Azure осуществляется с помощью учетной записи хранения. Accounts: All access to Azure Storage is done through a storage account. См. сведения об учетных записях хранения. For more information about storage accounts, see Storage account overview.

Весь доступ к Azure Cosmos DB осуществляется с помощью учетной записи API таблиц. All access to Azure Cosmos DB is done through a Table API account. Дополнительные сведения о создании учетной записи API таблиц см. в разделе Создание учетной записи API таблиц. See Create a Table API account for details creating a Table API account.

Таблица. Таблица — это коллекция сущностей. Table: A table is a collection of entities. Таблицы не налагают схему на сущности. Это означает, что одна таблица может содержать сущности, которые имеют различные наборы свойств. Tables don’t enforce a schema on entities, which means a single table can contain entities that have different sets of properties.

Сущность. Сущность — это набор свойств подобно строке базы данных. Entity: An entity is a set of properties, similar to a database row. Максимальный размер сущности в службе хранилища Azure — 1 МБ. An entity in Azure Storage can be up to 1MB in size. Максимальный размер сущности в Azure Cosmos DB — 2 МБ. An entity in Azure Cosmos DB can be up to 2MB in size.

Свойства. Свойство представляет собой пару «имя-значение». Properties: A property is a name-value pair. Каждая сущность может содержать до 252 свойств для хранения данных. Each entity can include up to 252 properties to store data. Каждая сущность также имеет три системных свойства, которые определяют ключ раздела, ключ строки и отметку времени. Each entity also has three system properties that specify a partition key, a row key, and a timestamp. Сущности с тем же ключом раздела можно запросить быстрее, и они добавляются или обновляются с помощью атомарных операций. Entities with the same partition key can be queried more quickly, and inserted/updated in atomic operations. Ключ строки сущности — это ее уникальный код внутри раздела. An entity’s row key is its unique identifier within a partition.

Дополнительные сведения об именовании таблиц и ее свойствах см. в обзорной статье о модели данных службы таблиц. For details about naming tables and properties, see Understanding the Table Service Data Model.

Дальнейшие действия Next steps

Обозреватель хранилищ Microsoft Azure — это бесплатное автономное приложение от корпорации Майкрософт, позволяющее визуализировать данные из службы хранилища Azure на платформе Windows, macOS и Linux. Microsoft Azure Storage Explorer is a free, standalone app from Microsoft that enables you to work visually with Azure Storage data on Windows, macOS, and Linux.

Дополнительные сведения о доступных API-интерфейсах см. в справочной документации по службе таблиц: View the Table service reference documentation for complete details about available APIs: