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

Ттл на час

Индекс на данные за последний час? А потом что происходит с ним? Помоему напрашивается на разделение горячей/холодной части

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

Можно использовать partialFilterExpression, и проверять по условному полю isRecent, которое при создании документов ставить true, и спустя время изменять на false. Самого по себе механизма с ttl индексов нет.

Привет, Что можно попробовать чтобы быстрее удалить данные с монго. Имеется коллекция с 15 млн записей. deleteMany(date) - примерно 6 млн записей, индекс по дате есть. Примерно удаляет по 20к в 10мин, что очень слабо. Также пробловал с батчами - разницы не видно.

как диски себя чувствуют?

Привет, Что можно попробовать чтобы быстрее удалить данные с монго. Имеется коллекция с 15 млн записей. deleteMany(date) - примерно 6 млн записей, индекс по дате есть. Примерно удаляет по 20к в 10мин, что очень слабо. Также пробловал с батчами - разницы не видно.

удаление как именно выполняется? через орм какуюто или ручками обычный запрос напрямую в монгу или может еще как

просто .deleteMany сразу на бд скриптом, без орм

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

просто .deleteMany сразу на бд скриптом, без орм

покажите какой фильтр указываете на удаление

просто .deleteMany сразу на бд скриптом, без орм

+ за возможную проблему с диском. Попробуй через drop(раз тебе всё равно надо все удалить) upd понял что не всё раз с фильтром. поле по которому удаляешь в индексе? просто по приколу решил проверить локально сколько это займет (удаляет 16млн записей).

Да, индекс есть. Я ещё в обед погуглил что это распространенная проблема, что это долго по дефолту происходит. С решений выделяли 2 возможные: 1) батчи - в моем случаее без изменений; просто типо вроде нагрузки меньше и не лочишь данные; 2) это через TTL - особо не чекал это, но думаю что тоже не подойдёт

скорее всего в iops диска упирается и тут уже никакая магия не поможет. Следует разговаривать с хостером.

всем привет может кто помочь объяснить поведение монги. Я сетаплю совершенно новый кластер, хочу собрать секьюрный репликасет. в конфиге прописываю security: keyFile: /opt/mongodb/keyfile у файла права 400 и овнер с группой mongod Также прописываю имя своего репликасета подключаюсь через mongosh (без указания параметров, то есть коннекчюсь просто к localhost:27017), делаю rs.initialize(...) со всеми параметрами своего rs, получаю успех, новый репликасет успешно создан пытаюсь с нуля сделать то же самое, но только подключаюсь через mongosh к mongodb://<master_dns>:27017, где master_dns - днс имя того же самого хоста. подключение происходит, только при выполнении rs.initialize(...) получаю ошибку MongoServerError[Unauthorized]: Command replSetInitiate requires authentication не понимаю, почему при подключении к localhost у меня нет ошибки, а при подключении по днс - есть PS и localhost, и <master-dns> прописаны через запятую в net.bindIp. Более того, ошибка повторяется даже при указании 0.0.0.0 в bindIp. Версия 8.0

всем привет может кто помочь объяснить поведение монги. Я сетаплю совершенно новый кластер, хочу собрать секьюрный репликасет. в конфиге прописываю security: keyFile: /opt/mongodb/keyfile у файла права 400 и овнер с группой mongod Также прописываю имя своего репликасета подключаюсь через mongosh (без указания параметров, то есть коннекчюсь просто к localhost:27017), делаю rs.initialize(...) со всеми параметрами своего rs, получаю успех, новый репликасет успешно создан пытаюсь с нуля сделать то же самое, но только подключаюсь через mongosh к mongodb://<master_dns>:27017, где master_dns - днс имя того же самого хоста. подключение происходит, только при выполнении rs.initialize(...) получаю ошибку MongoServerError[Unauthorized]: Command replSetInitiate requires authentication не понимаю, почему при подключении к localhost у меня нет ошибки, а при подключении по днс - есть PS и localhost, и <master-dns> прописаны через запятую в net.bindIp. Более того, ошибка повторяется даже при указании 0.0.0.0 в bindIp. Версия 8.0

Два вопроса: 1. У вас есть пользователь с правами входа в кластер и ошибка после входа через него? 2. Получается когда входите в localhost у вас есть статус репликасета? Проверьте db.serverStatus() что там с самой нодой в обоих случаях

вроде как после инит есть единственный раз подключения с локальной машины без пароля, как раз для установки пароля db.createUser({user: \"root\", pwd: \""{{ mongo_root_password }}"\", roles: [{role: \"root\", db: \"admin\"}]})

Пользователя нет, инстансы только только подняты

Пользователя нет, инстансы только только подняты

Желательно пользователя делать до инит

Вы не ответили на вопрос 2

Желательно пользователя делать до инит

https://www.mongodb.com/docs/manual/core/localhost-exception/

почему?

@yatoba @lnExtremo да, все упирается в диск. Сейчас 10-11к/сек операций и это почти 100% нагрузки. За 16ч удалило только 2млн записей

достаточно предсказуемо, теперь бы еще глянуть метрику вытеснения данных из вт кэша (evicted wt cache pages чтото подобное) если она зашкаливает, то памяти уже не хватает под подобные нужды. Но если такое удаление разовое, то можно и потерпеть, но если планируется расти дальше по тем же апдейтам, то стоит задуматься либо более быстрых дисках либо о памяти

Привет, есть такой пайплайн: [ { $match: { article: { $in: [ ... ] } } }, { $sort: { _id: -1 } }, { $limit: 20 } ] На поле article есть индекс, но судя по эксплейну, монга использует _id для фильтрации и сортировки. "executionStats": { "executionSuccess": true, "executionTimeMillis": "3774.066", "planningTimeMillis": "0.208", "executionStages": { "stage": "LIMIT_SKIP", "nReturned": "6", "executionTimeMillisEstimate": "3773.817", "inputStage": { "stage": "IXSCAN", "nReturned": "6", "executionTimeMillisEstimate": "3773.809", "indexName": "_id_", "direction": "backward" } } }, Если убрать сортировку, запрос выполняется мгновенно. Без него 10-15 секунд. Есть способ сделать, чтобы монга использовала индексы оптимальней? Знаю, что можно подсказать, какие индексы использовать, но поля могут быть разные, и индексы тоже. Подсказки НЕ использовать индекс _id нет(

И ещё одно уточнение - у нас не монга а documentDB)

сколько вссего документов в коллекции?

Привет, есть такой пайплайн: [ { $match: { article: { $in: [ ... ] } } }, { $sort: { _id: -1 } }, { $limit: 20 } ] На поле article есть индекс, но судя по эксплейну, монга использует _id для фильтрации и сортировки. "executionStats": { "executionSuccess": true, "executionTimeMillis": "3774.066", "planningTimeMillis": "0.208", "executionStages": { "stage": "LIMIT_SKIP", "nReturned": "6", "executionTimeMillisEstimate": "3773.817", "inputStage": { "stage": "IXSCAN", "nReturned": "6", "executionTimeMillisEstimate": "3773.809", "indexName": "_id_", "direction": "backward" } } }, Если убрать сортировку, запрос выполняется мгновенно. Без него 10-15 секунд. Есть способ сделать, чтобы монга использовала индексы оптимальней? Знаю, что можно подсказать, какие индексы использовать, но поля могут быть разные, и индексы тоже. Подсказки НЕ использовать индекс _id нет(

Привет, есть такой пайплайн: [ { $match: { article: { $in: [ ... ] } } }, { $sort: { _id: -1 } }, { $limit: 20 } ] На поле article есть индекс, но судя по эксплейну, монга использует _id для фильтрации и сортировки. "executionStats": { "executionSuccess": true, "executionTimeMillis": "3774.066", "planningTimeMillis": "0.208", "executionStages": { "stage": "LIMIT_SKIP", "nReturned": "6", "executionTimeMillisEstimate": "3773.817", "inputStage": { "stage": "IXSCAN", "nReturned": "6", "executionTimeMillisEstimate": "3773.809", "indexName": "_id_", "direction": "backward" } } }, Если убрать сортировку, запрос выполняется мгновенно. Без него 10-15 секунд. Есть способ сделать, чтобы монга использовала индексы оптимальней? Знаю, что можно подсказать, какие индексы использовать, но поля могут быть разные, и индексы тоже. Подсказки НЕ использовать индекс _id нет(

Так вроде вы указали сортировать по _id

Не понятно в чем проблема.

Это все через тупость documentDB. Проверил на монге, она адекватно применяет индексы👍