Лучший подход к кешу Подсчет таблиц SQL?

Question

Я хотел бы разработать Форум с нуля, с особыми потребностями и настройкой.

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

Имея только три таблицы, tblForum, tblForumTopics, tblForumReplies, каков наилучший подход к кешу, темы пользователя и ответы?

Подумайте по простому сценарию: нажмите на ссылку и откройте страницу Replies.aspx? Id = x & page = y и начните читать ответы. В запросе HTTP сервер выполнит команду SQL, которая будет получать все ответы для этой страницы, а также «внутреннее соединение с tblForumReplies, чтобы узнать количество ответов пользователей для каждого пользователя, который ответил».

select 
    tblForumReplies.*, 
    tblFR.TotalReplies 
from 
    tblForumReplies 
    inner join 
    (
     select IdRepliedBy, count(*) as TotalReplies 
     from tblForumReplies 
     group by IdRepliedBy 
    ) as tblFR 
    on tblFR.IdRepliedBy = tblForumReplies.IdRepliedBy 

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

При подсчете ответов для каждого пользователя на вставку/удаление и сохранение его в отдельном поле, как синхронизировать с ручным изменением данных. Предположим, что я вручную удалю ответы от SQL.

Answer 1

Эти три подхода, я бы думать о:

1) Может производительность SQL Server будет достаточно хорошо, что вам не нужно кэшировать. Возможно, вы недооцениваете, насколько хорошо SQL Server может выполнять свою работу. Если вы выполняете свои права, это всего лишь один запрос, чтобы получить все подсчеты всех пользователей, которые находятся в этом потоке. Если вы думаете об этом как о одном запросе на пользователя, это неправильно.

2) Не кешируйте. Избавьтесь от количества пользователей в таблице пользователя. Обновляйте строку пользователя всякий раз, когда сообщение вставляется или удаляется.

3) Если у вас тысячи пользователей, даже много тысяч, но не миллионы, вы можете обнаружить, что практическое кэширование пользователя и их количество в памяти веб-уровня - для кеша ASP.NET, «Приложения».

Answer 2

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

Кстати, я не думаю, что ваш запрос потребляет процессор. SQL-сервер будет оптимизировать этот материал, а COUNT (*) будет работать в тиках ...

Answer 3

tbl префиксы сосать - целых Replies.aspx?id=x&page=y URIs do. Рассмотрим ASP.NET MVC или просто часть маршрутизации.

Во-вторых, не оптимизируйте преждевременно. Однако, если вам это действительно нужно, денормализовать свои данные: добавьте столбец TotalReplies в таблицу ForumTopics и либо положитесь на свой DAL/BL, чтобы это обновление обновлялось (возможно, с запланированной задачей для повторной синхронизации), либо используйте триггеры.

Answer 4

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