Как правильно пересчитывать счетчики для поста?

Question

[likejavascript]

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

Я использую Nodejs/MongoDB. Сейчас у меня есть две коллекции:

Posts:

[{
   _id: ObjectId(1),
   title: 'Untitled',
   content: 'empty'
}]

Votes:

[{ 
    _post: ObjectId(1),
    _user: ObjectId(...),
    vote: 1,        
}, {
    _post: ObjectId(1),
    _user: ObjectId(...),
    vote: 1,
}]

Когда пользователь голосует за пост с ObjectId(1), то отправляется следующий запрос:

Votes.create({_post: ObjectId(1), vote: 1}).exec(cb);

При получении списка постов мне приходится делать несколько запросов:

1. Запросить все посты, отсортированные по дате создания
2. Запросить все оценки по каждому посту и добавить их в посты в nodejs.

При частом запросе списка постов будут проблемы в постоянном пересчете счетчиков, я бы хотел улучшить путем пересчета сохранения счетчика прямо в посте:

[{
   _id: ObjectId(1),
   title: 'Untitled',
   content: 'empty',
   votes: 2
}]

Но в этом случае мне нужно как-то поддерживать целостность данных и гарантированно обновлять актуальные счетчики в посте на основе данных оценок в Votes.

Данную проблему можно решить встраиванием оценок в виде массива и хранить его в постах, но MongoDB не любит обновлять большие документы.

В общем посоветуйте паттерн для гарантированного пересчета счетчиков в посте, что можно использовать, очереди, версионность или что-то еще?

Answer 1

[lega]

Я бы подумал о таком варианте (posts):

{
  votes: 15,
  vote: {
    user1: 1,
    user2: -1
  }
}

Одним запросом и пересчет и защита от повторного голосования, и выборка одним запросом.

Comments

[Александр Вульф]

А если будет 100к голосов?

[lega]

Александр Вульф:
покажите мне пост на стековерфлоу где есть 100к голосов

даже если такие будут, и если они будут тормозить, то их можно будет поместить в группу особенных и обрабатывать по другому
если пробовать хранить компактно то это 100к * 3байта на юзера = всего 300кб

[likejavascript]

lega, да максимум там ~15k stackoverflow.com/questions?sort=votes А как гарантировать правильное обновление счетчика при скажем повторном голосовании пользователя?

[lega]

likejavascript: это в условии проверять:

db.posts.update({'vote.user1': {$exists: false}}, {votes: {$inc: 1}})
по результату можно проверить прошла запись или нет, если не прошла - значит коллизия (двойное нажатие)

а на клиентской стороне кнопка будет просто не активна если пользователь уже проголосовал (это достается в одном запросе с постом)

[likejavascript]

Ок, а как тогда предусмотреть такой кейс. Пользователь ранее проголосовал положительно, т.е есть `1` и теперь голосует отрицательно `-1`. В этом случае нам нужно изменить оценку в vote.user и отнять `2` голоса от votes. Я так понимаю, что за одну операцию это сделать одновременно с проверкой накручивания голосов не получится?

[lega]

likejavascript: Получится, вы на клиенте знаете что это изменение голоса, поэтому делайте соотв. запрос.

[likejavascript]

Проблема будет с двумя открытыми вкладками на одной из которых более старая информация, чем на другой

[lega]

likejavascript: второй запрос не пройдет, т.к. не удовлетворит по условию.