Я пробовал тестит mонгу и rabbit через питон kombu-либу, монга в несколько раз медленнее была.

Удивительный факт)

Справедливости ради, могла ещё реализация очереди в самом kombu тормозить.

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

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

Это mongoose и express

Если просто выполнить aggregate то работает а если poppulate то нет

Коллеги добрый день Подскажите, можно ли в монго посмотреть клиентские коннекты (как?) и какие сертификаты они используют?

и еще вопрос почему когда прогоняю команду db.currentOp(true).inprog.forEach(function(x) { print(x.client) }) выдает вывод [unknown type]

populate('field'',[select], 'Model')

populate('field'',[select], 'Model')

Уже решил так но почему то опция лимит не работает

Всем пример. Пытался самостоятельно отыскать решение но безуспешно. Как сортировать по длине массива в aggregate? Всем откликнувшимся спасибо. if (req.query.sort === 'comments') sort = { 'services.comments.length': -1 } ??? else sort = { 'services.rating': -1 } const users = await User.aggregate([ { $match: query }, { $sort: sort }, { $limit: 10 } ])

Help. Mongoose. Обычный .find() к коллекции на 240 элементов без единого фильтра занимает 500-600ms. Добавление .lean() не приводит ни к каким изменениями, все так же 500-600ms. В чем может быть проблема?

Help. Mongoose. Обычный .find() к коллекции на 240 элементов без единого фильтра занимает 500-600ms. Добавление .lean() не приводит ни к каким изменениями, все так же 500-600ms. В чем может быть проблема?

тот же find прямым запросом к базе сколько по времени отрабатывает, что говорит explain на запрос?

тот же find прямым запросом к базе сколько по времени отрабатывает, что говорит explain на запрос?

Без lean() ~577ms С lean() ~557ms Также проверил размер объекта, судя по результату понятно что lean() срабатывает и убирает лишние от mongoose, но на скорости это никак не отражается

погодите, я вас о другом спрашивал, я просил показать не запрос из вашего приложения, а результат выполнения запроса напрямую в базе (подключится через любое gui и выполнить запрос), чтобы можно было понять проблема с данными или у вас в приложение. далее я попросил дать план запроса (так же выполнив соответствующие действия напрямую в базе) чтобы можно было посмотреть индексы (или их отсутствие) в случае если проблема с данными и результат прямого запроса к базе покажет +/- тот же результат что и у вас в приложение

Без lean() ~577ms С lean() ~557ms Также проверил размер объекта, судя по результату понятно что lean() срабатывает и убирает лишние от mongoose, но на скорости это никак не отражается

Почему это должно сильно отразиться на скорости?

Help. Mongoose. Обычный .find() к коллекции на 240 элементов без единого фильтра занимает 500-600ms. Добавление .lean() не приводит ни к каким изменениями, все так же 500-600ms. В чем может быть проблема?

При таком малом количестве элементов разница во времени исполнения будет на уровне погрешности, т.к. по сути вызов lean приводит к тому, что mongoose возвращает не инстансы Document (собственный тип mongoose с кучей методов и прочего), а обычные JS-объекты. Т.к. это происходит в рантайме вашего приложения, то это и не влечёт за собой каких-то невероятных накладных расходов. Также нет зависимости между сложностью вашего запроса и ускорением при использовании lean, т.к. в этом случае работа идёт уже с результатом выборки, который вернула MongoDB. Существенная разница в вашем кейсе будет видна только при запросах, где в качестве результата будут выступать массивы состоящие из тысяч элементов и больше.

у меня есть документ где одно из полей указывает тип, как сделать $lookup с условием? То есть, если тип == 'foo' надо делать lookup с одной коллекции, если тип == 'bar' с другой

у меня есть документ где одно из полей указывает тип, как сделать $lookup с условием? То есть, если тип == 'foo' надо делать lookup с одной коллекции, если тип == 'bar' с другой

имхо, сделать условие формирования запроса на уровне приложения

у меня есть документ где одно из полей указывает тип, как сделать $lookup с условием? То есть, если тип == 'foo' надо делать lookup с одной коллекции, если тип == 'bar' с другой

На каждый тип свой лукап стейдж

Всем пример. Пытался самостоятельно отыскать решение но безуспешно. Как сортировать по длине массива в aggregate? Всем откликнувшимся спасибо. if (req.query.sort === 'comments') sort = { 'services.comments.length': -1 } ??? else sort = { 'services.rating': -1 } const users = await User.aggregate([ { $match: query }, { $sort: sort }, { $limit: 10 } ])

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

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

Я пробовал разные способы с проект но не работает. Вы могли бы на мое примере показать ?

Я пробовал разные способы с проект но не работает. Вы могли бы на мое примере показать ?

https://docs.mongodb.com/manual/reference/operator/aggregation/size/

Смотрите примеры

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

Всем пример. Пытался самостоятельно отыскать решение но безуспешно. Как сортировать по длине массива в aggregate? Всем откликнувшимся спасибо. if (req.query.sort === 'comments') sort = { 'services.comments.length': -1 } ??? else sort = { 'services.rating': -1 } const users = await User.aggregate([ { $match: query }, {$project: сюда ставить??? { $sort: sort }, { $limit: 10 } ])

Лучше через $addFields вместо проджекта, и да туда то что выше скинул. Потом сортировку

Смотрите примеры

В примере numberOfColors как его получить в $sort в моем примере ?

Просто указать его и порядок сортировки

На каждый тип свой лукап стейдж

Не совсем понимаю. У меня модель данных следующая - { type: 'a', value: ''b'}, {type: 'z', value: 'x'}

И исходя ив type хранится ключ, по которому узнаю что надо аггрегировать

Отдельная коллекция = отдельный лукап, никак на уровне запроса вы не зададите какую коллекцию использовать, поэтому достаете док и делаете доп запросы. Либо меняете структуру, чтобы можно было использовать кучу стейджей с лукапами на каждый тип. В любом случае нужно менять подход к хранению, чтобы можно было комфортно работать

Спасибо

Есть ли какая-то возможность динамически формировать параметры поиска в mongo? То есть, если в запрос добавят через “?param=value” какой-нибудь новый параметр, то он автоматом (если у модели есть такое поле) подставился в поисковый запрос.

Есть ли какая-то возможность динамически формировать параметры поиска в mongo? То есть, если в запрос добавят через “?param=value” какой-нибудь новый параметр, то он автоматом (если у модели есть такое поле) подставился в поисковый запрос.

создай обьект const query = {user_id: req.user_id} после наполни его экстра данными для фильтрации через Object.keys() и запихни полученный обьект в Order.find(query)

создай обьект const query = {user_id: req.user_id} после наполни его экстра данными для фильтрации через Object.keys() и запихни полученный обьект в Order.find(query)

то есть просто все поля req.query добавлять в find()?

da

ну и желательно валидировать конечно

спасибо

Господа, посоветуйте, куда посмотреть. Монга не может синкнуть данные из праймари. Выкачивает в разные моменты разное кол-во данных, например, 20-100гб, и процесс синка перезапускается. В логах ничего не нашел, версия 3.6.16

Может oom killer по памяти убивает?

Нет ограничений

Памяти - 32Гб

Ну и это не значит, что она её не съест

Ты по логам oom посмотри и по мониторингу

Нет OOM

Что вообще в dmesg, messages syslog

Если что-то случилось, то что-то должно думаю было записаться

Там все пусто

Процесс монги же не убивается

И тд

подскажите где можно посмотреть логи что удалилось-очистилось после запуска db.repairDatabase()

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

и еще хотел спросить - после команды db.repairDatabase - просто удаляется документ где была проблема или затирается поле ? Или скиньте ссылку где можно почитать логику работы этой команды. Просто прям подробно не нашел. спасибо

Может кто объяснить или поделиться источником разъяснения. Как работает поиск в коллекции? Есть ли какая либо логика поиска по коллекции? Использую разные методы(find, findOne, aggregate и т.п), копируя из разных источников но как эти методы достигают конечной пойсковой точки в структуре объекта не понятно. Есть ли логика поиска может кто объяснить ? Или дайте туториал на русском желательно чтобы лучше дошло )))

Может кто объяснить или поделиться источником разъяснения. Как работает поиск в коллекции? Есть ли какая либо логика поиска по коллекции? Использую разные методы(find, findOne, aggregate и т.п), копируя из разных источников но как эти методы достигают конечной пойсковой точки в структуре объекта не понятно. Есть ли логика поиска может кто объяснить ? Или дайте туториал на русском желательно чтобы лучше дошло )))

https://docs.mongodb.com/manual/tutorial/query-documents/

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

el.toObject() если это не массив

если массив то arr.map(el => el.toObject())

el.toObject() если это не массив

Спасибо!

Коллеги, добрый день. Столкнулся с очень странной ситуацией. Пришел OOM и убил монгу. Это был секондари нода. По графикам в заббиксе РАМ из 42 было использовано 24. [Thu Feb 13 14:47:16 2020] Free swap = 0kB [Thu Feb 13 14:47:16 2020] Total swap = 524284kB Выглядит словно забился своп. Я вообще не понимаю почему так произошло. Может у кого есть мысли, буду благодарен

@dd_bb

монга же занимает половину оперативки по дефолту вроде

монга же занимает половину оперативки по дефолту вроде

ну там чуть меньше половины

Коллеги, добрый день. Столкнулся с очень странной ситуацией. Пришел OOM и убил монгу. Это был секондари нода. По графикам в заббиксе РАМ из 42 было использовано 24. [Thu Feb 13 14:47:16 2020] Free swap = 0kB [Thu Feb 13 14:47:16 2020] Total swap = 524284kB Выглядит словно забился своп. Я вообще не понимаю почему так произошло. Может у кого есть мысли, буду благодарен

зачем своп включен?)

а почему нет?

дикое снижение производительности на ровном месте при наличии достаточного количества оперативы

то есть из-за свопа у нас ООМ пришел?

MongoDB performs best where swapping can be avoided or kept to a minimum, as retrieving data from swap will always be slower than accessing data in RAM. However, if the system hosting MongoDB runs out of RAM, swapping can prevent the Linux OOM Killer from terminating the mongod process.

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

хмм ну ладно, спасибо

Eсли я правильно понимаю, что первый $match сначала выберет все документы, а вторым я уже могу фильтромс учетом аггрегированых данных, верно?

https://share.getcloudapp.com/eDuxAA1g

Eсли я правильно понимаю, что первый $match сначала выберет все документы, а вторым я уже могу фильтромс учетом аггрегированых данных, верно?

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

Я понимаю

Тут суть, что мне взять документ с caseModel если лукап для events подходит под критерий

И вот пытаюсь разобраться

Не понял что нужно

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