Какой лучший алгоритм подсчета для данных журнала хранилища таблиц Azure?

Я использую Windows Azure и впервые отправляюсь в хранилище таблиц Azure, чтобы сделать свое приложение масштабируемым для нагрузок с высокой плотностью трафика. Моя цель проста: регистрировать каждый входящий запрос по набору параметров и для подсчета или суммирования данных из журнала. В этом я предложил 2 варианта, и я хотел бы знать, что более опытные люди считают лучшим вариантом.

Вариант 1. Используйте логические значения и подсчитайте «Истинные» строки

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

Вариант 2: используйте значения типа Int и просуммируйте строки

Каждая строка записывается, как указано выше, но вместо этого каждый столбец параметров добавляется как значение 0 или 1. Суммирование будет происходить путем запроса всех строк и использования операции Sum для каждого столбца. Это будет быстрее, потому что суммирование может произойти в одном запросе, но теряю ли я что-то при хранении 32-битных целых чисел для логического значения?

Я думаю, что на данный момент для скорости запроса лучше всего подходит вариант 2, но я хочу спросить вслух, чтобы узнать мнение об аспектах хранения и извлечения, потому что я не очень хорошо знаком с таблицами Azure (и я надеюсь, что это поможет другим людям по дороге).


person eudaimos    schedule 11.06.2011    source источник


Ответы (1)


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

Я думаю, вам лучше вести текущий результат, а не пересчитывать все каждый раз. Мы говорили о нескольких шаблонах для этого в эпизоде ​​43 Cloud Cover: http://channel9.msdn.com/Shows/Cloud+Cover/Cloud-Cover-Episode-43-Scalable-Counters-with-Windows-Azure

person user94559    schedule 11.06.2011
comment
Я уже видел ваше сообщение в блоге и скачал исходник перед тем, как опубликовать свой вопрос. Я действительно смотрел этот эпизод, хотя он был ужасно мучительным (при загрузке iPad iTunes звук был прекрасным, но видео было ужасным - остановитесь, прыгайте вперед, останавливайтесь снова и снова, что делает его полностью недоступным для просмотра) и при просмотре Интернета на моем ноутбуке он продолжал буферизоваться (тест скорости. net сказал, что мой довод был 2,88 Мбит / с для загрузки). Так что мне потребовалось больше полутора часов, чтобы просмотреть ваш 30-минутный эпизод. К вашему сведению, тем, кто входит, прокрутите до отметки 9:30, где они начинают говорить о шаблонах для отслеживания подсчетов. - person eudaimos; 13.06.2011
comment
@smarx Я думал, вы добавили комментарии для своего блога. Что с ними случилось? Вы должны обновить сообщение в блоге и исходный код своими комментариями в конце шоу об использовании DeploymentId в качестве раздела. - person eudaimos; 13.06.2011
comment
@smarx Наконец, мои мысли о вашем ответе: Итак, вы говорите, что мне действительно не следует использовать журнал и подсчитывать данные журнала b / c, это в конечном итоге является большой проблемой для сериализации в XML и отправки по HTTP b / c вся агрегация не может выполняться локально. Означает ли это, что лучше иметь более мелкозернистые объекты (меньше свойств), потому что их легче вернуть? И лучшее, что я могу сделать для подсчета, - это синхронизировать количество потоков, это гарантировано? Я пошел по пути данных журнала b / c, у меня вообще не было бы никаких блокировок. - person eudaimos; 13.06.2011
comment
У меня были комментарии к моему блогу ... удалил их, потому что не было ничего, кроме спама. (Большинство отзывов сейчас идет в Twitter, и это меня вполне устраивает.) Что касается поставленной задачи, да, я говорю, что журнал, который вы опускаете для подсчета, кажется неоптимальным. Возможно, это не имеет большого значения для небольших объемов данных, но поскольку вы беспокоитесь о том, сколько битов используется для хранения логического значения, я подозреваю, что вы ожидаете большого количества данных. Есть несколько вариантов, но я думаю, что важно вести общий журнал, а не (или в дополнение к нему). - person user94559; 13.06.2011
comment
Спасибо, Стив. Однако вы не ответили на мой другой вопрос: гарантирована ли блокировка количества потоков на развертывание. Это? - person eudaimos; 13.06.2011
comment
@smarx, если я добавлю Thread.CurrentThread.ManagedThreadId к моему RowKey (т.е. RowKey = RoleInstance.Id + "-" Thread.CurrentThread.ManagedThreadId), устранит ли это необходимость блокировки счетчика для каждого RoleInstance? - person eudaimos; 13.06.2011
comment
Я не понимаю вопроса о гарантиях ... заблокированные инкремент и декремент являются потокобезопасными (в этом суть), если это то, о чем вы спрашиваете. Не уверен, спасает ли вас идентификатор потока ... возможно ли, чтобы один и тот же поток обслуживал несколько одновременных веб-запросов (и, таким образом, потенциально мог одновременно выполнять несколько асинхронных вызовов хранилища)? Кроме того, вам не нужно слишком много счетчиков (если бы каждый поток имел уникальный идентификатор - никогда не использовался повторно - вы бы вернулись к своей исходной идее). - person user94559; 13.06.2011
comment
@smarx re: garauntees, могу ли я предположить, что, поскольку Interlocked.Increment не генерирует исключения (кроме NullRef), он будет всегда выполняться правильно? re: ManagedThreadId, я предполагаю наличие пула потоков для каждого экземпляра WebRole, где потоки повторно используются, по одному на каждый WebRequest, поэтому это не будет то же самое, что и ведение журнала, т.е. max Rows = # потоков в пуле потоков. Фоновое суммирование может очистить старые идентификаторы потоков. Мои предположения неверны? Сколько потоков находится в пуле потоков для WebRole в Windows Azure? - person eudaimos; 14.06.2011
comment
Да, я считаю, что Interlocked.Increment гарантированно добьется успеха. Я понятия не имею, как работают потоки в ASP.NET. Они должны работать в Windows Azure так же, как и везде. - person user94559; 14.06.2011
comment
Будет ли ваше решение суммировать счетчики для производственных и промежуточных развертываний? - person eudaimos; 02.09.2011