С каких пор монга стала неподходящей априори?

Всегда была

с каких пор "удобство фронта (и в чём оно заключается?)" определяет какое хранилище данных использует бекенд?

Медленная

А какой лучший аналог?

Обязательно analог?

потому что фронт пишет бек?

Ну вместо)

Если брать noSQL то мб ScyllaDB, а если sql - PostgreSQL

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

Монга?

Вроде быстрая

зачем меня реплайнул?

реплай того, кто глупость сморозил

Так зарождается любовь

Успокойся просто сказал

у тебя какие-то проблемы?

Бекенд комюнити токсичный какой-то

я думаю что фронт намного токсичнее

Наоборот

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

Ты мог просто не обращат внимание он сам увидел бы

Быстрая на запись По поиску уступает распространённым рсубд

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

У меня были другие результаты. По ним монга практически всегда уступала Это были тесты не уровня hello world, а приближенные к реальности наборы данных

ну да, я в тупую заливал данные в бд по одной структуре, разве что наполнение генерил рандомно. по итогу было 50кк строк/документов, 1 индекс. монга искала строку по индексу за 4мс, постгря за 10мс. так еще и на диске монга занимала 7гб, в отличии от 15гб постгри

У монги кластеризованный индекс был? За счёт этого возможно она может обогнать при поиске по pk Но кластеризованные индексы есть в мускуле и mssql, если предполагается именно такая нагрузка - поиск по pk - можно выбрать эти субд

поиск был не по pk

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

У монги кластеризованный индекс был? За счёт этого возможно она может обогнать при поиске по pk Но кластеризованные индексы есть в мускуле и mssql, если предполагается именно такая нагрузка - поиск по pk - можно выбрать эти субд

По кластеризованному индексу?

нет, по обычному, по строке

я даже не лазил в эту часть монги

В таком случае очень странно Повторюсь, на наших тестах монга уступала в скорости поиска/чтения постгре Тесты были приближены к реальности - несколько таблиц в постгре, связи между ними, и пара коллекций в монге (с ненормализованными данными) Я не думаю, что за три года что-то изменилось, поэтому полагаю, что дело либо в железе (менее вероятно), либо в особенностях теста и данных

ну, может быть из-за связки, у меня была одна коллекция

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

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

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

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

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