Опубликован выпуск проекта FerretDB 0.3, позволяющего заменить документо-ориентированную СУБД MongoDB на PostgreSQL без внесения изменений в код приложений. FerretDB реализован как прокси-сервер, транслирующий обращения к MongoDB в SQL-запросы к PostgreSQL, что позволяет использовать PostgreSQL в качестве фактического хранилища. Код написан на языке Go и распространяется под лицензией Apache 2.0...Подробнее: https://www.opennet.ru/opennews/art.shtml?num=57290
Опасная концентрация ненужного. Будьте осторожны.
Задался вопросом, а нафига собственно? Пока не почитал лицензию mongodb (SSPL).
Собственно хочу сказать инвестору FerretDB: ах тыж хитрая жопа.джпг
Возникает вопрос: а как этот инвестор будет отбивать свои инвестиции?
В такой схеме, если клиенту понадобится платная поддержка, то логичнее будет связаться со спецами по постгресу.
Проект можно развивать и на донаты.
А как отбивать с донатов инвестиции?
С русиш айпи теперь и документацию монги хрен почитаешь
Лол, что значит, "теперь"? Ты вчера родился, или правда не в курсе? Я уже много лет вижу самую разнообразную дискриминацию в виде перекрытого доступа к информационным ресурсам. Таблички в духе "доступ с этого айпи запрещён" намекают. Не, ну ты понял, доступ с моего айпи запрещён?А что касается монги, так что-то не удивлён.
Это да, а еще называют себя толерантными..)Но иногда есть и случаи, когда провайдеры криворуки.
С сетей Ростелекома нет доступа к документации postfix, к примеру.
А все из-за того, что они поменяли какое-то время назад у себя что-то в конфигурации.С тех пор подключение выглядит так:
ip a:
ppp0: <POINTOPOINT,MULTICAST,NOARP,UP,LOWER_UP> mtu 1492 qdisc pfifo_fast state UNKNOWN group default qlen 3
link/ppp
inet x.x.x.x peer 10.181.192.1/32 scope global ppp0ip r:
default dev ppp0 scope link
10.181.192.1 dev ppp0 proto kernel scope link src x.x.x.x10.181.192.1 - это то, что "новое". Раньше этого адреса не фигурировало. Ну, года два назад так.
Добавлю...ppp0: <POINTOPOINT,MULTICAST,NOARP,UP,LOWER_UP> mtu 1492 qdisc pfifo_fast state UNKNOWN group default qlen 3
link/ppp
inet x.x.x.x peer 89.239.189.2/32 scope global ppp0
Когда у коннекта pppoe Ростелекома пир указан такой, то все работает, проблем нет.ppp0: <POINTOPOINT,MULTICAST,NOARP,UP,LOWER_UP> mtu 1492 qdisc pfifo_fast state UNKNOWN group default qlen 3
link/ppp
inet x.x.x.x peer 10.181.192.1/32 scope global ppp0
Когда там указан такой пир, то доступ до сайта postfix "блокируется".Я пытался пробиться через тех.поддержку Ростелекома, но, увы, это то, чем Ростелеком печально известен.
т.е. вопросы из разряда, а что там с производительностью в этой погремушке тебя мало интересуют. А это просто адаптер, над не семом быстром Го над не самой быстрой базой Постгрей. Напомню что производительность монги на некоторых задачах просто феноменальная.
> производительность монги на некоторых задачах просто феноменальная.обоснуй (если речь не о замерах под фенобарбиталом)
Что тебе обосновать что на перегоне данных из одного формата в другой теряешь время? Или что Го медленнее C++ так то есть полно бенчей https://benchmarksgame-team.pages.debian.net/benchmarksgame/...Но конкретно тебе я бы посоветовал семки грызть в падике сюда больше не заходи.
Обосновать в каких задачах скорость mongo феноменальная.
1. В Posgres есть встроенная поддержка jsonb и это не TEXT, а именно jsonb объекты с маппингом типов полей на типы posgres и возможностью добавлять индексы на поля и значения jsonb
2. Потери производительности и баги скорее всего будут на начальном этапе 100%, т.к. вряд ли Posgres сможет реализовать совсем все фичи спец DB для json
Да, но jsonb работает более-менее быстро, если маленький (по-моему, в пределах 4 Кб).
См. доклады Бартунова, например.
> Или что Го медленнее C++ так то есть полно бенчейТолько на hello world. В остальных случаях - не всё так однозначно.
"Самой быстрой" БД не бывает. Например, нарывался на случаи, когда PostgreSQL существенно выигрывал в производительности у MS SQL (например, благодаря массивам или нелогируемым таблицам). Реже - у Oracle (например, когда много вызовов математики через PL/Python или PL/R). Так что от задач всё немало зависит.
> Задался вопросом, а нафига собственно?патамуштамогет!
> Пока не почитал лицензию mongodb
какая сура корана воспрещает правоверному пользоваться открытой версией?
И, кстати, самостоятельно ее развивать может оказаться и попроще чем пытаться приляпать совершенно чуждый интерфейс к sql.
> И, кстати, самостоятельно ее развивать может оказаться и попроще чем пытаться приляпать совершенно чуждый интерфейс к sql.Полового из ДЦ видно за версту. В какой суре корана написано, что манипуляция данными — чуждый интерфейс к sql? Или может будешь оспаривать применимость паттерна «Адаптер»?
Оспаривается не применимость, а производительность. Адаптер не может не накладывать дополнительные расходы. А это уже влияет на коэффициент ненужность, вплоть до полное ненужности.
> Оспаривается не применимость, а производительность.Прочитай внимательно сообщение поха.
> Адаптер не может не накладывать дополнительные расходы.
И что? В зависимости от задачи может так статься, что меня эти расходы вполне устроят. Только опеннетная школота строит бесконечно скалируемый хайлоад на любой чих.
Наоборот, настоящие труЪ олды из шестого "Б" считают, что одного апача с mod_php и мускулем хватит всем. Универсальность, KISS и вот этого вот всё, никаких смузи-девляпсовских nginx, постгресов и кубернетисов.
Отказоустойчивого синхронного multimaster кластера нет, вместо этого перед бд появится адаптер который сам по себе может сломаться.Низкая производительность, которая всегда будет значительно ниже прямой работы с бд. И сама mongodb скорее всего быстрее postgresql
Реализовано только часть команд mongodb
Может быть лучше старую mongodb гонять чем этот адаптер?
> Отказоустойчивого синхронного multimaster кластера нетА у монги, можно подумать, есть? Там тоже мастер только один, реплики проксируют к нему запросы на запись.
Полноценный мультимастер только там, где есть полноценное шардирование - elasticsearch, clickhouse.
> вместо этого перед бд появится адаптер который сам по себе может сломаться.
Достаточно бессмысленный аргумент - он как бы должен символизировать, что "хрупкость" обертки+постгреса больше, чем "хрупкость" монги. Но для этого нужно доказать, что "хрупкость" постгреса больше либо равна "хрупкости" монги, что пока ещё не доказано.
> Низкая производительность, которая всегда будет значительно ниже прямой работы с бд.
Опять же, надо сравнивать с монгой, а не с постгресом.
> И сама mongodb скорее всего быстрее postgresql
А вот это неплохо было бы доказать. У любого индивида с IQ выше хлебушка уже давно должна была развиться идиосинкразия на аргументы вида "хайли лайкли".
Это типо BolgenDB, или что то серьёзное?
Не, не на расте, так что несерьезное в принципе.
Прокси сервер обёртка над обёрткой над врапером. Это всё улучшает производительность. Мы ведь любим монгу и постргресс за это.
Я хз че это. Не нужно.
сказал как отрезал
Лучше бы на SQLite.
А если серверов больше одного?
rqlite https://www.opennet.ru/opennews/art.shtml?num=56600 или любой аналог