Захват неявных сигналов интереса в Джанго

Question

Чтобы установить фон: я заинтересован в:

• Захват неявных сигналов интереса к книгам при просмотре пользователями сайта. Сайт написан на django (python) с использованием mysql, memcached, ngnix и apache

Скажем, например, мой сайт продает книги. Когда пользователь просматривает мой сайт, я хотел бы отслеживать, какие книги он просматривал и сколько раз их просматривал.

Не то чтобы я сохранял данные таким образом, но в идеале я мог бы иметь доступ на лету к такой структуре, как:

{user_id : {book_id: number_of_views, book_id_2: number_of_views}}

Я понимаю, что здесь есть несколько подходов:

• Какой-то журнал плоских файлов
• Запись объекта в базу данных каждый раз
• Запись в объект в memcached

На самом деле я не знаю, как это повлияет на производительность, но я бы предпочел не записывать в базу данных при каждом просмотре страницы, а задержка записи в журнал и вычисления структуры позже кажется недостаточно быстрой, чтобы дать хорошие рекомендации. на лету, когда вы используете сайт, и memcached appraoch кажется нормальным, но сохранение этого объекта в памяти стоит: вы можете потерять его, и он никогда не будет записан где-то «постоянным».

Какой подход вы бы предложили? (не обязательно должен быть одним из вышеперечисленных) Спасибо!

Answer 1

Если эти данные не являются неважной статистикой, которая может быть или не быть доступной, я бы предложил использовать простой подход и использовать модель. Это наверняка попадет в базу данных каждый раз.

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

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

Сначала я определенно пойду с моделью и посмотрю, как она работает. (а также как работают другие части проекта)

Answer 2

Можно использовать хранилище данных документа (mongo / couchdb) или постоянное хранилище значений ключей (tokyodb, memcachedb и т. Д.).

Никаких конкретных рекомендаций от меня нет, поскольку окончательное решение зависит от множества факторов - нагрузки, вашей готовности изучать / внедрять новые технологии, размера данных ...

Answer 3

Какой подход вы бы предложили? (не обязательно должен быть одним из вышеперечисленных) Спасибо!

хммммм ... это как в комнате с четырьмя стенами, где только одна дверь, и я говорю, что хочу выйти из комнаты, но не через единственную дверь ...

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

Answer 4

Мне кажется, что одним из подходов может быть использование memcached для сохранения счетчика, но регулярный запуск cron для хранения значения из memcached на БД или диск. Таким образом вы получите всю производительность memcached, но в случае сбоя вы не потеряете данные более чем за пару минут.