Разработка масштабируемых и производительных таблиц
Совет
Сведения в этой статье применимы к обычному хранилищу таблиц Azure. Однако те же принципы применяются и к новой базе данных Azure Cosmos DB для таблиц, которая обеспечивает более высокую производительность и доступность, глобальное распределение и автоматические вторичные индексы. Он также доступен в бессерверном режиме, основанном на потреблении. Существуют некоторые различия между API таблиц в Azure Cosmos DB и хранилищем таблиц Azure. Дополнительные сведения см. в статье Azure Cosmos DB для таблицы. Для простоты разработки мы предоставляем унифицированный пакет SDK таблиц Azure , который можно использовать как для хранилища таблиц Azure, так и для Azure Cosmos DB для таблиц.
При разработке масштабируемых и высокопроизводительных таблиц необходимо учитывать факторы, такие как эффективность, масштабируемость и затраты. Если вы уже занимались созданием схем для реляционных баз данных, эти рекомендации будут известны. Однако несмотря на некоторое сходство между моделью хранения службы таблиц Azure и реляционными моделями, необходимо также отметить важные различия. Как правило, эти различия приводят к созданию разных вариантов, которые могут показаться пользователям, знакомым с реляционными базами данных, алогичными или неверными. Но если разработка выполняется для хранилища NoSQL типа "ключ-значение", например службы таблиц Azure, эти различия будут иметь смысл. Многие из них будут отражать тот факт, что служба таблиц предназначена для поддержки масштабирования облачных приложений, содержащих миллиарды сущностей ("строк" в терминологии реляционных баз данных) данных, или для наборов данных, которые должны поддерживать значительные объемы транзакций. Поэтому необходимо по-новому взглянуть на способы хранения данных и понять, как работает служба таблиц. Решение, в котором используется правильно спроектированное хранилище данных NoSQL, имеет все перспективы для значительного масштабирования (при более низких затратах), по сравнению с решением на основе реляционной базы данных. Данное руководство поможет решить эти задачи.
Информация о службе таблиц Azure
В этом разделе представлены некоторые ключевые функции службы таблиц, имеющие особое значение в процессе разработки производительных и масштабируемых компонентов. Если вы не знакомы со службой хранилища Azure и службой таблиц, сначала ознакомьтесь со статьей Начало работы с хранилищем таблиц Azure с помощью .NET , прежде чем читать оставшуюся часть этой статьи. Несмотря на то, что основной акцент в руководстве сделан на службе таблиц, здесь будут рассматриваться вопросы, имеющие отношение к службам очередей и больших двоичных объектов Azure и их использовании со службой таблиц.
Что такое служба таблиц? Как видно из названия, служба таблиц использует табличный формат для хранения данных. Согласно стандартной терминологии каждая строка таблицы представляет сущность, а различные свойства этой сущности хранятся в столбцах. Каждая сущность имеет уникально идентифицирующую ее пару ключей и столбец метки времени, который служба таблиц использует для отслеживания времени последнего обновления сущности. Метка времени применяется автоматически, ее нельзя вручную перезаписать произвольным значением. Служба таблиц применяет отметку времени последнего изменения (LMT) для управления оптимистическим параллелизмом.
Примечание
Операции API-интерфейса REST службы таблиц также возвращают значение ETag , являющееся производным от отметки времени последнего изменения (LMT). В этом документе термины ETag и LMT будут использоваться на взаимозаменяемой основе, так как они относятся к одним и тем же базовым данным.
В следующем примере показана простая схема таблицы для хранения сущностей сотрудников и отделов. Подобную структуру имеет большинство таблиц, приведенных далее в этом руководстве.
| PartitionKey | RowKey | Отметка времени | |||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|
| Маркетинг | 00001 | 2014-08-22T00:50:32Z |
| ||||||||
| Маркетинг | 00002 | 2014-08-22T00:50:34Z |
| ||||||||
| Маркетинг | отдел; | 2014-08-22T00:50:30Z |
|
||||||||
| Sales | 00010 | 2014-08-22T00:50:44Z |
|
Итак, эти данные похожи на таблицу в реляционной базе данных. Главными отличиями являются обязательные для заполнения столбцы, а также возможность хранения в одной таблице нескольких типов сущностей. Кроме того, все определенные пользователями свойства, например FirstName или Age, имеют такой тип данных, как целое или строка, аналогично столбцам в реляционной базе данных. В отличие от традиционных реляционных баз данных табличное хранилище имеет бессхемную конструкцию. Это значит, что свойства могут относиться к разным типам. Для хранения сложных типов данных в одном свойстве необходимо использовать сериализованный формат, например JSON или XML. Дополнительные сведения о службе таблиц, например о поддерживаемых типах данных, поддерживаемых диапазонах дат, правилах именования и ограничений по размерам, см. в статье Understanding the Table Service Data Model (Общие сведения о модели данных службы таблиц).
Основой для разработки эффективной таблицы является выбор свойств PartitionKey и RowKey. Каждая сущность, хранящаяся в таблице, должна иметь уникальное сочетание значений PartitionKey и RowKey. Как и в случае с ключами в таблице реляционной базы данных, значения PartitionKey и RowKey индексируются для создания кластеризованного индекса, позволяющего выполнять быстрый поиск. Однако служба таблиц не создает какие-либо вторичные индексы, поэтому PartitionKey и RowKey являются единственным индексируемыми свойствами. Несколько шаблонов, описанных в разделе шаблонов для разработки таблиц, показывают, как обойти это очевидное ограничение.
Таблица состоит из одного или нескольких разделов. Большая часть принимаемых проектных решений будет связана с выбором подходящих свойств PartitionKey и RowKey для оптимизации решения. В решение может входить одна таблица, в которой все сущности упорядочены по разделам. Однако обычно решение состоит из нескольких таблиц. Таблицы позволяют логически организовать сущности, они упрощают управление доступом к данным с помощью списков контроля доступа, а для их удаления достаточно выполнить одну операцию хранения.
Разделы таблицы
Имя учетной записи, имя таблицы и свойство PartitionKey, вместе взятые, определяют раздел в службе хранилища, где служба таблиц хранит сущность. Так как разделы являются частью схемы адресации для сущностей, они определяют область действия транзакций (см. раздел Транзакции группы сущностей ниже) и формируют основу варианта масштабирования таблицы. Дополнительные сведения о секциях см. в статье Контрольный список для обеспечения масштабируемости и производительности для Хранилища таблиц.
В службе таблиц отдельный узел обслуживает один или несколько полных разделов, а масштабирование службы осуществляется за счет динамического распределения нагрузки разделов между узлами. Если узел находится под нагрузкой, служба таблиц может разделить диапазон разделов, обслуживаемых этим узлом, на отдельные узлы. При уменьшении объема трафика служба может объединить диапазоны разделов с незагруженных узлов в один узел.
Дополнительные сведения о внутренних подробностях службы таблиц, в особенности о том, как служба управляет разделами, см. в документе Microsoft Azure Storage: A Highly Available Cloud Storage Service with Strong Consistency (Хранилище Microsoft Azure: высокодоступная служба облачного хранения со строгой согласованностью).
Транзакции группы сущностей
В службе таблиц транзакции группы сущностей (EGT) являются единственным встроенным механизмом для выполнения атомарных обновлений в нескольких сущностях. Транзакции группы сущностей иногда называются пакетными транзакциями. Эти транзакции поддерживаются только для сущностей, хранящихся в одном разделе (имеющих общий ключ раздела в данной таблице). Поэтому каждый раз, когда в нескольких сущностях требуется провести атомарные транзакции, необходимо убедиться, что эти сущности находятся в одном разделе. Именно этот момент часто является основанием для хранения нескольких типов сущностей в одной таблице (и разделе) и отказа от использования нескольких таблиц для разных типов сущностей. Одна транзакция группы сущностей может работать с максимум 100 сущностей. При отправке сразу нескольких транзакций группы сущностей для обработки важно убедиться в том, что эти транзакции не работают с сущностями, которые являются общими между такими транзакциями, в противном случае обработка может быть отложена.
Кроме того, применение транзакций группы сущностей приводит к необходимости сопоставить преимущества и недостатки и сделать компромиссный выбор при разработке. То есть использование дополнительных разделов будет способствовать повышению масштабируемости приложения, так как Azure предоставляет множество вариантов для балансировки нагрузки запросов между узлами. Но это может ограничить возможности приложения по выполнению атомарных транзакций и обеспечению высокого уровня согласованности данных. Кроме того, следует принять во внимание наличие определенных целевых показателей масштабируемости на уровне раздела, которые могут ограничивать ожидаемую пропускную способность для транзакций на одном узле. Дополнительные сведения о целевых показателях масштабируемости для учетных записей хранения Azure ценовой категории "Стандартный" см. в статье Целевые показатели масштабируемости и производительности для стандартных учетных записей хранения. Дополнительные сведения о целевых показателях масштабируемости для службы таблиц см. в статье Целевые показатели масштабируемости и производительности для хранилища таблиц.
Рекомендации по емкости
В следующей таблице показаны целевые показатели масштабируемости и производительности для хранилища таблиц.
| Ресурс | Назначение |
|---|---|
| Количество таблиц в учетной записи хранения Azure | Ограничено только емкостью учетной записи хранения |
| Количество разделов в таблице | Ограничено только емкостью учетной записи хранения |
| Количество сущностей в разделе | Ограничено только емкостью учетной записи хранения |
| Максимальный размер одной таблицы | 500 ТиБ |
| Максимальный размер одной сущности, включая все значения свойств | 1 МиБ |
| Максимальное количество свойств в сущности таблицы | 255 (включая три системных свойства: PartitionKey, RowKey и Timestamp) |
| Максимальный общий размер отдельного свойства в сущности | Зависит от типа свойства (см. сведения о типах свойств в документации по модели данных службы таблиц) |
| Размер свойства PartitionKey | Строка размером до 1 КиБ |
| Размер свойства RowKey | Строка размером до 1 КиБ |
| Размер транзакции группы сущностей | Транзакция может содержать не более 100 сущностей, а объем полезных данных не должен превышать 4 МиБ; транзакция группы сущностей может включать только однократное обновление сущности |
| Максимальное количество хранимых политик доступа на таблицу | 5 |
| Максимальная частота запросов на учетную запись хранения | 20 000 транзакций в секунду (предполагается размер сущности в 1 КиБ) |
| Целевая пропускная способность для одной секции таблицы (размер сущностей 1 КиБ) | До 2000 сущностей в секунду |
Рекомендации по стоимости
Табличное хранилище является относительно недорогой системой хранения данных. Однако в рамках оценки решения службы таблиц необходимо провести расчет затрат как на использование емкостей, так и на количество транзакций. Во многих сценариях хранение денормализованных или повторяющихся данных для повышения производительности или масштабируемости решения является вполне правомерным подходом. Дополнительные сведения о ценах см. на странице Цены на хранилища Azure.