Рейтинг в реальном времени или другая приемлемая реализация

Может есть какие-то такие расщетные базы данных, чтоб держать там только id и общий скор и в любой момент быстро получать позициию пользователя. Вообще может есть алгоритм по которому я смогу пересчитывать только изменившиеся позиции?

короче собрал мысли в кучу, теперь

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

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

Юзал бы реляционную базу, жил бы спокойно.

в смысле? я и так их юзаю, у меня на сервере есть и postgresql и mysql (нужен для gitlab_ci и некоторых движков), но мне кажется обновлять для всех юзеров будет быстрее чем пытаться вытянуть рейтинг тяжелым запросом

еще будут люди вообще без голосов, такие в рейтинге не участвуют

Если я правильно тебя понял, то можно использовать таблицы типа memory для хранения и пересчета недавних результатов, постепенно сохраняя в обычные.

ну так вот прикинь сколько займет 40 000 последовательных апдейтов

Это же монго, там же довольно вольная структура данных. Почему бы не завести поле - массив (например) votes в таблице юзеров, на каждый голос ты добавляешь в votes что-то типа [1, (new Date)], таким образом у каждого пользователя много votes. На каждое добавление ты высчитываешь его рейтинг с помощью какой-нибудь функции, массив из ~1000 элементов js обсчитает за доли секунды (а сильно старые голоса можно сразу и удалять), а результат сохраняй в соседней поле (например) rait в виде целого числа, поле рейт индексируешь. В принципе, в votes можешь хранить только даты, а можешь еще и user_id голосовавшего (на всякий).

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

точнее не сам перебор а update поля rate

без перебора всех невозможно
update поля rate

Всех юзеров? поясни-ка этот момент, т.к. я предложил перебрать (суммировать, вычислить) только вложенные записи.

Мм понял, а простая сортировка тебе не помогает, всмысле, если нужно отобразить на странице первых 10, то я и выберу первых 10 по рейтингу.

есть 40к юзеров и 40к мест в рейтинге со-во, с первого места (больше всего очков) до последнего, 40к-вого

Короче, тебе во-видимому не сильно нужно поле с номером юзера в рейтинге, т.к. при запросе ты либо знаешь его, либо можешь получить (вариант для mysql http://stackoverflow.com/questions/3614666/mysql-get-row-position-in-order-by).

вместо отдельного определения порядка юзеров, выполняй сортировку сразу, при изменении рейтинга, для этого достаточно удалять записи у которых сменился ретинг и вставлять обратно используя в качестве хоронилища R-tree или чего угодно по вкусу (только, бугага это есть ручной кодирование любой базы с тупым индексом)

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

черт, он записывает номер юзера?

угу

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

users.find(user.score < score).count() таким образом получая позицию в рейтинге

и не тормозит такое затейство?

count очень быстрый, score индексируется

ансинхронно же кроме того

ыы, лишнее процессорное время и как с ним бороться :) (это я про воркер обновляющий 40к записей)

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

nosql быдлокод как он есть

но операция count как и выборка в mongo действительно очень очень быстрая, даже без индексов, оно же не выбирает все записи

у тебя запрос на каждую запись, этого достаточно, даже если там будет «selct 1;»

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

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

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

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

1) Пересчитать рейтинг пользователя - просто прибавить или отнять значение счетчика из мепы. 2) Если значение прибавляем, то сравниваем с рейтингом следующего пользователя, если рейтинг больше, чем у него, то меняем местами с ним. Повторить. 3) Если значение вычитаем, то двигаемся вниз.

В место массива вполне можно использовать список, сложность не ухудшится, однако массив дает меньшую константу.

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

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

Да, при наступлении 00:00 нужно остановить обработку лайков и пересчитать опять всю структуру.

Без массива тоже не сложно: нужно что бы воркер проапдейтил текущее значение рейтинга - добавил или удалил. А ночью в 00:00 пересчитывать весь рейтинг с учетом того, что чем лайк старее, тем меньше его вес.

Ну да и забирать ранк примерно как select rank from (select user_id, rank() over (order by raiting) from user_rating) r where user_id = ? если для рсубд и кешить надолго

А почему бы не заюзать для этого какой-нибудь redis? Вроде бы почти идеальное решение.

ну вот чем это будет толичатся крмое еще одной сущности?

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