ребят, я тут краем уха услышал, что в mongo count может не корректное количество документов возвращать. если правда, то поделитесь best practics для получения общего числа документов для пагинации например?

https://docs.mongodb.com/manual/reference/command/count/#accuracy-and-sharded-clusters

https://docs.mongodb.com/manual/reference/command/count/#accuracy-and-sharded-clusters

да, спасибо, уже тоже нашел

или документация не для нас?

Попрошу воздержаться от подобных комментариев.

Хотите помочь — дайте ссылку

да, спасибо, уже тоже нашел

На secondary подсчёт count с помощью aggregate тоже может некорректные результаты выдать при использовании read concern "available".

ребят, я тут краем уха услышал, что в mongo count может не корректное количество документов возвращать. если правда, то поделитесь best practics для получения общего числа документов для пагинации например?

Для пагинации даже не запаривайтесь :)

А ссылки правильные дают, да

Для пагинации даже не запаривайтесь :)

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

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

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

вы увидите счётчик в какой-то момент

какой это момент — ¯\_(ツ)_/¯

если вы показываете статистику привязанную к времени, используйте условие по времени

ага, я понял, еще раз спасибо и еще такой момент, я правильно помню, что skip в монго очень накладная операция из-за перебора всех записей для получения среза? и дешевле использовать limit + > _id? (где _id последний objectId ранее отданного среза)

ага, я понял, еще раз спасибо и еще такой момент, я правильно помню, что skip в монго очень накладная операция из-за перебора всех записей для получения среза? и дешевле использовать limit + > _id? (где _id последний objectId ранее отданного среза)

Да. Особенно на шардированных коллекциях. Там может быть несколько сложнее, чем {$gt: _id}, но идея правильная.

Да. Особенно на шардированных коллекциях. Там может быть несколько сложнее, чем {$gt: _id}, но идея правильная.

еще раз спасибо 👍

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

skip и limit сильно зависят от запроса

и от размера коллекции

или индекса

смотрите explain, настройте дешборд

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

Хм, интересная мысль, забрал на подумать, спасибо!

смотрите explain, настройте дешборд

А что в качестве дашборд посоветуйте использовать?

https://www.percona.com/software/database-tools/percona-monitoring-and-management

https://www.percona.com/software/database-tools/percona-monitoring-and-management

Ещё раз спасибо

@dd_bb $lookup до сих пор не умеет в индексы?

Народ подскажите пожалуйста как оптимально в древовидной структуре построенной с parentid, выбрать потомков узла? graphLookup ? рекурсия? ...

Народ подскажите пожалуйста как оптимально в древовидной структуре построенной с parentid, выбрать потомков узла? graphLookup ? рекурсия? ...

materialized path

materialized path

нет хранить нужно по простому с parentid

Почему такое ограничение?

https://dumpz.org/bqANNaAfWX6d подскажите почему даже при наличии индексов монго почти всю коллекцию сканирует?

@dd_bb $lookup до сих пор не умеет в индексы?

https://jira.mongodb.org/browse/SERVER-31760

сделал составной тоже тупит уже минуту

а если есть поле которого нет в большей части документов может сделать sparse index?

db.queue_profiles.createIndex({"payload.remove": 1, finished_at: -1})

https://dumpz.org/bqANNaAfWX6d подскажите почему даже при наличии индексов монго почти всю коллекцию сканирует?

Потому что индексы не селективные. План начинается со сканирования индекса для $exists по finished_at, но оттуда выпадает 157327425 документа за 185 секунд. Вторым шагом идёт вытаскивание этих 157327425 документов из хранилища, с фильтром по payload.remove

Спасибо

Что делать в такой ситуации?

Если в результате всех этих вычисления 0 документов, то вы правильно начали смотреть в сторону sparse/partial индексов

Спасибо! Щаз разберусь

https://jira.mongodb.org/browse/SERVER-31760

хм, странно что explain() ничего не показывает

let path = [] while (folder && folder.parent) { folder = await Folder.findOne({ _id: folder.parent }).exec() path.push(folder.name) } path.reverse().join(" / ")

как такое переписать без рекурсии? это получение потомков для узла дерева.

использовать materialized path

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

потому что $graphLookup вы просто рекурсивный поиск в монгу перенесёте

использовать materialized path

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

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

думаете обычный while не хуже graph lookuop

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

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

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

как такое переписать без рекурсии? это получение потомков для узла дерева.

это не рекурсия

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

ну это при создании папок надо.. иначе баг..

Всем привет, подскажите, как указать с какой коллекцией работать?

const FolderSchema = new mongoose.Schema( { name: { type: String, required: true }, isFile: { type: Boolean, required: true }, isRoot: { type: Boolean, default: false }, //trashedAt: { type: Date, index: true }, deletedAt: { type: Date, index: true }, parent: { type: mongoose.Schema.Types.ObjectId, index: true, ref: "Folder" }, user: { type: mongoose.Schema.Types.ObjectId, index: true, ref: "User", required: true } }, { versionKey: false } ) const folderWithParents = await Folder.aggregate([ { $match: { _id: folder._id } }, { $graphLookup: { from: "Folder", startWith: "$parent", connectFromField: "parent", connectToField: "_id", as: "ancestors", depthField: "depth" //restrictSearchWithMatch: { parent: { $ne: null } } } } ]).exec() console.log("path", folderWithParents)

не работает.. выдает path [ { _id: 5bec038d7f1fea178c85d4d4, isRoot: false, user: 5bec033c7f1fea178c85d4cf, parent: 5bec03887f1fea178c85d4d3, name: '1234', isFile: false, ancestors: [] } ] потомков не отдает... пробовал без match нет все равно отдает все доки, но без потомков

название полей совпадает.. в чем же дело?

connectFromField и connectToField точно в правильно прописаны?

мож наоборот?

parent коннектится к _id

может надо в схеме явно _id указать?

но оно же есть

действительно parent совпадает с id

db.getCollection('folders').find({ parent: ObjectId("5bead35b46a61f3d3c8e5e65") }) db.getCollection('folders').find({ _id: ObjectId("5bead35b46a61f3d3c8e5e65") })

вот так работает.. те связка есть

from: "folders", а не from: "Folder" вот что надо было

бло

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

Народ, кто может оценить затратность такого кода в монге? const median = function(arr) { arr = arr.slice(0); var middle = (arr.length + 1) / 2, sorted = arr.sort(); return (sorted.length % 2) ? sorted[middle - 1] : (sorted[middle - 1.5] + sorted[middle - 0.5]) / 2; }; мне надо в аггрегации это считать. массив около 3000-4000 чисел и в фасетке таких аггрегаций 8 штук. Запускается раз в сутки ночью.

монга 3.6

Народ, кто может оценить затратность такого кода в монге? const median = function(arr) { arr = arr.slice(0); var middle = (arr.length + 1) / 2, sorted = arr.sort(); return (sorted.length % 2) ? sorted[middle - 1] : (sorted[middle - 1.5] + sorted[middle - 0.5]) / 2; }; мне надо в аггрегации это считать. массив около 3000-4000 чисел и в фасетке таких аггрегаций 8 штук. Запускается раз в сутки ночью.

ваш код плохо читаем и не устойчив к пустым массивам

ваш код плохо читаем и не устойчив к пустым массивам

что в нём нечитаемо?

Народ, кто может оценить затратность такого кода в монге? const median = function(arr) { arr = arr.slice(0); var middle = (arr.length + 1) / 2, sorted = arr.sort(); return (sorted.length % 2) ? sorted[middle - 1] : (sorted[middle - 1.5] + sorted[middle - 0.5]) / 2; }; мне надо в аггрегации это считать. массив около 3000-4000 чисел и в фасетке таких аггрегаций 8 штук. Запускается раз в сутки ночью.

сорт без компаратора

сорт без компаратора

a-b имеешь в виду?

1. инициализация в одной строке двух переменных 2. тернарный опаратор, один из операндов которого - сложное выражение

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

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

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

Народ, кто может оценить затратность такого кода в монге? const median = function(arr) { arr = arr.slice(0); var middle = (arr.length + 1) / 2, sorted = arr.sort(); return (sorted.length % 2) ? sorted[middle - 1] : (sorted[middle - 1.5] + sorted[middle - 0.5]) / 2; }; мне надо в аггрегации это считать. массив около 3000-4000 чисел и в фасетке таких аггрегаций 8 штук. Запускается раз в сутки ночью.

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

разве что сортировка будет на стороне монги

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

mean !== median