Где я должен хранить пользовательскую статистику, которую нужно часто просматривать?

Question

В моем веб-приложении у моих пользователей много событий. Одним из таких событий является «пользователь обновил статус Facebook». Пользователь может иметь сотни событий такого типа, и существует 10 типов событий. Мне нужно отображать количество событий и другую пользовательскую статистику, основанную на событиях, очень масштабируемым образом. Это потому, что каждый пользователь сможет увидеть свою статистику. Очевидно, что мы не можем позволить себе выполнять каждый расчет каждый раз, когда пользователь посещает веб-сайт, поэтому кэширование этих статистических данных, безусловно, поможет.

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

Answer 1

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

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

Нереляционные хранилища данных обращаются эта модель полностью, потому что они не имеют сложных операций чтения SQL. Модель заставляет вас сдвигаться ваши вычисления в записи, в то время как сводя большинство чтений к простому операции - эквивалент SELECT * ОТ Table.