Как и писал, нужны веские основания, чтобы на сегодня использовать Монгу в серьёзных проектах. Допустим, они есть. Тогда Ок

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

Это синтетический пример, я же написал, его можно структуировать разными способами. Можно в колоночную сложить, можно файлами хранить и всякими Hive, Athena выбирать. Вариантов много... Я привел пример где есть место Mongo если не трансформировать данные вовсе.

Одно из веских оснований, что MongoDB , кроме интересных фич по документоориентированным обьектам, вполне прилично финансируется из разных фондов. Получила более 200 M $ инвестиций, что улучшает качество продукта и делает его более пригодным для "кровавого энтерпрайза". Хотите работать с опенсорсом . разрабатываемых какими то сумасшедшими асоциопатами и делающим его "за еду" в минуты только хорошоего настроения - флаг в руки...  но я бы подобные решения к себе в портфель не брал бы..

Эээ, на каких настройках и с какими гарантиями? И можно ссылку на эти бенчмарки?

Бенчмарки лучше не упоминать в суе

Бенчмарки лучше не упоминать в суе

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

Скорее эээ с моей стороны. Не может быть РБД быстрее - только хотя бы из-за того, что она уже реляционная.

опять про PG и его работу с JSON. Долго искал свой API Key от Wisuki и не нашел, но нашел от Windy, там конечно данные более структуированные https://jsoneditoronline.org/#left=cloud.7e4703495c6a44c980371e8e805a44d0

Докустим мы не хотим их разбирать на поля, потому что у них не всегда фиксированный размер, зависит от времени среза и размера среза (это похоже на запрос Google Analytics API). Вы получаете массив вложенных данных переменного размера. А далее начинаются запросы по структуре, когда не хотелось бы вынимать весь документ. В случае погоды для полетов, это может быть запрос по: где сейчас ветер до 10М/с с направлением между такими-то углами по компасу, при это только до 3/мс если это С-СЗ и только до 7м/с если это З, но не менее 2/мс. А еще чтобы 0 снега, 0 дождя, 0 осадков, цельным отрезком такая погода не менее 3-х часов, база облаков выше 3км, на такой-то площади, облака определенного типа, выстроены лестницей, градиент ветра такой-то по высоте, без инверсий и еще куча всего.....

Я бы все волосы выщипал на голове в синтаксиса запросов PgSQL для JSON)))

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

Если это реализовано — я думаю многие бы подписались в узких кругах 😏

ты понял для чего это)))) там не так просто)))) я забил..... там AI надо тренировать еще и все это ради бота в телеги, который бы мне утром в выходные говорил "где полетать"))) погода очень сложная сволочь. Ее нельзя посчитать школьной формулой даже если она очень агрегирована как у Windy/Wisuki.

Скорее эээ с моей стороны. Не может быть РБД быстрее - только хотя бы из-за того, что она уже реляционная.

Я бы скорее по заранее понятным местам/маршрутам анализировал возможность, адекватность цели, времени и силам :)

Как раз ровно наоборот, в РБД гораздо больше думают про эффективность работы с дисковой подсистемой и набрали гораздо больше опыта.
Собственно, кроме специальных кейсов типа логов, почти всегда РСУБД эффективнее работает с диском и на выделенной машине при одинаковых требованиях к гарантиям РСУБД эффективнее.

Как раз ровно наоборот, в РБД гораздо больше думают про эффективность работы с дисковой подсистемой и набрали гораздо больше опыта.
Собственно, кроме специальных кейсов типа логов, почти всегда РСУБД эффективнее работает с диском и на выделенной машине при одинаковых требованиях к гарантиям РСУБД эффективнее.

И ровно поэтому в pg есть double buffering? ;)

опять про PG и его работу с JSON. Долго искал свой API Key от Wisuki и не нашел, но нашел от Windy, там конечно данные более структуированные https://jsoneditoronline.org/#left=cloud.7e4703495c6a44c980371e8e805a44d0

Докустим мы не хотим их разбирать на поля, потому что у них не всегда фиксированный размер, зависит от времени среза и размера среза (это похоже на запрос Google Analytics API). Вы получаете массив вложенных данных переменного размера. А далее начинаются запросы по структуре, когда не хотелось бы вынимать весь документ. В случае погоды для полетов, это может быть запрос по: где сейчас ветер до 10М/с с направлением между такими-то углами по компасу, при это только до 3/мс если это С-СЗ и только до 7м/с если это З, но не менее 2/мс. А еще чтобы 0 снега, 0 дождя, 0 осадков, цельным отрезком такая погода не менее 3-х часов, база облаков выше 3км, на такой-то площади, облака определенного типа, выстроены лестницей, градиент ветра такой-то по высоте, без инверсий и еще куча всего.....

Я бы все волосы выщипал на голове в синтаксиса запросов PgSQL для JSON)))

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

Я писал выше, что документные БД в отличии от Key-Value многих (не всех) или РСУБД где можно JSON кинуть в поле просто, умеют делать глубокие индексы и богатый условный поиск.

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