NI
Если не останется параграфов? То фейл. Но можно по разному сделать
Я в вашем варианте, не понял, как искать для пользователя непроверенный документ
Size: a a a
2020 November 16
YG
Nikita Ilin
Я в вашем варианте, не понял, как искать для пользователя непроверенный документ
Я не учёл, что нужно выбирать именно документ с наибольшим кол-ом проверок, тогда фэйлы будут часто.
Но суть в том что у каждого пользователя список с непроверенными им док-ми.
Но суть в том что у каждого пользователя список с непроверенными им док-ми.
NI
Я не учёл, что нужно выбирать именно документ с наибольшим кол-ом проверок, тогда фэйлы будут часто.
Но суть в том что у каждого пользователя список с непроверенными им док-ми.
Но суть в том что у каждого пользователя список с непроверенными им док-ми.
У каждого пользователя будет вначале тогда 1 млн документов
SP
Nikita Ilin
Я имею в виду хранить номер потенциально следующего документа (если он ещё не закончен)
ну это как по мне не оч предсказуемая штука
SP
опять же - книги тут не столь важны - у тебя параграфы по порядку будут всегда идти
SP
тут как бы два момента: если мне поставили бы такую задачу и если бы у меня реально было 10К юзеров мне стоило бы задаться вопросом "а как часто и какие риски если какие-то из этих правил будут нарушены".
Тут скорее всего сложность в том что правила апрува скорее всего у тебя посложнее нежели 3 чела ткнули упрув. Иначе не надо было бы возиться с агрегатами.
Тут скорее всего сложность в том что правила апрува скорее всего у тебя посложнее нежели 3 чела ткнули упрув. Иначе не надо было бы возиться с агрегатами.
SP
была бы табличка, параграфы... у них был бы json мэпа с ключами айдишками юзеров и значениями таймстэмпами когда был зарезервирован". Чел шлет запрос "хочу следующий" и мы тупо делаем update с включением нашего айдишника в мэпу (это можно делать атомарно в каком postgres). забронировали - заапрувили. Отдельный процесс ходит и высвобождает по таймауту забронированные параграфы... Да стэйт центраизован да если база упадет все плохо. Зато быстро.
Ну или опять же вариант @nekt_ru с курсорами в памяти/рэдисах каких.
Ну или опять же вариант @nekt_ru с курсорами в памяти/рэдисах каких.
SP
может быть распределение работы и саму работу стоит отдельно рассматривать...
SP
мол распределение сделать эффективным и быстрым а уже когда распределены айдишники параграфов там другие агрегаты и есть варианты выбрать уже партиции поменьше
˸A
есть какая-то логика мол "если забрал и не заапрувил - можно выдать другому?"
Умеешь правильные вопросы задавать))
NI
была бы табличка, параграфы... у них был бы json мэпа с ключами айдишками юзеров и значениями таймстэмпами когда был зарезервирован". Чел шлет запрос "хочу следующий" и мы тупо делаем update с включением нашего айдишника в мэпу (это можно делать атомарно в каком postgres). забронировали - заапрувили. Отдельный процесс ходит и высвобождает по таймауту забронированные параграфы... Да стэйт центраизован да если база упадет все плохо. Зато быстро.
Ну или опять же вариант @nekt_ru с курсорами в памяти/рэдисах каких.
Ну или опять же вариант @nekt_ru с курсорами в памяти/рэдисах каких.
Бронировать точно как-то нужно. Иначе прилетит 100 запросов и всем вернётся один и тот же параграф, что бессмысленно
NI
Хотя, если этот процесс в одном потоке
SP
ну вот я бы бронь одним потоком держал бы, что бы можно было текущее состояние дел держать в памяти и не надо было бы тратить время на походы по сети
SP
а вот после брони уже есть варианты думается мне
NI
В памяти опасно
NI
Ну т е помимо в памяти нужно тут же в базу сохранять, а память только как кэш использовать
АГ
у каждого параграфа ууид. юзеру выдается ууид параграфа, и больше он ничего взять не сможет. хранится в памяти список троек - ууид параграфа, ууид юзера, время взятия. просроченные записи удаляются например каждую минуту по крону.
АГ
как только юзер зааппрувит параграф, он добавляется в историю (чтобы нельзя было взять 2 раза одно) и удаляется из этого пула.
NF
Nikita Ilin
Всем привет!
Решаю кейс и пытаюсь спроектировать агрегаты, нужна помощь, может, кто сталкивался с такой задачей)
Имеются книги, каждая из которых содержит в среднем 5000 параграфов.
Всего около 1 млн книг.
Каждая из книг может быть просмотрена пользователем максимум один раз.
Пользователи проверяют параграфы на достоверность.
Процесс выглядит следующим образом:
Пользователь жмёт кнопку GetNextItem, получает новый параграф, проверяет его на достоверность и жмёт либо valid, либо invalid. Далее цикл повторяется. В следующий раз пользователь получит параграф из другого документа (пользователь может посмотреть максимум один параграф из одного документа).
Когда у параграфа два подтверждения -> параграф считается правильным. Когда два раза invalid - считается invalid соответсвенно.
Когда все параграфы документа пройдены, документ считается выполненным.
При этом каждый раз пользователю должен выдаваться параграф из документа, который имеет минимальное количество параграфов для проверки (максимальное прогресс).
Всё это похоже на очередь, но нужно проверять на уникальность участников.
У кого есть какие-то мысли как правильно спроектировать агрегаты, так чтобы не было много проблем с конкурентным доступом, т.к. ожидается большое количество конкурентных пользователей (10 000)?
Решаю кейс и пытаюсь спроектировать агрегаты, нужна помощь, может, кто сталкивался с такой задачей)
Имеются книги, каждая из которых содержит в среднем 5000 параграфов.
Всего около 1 млн книг.
Каждая из книг может быть просмотрена пользователем максимум один раз.
Пользователи проверяют параграфы на достоверность.
Процесс выглядит следующим образом:
Пользователь жмёт кнопку GetNextItem, получает новый параграф, проверяет его на достоверность и жмёт либо valid, либо invalid. Далее цикл повторяется. В следующий раз пользователь получит параграф из другого документа (пользователь может посмотреть максимум один параграф из одного документа).
Когда у параграфа два подтверждения -> параграф считается правильным. Когда два раза invalid - считается invalid соответсвенно.
Когда все параграфы документа пройдены, документ считается выполненным.
При этом каждый раз пользователю должен выдаваться параграф из документа, который имеет минимальное количество параграфов для проверки (максимальное прогресс).
Всё это похоже на очередь, но нужно проверять на уникальность участников.
У кого есть какие-то мысли как правильно спроектировать агрегаты, так чтобы не было много проблем с конкурентным доступом, т.к. ожидается большое количество конкурентных пользователей (10 000)?
Если это то же самое что и в appen. Только для книг, то нужно ещё собирать комментарии-обоснования, а не просто valid invalid.
NF
Nikita Ilin
Всем привет!
Решаю кейс и пытаюсь спроектировать агрегаты, нужна помощь, может, кто сталкивался с такой задачей)
Имеются книги, каждая из которых содержит в среднем 5000 параграфов.
Всего около 1 млн книг.
Каждая из книг может быть просмотрена пользователем максимум один раз.
Пользователи проверяют параграфы на достоверность.
Процесс выглядит следующим образом:
Пользователь жмёт кнопку GetNextItem, получает новый параграф, проверяет его на достоверность и жмёт либо valid, либо invalid. Далее цикл повторяется. В следующий раз пользователь получит параграф из другого документа (пользователь может посмотреть максимум один параграф из одного документа).
Когда у параграфа два подтверждения -> параграф считается правильным. Когда два раза invalid - считается invalid соответсвенно.
Когда все параграфы документа пройдены, документ считается выполненным.
При этом каждый раз пользователю должен выдаваться параграф из документа, который имеет минимальное количество параграфов для проверки (максимальное прогресс).
Всё это похоже на очередь, но нужно проверять на уникальность участников.
У кого есть какие-то мысли как правильно спроектировать агрегаты, так чтобы не было много проблем с конкурентным доступом, т.к. ожидается большое количество конкурентных пользователей (10 000)?
Решаю кейс и пытаюсь спроектировать агрегаты, нужна помощь, может, кто сталкивался с такой задачей)
Имеются книги, каждая из которых содержит в среднем 5000 параграфов.
Всего около 1 млн книг.
Каждая из книг может быть просмотрена пользователем максимум один раз.
Пользователи проверяют параграфы на достоверность.
Процесс выглядит следующим образом:
Пользователь жмёт кнопку GetNextItem, получает новый параграф, проверяет его на достоверность и жмёт либо valid, либо invalid. Далее цикл повторяется. В следующий раз пользователь получит параграф из другого документа (пользователь может посмотреть максимум один параграф из одного документа).
Когда у параграфа два подтверждения -> параграф считается правильным. Когда два раза invalid - считается invalid соответсвенно.
Когда все параграфы документа пройдены, документ считается выполненным.
При этом каждый раз пользователю должен выдаваться параграф из документа, который имеет минимальное количество параграфов для проверки (максимальное прогресс).
Всё это похоже на очередь, но нужно проверять на уникальность участников.
У кого есть какие-то мысли как правильно спроектировать агрегаты, так чтобы не было много проблем с конкурентным доступом, т.к. ожидается большое количество конкурентных пользователей (10 000)?
Если коротко это че-то типа фокус-групп, только на кучу юзеров:
- тебе показывают рекламу ты должен проверить что она не гавно
- тебе показывают выдачу в гугле, ты должен проверить что она совпадает с тем что ты искал
Твой кейс выглядит в точности эквивалентным.
- тебе показывают рекламу ты должен проверить что она не гавно
- тебе показывают выдачу в гугле, ты должен проверить что она совпадает с тем что ты искал
Твой кейс выглядит в точности эквивалентным.