Вот немножко за агрегацию стремно просто)

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

Да вот сейчас этим и будем заниматься. Просто сложилось ощущение (надеюсь, что ошибочное), что аггрегацией в MongoDB стоит заниматься только в крайних случаях))

Вы поймите, что волшебства не бывает. Если вам надо суммировать 100 миллионов значений, это будет примерно везде одинаково медленно, просто в зависимости от реализации порядки «медленно» будут разными

Если у вас такие запросы это редкая аналитика, это одна задача

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

Просто болеть будет в разных местах

Вы поймите, что волшебства не бывает. Если вам надо суммировать 100 миллионов значений, это будет примерно везде одинаково медленно, просто в зависимости от реализации порядки «медленно» будут разными

Про волшебство-то понятно. Тут главное, чтоб та же самая задача при одинаковых объемах решалась не медленее, чем в Postgres) и все). А эти сегменты нужны для того, чтоб по ним емейлы или пуши слать. То есть пользователь может подождать))

Если переложить из пг как есть, то вероятнее всего будет гораздо хуже

Но тут я хотел задать вытекающий вопрос. Если мне по определнному условию нужно определить, показывать ли ОДНОМУ пользователю попап на сайте или нет (то есть уже realtime). Костыльно ли будет решение к тому же пайплайну в начало добавить стадию $match: { session_id: "<КАКОЙ-ТО ID сессии>"} ?

А остальное оставить как есть?

Если переложить из пг как есть, то вероятнее всего будет гораздо хуже

Ну это понятно, что не в табличной форме перекладывать. Как раз и хотим поэтому на монгу перейти, потому табличная форма плохо подходит))

У вас какое-то предубеждение против AF

Нет ничего костыльного. Костылем с натяжкой можно считать map/reduce и $expr

А все остальное или решает вашу задачу или не решает

Без данных перед глазам и плана запросов тяжело что-то сказать. Могу только сказать что у документных хранилищ есть определённая кривая обучения и сначала будет очень трудно перестроить мышление

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

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

Но это абстрактный кейс в вакууме

https://db-ai.co приходите, я вам помогу провалидировать насколько монга подходящее решение

Спасибо)

Извиняюсь. Последний вопрос на сегодня))) А если мне нужно посчитать сумму покупок (purchases) за опр. диапазон дат : то тут уже reduce использовать нобходимо?

db.atrn.aggregate( [ { $addFields: { purchaseSum: { $sum: "$purchases.price" }, viewsSum: { $sum: "$views.count" } } }, { $match: { purchaseSum : { $gt : 200}, viewsSum : {$lt: 100} } } ])

Извиняюсь. Последний вопрос на сегодня))) А если мне нужно посчитать сумму покупок (purchases) за опр. диапазон дат : то тут уже reduce использовать нобходимо?

Весли у вас документы по времени сгруппированы то $group

Весли у вас документы по времени сгруппированы то $group

Ну наверное не совсем. В каждом документе будет массив объектов purchases: [{date:ISODate("..."), sum:200}, {date:ISODate("..."), sum:540}, ..... ]

И для каждого корневого документа нужно, грубо говоря, посчитат сумму покупки за опр. диапазон даты))

привет! правильно ли я создал индексы?

this.db.collection('sources').createIndexes([ { key: { shortcode: 1 } }, { key: { enabled: 1 } } ]).catch((err) => { console.error(err); }); this.db.collection('visits').createIndexes([ { key: { uuid: 1 } }, { key: { source: 1 } } ]).catch((err) => { console.error(err); });

привет! правильно ли я создал индексы?

Индексы строят под запросы, так что стоит начать с них. Посмотрите экплейны с индексами и без них https://docs.mongodb.com/manual/reference/method/cursor.explain/

Ну наверное не совсем. В каждом документе будет массив объектов purchases: [{date:ISODate("..."), sum:200}, {date:ISODate("..."), sum:540}, ..... ]

В чем сакральный смысл хранить покупки массивами?

Индексы строят под запросы, так что стоит начать с них. Посмотрите экплейны с индексами и без них https://docs.mongodb.com/manual/reference/method/cursor.explain/

я имею ввиду, правильно ли они создались

или вдруг монга не индексирует сейчас ничего

я имею ввиду, правильно ли они создались

Сдается мне вы пытались составной индекс сделать, тогда неправильно

В чем сакральный смысл хранить покупки массивами?

Хм. А как еще? ну, если что, мы не интернет-магаз пилим)) А систему, позволяющую отслеживать покупки на сайте и не только покупки. (Просто за покупки как раз таки сейчас стремнее всего))). А так же строить по этим данным сегменты, рекомендации и т. д. Ну это в кратце

Хм. А как еще? ну, если что, мы не интернет-магаз пилим)) А систему, позволяющую отслеживать покупки на сайте и не только покупки. (Просто за покупки как раз таки сейчас стремнее всего))). А так же строить по этим данным сегменты, рекомендации и т. д. Ну это в кратце

По какому принципу вы укладывакте покупки в док, а то из названия коллекции не ясно

По какому принципу вы укладывакте покупки в док, а то из названия коллекции не ясно

В монгу - пока ни в каком. Сейчас просто экспериментируем. Сейчас в постгресе это. Ну, грубо говоря, когда человек нажимает на кнопку Купить на сайте, из js-скрипта посылается запрос о том, что товар добавлен в корзину. Там по идентификатору сессии в монге нужно будет найти нужный документ (содержащий все данные об этом пользователе) и в коллекцию purchases добавить объект

Кто-нибудь может показать реальный пример использования? update совместно с aggregation.

Интересует конкретно применение в updateOne/Many, не runCommand и не db.aggregate

Как забиндить localhost и какой-то сторонний IP в конфиге?

Любое значение, кроме 127.0.0.1 и 0.0.0.0 при рестарте mongod, его крашит

Любое значение, кроме 127.0.0.1 и 0.0.0.0 при рестарте mongod, его крашит

через запятую?

через запятую?

Крашит

В скобках крашит

В кавычках крашит

Абсолютно любое значение кроме двух выше

ищи issue

net: port: 27017 bindIp: 127.0.0.1,{{ mongo_listen_addr }} у меня вот такой шаблон работает отлично

{{ mongo_listen_addr }}

Что это означает?

3.6, 4.0

{{ mongo_listen_addr }}

в этой переменной IP адрес самой ноды

адрес, который существует на машине с монгой

Окей, сохраняю файл

и на котором тебе надо, чтобы монга работала

Интересует конкретно применение в updateOne/Many, не runCommand и не db.aggregate

AF не применим в контексте findAndModify. Изменение существующих документов через AF возможно только в 4.2 и только через $merge

Окей, сохраняю файл

прочитай подробнее лог, journalctl -fu mongod

Если что вот версия

кто-то уже слушает этот порт?

кто-то уже слушает этот порт?

Нет

Если что вот версия

Найдите лог монги

Говорю, что при значениях локалхоста и 0.0.0.0 монгод запускается и работает

Или stdout/err из процесса

Да, видимо текст там основной, логирование в файл настроено. /var/log/mongod/mongo*.log

Вот конец

Это было начало лога, извиняюсь

Вот конец

ip a | grep 216.233

Пусто

Это IP моего ПК

О чём тебе монга и говорит. Адрес должен быть на машине, на которой монга запущена

https://docs.mongodb.com/manual/core/security-mongodb-configuration/

Разве тут не написано, что можно внешний IP добавлять?

Так понял внешние IP только через 0.0.0.0 и включение auth?

Разве тут не написано, что можно внешний IP добавлять?

Можно, если этот адрес есть на интерфейсе, где запущена монга

Ты по-моему запутался. Что ты хочешь сделать-то?

Хотел сделать доступ к монго по внешнему IP (именно внешнему, а не на машине, как это реализовано в MySQL)

Чтобы я мог использовать БД только с локалки или с моего ПК и нигде больше

Но раз так нельзя, то придется ставить bindAll