Bro
он всегда индексы сканирует
Bro
There are two problems here: $exists : false is evil, and I doubt indexing will help: Indexes are made for data, while $exists is a 'meta-query' on the structure. It can use an index if there is one on the field and the query is $exists : true, because if an indexed value exists, the field itself must also exist on a given document. Reversing that logic is tricky: if the field doesn't exist, it's not in the index or it has super low selectivity. 'Turning around' indexes is generally problematic, that is also true for queries using $ne by the way. MongoDB will have to de-serialize 500k objects and inspect each one to perform the $exists. You can't compare this to MySQL where you have a fixed table structure, in fact, $exists : false doesn't have a SQL-equivalent, because the field MUST exist, otherwise your table is badly broken.
Bro
нашел на стэковерфлоу
Bro
короче щаз поле просто это везде назначу типа finished_at = datetime.fromtimestamp(0)
Bro
и просто find().sort({finished_at: -1, priority: -1})
Bro
вернее как
Bro
для $exists: true
Bro
можно partial index сделать
Bro
а вот для $exists: false нельзя
Bro
такие дела
Alexandr
Всем привет, такой вопрос, можно ли как-то выполнить функцию, сохраненную в коллекции, кроме как через db.eval. Я достал это поле, оно с типом Code, пробовал передавать в new Function() и через eval(). Никак не работает. Может есть какой-то способ?
Bro
Nick
де жа вю, както перешагивали порог, потом метлой прошлись и обратно на 900+ скатились)
Bro
боты добавляются
Александр
Обескураживает. А я то уже губу раскатал на всякие ништяки, как тысячный мембер)
yopp
а вот для $exists: false нельзя
Звенят какие-то колокольчики на эту тему.
Bro
https://docs.mongodb.com/manual/core/index-partial/
Bro
sort норм будет работать?
Bro
$exists: true expression, - с партиал индексом
yopp
0 опасно, потому что это валидная дата
°¿°
Привет. Запускаю монгу 4.1.3 в кластере k8s из хелм-чарта с официальным монговским контейнером, при логине в монгу она пишет "You are running on a NUMA machine. We suggest launching mongod like this to avoid performance problems: numactl --interleave=all mongod [other options]". Судя по докерфайлу это должно само собой выполняться, но не работает. Кто-нибудь сталкивался с таким?
yopp
4.1.3 это development ветка, это не стабильная версия. https://github.com/docker-library/mongo/issues/113
°¿°
Хм.. может и правда попробовать стабильную?
yopp
development ветку вообще без конкретной цели нет смысла использовать
yopp
используйте стабильную
°¿°
development ветку вообще без конкретной цели нет смысла использовать
Справедливо. 4.1 здесь не я начал использовать, а каких-то преимуществ там нет. Попробую 4.0 - если не поможет, то вернусь.
yopp
с numa не поможет, это seccomp
yopp
4.1 использовать, особенно в продакшене, совершенно не стоит. там может быть всё что угодно сломано
°¿°
с numa не поможет, это seccomp
Ага, почитал то issue.
Ilya
всем привет, кто подскажет если wiredTiger будет выставлен больше чем пишут в доках, как это отразиться на производительности монги, Т.е. это хреново так делать или ничего особо не повлияет?
Ilya
вообщем я устроился на работу а там монго, три ноды по 128гб озу - праймари, и два секондари. на праймари кеш не выстален, он жрет 70-80 гигов. на секодарях кеш выставлен по 40 и 48, жрут озу примерно по столько же. Понял что надо разбираться.
Ilya
так и не хочу
Ilya
просто беспокоит праймари который 80 гб из 128 забирает.
yopp
вообщем я устроился на работу а там монго, три ноды по 128гб озу - праймари, и два секондари. на праймари кеш не выстален, он жрет 70-80 гигов. на секодарях кеш выставлен по 40 и 48, жрут озу примерно по столько же. Понял что надо разбираться.
эффективнее оставлять по-умолчанию, если для этого нет предпосылок. ручка с размером кеша скорее нужна для окружений, где монга не может корректно определить объём доступной ей памяти. например контейнеры
yopp
отдавать всю память под кеш неэффективно. WT в кеше хранит несжатые страницы и сжимает только когда сбрасывает на диск. если выделить всю память под кеш WT, то дисковому кешу ничего не останется
yopp
а так оставшаяся половина уйдёт под дисковый кеш и получится что там хранятся сжатые документы
yopp
надо учитывать что ограничить можно только размер кеша WT, но это не единственный потребитель памяти в монге. даже если кеш выставлен 40, но много агрегаций или сортировок в памяти, монга может потреблять существенное количество памяти
Ilya
отдавать всю память под кеш неэффективно. WT в кеше хранит несжатые страницы и сжимает только когда сбрасывает на диск. если выделить всю память под кеш WT, то дисковому кешу ничего не останется
и если уменьшать размер кеша, то монга будет чаще сжимать данные и складывать на диск, тем самым увеличивается работа с диском верно? Предположим я уменьшаю кеш до 1GB, в этом случае будет огромное кол-во ИОпсов так?
yopp
чем меньше кеш, тем больше дискового IO, да
yopp
плюс больше расходов на координацию кеша. т.е. кеша не будет хватать под выполнения текущих операций и кеш будет находится в нестабильном состоянии
yopp
минимальный размер должен быть не меньше чем размер индексов используемых коллекций
yopp
если индексы не влазят в кеш, будет совсем плохо
Ilya
я нашел в конфиге на одной из нод кеш вообще не прописан, по умолчанию что там на самом деле?
yopp
половина от доступной памяти
yopp
но не меньше гигабайта, чтоли
yopp
в доке есть
Ilya
да видел, но не все понял пока
Ilya
спасибо
yopp
https://docs.mongodb.com/manual/core/wiredtiger/#memory-use
yopp
Starting in 3.4, the WiredTiger internal cache, by default, will use the larger of either: 50% of (RAM - 1 GB), or 256 MB.
yopp
но ещё раз: это только кеш
Ilya
да вот как раз сейчас читаю)
Павел 💻
ребят,подскажите пожалуйста откуда это переменная может быть?
Павел 💻
Alexandr
Это не переменная, а аргумент колбек функции, тоесть данные которые возвращает монга при успешном сохранении
Andrejs Sahniks
👍
Andrejs Sahniks
Выведи её в консоль и посмотри что это.
Andrejs Sahniks
.then(idea => { console.log(idea); res.redirect(‘/idea’) });
Veaceslav
Всем добрый день, ребят помогите плиз правильно сделать выборку из базы. У меня есть такая вот структура: "meta": { "view_count": 0, "author": { "$oid": "5bec5c53ef46723d449207b4" }, "posted_time": { "$date": "2018-11-16T08:24:49.026Z" } }, Мне нужно получить все запись автора. Но чет не могу понять как это сделать.
Veaceslav
{ "meta.author": { _id: req.params.id } }
Veaceslav
Ну типа {"meta.author" : ObjectId("5bec5c53ef46723d449207b4")} ИЛИ {"meta.author" : {"$oid" : "5bec5c53ef46723d449207b4"}}
У меня еще один вопрос. Я использую populate, но иногда нужно по 3 раза ее использовать. Это нормально или не очень круто так делать ?
Veaceslav
.populate("author", "fullname") .populate("replays.author", "fullname");
Veaceslav
Вот как пример
Vova
mongodb projection
Я неправильно понял, а в метро долго отправляло
Maksim
Понял, спасибо.
Я с mongoose не работал, но мне кажется, populate будет использовать eager loading и тем самым проблемы N + 1 не будет. 3 populate и запрос для основной модели на мой взгляд породят 4 запроса в БД.
Anonymous
Всем привет! Чем отличаются mongoose.connection.close() и mongoose.connection.disconnect() ? Какой метод лучше использовать для создания тестовой базы?
Anonymous
connect
Насколько я понял из доков disconnect вызывает событие .close() для всех соединений. А метод close() только для текущего. Это верно? Для тестовой базы лучше использовать connect?
Kool
close закрывает mongoose соединение, если нужно, с коллбеком