Холивар начался) Совет мне переписать код и применять индексы

в монге ?

проверь на каком именно месте у тебя тормоза

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

А что лучший?)

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

Вот именно, json-поля есть уже везде, смысла в монге нет никакого, только сложности из-за отсутствия SQL

я, конечно, банальность скажу, но работает? не трогай

готовится к переезду?) рано или поздно понадобится, но как говорят работает не трожь, но подстелить не помешает заранее.

вы знаете в чём разница между подходами NoSQL и SQL? Видимо нет

смотря с чем и для чего

NoSQL - это когда данные в json хранишь SQL - когда в табличках (c) Личинка Кайтера (наверное)

В том использовании и не использовании Структурного Языка Запросов

знаете про касандру? так вот, там CQL, посмотрите, получите флешбеки

И чего?

(нет)

Нет. Советую всё же почитать что-то об NoSQL, а не сшулать доклады хипсторов

Ну выходит так, ага

Что нет?

вы глупый? там где использую касандру, монгу, хадуп - ваш SQL ничоень то и нужен, там другие запросы и хотелки. Им не нужно миллиард табличек агрегировать. У них другие цели, новы как истинный сектант, орете про SQL и поля JSON.

У вас каша в голове

скорее она у вас

ну там прикол в том что с одной стороны все работает и удобно, никаких мапперов не нужно юзать (сразу json приходит фактически), можно хранить некоторые большие документы, без необходимости плодить 100500 таблиц, возможность очень быстро менять схему документов, и .тд., но появились некоторые фичи например статистика, аналитика или некоторые финансы, которые лучше со связами работают плюс констистентость данных (ACID или как там его) для финансов, вот щас сижу и думаю, что делать

Использование структурного языка запросов не является признаком NoSQL баз данных. В первую очередь это подход к хранению и моделированию БП. При этом в NoSQL БД может быть вполне себе SQL-подобное (ArangoDB)

либо монга с рефами от монгуса))))

NoSQL БД может использовать SQL-подобное? Ясно, продолжайте вести наблюдение...

уберите слово как, получите то, как есть

Для начала надо посмотреть задачу. Более конкретно. Так - сказать очень сложно. Но могу сказать, что банки любят MongoDB и это одна из её ниш

Лучше - вложенные документы. Это более правильный подход

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

В postgres есть jsonb, встроенная монга почти

да что вы говорите

Так это документооборотистый подход. Нормальный. Связан с тем, что если вы продали карабок спичек, то его цена и должна оставаться 5 копеек, а не 10 как сегодня поставили. Утрированный пример, но это так. Если у вас документооборотистая система - то реляция скорее вредна. Вам нужно копировать данные и не держать их консистетными. Это потребность бизнеса

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

😀😀😀

Вы не знаете как работать с MongoDB. PGSQL кстати не слишком хорошо работает с JSON в кейсах NoSQL

в моем варианте лучше монга

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

Так а как вы по другому хотите в документооборотистой системе? Не получится. Это нормальный путь для данного подхода и он ничем не хуже аналогов из реляции. Он просто другой. Ну и советую углубиться в составление агрегированных отчётов.

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

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

Что тут мб не так

а сколько документов у тебя?

А почему сразу в БД не сгруппировать?

монга не позволяет)))

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

))) означает стеб)

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

Позволяет. но для этого надо сделать агрегации.

да за что же вы шуток не понимаете?)

Как ?

Тогда монго. Она хоть что-то запишет

почему бы не вынести «сессии» в отдельную коллекцию?

а типа постгрес может не записать?)

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

это бы сильно ускорило ?

В память? 😂 Там же mmap

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

есть ссылка, что такое нормальный запрос в монге ? Это кривой запрос ? await InformationUsers.find();

это вообще не запрос

Монгус или драйвер лучше использовать ?

монгус

В базу. Ещё раз убеждаюсь на сколько вы не знаете MongoDB

И тебя вылечат...

Как всегда. Аргументов нет - будет нападение. Слив засчитал, успокойтесь

Ну ты даже не понимаешь о чём речь. Ты знаешь что такое mmap()?

Я дальше не буду продолжать спор. С евангелистами - не имеет смысла

Ясно, я так и думал

А тем временем в монгоуниверситете говорят — мы не используем УСТАРЕВШИЙ подход sql 😉

А ты монгу с редисом не путаешь?

Нет, не путаю ;)

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

А у постгреса такого механизма нет?

SET LOCAL synchronous_commit = ...

Ну то есть аргумент про mmap несостоятелен просто потому что mmap есть везде

Нет, почитай что такое WAL

Но я же могу отключить в постгресе fsync

Нафига?

А нафига так делать в монге? Ну то есть аргумент сводится к тому, что вот в монге mmap, а в постгресе мы не отключаем fsync, и потому... Ну отлично, давайте постгрес поставим на денди, а монгу на нормальный комп, и сравним производительность - явно же у монги всё будет лучше

Давай лучше mongodb юзать с правильным write concern, а потом бенчмарки сравнивать с постгресом

А я не хочу сравнивать бенчмарки Это лишено смысла, потому что инструменты для разных задач Мы же не сравниваем 🏍️ с 🚜