Как оптимизировать количество новых сообщений в избранном - PullRequest
Новая
       102

Как оптимизировать количество новых сообщений в избранном

2 голосов
/ 10 марта 2011

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

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

Проблема Это, конечно, довольно дорого для БД, потому чтоОбычно 20-50 избранных, и я должен проверить БД, если какой-либо пост был добавлен в какую-либо из этих тем.Средняя тема имеет 1000-2000 сообщений.И это происходит для каждого просмотра страницы для каждого пользователя, что составляет примерно 900 000 просмотров в месяц.

Возможное решение 1 Я храню общее количество сообщений в каждой теме и храню количество последних просмотренных сообщений.для каждой темы, для каждого пользователя.Это может быть самым быстрым, но имеет много недостатков, которые являются функциональными (удаление, фильтрация сообщений и т. Д.).

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

База данных Я храню все сообщения по всем темам в одной огромной таблице = сотни тысяч сообщений.

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

Большое спасибо.

Ответы [ 3 ]

0 голосов
/ 10 марта 2011

Полагаю, ваши почтовые идентификаторы последовательны и всегда увеличиваются.

Создайте таблицу для вашего фаворита, по крайней мере, с такими полями: user_id, topic_id, last_post_id

Затем вы можете проверить наличие новых сообщений с помощью этого простого запроса: 

select topics.id, count(posts.id)
from users
inner join favorites on favorites.user_id = users.id
inner join topics on topics.id = favorites.topic_id
inner join posts on 
    posts.topic_id = topics.id and
    posts.id > last_post_id
where users.id = $id
group by topics.id

Это должно работать довольно гладко.

Вы также должны обновлять last_post_id каждый раз, когда пользователь посещает тему, но это должно быть довольно просто.

0 голосов
/ 10 марта 2011

Если у вас есть индекс (topic_id, post_id) для огромной таблицы all_posts, этот запрос не должен быть слишком дорогим: 

select topic_id, count(*)
from all_posts a
inner join user_favorites u on u.topic_id = a.topic_id
where a.post_id > u.post_id and u.user_id = @user_id
group by topic_id
0 голосов
/ 10 марта 2011

Во-первых: понятия не имею о вашей схеме или системе баз данных, но это должно быть относительно просто, если вы ведете учет того, когда вашего пользователя в последний раз видели ($ DATE_USER_WAS_LAST_SEEN в приведенном ниже примере), и каждое из ваших сообщений предположительно связано с егораздел с каким-то идентификатором, и у вас есть список всех идентификаторов $ FAVORITE. 

SELECT topic_id, count(*) AS count FROM posts 
WHERE topic_id IN ($FAVOURITES) 
    AND created_date > $DATE_USER_WAS_LAST_SEEN 
GROUP BY topic_id

даст вам вывод типа: 

topic_id   |   count
---------------------
  3        |     20
  1        |     27
  33       |     120

Это должно быть приемлемой скоростью дляВ таком масштабе вы можете улучшить запрос, не используя IN и создав длинную строку (topic_id = 1 OR topic_id = 2 OR topic_id = etc), если ваша база данных не оптимизирует эти вещи автоматически.

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

...