спасибо милый человек )

Нутак сначала ты ищешь совпадения, а только потом лимитишь и сортируешь. И на производительности тоже сказывается положительно

И да: match > limit > sort

В таком порядке

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

А, точно

а мне месседжи нужно с конца

Дада

Лан, я споть

короче все пашет как надо ) спасибо

?

Привет! попробую ещё тут спросить:

mongoose.connection.on('connected', async () => { log.info(`Mongoose connected to ${process.env.DB_URI}`); const db = mongoose.connection; db.once('open', () => { const changeStream = db.collection('rides').watch(); changeStream.on('create', async () => console.log('!!!1')); changeStream.on('change', async () => console.log('!!!2')); }); }); подскажите плиз, почему при добавлении подписки на монгу у меня сервак начинает отвечать в 10-20 раз медленне

при чём екшены в этот момент не тригерятся - просто сам факт наличия подписки жутко тормозит сервер

Извините, но в терминах монги нет понятия "подписка".

Извините, но в терминах монги нет понятия "подписка".

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

https://docs.mongodb.com/manual/changeStreams/

mongoose.connection.on('connected', async () => { log.info(`Mongoose connected to ${process.env.DB_URI}`); const db = mongoose.connection; db.once('open', () => { const changeStream = db.collection('rides').watch(); changeStream.on('create', async () => console.log('!!!1')); changeStream.on('change', async () => console.log('!!!2')); }); }); подскажите плиз, почему при добавлении подписки на монгу у меня сервак начинает отвечать в 10-20 раз медленне

стесняюсь спросить, а где тут “await” ? или не обязательно его указать?

А, стримы, это другое дело. Теперь ваш вопрос понятнее. То есть когда ваша апликуха подписывается на ченджстрим, начинаются тормоза?

стесняюсь спросить, а где тут “await” ? или не обязательно его указать?

не обязательно, я забыл убрать - там все операции синхронные

А, стримы, это другое дело. Теперь ваш вопрос понятнее. То есть когда ваша апликуха подписывается на ченджстрим, начинаются тормоза?

да, именно

тормоза - Х10 - Х20 раз

не обязательно, я забыл убрать - там все операции синхронные

ааа ясненько, спасибо

А поток большой? Может так и должно быть?

А поток большой? Может так и должно быть?

нет - там событий не происходит вообще

А поток большой? Может так и должно быть?

да и рекордов мало в сумме - меньше 20

Так а что тромозит, если ничего не происходит?

Так а что тромозит, если ничего не происходит?

ну вот у меня тот же вопрос

любой запрос к монге теперь тормозит

А, так тормозят запросы к монге, а не апликуха? А какие именно запросы? Может это из-за write concern? https://docs.mongodb.com/manual/reference/write-concern/

А, так тормозят запросы к монге, а не апликуха? А какие именно запросы? Может это из-за write concern? https://docs.mongodb.com/manual/reference/write-concern/

рид запросы - файнды по коллекциях

А, так тормозят запросы к монге, а не апликуха? А какие именно запросы? Может это из-за write concern? https://docs.mongodb.com/manual/reference/write-concern/

там и документов штук по 20-40 в коллекциях

и "джойнов" тоже нету - ни через монгуз ни через агрегейшен фреймворк

там и документов штук по 20-40 в коллекциях

Очевидно, что это не связано с количеством документов

Очевидно, что это не связано с количеством документов

я понимаю. но увы не понимаю как лечить

Прежде всего нужно обратиться к логам. Повысьте уровень детализации если нужно https://docs.mongodb.com/manual/reference/method/db.setLogLevel/

Прежде всего нужно обратиться к логам. Повысьте уровень детализации если нужно https://docs.mongodb.com/manual/reference/method/db.setLogLevel/

ок, хорошо попробую

Прежде всего нужно обратиться к логам. Повысьте уровень детализации если нужно https://docs.mongodb.com/manual/reference/method/db.setLogLevel/

конекшен пул...

я по дефолту юзал один конекшен)

и стрим его блочил)

но в любом случае - спасибо!

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

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

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

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

спасибо, понял. а как обычно мониторят монгу? (у меня mongodb cloud)

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

Есть ли какой-нибудь способ безопасно удалить индекс из коллекции? Ну т. е. есть у меня индекс X, который я хочу удалить. Согласно статистике, он довольно активно используется, но, в теории, вместо него может использоваться другой индекс. Запросов разных много. Исчерпывающего списка их шейпов нет. Хочется удалить индекс X, но так, чтобы либо быстренько его вернуть, если что, либо достоверно убедившись, что сможем жить без него. Штуки вроде задизейбливания индексов в монге, насколько мне известно, нет. В кеше планов, насколько я понимаю, есть не все шейпы запросов.

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

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

"priseGraph": [ { "uv": 3.8726395761729204, "date": "2018-10-09T13:01:13.536Z" }, { "uv": 3.873669297632242, "date": "2018-10-09T13:00:14.516Z" }, ]

массив выглядит вот так

вот кусок группировки

{ $group: { _id: "$token", marketCap: { $first: "$marketCap" }, wallets: { $first: "$wallets" }, investors: { $first: "$investors" }, price: { $first: "$price" }, priceNSU: { $first: "$priceNSU" }, priseArr: { $push: "$price" }, priseGraph: { $push: { uv: "$price", date: "$createdAt" } }, id: { $first: "$_id" } } },

мне ниже нужно еще одну группировку сделать?

нужно группироват ьпо дате просто

если вам нужно среднее на срезе token-date то указываете их в _id, если нет, то то на чем нужен срез

да, мне нужен срез на токен

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

у вас после этой агрегации уже не останется инфомрациии о дате

Вечер добрый , подскажите в чем может быть косяк, post hook на save не работает LogSchema.post('save', (doc) => { console.log('post save 2'); }); // вот собственно так создаю логи exports.creatLog = log => new LogModel(log).save();

Парни кто конектился к mlab. Такая проблема получается "failed to connect to server [ds247330.mlab.com:47330] on first connect [MongoNetworkError: connection 0 to ds247330.mlab.com:47330 timed out]", "stack": "MongoNetworkError: failed to connect to server [ds247330.mlab.com:47330] on first connect

telnet ds247330.mlab.com 47330 пройдет?

лучше не светить айпи с портами, логины/пароли и прочее :)

Всем привет

У меня такая хрень: есть ну очень жирная база данных с кучей коллекций по 60к документов. Иногда необходимо целиком обновлять её, и как мне кажется самым быстрым способом было бы создание второй бд во время обновления а затем подмена основной на свежую с выпилом всех старых данных

Как бы вы такое реализовали?

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

У меня такая хрень: есть ну очень жирная база данных с кучей коллекций по 60к документов. Иногда необходимо целиком обновлять её, и как мне кажется самым быстрым способом было бы создание второй бд во время обновления а затем подмена основной на свежую с выпилом всех старых данных

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

60к доков - не жирная база, если тебе дают дамп - то прост дроп старой - заливка новой. опять же если позволяется простой в работе бд

Если процент реально обновлённых документов невысок (цифра с потолка — меньше 10%), то стоит извлечь документ, сравнить и, если требуется, обновить. Идея с наливкой новой базы хорошая. Особенно если к базе идёт большое количество запросов от пользователей, т. к. массовая наливка однозначно повлияет на качество обслуживания чтений.

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

вдруг какая житейская хитрость есть

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

костыльненько

ваша задача - костыль

реально

да не говори, реально жесть из 1999

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

Почему нельзя-то? Пока наливаем новую, ходим в старую. Как перелили переключаемся на новую.

Почему нельзя-то? Пока наливаем новую, ходим в старую. Как перелили переключаемся на новую.

а перключение мгновенное?

я такого еще нигде не видел

да не говори, реально жесть из 1999

а данные в таблицах меняюстя или они там только на чтение?

а данные в таблицах меняюстя или они там только на чтение?

только чтение

тогда проще

а перключение мгновенное?

Нет, конечно. Но оно и не должно быть мгновенным для availability. Ну, при условии, что данные помимо переливки не модифицируются

создаете у всех доков поле по типу updatedAt и загоняете новые данные и обновляя время заливки. потом удаляете все что старше времени начала заливки

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

и так бесконеееееееееееееееееееееее

создание новых проблем - это так себе решение текущей

создаете у всех доков поле по типу updatedAt и загоняете новые данные и обновляя время заливки. потом удаляете все что старше времени начала заливки

вот такое будет получше даже

если у вас вдруг 4 монга и уже ест ьтранзакции, то это даже можно сделать атомарно

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

и всё что старше 1 минуты удалять к хренам

точно

не используйте objectid кроме как id

забудьте что гдето там есть время