Хранилище таблиц Azure. Как быстро я могу сканировать таблицы?
Все предупреждают о том, что не следует запрашивать что-либо, кроме RowKey или PartitionKey в хранилище таблиц Azure (ATS), иначе вас заставят сканировать таблицы. Какое-то время это парализовало меня, пытаясь придумать точно правильные PK и RK и создать псевдо-вторичные индексы в других таблицах, когда мне нужно было запросить что-то еще.
Однако мне приходит в голову, что я обычно сканирую таблицы в SQL Server, когда считаю нужным.
Поэтому возникает вопрос, как быстро я могу сканировать таблицу Azure Table. Является ли это константой в единицах в секунду или зависит от размера записи и т. Д. Существуют ли практические правила относительно того, сколько записей слишком много для сканирования таблицы, если вы хотите адаптивное приложение?
4 ответа
Проблема сканирования таблицы связана с пересечением границ раздела. Уровень производительности, который вам гарантирован, - это простота, установленная на уровне раздела. следовательно, когда вы запускаете полное сканирование таблицы, это а) не очень эффективно, б) не дает никаких гарантий производительности. Это связано с тем, что сами разделы устанавливаются на отдельных узлах хранения, и когда вы запускаете сканирование между разделами, вы потребляете потенциально огромное количество ресурсов (связывая несколько узлов одновременно).
Я полагаю, что эффект пересечения этих границ также приводит к токенам продолжения, которые требуют дополнительных обращений к хранилищу для получения результатов. Это приводит к снижению производительности, а также увеличению количества транзакций (и впоследствии стоимости).
Если количество пересекаемых разделов / узлов довольно мало, вы, вероятно, не заметите никаких проблем.
Но, пожалуйста, не цитируйте меня по этому поводу. Я не эксперт по хранилищу Azure. На самом деле это область Лазурного моря, о которой я знаю меньше всего.:П
Я думаю, что Брент на 100% на деньги, но если вы все еще чувствуете, что хотите попробовать, я могу только предложить выполнить несколько тестов, чтобы выяснить это самостоятельно. Попробуйте включить параметр sectionKey в свои запросы, чтобы не допустить пересечения разделов, потому что в конечном итоге это снижает производительность.
Таблицы Azure не оптимизированы для сканирования таблиц. Сканирование таблицы может быть приемлемым для длительной фоновой работы, но я бы не стал делать это, когда требуется быстрый ответ. С таблицей любого разумного размера вам придется обрабатывать токены продолжения, когда запрос достигает границы раздела или получает результаты 1k.
У группы хранения Azure есть отличная статья, в которой объясняются цели масштабируемости. Целевой показатель пропускной способности для одного раздела таблицы составляет 500 объектов / сек. Общая цель для учетной записи хранения составляет 5000 транзакций в секунду.
Ответ - нумерация страниц. Использовать top_size - максимальное количество результатов или записей в результате - в сочетании с next_partition_key а также next_row_key жетоны продолжения. Это делает существенную даже факторную разницу в производительности. С одной стороны, ваши результаты статистически более вероятны из одного раздела. Простые результаты показывают, что наборы сгруппированы по ключу продолжения раздела, а не по ключу продолжения строки.
Другими словами, вам также нужно подумать о своем пользовательском интерфейсе или системном выводе. Не беспокойтесь о том, чтобы возвращать более 10 - 20 результатов, максимум 50. Пользователь, вероятно, больше не будет использовать или исследовать.
Звучит глупо. Выполните в Google поиск по запросу "собака" и обратите внимание, что поиск возвращает только 10 элементов. Больше не надо. Следующие записи будут вам полезны, если вы нажмете "продолжить". Исследования доказали, что за этой первой страницей почти никто не рискует.
select (возвращая подмножество значений ключа) может иметь значение; например, использовать select знак равно "PartitionKey,RowKey" или же 'Name' какой бы минимум вам ни понадобился.
"Я полагаю, что эффект пересечения этих границ также приводит к токенам продолжения, которые требуют дополнительных обращений к хранилищу для получения результатов. Это приводит к снижению производительности, а также к увеличению количества транзакций (и последующей стоимости). ".
... немного неверно. маркер продолжения используется не из-за пересечения границ, а потому, что таблицы Azure допускают не более 1000 результатов; поэтому два токена продолжения используются для следующего набора. по умолчанию top_size по существу 1000.
Для вашего удобства просмотра приведено описание запросов к объектам из интерфейса Azure Python. другие во многом такие же.
'''
Get entities in a table; includes the $filter and $select options.
table_name: Table to query.
filter:
Optional. Filter as described at
http://msdn.microsoft.com/en-us/library/windowsazure/dd894031.aspx
select: Optional. Property names to select from the entities.
top: Optional. Maximum number of entities to return.
next_partition_key:
Optional. When top is used, the next partition key is stored in
result.x_ms_continuation['NextPartitionKey']
next_row_key:
Optional. When top is used, the next partition key is stored in
result.x_ms_continuation['NextRowKey']
'''