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

Понял, я думал это remoted import

Как сделать Distinct в Agregate?

Как сделать Distinct в Agregate?

Глянь в доке. Там есть инфа про это

Как сделать Distinct в Agregate?

group

У кого был опыт создания 1 к 1 мессенджера?

как получить список переписок?

я пытаюсь вытащить из таблицы СООБЩЕНИЯ все сообщения которые были отправлены юзерайди или ПОЛУЧЕНЫ юзерайди

теперь необходимо уникализировать записи чтобы вытащить не все переписки а только дистинктивные по одному сообщению к переписке между юзером 1 и 2 и например 2 и 3

как получить список переписок?

лучше всего хранить список переписок в самом юзере, а не собирать их по сообщениям

теперь необходимо уникализировать записи чтобы вытащить не все переписки а только дистинктивные по одному сообщению к переписке между юзером 1 и 2 и например 2 и 3

что вы вкладываете в понятие "дистинктивные"?

что вы вкладываете в понятие "дистинктивные"?

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

group by

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

как лучше их хранить? какие поля там должны быть?

подскажите структуру таблицы

подскажите структуру таблицы

Внутри юзера

Внутри юзера

Когда юзер А начинает переписку с юзером Б у обоих юзеров обновить коллекцию conversations: [] и сделать туда ПУШ ID?

Да

Первому добавить второй второму первый

при пуше дублей не будет да уже?

при пуше дублей не будет да уже?

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

Я думаю в action add message на сокете делать апдейт юзеров и обновить их коллекцию

Я думаю в action add message на сокете делать апдейт юзеров и обновить их коллекцию

Ни в коем случае

Юзер А нажал написать Юзеру Б. Набрал сообщение и нажал ОТПРАВИТЬ. В этот момент я у обоих юзеров сделал бы апдейт их поля conversations где у друг друга указал бы айди

Юзер А нажал написать Юзеру Б. Набрал сообщение и нажал ОТПРАВИТЬ. В этот момент я у обоих юзеров сделал бы апдейт их поля conversations где у друг друга указал бы айди

Юзер а нашел юзера б в поиске, значит между ними не было разговоров, иначе бы он его нашел в списке диалогов. Значит с клиента прилетает флаг что диалог стартует из поиска. На бэке по этому флагу производится сверка отсутвия такого диалога у обоих юзеров, проводится поиск ЧС например и другие проверки на допустимость начать диалог, после чего добавляются в списки начатых диалогов. И уже после этого начинается сохранение самого сообщения

Юзер а нашел юзера б в поиске, значит между ними не было разговоров, иначе бы он его нашел в списке диалогов. Значит с клиента прилетает флаг что диалог стартует из поиска. На бэке по этому флагу производится сверка отсутвия такого диалога у обоих юзеров, проводится поиск ЧС например и другие проверки на допустимость начать диалог, после чего добавляются в списки начатых диалогов. И уже после этого начинается сохранение самого сообщения

Спасибо. Буду к такому стремится

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

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

Вот вот

А чем такая архитектура лучше если бы сообщения отдельно хранились в коллекции сообщений?

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

А чем такая архитектура лучше если бы сообщения отдельно хранились в коллекции сообщений?

Они и так хранятся отдельно

Они и так хранятся отдельно

Я понял что они в массиве у юзера

Я понял что они в массиве у юзера

Список диалогов у юзера

как в $lookup сделать ограничение/лимит нанпрмиер чтобы обединить 2 документа?

как в $lookup сделать ограничение/лимит нанпрмиер чтобы обединить 2 документа?

$limit

Агригат

есть пример?

let recipes = await Recipe .aggregate([ { "$addFields": { "_id": { "$toString": "$_id" } } }, {$lookup: { from: "likes", localField: "_id", foreignField: "recipeId", as: "likes" } } ])

например мне нужно чтобы в массиве likes было 5 документов

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

rs.status() ?

.

сделал

Добрый день! Насколько сильно влияет project на скорость выполнения запроса? Есть жирные документы в коллекциях, думаю обрезать лишние... пока разницу не особо замечаю

Добрый день! Насколько сильно влияет project на скорость выполнения запроса? Есть жирные документы в коллекциях, думаю обрезать лишние... пока разницу не особо замечаю

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

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

ok,понял. хм, а есть ли какой-то способ снизить I/O на диск в самых запросах? или только менять "модель"даных?

Можете менее используемые части вынести в дргугую коллекцию и цеплять ее по FK

Можете менее используемые части вынести в дргугую коллекцию и цеплять ее по FK

ну по сути изменить модлель =)

ну по сути изменить модлель =)

Ну вообще - да)

ok,понял. хм, а есть ли какой-то способ снизить I/O на диск в самых запросах? или только менять "модель"даных?

Только менять модель или сужать выборки. Можно еще делать предагрегаты или вообще завести кэш вне монги

Можете менее используемые части вынести в дргугую коллекцию и цеплять ее по FK

Палка о двух концах

Только менять модель или сужать выборки. Можно еще делать предагрегаты или вообще завести кэш вне монги

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

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

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

А вас сильно ограничивают в ресурсах? И рельно данных много или просто задел на далекое будущее?

вообще какая-проблема - есть жирная коллекция в документах которых кроме прочих даных лежит массив координат.. всё было норм, пока не начали собирать статистику

проблема реальная - на атласе уже ворнинги на I/O - выше 70-80%

подняли пока план до 32 Гб оперативы)

вообще какая-проблема - есть жирная коллекция в документах которых кроме прочих даных лежит массив координат.. всё было норм, пока не начали собирать статистику

А в данный момент все хранится в одной коллекции?

но это накапало за несколько месяуев

А в данный момент все хранится в одной коллекции?

да, уже была идея разнести это на две коллекции

даже не так - одну оставить как есть, а во вторую - дублировать только нужные данные

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

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

Имеется ввиду, что на самые тяжелые запросы делается доп коллекция и данные туда заносятся вместе с основной коллекцией, но в уже подготовленном виде. Например из 50 полей остаются 6, или считаются счетчики или другие агрегаты

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

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

Имеется ввиду, что на самые тяжелые запросы делается доп коллекция и данные туда заносятся вместе с основной коллекцией, но в уже подготовленном виде. Например из 50 полей остаются 6, или считаются счетчики или другие агрегаты

по сути получается "пирамида" с данными

сужаем их до нужного количества?

@yatoba @al_web а где про это можно почитать? этому процессу есть общее название?

статти / книжки?

По типу, это просто подходы к оптимизации

я понимаю, просто может есть общие практики?

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

у нас паплайны местами на 400 строчек и с десяток лукапов =), ещё и динамически генерятся)

у нас паплайны местами на 400 строчек и с десяток лукапов =), ещё и динамически генерятся)

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

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

ок, а есть какие-то удобные инструменты для поиска конкретных запросов которые делают БД больно?

хотя ладно, слишком много вопросов)

спасибо!

.explain()

Хм, у меня както больше все на опыте. Но база это понимание нлрмальных форм при работе sql https://ru.m.wikipedia.org/wiki/Нормальная_форма

Хм, у меня както больше все на опыте. Но база это понимание нлрмальных форм при работе sql https://ru.m.wikipedia.org/wiki/Нормальная_форма

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

Она применима к данным вообще никак не ограничиваясь компьютерами, вплоть до записей в вашем блокнотике

Всем привет. Можно ли вставить документ в другой документ? Просто как вложенный обьект, но чтоб монго сгенерило _id?