Разработка для запросов
в решениях службы таблиц может быть связана с большим количеством операций чтения, записи или сочетания этих двух видов нагрузки. В этой статье рассматриваются вопросы, которые необходимо учесть при разработке службы таблиц для эффективной поддержки операций чтения. Как правило, схема, поддерживающая операции чтения, также эффективна для операций записи. Тем не менее, при реализации поддержки операций записи следует придерживаться дополнительных рекомендаций, которые приводятся в статье Design for data modification (Проектирование изменения данных).
Хорошей отправной точкой для разработки решения службы таблиц с эффективным чтением данных является вопрос о том, какие запросы потребуется выполнить приложению для получения необходимых данных из службы таблиц.
Примечание
Для службы таблиц очень важно правильно заранее спроектировать решение, поскольку его последующие изменения связаны с реализацией трудных и дорогостоящих процессов. Например, чтобы устранить проблемы с производительностью в реляционной базе данных, можно просто добавить индексы в существующую базу данных. Но этот вариант неприемлем для службы таблиц.
В этом разделе рассматриваются основные вопросы, которые необходимо учитывать при проектировании таблиц для выполнения запросов. В этом разделе затрагиваются следующие темы.
- Влияние выбора свойств PartitionKey и RowKey на производительность запросов
- Выбор соответствующего свойства PartitionKey
- Оптимизация запросов для службы таблиц
- Сортировка данных в службе таблиц
Влияние выбора свойств PartitionKey и RowKey на производительность запросов
В следующих примерах предполагается, что сущности сотрудников хранятся в службе таблиц согласно приведенной далее структуре (для большей ясности во многих примерах свойство Timestamp опущено).
| Имя столбца | Data type |
|---|---|
| PartitionKey (Название отдела) | Строка |
| RowKey (ИД сотрудника) | Строка |
| FirstName | Строка |
| LastName | Строка |
| Age | Целочисленный тип |
| EmailAddress | Строка |
В статье Общие сведения о Хранилище таблиц Azure описываются некоторые ключевые особенности службы таблиц Azure, оказывающие прямое влияние на процесс разработки запросов. С их учетом были сформулированы следующие общие рекомендации по разработке запросов службы таблиц. Обратите внимание, что синтаксис фильтрации, используемый в приведенных ниже примерах, взят из REST API службы таблиц. Дополнительные сведения см. в статье о сущностях запроса.
- Точечный запрос представляет собой самый эффективный вариант поиска и рекомендуется к использованию при крупномасштабном поиске или поиске, требующем минимальной задержки. Для эффективного поиска отдельных сущностей в таком запросе можно использовать индексы и указать значения PartitionKey и RowKey. Например: $filter=(PartitionKey eq 'Sales') and (RowKey eq '2')
- Вторым по эффективности можно назвать запрос диапазона, который использует свойство PartitionKey и выполняет фильтрацию в диапазоне значений RowKey для возврата нескольких сущностей. Значение PartitionKey определяет конкретный раздел, а значения RowKey определяют подмножество сущностей в этом разделе. Например: $filter=PartitionKey eq 'Sales' and RowKey ge 'S' and RowKey lt 'T'
- Третьим по эффективности является сканирование разделов с использованием свойства PartitionKey и фильтрации по другому неключевому свойству. Этот тип поиска может возвращать несколько сущностей. Значение PartitionKey определяет конкретный раздел и значения свойств, выбранные для подмножества сущностей в этом разделе. Например: $filter=PartitionKey eq 'Sales' and LastName eq 'Smith'
- Тип поиска сканирование таблиц не использует свойство PartitionKey и является очень неэффективным, так как поиск совпадающих сущностей выполняется по всем разделам таблицы. Просмотр таблицы будет осуществляться независимо от того, использует фильтр свойство RowKeyили нет. Например: $filter=LastName eq 'Jones'
- Запросы, возвращающие несколько сущностей, возвращают их отсортированными по свойствам PartitionKey и RowKey. Чтобы избежать повторной сортировки сущностей в клиенте, выберите свойство RowKey, которое определяет самый распространенный порядок сортировки.
Обратите внимание, что использование or для указания фильтра на основе RowKey приведет к запуску просмотра раздела и не будет обрабатываться как запрос диапазона. Поэтому следует избегать запросов, использующих следующие фильтры: $filter=PartitionKey eq 'Sales' and (RowKey eq '121' or RowKey eq '322').
Примеры кода на стороне клиента с использованием клиентской библиотеки хранилища для выполнения запросов см. в следующих разделах.
- Выполнение точечного запроса с помощью клиентской библиотеки хранилища
- Извлечение нескольких сущностей с помощью LINQ
- Проекция на стороне сервера
Примеры кода на стороне клиента, который может обрабатывать несколько типов сущностей, хранящихся в одной таблице, см. в следующем разделе:
Выбор соответствующего свойства PartitionKey
При выборе PartitionKey необходимо сбалансировать необходимость использования транзакций группы сущностей (для обеспечения согласованности) с требованием распределения сущностей между несколькими секциями (для обеспечения масштабируемого решения).
С одной стороны, все сущности можно хранить в одном разделе, но это может ограничить масштабируемость решения, а служба таблиц не сможет балансировать нагрузку запросов. С другой стороны, в каждом разделе можно хранить одну сущность, что обеспечит значительную масштабируемость решения и распределение нагрузки запросов, но не позволит использовать транзакции группы сущностей.
Идеальное свойство PartitionKey позволяет применять эффективные запросы и располагает достаточным количеством разделов для обеспечения масштабируемости решения. Вы поймете, что сущности имеют соответствующее свойство, которое распределяет их по необходимому количеству разделов.
Примечание
Например, в системе, где хранятся сведения о пользователях или сотрудниках, идентификатор пользователя (UserID) может быть выражен подходящим значением PartitionKey. Использовать тот или иной идентификатор пользователя (UserID) в качестве ключа раздела могут сразу несколько сущностей. Все сущности, в которых хранятся данные о пользователе, группируются в один раздел. В результате все операции с этими сущностями выполняются через транзакции группы сущностей, но масштабируемость остается высокой.
При выборе свойства PartitionKey необходимо учесть ряд дополнительных аспектов, которые имеют отношение к операциям вставки, обновления и удаления сущностей. Дополнительные сведения см. в разделе Design for data modification (Проектирование изменения данных).
Оптимизация запросов для службы таблиц
Служба таблиц автоматически индексирует сущности с помощью значений PartitionKey и RowKey в одном кластеризованном индексе. Именно поэтому точечные запросы самые эффективные. Однако не существует индексов, отличных от кластеризованного индекса, использующего значения PartitionKey и RowKey.
Многие разработки должны соответствовать требованиям по включению поиска сущностей на основании нескольких условий. Например, поиск сущностей сотрудников на основе адреса электронной почты, кода сотрудника или фамилии. Шаблоны, описанные в разделе Шаблоны для разработки таблиц, обеспечивают соответствие этим типам требований и описывают способы работы с тем фактом, что в службе таблиц отсутствуют вторичные индексы.
- Шаблон вторичного индекса внутри раздела — хранение нескольких копий каждой сущности с помощью различных значений RowKey (в одном разделе) для выполнения быстрых и эффективных операций поиска и активации альтернативных порядков сортировки с помощью различных значений RowKey.
- Шаблон вторичного индекса в разных разделах — хранение нескольких копий каждой сущности с помощью различных значений RowKey в отдельных разделах или отдельных таблицах для выполнения быстрых и эффективных операций поиска и активации альтернативных порядков сортировки с помощью различных значений RowKey.
- Шаблон сущностей индекса — поддержка сущностей индекса для выполнения эффективных операций поиска, возвращающих списки сущностей.
Сортировка данных в службе таблиц
Служба таблиц возвращает сущности, отсортированные по возрастанию сначала на основе PartitionKey, а затем на основе RowKey. Эти ключи являются строковыми значениями. Чтобы правильно отсортировать числовые значения, их необходимо преобразовать в значения фиксированной длины и заполнить нулями. Например, если значение идентификатора сотрудника, используемое в качестве RowKey, является целочисленным значением, ИД сотрудника 123 необходимо преобразовать в 00000123.
Многие приложения предъявляют требования к использованию данных, отсортированных в разных порядках. Например, сотрудники могут быть отсортированы по имена или по дате присоединения. Следующие шаблоны предназначены для выбора альтернативных порядков сортировки для сущностей.
- Шаблон вторичного индекса внутри раздела — хранение нескольких копий каждой сущности с помощью различных значений RowKey (в одном разделе) для выполнения быстрых и эффективных операций поиска и активации альтернативных порядков сортировки с помощью различных значений RowKey.
- Шаблон вторичного индекса в разных разделах — хранение нескольких копий каждой сущности с помощью различных значений RowKey в отдельных разделах или отдельных таблицах для выполнения быстрых и эффективных операций поиска и активации альтернативных порядков сортировки с помощью различных значений RowKey.
- Шаблон для заключительного фрагмента журнала — извлечение n сущностей, недавно добавленных в раздел, с помощью значения RowKey , выполняющего сортировку по дате и времени в обратном порядке.