Будьте уверены с Azure .NET — хранилище таблиц Azure (часть 2)

В нашей  статье Be Sure с Azure .NET — хранилище таблиц Azure (часть 1)  мы подробно расскажем о хранилище таблиц Azure, например, работе с базами данных NoSQL, их сравнении с реляционными базами данных, разработке и создании таблицы Azure, а также обо всех доступные операции для сохранения данных. Во второй части таблицы Azure собирались охватить остальные аспекты службы хранения таблиц, такие как:

1. Эффективные и неэффективные запросы
2. Крысы! Мы попали в ловушку (работа с политиками повторных попыток)
3. совпадение
4. Безопасность
5. Вторичные индексы (Бонус)

Запросы: эффективные и неэффективные

	
TableOperation query = TableOperation.Retrieve<Footwear>(partitionkey, rowKey);
TableResult result = table.Execute(query);
Footwear footwear = (Footwear) result.Result;

IQueryable<Footwear> query = table.CreateQuery<Footwear>().Where(f => f.PartitionKey == partitionKey);
List<Footwear> shoes = query.ToList();

Здесь вы заметите, что мы используем не  метод Retrieve,  а  CreateQuery,  который позволит вам создавать и выполнять запросы с помощью LINQ. У CreateQuery есть ограничения,  так  как он был специально оптимизирован для работы с хранилищем таблиц Azure, но вы можете просмотреть все  доступные поддерживаемые  операции LINQ .

Несколько менее эффективные запросы будут включать диапазоны ключей строк или диапазонов ключей разделов и / или строк.

IQueryable<Footwear> query =
table.CreateQuery<Footwear>()
.Where(f => f.PartitionKey.Equals(startPartitionKey) || f.PartitionKey.Equals(endPartitionKey));
List<Footwear> shoes = query.ToList();

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

Неэффективные Запросы

(Короткий рекламный перерыв)

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

Это только высокоуровневое представление некоторых архитектур хранилища Azure, но  подробный документ  доступен для подробностей на уровне земли. Хранилище Azure состоит из различного числа узлов хранения, которые помогают распределить нагрузку по запросам. Раздел данных может легко охватывать несколько узлов хранения. Сервер разделов используется для обработки всех запросов к определенному разделу данных и может отвечать за обработку запросов для более чем одного раздела.

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

Запрашивать все вещи

Для всех наших запросов до настоящего времени требовались либо ключ раздела, либо ключ строки, либо оба. Но Partition и Row Key — обычно не единственные два свойства в табличном объекте. Как только вы начнете писать запросы, использующие свойства сущностей, вы перейдете в область неэффективных запросов.

<pre>IQueryable<Footwear> query = table
.CreateQuery<Footwear>()
.Where(f => f.Gender == "Male"&& (f.Size > 4 && f.Size < 7));
IEnumerable<Footwear> shoes = query.ToList();

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

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

Жетоны продолжения

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

• Запрос превысил максимальный результат возврата 1000 объектов
• Выполнение запроса превысило 5 секунд
• Запрос перешел границу раздела

Из-за этих ограничений вы можете видеть, как размер раздела может легко повлиять на производительность. Показано, что слишком большое количество разделов напрямую влияет на возможность масштабирования, а слишком маленькое может легко повлиять на производительность. Запрос, имеющий результат 5 сущностей, каждая из которых имеет собственный раздел, может заставить вас обработать 4 маркера продолжения, чтобы полностью получить все результаты. Итак, как нам обращаться с токеном продолжения?

Хорошая новость заключается в том, что если вы не хотите, то Storage Client SDK обрабатывает маркеры продолжения для вас. Однако существуют случаи, когда вам нужно более детально подходить к вашим запросам, как в случае, когда вы хотите убедиться, что вы не отбрасываете подавляющее количество сущностей или, возможно, хотите реализовать разбиение на страницы. Ниже приведен пример использования  токенов продолжения :

TableQuery<Footwear> query = table.CreateQuery<Footwear>().Where(f => f.PartitionKey == partitionKey).AsTableQuery();
TableContinuationToken token = null;
List<Footwear> shoes = newList<Footwear>();
do
{
  TableQuerySegment<Footwear> queryResult = query.ExecuteSegmented(token);
  token = queryResult.ContinuationToken;
  shoes.AddRange(queryResult.Results);
} while(token != null);

Продолжение должно основываться не на том, были ли возвращены какие-либо результаты, а на том, был ли токен продолжения  нулевым . Это связано с тем, что запрос, отправленный на сервер разделов, может не дать никаких результатов, а поскольку он перешел через сервер разделов, он автоматически вернул токен продолжения  без результатов запроса . Кроме того, всегда рекомендуется писать запросы для обработки токенов, чтобы убедиться, что вы случайно не извлекаете излишние результаты данных.

Крысы! Мы попали в ловушку (работа с политиками повторных попыток)

Является ли это тем, что интернет-хомяки спят или какой-то другой snafu, вы можете быть уверены, что будут ситуации, когда наши попытки не удаются. К счастью для нас, мы можем определить  Политику Повтора,  которая обеспечивает средство для повторения неудачной операции при необходимости. Это тема, которую мы не затронули в первой статье «Будьте уверены с Azure» в  хранилище BLOB-объектов,  но применимы ко всем службам хранилища. Доступно несколько готовых политик, а также возможность создавать собственные политики повторов. Доступны 3 политики:

• линейный
• экспоненциальный
• Никто

Мы можем установить  DefaultRequestOptions  для нашего  CloudTableClient,  который позволяет нам указывать такие параметры, как наша политика повторных попыток. В дополнение к настройке политики повторных попыток в приведенном ниже примере мы также устанавливаем  MaximumExecutionTime просто для того, чтобы указать на это. Правила  повторных попыток позволяют указать время  задержки Delta между повторными попытками, а также количество максимальных попыток:

TableClient.DefaultRequestOptions = newTableRequestOptions
{
  RetryPolicy = newExponentialRetry(TimeSpan.FromSeconds(10), 5),
  MaximumExecutionTime = TimeSpan.FromSeconds(10)
};

Политика экспоненциальных повторов заставит период времени между попытками экспоненциально расти таким образом, что в приведенном выше примере будет запущена первая повторная попытка через 5 секунд, 10 секунд между следующей повторной попыткой, затем 20 секунд и т. Д. До максимального числа попыток было достигнуто. Это определяется как первый параметр конструктора  deltaBackoff. Кроме того, мы можем указать максимальное количество повторов.

Линейные  повторы работают таким образом, что интервал между попытками остается согласованным на основе указанного  времени deltaBackoff . Ни один  не политика , а просто возвращает  значение False  для  ShouldRetry ()  метод , когда проверяется CloudTableClient.

Итак, как мы узнаем, когда произошла повторная попытка?

Часто задаваемый вопрос: как узнать, произошла ли операция и была ли предпринята попытка повторной попытки? Есть несколько доступных вариантов. Одним из них является использование Microsoft  Application Transient Fault Application Block,  легко доступного через  Nuget,  и привязка к его обработке событий и встроенная способность узнавать о переходных сбоях при их возникновении.

RetryPolicy<StorageTransientErrorDetectionStrategy> retryPolicy = newRetryPolicy<StorageTransientErrorDetectionStrategy>(newIncremental(5, TimeSpan.FromSeconds(1), TimeSpan.FromSeconds(3)));
retryPolicy.Retrying += (obj, eventArgs) => System.Console.WriteLine("Retrying");
TableClient.DefaultRequestOptions = newTableRequestOptions
{
  RetryPolicy = newNoRetry(),
};
TableOperation query = TableOperation.Retrieve<Footwear>(partitionKey, rowKey);
TableResult result = retrypolicy.ExecuteAction(() => table.Execute(query));
Footwear shoe = (Footwear) result.Result;

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

Доступные текущие политики повторных попыток не повторяют для HTTP-кодов состояния 4xx, 306, 501, 505. Поэтому, если вы пишете свою собственную настраиваемую политику повторных попыток, вы также захотите ее обработать.

совпадение

В последней статье о хранилище BLOB-объектов я описал различные механизмы управления параллелизмом — оптимистический и пессимистичный параллелизм. Если у вас не было возможности или вы не знакомы с этими различными элементами управления,  переверните  и прочитайте, прежде чем двигаться дальше. Хорошим товаром с таблицами Azure является то, что они используют оптимистичный параллелизм в качестве механизма по умолчанию. Кроме того, параллелизм находится на уровне объекта, а не на уровне таблицы. Это одно из различий между параллелизмом хранилища BLOB-объектов, который предоставляется как на уровне BLOB-объекта, так и на уровне контейнера.

ETag  является свойством , что Azure Tables использовать для проведения оптимистического параллелизма. Когда объект извлекается, предоставляется  свойство ETag . Когда вы сохраняете обновление сущности,  ETag  является обязательным свойством, которое необходимо установить. Служба выполнит сравнение, чтобы убедиться, что оно соответствует  ETag  текущего объекта в таблице, чтобы обновление было успешным. Если нет, будет возвращен код состояния HTTP 412.

//generate Shared Access Policy
SharedAccessTablePolicy policy = newSharedAccessTablePolicy
{
    Permissions = SharedAccessTablePermissions.Add | SharedAccessTablePermissions.Update |
  SharedAccessTablePermissions.Query,
  SharedAccessExpiryTime = DateTime.UtcNow.AddHours(1),
};
//generate Shared Access Signature using the policy
stringsas = table.GetSharedAccessSignature(
    policy,
    null,
    "Athletics",
    null,
    "Running",
    null
);

StorageCredentials creds = newStorageCredentials(sas);

//endpoint created in this fashion to make clear what it represents
stringendpoint = string.Format("http://{0}.table.core.windows.net", accountName);
CloudTableClient tableClient = newCloudTableClient(newUri(endpoint), creds);
CloudTable table = tableClient.GetTableReference("footwear");

TablePermissions permissions = newTablePermissions();
permissions.SharedAccessPolicies.Add("tablepolicy1", newSharedAccessTablePolicy
{
  SharedAccessExpiryTime = DateTime.UtcNow.AddDays(2),
  Permissions = SharedAccessTablePermissions.Add | SharedAccessTablePermissions.Query
});
table.SetPermissions(permissions);

//generate Shared Access Signature using the policy identifier
stringsas = table.GetSharedAccessSignature(
    null,
    "tablepolicy1",
    "Athletics",
    null,
    "Running",
    null
);

StorageCredentials creds = newStorageCredentials(sas);
//endpoint created in this fashion to make clear what it represents
stringendpoint = string.Format("http://{0}.table.core.windows.net", accountName);
CloudTableClient tableClient = newCloudTableClient(newUri(endpoint), creds);
CloudTable table = tableClient.GetTableReference("footwear");