Серж, спасибо за ответ. Дальнейшее пользование будет такое: отобразить всех пользователей, отобразить все компании, переместить пользователя в другую компанию, удалить пользователя или компанию. И что меня смущает это насколько быстро будут работать выборки по отображению всех пользователей или компаний если в монго хранить их в одном документе?

В этом случае предпочтительнее будет 2 коллекции сделать. А в пользователях хранить ссылку на id компании.

В этом случае предпочтительнее будет 2 коллекции сделать. А в пользователях хранить ссылку на id компании.

Вот так в итоге и сделали, теперь встряли когда нам надо удалить компанию и надо ж как-то атомарность операции поддержать, т.е. удалить компанию и соответственно обнулить идшки в пользователях, а монго транзакции не поддерживает. Теперь по идее надо заморочиться с two phase commit и это вообще не прикольно.

ойвей

2pc это для сильных духом, но вероятнее всего вы его убётесь делать

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

зачем вам атомарность в пользователях?

вы вообще можете ничего не обнулять

если источника связи нет, то какая разница что там в поле

связуемого документа то нет

Хм, интересно я об этом как-то не подумал.

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

и retry

Короче щас я думаю, что надо наверное все таки было компанию в пользователей запихивать. Ну сколько там тех пользователей будет потенциально ну пусть 100к не так уж это и долго будет выбрать компании из пользователей. Или нет все таки?

если у вас такие связи, то лучше не вкладывать документы

Понял

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

вкладывать с самого начала стоит только те вещи, которые в самой модели вложенные

например адрес доставки, список телефонов и так далее

товары в корзине

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

лучше обновлять конечно, но даже если она не обновится, ничего страшного не будет

Привет Есть две коллекции, из одной я вытаскиваю id документов, чтобы вытащить из другой документы, в которых есть эти id. Хотелось бы после аггрегации заменить id из первой коллекции другим полем из первой коллекции (полем из документа с этим id)

Привет Есть две коллекции, из одной я вытаскиваю id документов, чтобы вытащить из другой документы, в которых есть эти id. Хотелось бы после аггрегации заменить id из первой коллекции другим полем из первой коллекции (полем из документа с этим id)

тащите сразу нужные поля и потом проекциями оставляйте нужное

...оставляйте нужное или переименовывайте как вам нужно.

Прозрение не наступило? :)

Привет. Не :( Сейчас почитал, не наступило. Не понимаю.. У меня группируется по _id: '$user' и $sum считает сумму для всех у кого $id = $user. И как поверх этой группировки получить сумму всех. Совсем не идёт мне..

Привет. Не :( Сейчас почитал, не наступило. Не понимаю.. У меня группируется по _id: '$user' и $sum считает сумму для всех у кого $id = $user. И как поверх этой группировки получить сумму всех. Совсем не идёт мне..

Добрый день. Вот что накрапал. Не очень красиво, но как стартовый вариант: db.ttt.insertMany([{'type': 'in', 'user': 'aa', 'sid': 'aa1', 'amount': 100}, {'type': 'in', 'user': 'bb', 'sid': 'bb1', 'amount': 200}, {'type': 'in', 'user': 'cc', 'sid': 'cc1', 'amount': 300}, {'type': 'in', 'user': 'aa', 'sid': 'aa1', 'amount': 400}, {'type': 'in', 'user': 'bb', 'sid': 'bb1', 'amount': 500}, {'type': 'in', 'user': 'cc', 'sid': 'cc1', 'amount': 600}, ]) db.ttt.aggregate([ {$match: {'type': 'in'}}, {$group: {_id: null, tot_sum: {$sum: '$amount'}, docs: {$push: "$$ROOT"}}}, {$unwind: '$docs'}, {$group: {_id: '$docs.user', sum: {$sum: '$docs.amount'}, tot_sum: {$first: '$tot_sum'}}}, ]).pretty()

Привет, подскажите, есть ли у монги аналог TTL индекса, только который не удаляет запись, а выполняет некое действие? (мне надо навесить метку архива на документ, который не обновлялся час+)

нет

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

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

хотел утаскивать такие документы в другую коллекцию силами монги.

хотел утаскивать такие документы в другую коллекцию силами монги.

так и утаскивейте по признаку "старше часа"

так и утаскивейте по признаку "старше часа"

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

лишние сущности никому не нужны

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

не обязательно. Можете писать в 2 коллекции в одной из которой есть удаление по ttl (https://docs.mongodb.com/manual/core/index-ttl/)

не обязательно. Можете писать в 2 коллекции в одной из которой есть удаление по ttl (https://docs.mongodb.com/manual/core/index-ttl/)

чет выглядит как-то странновато. Делать в два раза больше записей

ну вы просили более странное: что бы база _данных_ переносила из одной коллекции в другую по расписанию

ну вы просили более странное: что бы база _данных_ переносила из одной коллекции в другую по расписанию

точно такая же странность, как и писать в две коллекции)

точно такая же странность, как и писать в две коллекции)

мне видится большей странностью :)

хотел утаскивать такие документы в другую коллекцию силами монги.

Зачем?

Зачем?

Это вопрос в чем задача? Если да, то: Есть набор сервисов, которые пишут о себе. Если сервис отвалился-выключился-ушел на обслуживание, то его надо положить в архив. Возможно потом вытащить

А зачем в отдельную коллекцию складывать?

А зачем в отдельную коллекцию складывать?

Это я просто предположил. Можно действительно, просто при Read учитывать дату изменения

Если это бизнес-логика, то оставьте документы в коллекции и фильтруйте запросом. Смысла в физическом переносе очень мало

А проблем будет очень много

Если это бизнес-логика, то оставьте документы в коллекции и фильтруйте запросом. Смысла в физическом переносе очень мало

ок, спасибо за подсказку

Всем приввет. Есть колекции User и Room. В Room есть поле users с айдишками юзеров. Как мне сделать агрегацию что бы получить такой ответ { users:[], rooms: [] } и возможно ли это вообще сделать одним запросом?

возможно, посмотрите на $lookup

через $lookup получается что каждому юзеру добавятся комнаты в которых он есть, то есть будет много повторов,

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

в которых юзеры есть

фильтрация не столь важна

по ходу как то групировать нужно заумно

фильтрация не столь важна

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

вообще тут ничего заумного, вам нужен addtoSet и each

https://docs.mongodb.com/manual/reference/operator/update/each/

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

и группирвока по константе

спасибо, буду разбираться)

а зачем?

в смысле зачем вам именно в таком виде ответ

для поиска

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

тогда лучше в два запроса

сначала найти пользователей, а потом сделать find с $in по их id

сначала найти пользователей, а потом сделать find с $in по их id

ну так я сделал

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

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

на тестовых данных запрос отрабатывает 70-100 мс

чето думаю когда будет много данных будут проблемы

запрос в rooms или запрос в users?

убедитесь что в rooms есть индекс по полю в которому лежат id пользователей

и в users есть индексы по полям по которым вы их фильтруете

В юзеров есть

А вот в комне на массив юзеров нету

Так вообще можно?)

можно конечно, индексы это опционально

Подскажите, хорошая ли практика в документе 'пост' хранить список с комментариями к этому посту? Ведь документ ограничен по размеру.

16 мегабайт вроде

Подскажите, хорошая ли практика в документе 'пост' хранить список с комментариями к этому посту? Ведь документ ограничен по размеру.

https://docs.mongodb.com/ecosystem/use-cases/storing-comments/