АГ
Nikita Ilin
Я не очень понял, как в реалтайме всё проверять очень быстро.
кликхаус, возможно эластик, норм запросы такие обрабатывает
Size: a a a
2020 November 16
YG
Nikita Ilin
Как гарантировать тогда, что пользователя не нарвутся на один и тот же параграф и все параграфы будут в итоге просмотрены?
Я так понял они говорят про разбиение на партиции?
YG
По id юзера
АГ
в целом, конечно, проще заявки класть в очередь, и выдавать юзерам не синхронно а потом. потому что в реалтайме реально слишком уж хайлоад будет.
АГ
вешать лоадер
NI
Я так понял они говорят про разбиение на партиции?
Тогда я неправильно понял
YG
Я может быть тоже 🙃
АГ
По id юзера
разбиение чего? по какому принципу? не понимаю чот
NI
в целом, конечно, проще заявки класть в очередь, и выдавать юзерам не синхронно а потом. потому что в реалтайме реально слишком уж хайлоад будет.
Будет в очереди, какая разница
SP
По id юзера
Это не эффективно распределяет нагрузку. Мол у тебя одни юзеры быстро апрувят другие медленно
NI
Так фишка не только в том, чтобы быстро сделать поиск. Но ещё и быстро обновить стейт
АГ
Nikita Ilin
Будет в очереди, какая разница
алгоритм "что выдать следующее" использует 2 базовых принципа - 1) циклический обход по кругу от меньшего к большему,потом с начала. 2) проверку истории для избежания дублирования. если это не синхронно считать - то норм с очередью должно быть, без особых тупняков, за 2-10 сек я думаю система сможет выдать следующий абзац
АГ
Nikita Ilin
Так фишка не только в том, чтобы быстро сделать поиск. Но ещё и быстро обновить стейт
в твоем случае все надо делать через очереди.
АГ
нажал лайк / дизлайк - событие на обработку
АГ
обработалось - убираем из текущего стейта, кладем в историю
YG
Это не эффективно распределяет нагрузку. Мол у тебя одни юзеры быстро апрувят другие медленно
А балансить тут эффективно никак нельзя?
N
Я так понял они говорят про разбиение на партиции?
не. просто быстрый способ понять кому что дать, забив на возможные повторы поскольку в 5000-партиционированной книге первую партицию получат 1й, 5001й и 10001й юзеры(если показания первых двух не сойдутся), предполагая, что воемя оценки партиции меньше, чем время прохода 5000 юзеров
NI
Тут проблема в том что всё упирается в один поток в итоге. Обходить все документы от меньшего к большему для 10000 кокурентнвх пользователей тяжеловато будет
АГ
Nikita Ilin
Тут проблема в том что всё упирается в один поток в итоге. Обходить все документы от меньшего к большему для 10000 кокурентнвх пользователей тяжеловато будет
имеет смысл сделать такой сервис стейтфул, и держать в оперативе текущий стейт
АГ
должно быть по силам