тут надо мультирюкзаком раскидать

можно и проще, но задача простая на самом деле, обычные методы оптимизации

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

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

остаток от деления это рантайм не поддающийся оптимизации

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

А что с приоритетом?

“При этом каждый раз пользователю должен выдаваться параграф из документа, который имеет минимальное количество параграфов для проверки (максимальное прогресс).”

ну смотри, у тебя 100 юзеров, им надо 100 параграфов, какая разница в каком порядке?

Я не знаю. Видимо есть раз это часть условия задачи)

Ну это партиции и есть.

А что с этим?

Это не эффективно распределяет нагрузку. Мол у тебя одни юзеры быстро апрувят другие медленно

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

Это не эффективно если. Если бы мы могли выдавать юзеру параграфы из одной и той же книги не раз в месяц(или сколько там надо на 5000 книг), то тогда у нас бы были проблемы.

Это не эффективно если. Если бы мы раскидывали книги выбрав случайные критерии разбиения. В случае если мы выбираем критерии оптимально, или хотя бы близкими к оптимальным, то все будет ок.

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

Да, конечно, получить за один запрос статистику по процессу перевода по данным на обработке мы не сможем, но мы всегда можем(и должны) записать её в другое место.

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

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

Например, когда я покупаю VPS, могу платить хоть за 15 секунд пользования, хоть за месяц. serverless и мобильные операторы — похоже.

Как такое реализуется с программной стороны? Я представляю себе какие-то интервалы в БД "с ... по ..." и стоимость. Но не представляю, как эти интервалы туда записывать (кто их записывает?), как это агрегировать в статистику, что делать, если посреди периода меняется тариф на услугу?