Как вариант, так бывает часто, JSON (сериализованное представление какого-то объекта) хранится в реляционке в отдельном поле (соотв. типа), а ключевые атрибуты хранятся как обычно, как атрибуты. По ним можно индексацию выполнять, соединения и всё что угодно. При этом остаются все возможности работы с JSON, возможно менее удобные или менее производительные чем в Монге

Звучит как банальщина, но с помощью такого подхода можно множество сценариев реализовать. Мы ведь не с JSON работаем как с таковым, а с объектом (пусть это документ), где JSON - вариант представления объекта

монга так и делает под капотом.

у неё документо ориентированность только на словах

а так key value

подзабыл

покрайней мере с wired tiger

опять про 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 просто строка с каким-то базовым парсингом, то такие кейсы станут адом.

А кстати такой вопрос, как у PG с клиентами, к примеру, под .NET для работы с документами?

Я вот знаю, что для монги там можно прям LINQ заюзать

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

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

Почему? Монга уже давно используется в серьезных проектах.

Да пожалуйста

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

Так хранение данных организуется исходя из того как ими будут чаще всего пользоваться. Главный вопрос - а зачем эти данные хранить в json? ;)

Монга быстрее по бенчмаркам, причем значительно.

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

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

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