Предложения о том, как обрабатывать рейтинги - PullRequest
1 голос
/ 10 ноября 2010

У меня здесь вопрос архитектуры, с которым я борюсь.

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

Мой вопрос: как бы вы предложили это реализовать в архитектуре.

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

Таким образом, моя модель, которая у меня в голове, которая обеспечивает полный доступ к этим данным, будет состоять в том, что каждое из этих событий (post, comment, upvote) регистрируется, а рейтинг пользователей определяется из этих журналов. Проблема в том, что я знаю, что эта модель плохо масштабируется в долгосрочной перспективе, так как вычисление рейтинга пользователя превратится в кошмар SQL-запроса.

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

Ответы [ 3 ]

1 голос
/ 10 ноября 2010

Кто сказал, что вы должны хранить данные только один раз?

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

Опираясь на то, что вы сказали, в дополнение к хранению определенных баллов по отношению к конкретным объектам (таким как вопросы, ответы и т. Д.), Вы также можете хранить «промежуточную сумму» (балл), которая увеличивалась при назначении баллов (я думаю это будет столбец Int в таблице «Пользователь» в вашей базе данных).

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

Другой подход такой же, но в промышленном масштабе; Вы слышали об OLTP и OLAP?

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

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

Нет причины, по которой вы не можете сделать то и другое, большой вопрос - как. Решение «промежуточный итог» делает это, но только для очень конкретного случая. Возможно, стоит взглянуть на более широкую систему (и где вы хотите ее взять) и, возможно, «инвестировать» в более комплексную систему с разделами.

0 голосов
/ 10 ноября 2010

Если вы можете использовать что-то вроде ' Redis ', это очень поможет.Идея такова - пишите в redis и mysql оба, но при чтении читайте только из redis.Но вам нужно предварительно решить все ключи, которые вам понадобятся в Redis.

Например: Для подсчета комментариев у вас могут быть ключи, такие как Comments:<userId>:count, которые вы можете увеличивать для каждого комментария, опубликованного,Аналогично, вы можете иметь такие ключи, как Posts:<userId>:count и т. Д. По сути, вы (в некотором смысле) кэшируете все запросы типа count (*) на сервере redis.

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

0 голосов
/ 10 ноября 2010

Если вы хотите иметь историю всех изменений рейтинга, вам нужно как-то войти в нее. Вы можете создать файл, который будет регистрировать их все и анализировать, таким образом, вы можете хранить длинную историю. Если вы хотите перейти на SQL, оставьте последние n изменений в деталях и жестко запишите рейтинг перед изменениями.

Добро пожаловать на сайт PullRequest, где вы можете задавать вопросы и получать ответы от других членов сообщества.
...