Почему будут пропускаться?

А зачем вам на ид завязываться?

Потому-что он вроде как должен гарантировать монотонное увеличение и уникальность

Почему будут пропускаться?

Потому-что если грубо говоря у тебя подряд десять записей с updatedat=100, ты получил первый такой и сделаешь ge 100 он про пустит остальные девять

Я не совсем понимаю вашу задачу. Вывести документы отсортированные по апдейту + пагинация?

Да, при этом чтобы если мы дошли до конца и у какого-то документа обновился updatedat - можно было следующим чтением получить его

Потому-что если грубо говоря у тебя подряд десять записей с updatedat=100, ты получил первый такой и сделаешь ge 100 он про пустит остальные девять

Курсор выведет вам все документы, которые больше

Ну

Если у вас 100 документов с одинаковым апдейтом, то выведется все 100

А если я хочу доставать по 5 штук?

Так делайте скип и лимит.

Это медленно)

Сделайте индекс на поле)

Плюс кеш, по схеме что я описывал выше

Индекс не поможет при скипе

Скип за o(n) работает, это медленно

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

Если делать ge по updatedat будут пропускаться документы с одинаковым updatedat

ну ок, $gte + skip решит проблему неуникального updateAt

Грузите в кеш например. Или используйте инмемори дБ.

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

Да нет, лол, это стандартная практика

Например в нашем случае это нужно чтобы синхронизировать записи в монге и в эластике

ну ок, $gte + skip решит проблему неуникального updateAt

Звучит как полумера, разве нет?

Звучит как полумера, разве нет?

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

Например в нашем случае это нужно чтобы синхронизировать записи в монге и в эластике

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

Например в нашем случае это нужно чтобы синхронизировать записи в монге и в эластике

Такую синхронизацию я делал через апдейт сразу в два места. Но мне не надо была быстрая запись.

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

Скип грустно звучит на самом деле, скажем если будет 10к записей с одинаковым updatedat (а у нас нет гарантий что такого не может быть) будет грустненько

Такую синхронизацию я делал через апдейт сразу в два места. Но мне не надо была быстрая запись.

Типа сразу и в бд и в эластик писать?

Достаточно неконсистентно

Скип грустно звучит на самом деле, скажем если будет 10к записей с одинаковым updatedat (а у нас нет гарантий что такого не может быть) будет грустненько

а кто делает апдейты документов? человек\автоматика? какова вероятность, что у вас будет >100 одинаковых updateAt?

Система конечно

Вероятность ненулевая

Почему не консистентно? Оборачиваете код в транзакцию и пишете и туда и сюда, иначе откатываете.

Система конечно

ну понятно ,что в базу пишет не человек. но в конечном итоге кто делает изменения в документах?

Почему не консистентно? Оборачиваете код в транзакцию и пишете и туда и сюда, иначе откатываете.

Потому-что транзакция монги не распространяется на эластик

ну понятно ,что в базу пишет не человек. но в конечном итоге кто делает изменения в документах?

Тоже система

Транзакцию делаете в коде который пишет изменения. Не в монге.

Тоже система

ну ок тогда. можно тогда в updateAt вместо времени ObjectID делать :) он в себе и время содержит и монотонно возрастает

Вернее и в монге, но это уже низкоуровневая транзакция

Транзакцию делаете в коде который пишет изменения. Не в монге.

Что значит транзакция в коде?

ну ок тогда. можно тогда в updateAt вместо времени ObjectID делать :) он в себе и время содержит и монотонно возрастает

Ну вот похоже да, единственный вариант

Я правда не очень понял, судя по документации objectid это 4 байта на время, 5 рандомных и 3 - инкрементальный каунтер

Если порядок именной такой, то из-за рандомных значений тоже может произойти «запись в прошлое»

Ну вот похоже да, единственный вариант

Это не решит вашу проблему с пейджинацией

Почему, как раз решит

Каким образом? Тот же скип лимит придется применять

Нет, ge

Objectid гарантирует что одинаковых значений не будет

Хорошо, у вас будет 100 документов больше, а вам надо по 5

Ну лимит сделаем

Скипа то не будет

Лимит не дорогая операция, скип дорогая

20 курсоров будет?

С чего бы?

Тогда как вы пейджинг сделаете по этим 100 записям?

Да в смысле? Достаешь первые 10, сохраняешь значение updatedAt последнего в курсор

Потом делаешь ge по этому курсору

И так далее

)) это будет новый курсор

А, в этом смысле

Ну да, так работает пагинация курсорная

Это пейжин запросом. Он будет медленнее чем скип на существующем.

Нет конечно

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

Да для большого объема данных, что бы побить на батчи этот способ лучше.

Для вывода пользователей это тоже лучше

Пагинация курсорами всегда будет аутперформить пагинацию по лимит офсет

Плюс не будет проблем с дублями

Всем привет! Реябята, помогите пожалуйста, 4 часа мучаюсь с проблемой, уже не знаю что делать......

уже удалял коллекцию, потом удалял таблицу, потом удалял полностью mongo .... в чем может быть тут проблема?

уже удалял коллекцию, потом удалял таблицу, потом удалял полностью mongo .... в чем может быть тут проблема?

Дубликаты по уникальному полю

так все уникальное((

у меня в схеме только одно поле уникальное text

Дубликаты по уникальному полю

как монго определяет уникальность? Может быть разным текст одинаков для монго?

cookie.predictions index: usersRated_1 dup key: { : undefined } можете ее расшифровать эту ошибку?

В уникальном индексе usersRated_1 дубликат

Подозреваю он у вас по полю usersRated.

Там стоит у вас свойство уникальности

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

db.dropDatabase() после внесения правок в схему помогло

Как я понял индексы живут всегда, не зависимо есть они в схеме или уже нет?