Проект MangoDB развивает реализацию протокола СУБД MongoDB поверх PostgreSQL

A truly Open Source MongoDB alternative

Собственно зачем? Там же одни минусы.
Получается что в этом случае будут все минусы NoSQL и ни одного плюса SQL? И потери производительности на конвертации.

Если только из-за новой лицензии монги, то проще сразу уже нормально переписывать.

Здравствуйте, BlackEric, Вы писали:
BE>Собственно зачем? Там же одни минусы.
BE>Получается что в этом случае будут все минусы NoSQL и ни одного плюса SQL? И потери производительности на конвертации.
По-моему, получаются одни сплошные плюсы.
Вместо бездарной NoSQL начинки опираемся на industry-proven реляционное ядро.
По мере понимания ограничений DocStorage-подхода, пациенты смогут постепенно переезжать на православную реляционную модель, не испытывая особых мучений, свойственных поэтапному переходу с настоящей Mongo на RDBMS.

Здравствуйте, Sinclair, Вы писали:

S>Здравствуйте, BlackEric, Вы писали:
BE>>Собственно зачем? Там же одни минусы.
BE>>Получается что в этом случае будут все минусы NoSQL и ни одного плюса SQL? И потери производительности на конвертации.
S>По-моему, получаются одни сплошные плюсы.
S>Вместо бездарной NoSQL начинки опираемся на industry-proven реляционное ядро.
S>По мере понимания ограничений DocStorage-подхода, пациенты смогут постепенно переезжать на православную реляционную модель, не испытывая особых мучений, свойственных поэтапному переходу с настоящей Mongo на RDBMS.

Такие эксперименты, кстати, уже давно идут ( https://github.com/sebastienros/yessql ) и даже применяются в боевых проектах (см OrchardCore).

Здравствуйте, Sinclair, Вы писали:

S>Здравствуйте, BlackEric, Вы писали:
BE>>Собственно зачем? Там же одни минусы.
BE>>Получается что в этом случае будут все минусы NoSQL и ни одного плюса SQL? И потери производительности на конвертации.
S>По-моему, получаются одни сплошные плюсы.
S>Вместо бездарной NoSQL начинки опираемся на industry-proven реляционное ядро.
S>По мере понимания ограничений DocStorage-подхода, пациенты смогут постепенно переезжать на православную реляционную модель, не испытывая особых мучений, свойственных поэтапному переходу с настоящей Mongo на RDBMS.

Конвертация должна в любом случае просаживать производительность.
А зачем так переходить, если можно использовать 2 СУБД параллельно? Монга на самом деле весьма не плоха если нужно быстро выбирать документы по ID.
Если пытаться делать поиск с использованием данных из разных коллекций документов (типа join), то реляционка конечно лучше.

Здравствуйте, BlackEric, Вы писали:

BE>А зачем так переходить, если можно использовать 2 СУБД параллельно?
Можно в двух словах пример, когда это оправдано.
Потому что, как ни крути, а ко всякого рода сложным выборкам проект скатывается.

Здравствуйте, BlackEric, Вы писали:

BE>Конвертация должна в любом случае просаживать производительность.
Ну, строго говоря — не факт. Но в целом, наверное, вы правы.
BE>А зачем так переходить, если можно использовать 2 СУБД параллельно?
Например, для того, чтобы не думать, как обеспечить атомарность апдейта двух DB.
BE>Монга на самом деле весьма не плоха если нужно быстро выбирать документы по ID.
Она катастрофически плоха во всех остальных случаях. В частности, когда есть связи между "документами".
BE>Если пытаться делать поиск с использованием данных из разных коллекций документов (типа join), то реляционка конечно лучше.
А то.

Здравствуйте, Mihas, Вы писали:

M>Здравствуйте, BlackEric, Вы писали:

BE>>А зачем так переходить, если можно использовать 2 СУБД параллельно?
M>Можно в двух словах пример, когда это оправдано.
M>Потому что, как ни крути, а ко всякого рода сложным выборкам проект скатывается.

Статьи или их превьюшки для выдачи храним в монге, а вот всякую статистику, аналитику и прочеее уже пишем в ClickHouse или postgres