Лучше ли каждый раз вести отдельную таблицу подсчета по сравнению с запросом подсчета? - PullRequest
7 голосов
/ 23 августа 2011

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

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

Обновление:

Точно так же у меня есть функция опроса, в которой люди могут голосовать, Люди могут голосовать только за Да или Нет.Прямо сейчас я храню голоса в отдельной таблице.И мне нужно показать список опросов без участников, без «да» и «нет» на моей домашней странице.

Подобно домашней странице stackoverflow (где они показывают количество голосов, ответов и просмотров).

Ответы [ 3 ]

7 голосов
/ 23 августа 2011

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

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

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

Обновление: Вопрос для голосования "Нет / Да"немного по-другому, так как основная цель состоит в том, чтобы просто отслеживать количество, а не обязательно всю информацию (то есть кто проголосовал за).Таким образом, правильной реализацией может быть просто отслеживать накопленное количество голосов «за» и «нет».Тем не менее, чем больше информации вы храните (то есть, кто проголосовал «за», а не только за многих), тем больше вы можете сделать с ней, если вы решите это сделать (например, в Stackoverflow я всегда могу удалить свое upvote - то, что вы не сможете сделать, еслиты не отслеживал кто голосовал).Опять же, в этом случае я бы советовал не агрегировать на ранней стадии, потому что вы потеряете определенную информацию.

2 голосов
/ 23 августа 2011

Это зависит.

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

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

Сочетание двух этих типов, асинхронная подача таблицы статистики о фолловерах, может дать вам лучшие результаты (быстро в операциях записи, очень быстро при чтении).

0 голосов
/ 23 августа 2011

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

  • Нормализованная база данных для полных данных, которые вы читаете, когда хотите отобразить полные данные профиля
  • Индекс поиска(Например, Solr / Lucene) с наиболее часто отображаемыми данными, включая агрегаты, такие как счетчики, которые вы используете для быстрого отображения и поиска
Добро пожаловать на сайт PullRequest, где вы можете задавать вопросы и получать ответы от других членов сообщества.
...