как дешево ордербаить

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

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

а маркировать каждый док который прошел "кое какой" процесс я чет не хочу

доступное и понятное объяснение?

влияет ли индексация на скорость ордербая? 🤔🤔🤔🤔🤔🤔🤔

т.е. вместо стабильного решения с флагом обработки, вы хотите опираться на какойто порядок?

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

используйте порядок по _id

т.е. вместо стабильного решения с флагом обработки, вы хотите опираться на какойто порядок?

верно

без индексов сортировка это вообще катастрофа

используйте порядок по _id

спасибо за очередной хинт

но надежнее использовать флаг

и превратить каждый документ в мусор :(

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

то есть мне придется вводить поддокумент: shitTasks: [ { taskId: 'rf4387hfuh', done: true } ]

и делать дорогую выборку

https://docs.mongodb.com/manual/reference/operator/query-bitwise/

и используйте старые добрые флаги

одно поле tasks: Int

и выборки по маске

мне надо два поля видимо pendingTasks, doneTasks

0 pending, 1 done

мне надо два поля видимо pendingTasks, doneTasks

вам видимо нужны очереди, а не в базе это делать

вам видимо нужны очереди, а не в базе это делать

в базе нужно на случай падения скрипта

я работаю с нестабильными вещами к сожалению

и некоторые процессы занимают от нескольких часов до нескольких суток

8 бит это много 0 и 1, 0b0000_0000, на него кладём маску 0b1000_0000 и получаем состояние первого бита

если бит 0, значит pending, если 1 значит уже done

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

8 бит это много 0 и 1, 0b0000_0000, на него кладём маску 0b1000_0000 и получаем состояние первого бита

по поводу масок понял, хорошее решение

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

я глупый короче

я все понял

мне нужно по одной записи отбирать раз в 30 секунд, если я буду делать find, то он довольно шустро работать будет

мне не надо массив документов

давайте так, операция разовая или частая? по всем данным или только по новым спрошлого раза?

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

таким образом я просто буду вешать флаг и выбирать где он есть по 1 доку

пока не получу null

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

даже без ордера, порядок отбора доков мне не важен

и убедитесь что у вас операции индемпотентные

это сильно выручает

и убедитесь что у вас операции индемпотентные

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

я тут наткнулся на такое видео https://youtu.be/ZdYTPTQiXwc, в котором утвержадется, что в 4-й монге подтюнили балансировщик, и теперь миграция чанков на 40%(sic!) быстрее, интересно насколько это близко к реальности?есть у кого кластер с 4й монгой в проде?

я тут наткнулся на такое видео https://youtu.be/ZdYTPTQiXwc, в котором утвержадется, что в 4-й монге подтюнили балансировщик, и теперь миграция чанков на 40%(sic!) быстрее, интересно насколько это близко к реальности?есть у кого кластер с 4й монгой в проде?

40% это хрень вообще

там большая часть времени не передача данных, а непойми чо

вот и меня смутила такая цифра

я к тому что 40% быстрее это очень мало

на маленьких чанках особенно заметно насколько неэффективный этот процес

но вообще это легко проверяется через mlaunch

но я почти уверен что они на пустых чанках и меряли :)

но я почти уверен что они на пустых чанках и меряли :)

обычно когда говорят про скорость/производительность, прикладывают тесты, и/или описание как воспроизвести их mlaunch - это вот оно http://blog.rueckstiess.com/mtools/mlaunch.html ?

да, из mtools

обычно когда говорят про скорость/производительность, прикладывают тесты, и/или описание как воспроизвести их mlaunch - это вот оно http://blog.rueckstiess.com/mtools/mlaunch.html ?

обычно ничо не говорят :)

обычно когда говорят про скорость говорят ВТЫЩУ РАЗ БЫСТРЕЕ и всё

а на тестах потом блоггеры зарабатывают :))))

ксттаи, про чанки вопрос (опять из теории). если создать коллекцию, нарезать самостоятельно чанков и ждать, пока они разъедутся по шардам - ну это дня три занимает, 65к чанков. так вот, а что если пойти в config коллекцию да руками понаобновлять шард?

то есть заранее известно, что коллекция пустая, никакие там rangeDeleter-ы и прочее не нужны. update и всё. в моём понимании же дложно работать.

там есть какие-то нюансы в коллекции когда она шардированная

там точно была какая-то штука которая следит за размерами чанков

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

но тут могут быть нюнасы

и сюрпризы

размер - что в данном случае? мегабайты? так мы говорим про нули :) Пока еще документов в коллекции нет. ...у меня нарезаются чанки часа за полтора. оно как бы заранее всё это делать можно, но ждать, когда расползутся пустые (!) чанки ну както неоправданно долго. потому и было интересно :) Вроде ж монгос посморел, в какой range попал - туда и пошёл. и за миграциями лежат всякие красивости - локи, проверки, вычищалки, вот это всё. на пустой коллекции можно пренебречь теоретически :)

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

не у монгоса, а у коллекции

А что такое "менеджер чанков" у коллекции? это чтото внутреннее? или есть про это почитать?

да, это детали реализации chunk split

в исходниках читать

но не надо

ответ на ваш вопрос: это не поддерживается базой данных

попробовать можно, но вы это на свой страх и риск :)

гораздо проще не делать сразу 64к чанков, а сделать несколько и потом поделить их дальше на каждой из нод

надо будет попробовать, спасибо.

сделать по количеству нод, каждый двинуть на нужную ноду руками и там уже шинковать

руками при отставании реплики тоже не двигается проверено.

но идея ясна, надо будет опыты поставить.

кстати, а както можно от system.session избавиться?

зачем?