prog_130Стркутура БД. Статические данные, по которым не будет вестись какого то детального поиска - лишь связь коллекция - узел дерева.
А чем не подходит PostgreSQL, MySQL и любая другая современная СУБД с эффективным хранением того же json? Оно и надежнее монги и, скорее всего, быстрее )

skyANADPH3пропущено...

А чем не подходит PostgreSQL, MySQL и любая другая современная СУБД с эффективным хранением того же json? Оно и надежнее монги и, скорее всего, быстрее )
Это Ваше субъективное мнение, или тесты какие есть?

По производительности, например, https://habrahabr.ru/post/274313/
Но при этом в Postgre 9.6 уже есть изменение внутри документа, так что на update там все должно быть лучше.

skyANA,

ну, там тесты еще больший шлак. Mongo в режиме по умолчанию, насколько я помню, данные на диск скидывает "когда придется", а у PostreSQL при этом не выставлен fsync=off (и прочие аналогичные настройки).
Но вообще как только нужны хоть какие-то гарантии, производительность на запись сводится к IOPSам и умению работать с диском, а этого у PostgreSQL побольше, чем у Монги.

HettСразу видно, что с MongoDB не работал, зато кучу рекомендаций уже написал.
Нет, ты не прав, MongoDB пишет данные и журнал и флашит на диск. Есть широкие возможности управлением WriteConcern
https://docs.mongodb.com/manual/reference/write-concern/

Хм, по умолчанию j:true не выставлено, в этом случае для WhiteTiger журнал пишется на диск раз в 50ms, а не на каждую запись.

HettМонгу значит для тестов берем в режиме по умолчанию, а у постгриса отключаем флаш? Из тебя бы отменный тестер получился.

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

Чего именно там побольше? По подробнее пожалуйста.
Опыта работы с разным уровнем граблей и общей заточенности на надежное хранение (как традиционное для классических СУБД).