Эффективный способ отображения количества входящих сообщений (1) в веб-приложении без вызова БД для каждого запроса страницы.

В моем веб-приложении мы создали функциональность центра сообщений/почтовых ящиков, в навигации по каждой странице мы ссылаемся на «Центр сообщений» и включаем рядом с ним количество непрочитанных сообщений, например «Центр сообщений (2)». Чтобы заполнить (2), с каждым запросом мы запускаем *SELECT COUNT(**) FROM MessageTable WHERE unread = true blah blah*, чтобы получить количество для включения в навигацию.

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

Я придумал два варианта:

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

Это хорошие альтернативы, есть ли другие варианты?


database architecture performance jms
person MichaelKStuovo    schedule 30.10.2009    source источник
comment
Вы подтвердили наличие проблемы? Преждевременная оптимизация — корень всех зол. Правильный индекс сделает операцию SELECT COUNT очень дешевой.   -  person erikkallen    schedule 30.10.2009
comment
Когда мы делаем массовый обмен сообщениями и сильно нагружаем эту таблицу, это значительно влияет на производительность сайта.   -  person MichaelKStuovo    schedule 30.10.2009

Ответы (2)


arrow_upward
1
arrow_downward

Одно из предложений, упомянутых в вашем посте, заключается в использовании другой таблицы MessageCounters с чем-то вроде [UserId: NumberOfMessages]. Индексация UserId сделает эту операцию дешевой (и будет запускать запись только каждый раз, когда приходит новое сообщение). Недостатком является то, что для каждого нового сообщения вы будете выполнять две разные записи (одну в MessageTable, а другую в MessageCounters.

Другие варианты, которые вы можете рассмотреть, если вы действительно думаете, что это будет проблемой:

  • Сохраните эти данные в Memcached и получите их оттуда. Если вы находитесь на уровне, когда эти запросы вас беспокоят, вы, вероятно, все равно будете использовать Memcached.

  • Используйте отдельное постоянное хранилище K/V, такое как Redis или TokyoCabinet, для некоторых более простых задач веб-сайта (например, для ведения этого счетчика).

person Federico Builes    schedule 30.10.2009

arrow_upward
0
arrow_downward

Так это количество непрочитанных сообщений?

Возможно, вы можете сохранить этот номер в файле cookie пользователя и обновить его, когда

  • каждый раз, когда пользователь проверяет новые сообщения
  • пользователь прочитал сообщение (это можно сделать в javascript или серверном скрипте)
  • своевременная основа
person Darkerstar    schedule 30.10.2009
comment
Это решает проблему кэширования, но не свежесть. Если пользователь получит новое сообщение, значение cookie будет устаревшим. Мы все еще остаемся с той же проблемой. - person MichaelKStuovo; 31.10.2009