Window Azure Table Storage Производительность запроса

Question

Итак, у меня был запрос на запуск отчета на основе хранилища таблиц azure, после длительного процесса обработки отчета я получил данные. Однако, когда я закончил повторное факторинг консольного приложения, что-то не сидела со мной. Я не работал с azure очень долго, но у меня есть основная концепция, что то, что вы решили использовать в качестве PartitionKey и RowKey, либо сделает, либо сломает таблицу (в конечном итоге).

В запросе, который я запускаю, используется временная метка (есть ограничения на то, почему я использую это поле) в качестве фильтра, чтобы отбросить данные за день, потому что PartitionKey и RowKey неизвестны. Насколько я понимаю, это приведет к тому, что запрос будет проходить через всю таблицу (исправьте меня, если я ошибаюсь), если вы выполняете запрос без ПК и РК. Это приводит к очень плохому времени получения запроса.

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

Что произойдет, если в середине моего запроса серия записей будет изменена в середине выборки?

Возьмите этот сценарий, например:

• У меня есть 100 записей в моей таблице.
• Я сейчас в 50-й записи.

В то время, когда я получаю доступ к 50-й записи, запись 1-20 обновляется и ввод изменяется с 80-100.

Какие данные я могу получить? (Я бы поверил, что получаю записи обновления для 80-100, но сохраняю старые данные с 1-20).

Answer 1

Исправьте меня, если я ошибаюсь, но выполнение запроса без РК и РК приведет к очень плохому времени получения запроса.

Это серьезный анти-шаблон. Наиболее эффективный запрос - это точечный запрос на ПК и РК. Предоставление ПК по меньшей мере заставляет запрос обрабатывать один раздел или вычислить узел. Отсутствие гарантии полного сканирования таблицы. Как и во многих магазинах NoSQL, очень важно разработать модель данных по эффективности запросов. С контролем PK & RK вы могли бы вставить в них временную метку, оставаясь в курсе того, что еще одна запись в виде анти-шаблона добавляется только в один раздел. Это происходит, например, если вы основываете PK на ежедневном или почасовом ковше и только вставляете данные в один ведро.