Опубликован выпуск проекта FerretDB 0.1 (бывший MangoDB), позволяющего заменить документо-ориентированную СУБД MongoDB на PostgreSQL без внесения изменений в код приложений. FerretDB реализован как прокси-сервер, транслирующий обращения к MangoDB в SQL-запросы к PostgreSQL, что позволяет использовать PostgreSQL в качестве фактического хранилища. Код написан на языке Go и распространяется под лицензией Apache 2.0...Подробнее: https://www.opennet.ru/opennews/art.shtml?num=56971
Какой ужас, просто дичь какая-то. Дайте угадаю, написано на го?
> Дайте угадаю, написано на го?Какой Вы внимательный читатель!
Первый абзац:
> Код написан на языке Go и распространяется под лицензией Apache 2.0.
Спасибо, значит, угадал!
Нет. Это значит, что вы дальше заголовка не читаете.
> Нет. Это значит, что вы дальше заголовка не читаете.А зачем, если всё и так понятно?
Ржавый?
С тобой тоже все понятно...
Даже угадывать не надо.
Если какая-нибудь лютая неинженерная дичь - 99.99% игого.
Если эта дичь ещё нормально и не работает - 99.99% хруст.
Чуваки решили хорошую инженерную задачу: предоставили инструмент отвязки от вендора. Они вам его не продают, не навязывают, не говорят, что это чудо хрень. Наоборот предупреждают о падении производительности. И это не новая модная обёртка, как это любят делать широкоизвестные товарищи в узких кругах. Это самостоятельный работающий софт.Чем вы недовольны?
> Чем вы недовольны?Подозреваю тем, - что не могут осилить Го, а то, что на нем написанно масса полезного софта - их просто бесит
Хорошая шутка(нет). А что у тебя с пунктуацией, тебя го травмировал?
> Чуваки решили хорошую инженерную задачуЧуваки пока никакую задачу - не решили. Оно у них во-первых не работает, реализуя только 1/10 апи, во-вторых теперь еще и тормозит, потому что с первой попытки и 1/10 получилось криво и возвращала не те данные.
С чем их и поздравим.
> обёртка, как это любят делать широкоизвестные товарищи в узких кругах. Это
это именно новая модная обертка вокруг обычного postgres. Не новый бэкэнд под documents db (ну ок, для постгри это малореализуемо), не оптимизация жутковатого постгрезового json, просто обертка. На модном хайпе вокруг изменившейся лицензии, не касающейся ровно никого из тех кому в принципе может придти в голову заменять монгу этим бутербродом.
> Чем вы недовольны?
Например тем что поляна в результате загажена.
P.S. и вообще не пойму, чому не на хрусте?! Ведь было бы безопастно! (А результат что так, что этак околонулевой)
>> Чуваки решили хорошую инженерную задачу
> Чуваки пока никакую задачу - не решили. Оно у них во-первых не
> работает, реализуя только 1/10 апи, во-вторых теперь еще и тормозит, потому
> что с первой попытки и 1/10 получилось криво и возвращала не
> те данные.Пруфов, конечно же -- не будет.
> С чем их и поздравим.
>> обёртка, как это любят делать широкоизвестные товарищи в узких кругах. Это
> это именно новая модная обертка вокруг обычного postgres. Не новый бэкэнд под
> documents db (ну ок, для постгри это малореализуемо), не оптимизация жутковатого
> постгрезового json, просто обертка. На модном хайпе вокруг изменившейся лицензии, не
> касающейся ровно никого из тех кому в принципе может придти в
> голову заменять монгу этим бутербродом.Постгрес не умеет документоориентированность? Понятно, постгрес не знаем.
>> Чем вы недовольны?
> Например тем что поляна в результате загажена.Вы что-то перепутали. Цифровая поляна безразмерна. Вы бы учебник по информатике за 8 класс почитали, что ли. Для приличия.
> P.S. и вообще не пойму, чому не на хрусте?! Ведь было бы
> безопастно! (А результат что так, что этак околонулевой)Понятно всё. Хруст лучше Си. При всей моей нелюбви к обоим.
в свое время записался на официальные курсы по изучению монги. Молодой был, дурак. Курсы бесплатные, конечно. Потом как-то стало лень и забросил. Как выяснилось не зря. Это кстати не первый раз, когда моя лень оказывалась права.Сейчас испытываю лень по изучению раста.
Закусывать надо.
Это ты молодец, что за Rust взялся.
Монгу сгубила жадность разрабов. Кроме монги есть ещё множество решений, которые давно её заткнули за пояс.
Так что у тебя просто лень.
Из множества можете хотя бы пару выделить?
> Из множества можете хотя бы пару выделить?Я вам даже ссылок дам:
https://github.com/boltdb/bolt -- транзакции, бакеты, поиск, персистентность.
https://github.com/iwanbk/bcache -- реплицируемый LRU-кэш (самоочистка в соответствии с заданными правилами -- время. кол-во раз доступа)
https://github.com/dgraph-io/badger -- встраиваемая персистентная база (внизу бенчмарки)
https://github.com/akyoto/cache -- ин-мемори база данных, покрытие тестами 100%.
https://github.com/claygod/coffer -- ин-мемори БД, обещают ACID.
https://github.com/hdt3213/godis -- полный аналог Redis на go. Жрёт все доступные ядра, только дай.
https://github.com/syndtr/goleveldb -- моя любимая. Тупая как палка, но надёжная. С фильтрами Блума -- поиск по записям реактивный.
https://github.com/HouzuoGuo/tiedot -- 120к rps на 4х ядрах. Работает поверх HTTP. Фактически, готовый сторедж для боевого применения.https://russianblogs.com/article/94441340423/ -- отличная статья, почему goLevelDB рвёт все вот эти ваши Постгресы/Мускли как Тузик грелку. Имхо, за этой штукой будущее. Тарантул сделан на той же технологии (LSM -- кто это придумал -- гений)
Встраиваемая -- означает никуда не надо ходить по сети. Идеально для микросервисов, неприятно для РСУБД.
Текст по последней ссылке, о goLevelDB - просто атас. Гуглтранслейтом переводили, что ли, или обкуренные писАли. Про индексы. В самом начале пишут "...lsm_tree задерживает и группирует изменения индекса и эффективно переносит обновления на диск аналогично сортировке слиянием, уменьшая накладные расходы на вставку индекса.". А немного ниже, в "Ограничениях" - "Нереляционная модель данных (NoSQL) не поддерживает операторы SQL и не поддерживает индексы;". Так поддерживает индексы или нет? А это вообще шедевр, где-то в глубине - "Как видно из приведенного выше описания, разница между соседними версиями только в том, что одни файлы удаляются, а другие удаляются". И подобного добра там по всему повествованию богато размазано.
Это и есть гугель-транслейт. Ели вам действительно интересно -- на хабре есть статья про Тарантул -- там нормально всё описано в деталях. По-крайней мере,более толково про LSM в рунете я статей не встречал.Индексы есть в любой базе -- что SQL, что NoSQL. Иначе запись найти будет невозможно. Фильтр Блума без индексов не работает. Более того, для примера в goLevelDB индексы лежат в файле рядом (строгая регулярная структура.плюсом битовое поле по ключам для того самого фильтра Блума)
Что касается самой статьи -- я то эту мешанину понимаю, так как перед этим долго лазил выбирал, смотрел бенчмарки и отзывы (особенно открытые ишью).
http://www.lmdb.tech/bench/microbench/benchmark.html <- вот тут разрыв шаблона. Бенчмарк не новый, но я и относительно свежие бенчмарки видел (сейчас не найду). Всё-равно goLevelDB по задержкам, скорости, экономии пространства выигрывает очень прилично.
> почему goLevelDB рвёт все вот эти ваши Постгресы/Мускли как Тузик грелкуСравнивать полноценный SQL с key-value хранилищем, это экспертиза уровня боженька.
Но за ссылки спасибо.
Неплохо так сгубила - акции с 18-го года выросли в 15 раз примерно...
Первое апреля же уже прошло?
думаю года через два-три закончиться это твое первое апреля
Что это? Начало конца постреляционизма?
Конец начала реляционизма. Если кто не застал первые БД, то реляционные базы это всего лишь хипстерская смузи-штука, мода на которую когда-нибудь пройдет.
Интересно, как бы отнёсся профессор Эдгар Кодд, будь он жив, если бы его хипстером обозвали.
"Мода" на фундаментальную математику и, в частности, на теорию множеств никогда не пройдёт. А если вы это не осилили - сами себе злобный Буратино. Учиться надо, а не говнокодить.
Все что старше COBOL и IMS/360 - хипстерское смузи. Это такая постирония над местными комментаторами, которые вчера выучили аж полторы технологии и считают себя самыми умными. Теорию множеств там приплетают там где надо и не надо, к примеру. Поколение пепси, что с них взять.
Вы путаете теорию и практически полезную технологию. Нафига мне ваша реляционность, если мне надо много и быстро писать в единственную таблицу и читать буквально по паре признаков?Откройте для себя goLevelDb -- база, которая летает. Не надо никаких вакуумов, миграций, и задержек по сети. Потому что живёт в памяти процесса. 120к РПС на домашнем ноуте -- нет ничего проще.
> надо много и быстро писать в единственную таблицу и читать буквально по паре признаковЕсли наоборот? Или неизвестно распределение чтений и записей (рандом)?
С таким подходом мы до сих пор сидели бы по пещерам.
Слезать с пальмы и тащиться в пещеру? Я что хипстер-смузихлеб што ле? Мне и здесь неплохо.
Ды не. На самом деле у монги был шанс, но он слит в унитаз.
Та же самая участь ждёт эластики в скором времени. Тоже начнут проксировать для начала :D
Да уже конец концаНачало конца было, когда лет 7 назад многие профессионалы, хлебнув г%вна, дружно сказали: "нет, спасибо" (в смысле монга как инструмент очень ОК, но кейсы, где она применима, всё ещё не нашли)
Года 4-5 назад, когда постгрешники хвастались, что работают с JSON быстрее, чем монга, стало ясно, что область, где монга ялвяется лучшим решением, сокращается ещё сильнее
>Года 4-5 назад, когда постгрешники хвасталисьправда они 3.14здели как троцкие.
>сокращается ещё сильнее
скоро "сократится" до 99%
Вообще монга, это про удобство в первую очередь.
Мне интересно, а какой у вас опыт (проекты, технологии) и стаж (года) разработки? С профессионалом мне было бы реально интересно пообщаться, так как монгу не тыкал ни разу. А с новичком религиозным фанатиком не хочу. Регулярное чтение е*****го сайта на итальянском домене не делает профессионалом
У меня опыт есть. Чаты, знакомства, уведомления -- вот это вот всё.
Постгрес под нагрузкой в 50к РПС ложился. Монга втаскивала до 120..150к.
Так что разговоры про смерть NoSQL подходы мягко говоря преждевременны.
Дело было год назад.
> Чаты, знакомства, уведомления -- вот это вот всё.ну то есть всё, что можно класть сразу прямо в /dev/null - в случае чего никто не хватится :)
>> Чаты, знакомства, уведомления -- вот это вот всё.
> ну то есть всё, что можно класть сразу прямо в /dev/null -
> в случае чего никто не хватится :)Не важно куда. Важно что такая возможность есть и она энергетически существенно выигрывает.
И если вы считаете, что транзакции в монге эквиваленты /dev/null -- значит монгу вы не знаете.Более того, я вам открою тайну: на практике 80% данных в итоге отправляются в /dev/null. Это нормально.
> Постгрес ложился.Вы просто не умеете его готовить
>> Постгрес ложился.
> Вы просто не умеете его готовитьУгу. Я ничего не умею готовить, я уже понял. Сколько вы сделали бенчмарков лично на Постгресе?
>>> Постгрес ложился.
>> Вы просто не умеете его готовить
> Угу. Я ничего не умею готовить, я уже понял. Сколько вы сделали
> бенчмарков лично на Постгресе?Бенч бд у нас часть стресса, так что несколько раз в день.
>>>> Постгрес ложился.
>>> Вы просто не умеете его готовить
>> Угу. Я ничего не умею готовить, я уже понял. Сколько вы сделали
>> бенчмарков лично на Постгресе?
> Бенч бд у нас часть стресса, так что несколько раз в день.Ну ка, ну ка. Как влияет на производительность базы увеличение RAM в 2 раза?)
>так как монгу не тыкал ни разузато вылез с критикой монги и с баснями что слон быстрее. возьми и попробуй... правда если ты заскорузлый дба, тебе не понравится. монга для проектов, откуда дба давно выкинули за ненадобностью
Значит плохо искали ваши эксперты области применения. Почему-то мои эксперты сразу нашли. И реляционки вздрагивают от шороха нереляционок. СУБД такой скорости не достигнут никогда. Уметь надо кошек готовить.
Как хорошо нести чепуху, когда не разбираешься.Для начала надо понять что такое Mongo, и какие гарантии они дают, в отличие от реляционной БД.
И всё СРАЗУ станет понятно.
Как оно "летает" и за счёт чего.
> Как хорошо нести чепуху, когда не разбираешься.Ну давай, начинай))
> Для начала надо понять что такое Mongo, и какие гарантии они дают,
> в отличие от реляционной БД.
> И всё СРАЗУ станет понятно.
> Как оно "летает" и за счёт чего.Вот я то как раз отлично понимаю. И могу авторитетно заявить, что гарантии монги не хуже постгреса. Вы бы для приличия документацию почитали.
И представьте себе, полно ситуаций когда всё эти ваши гарантии -- нафиг не нужны.
>> Как хорошо нести чепуху, когда не разбираешься.
> Ну давай, начинай))Ну тут, очевидно, про ACID. Да, без блокировок летает, и данные с высокой скоростью становятся кашей. Но при этом никто не запрещает пользоваться головой и гарантии консистентности данных выносить в собственный код. Местами становится сильно сложнее, но оно вполне может того стоить
> Вот я то как раз отлично понимаю. И могу авторитетно заявить, что гарантии монги не хуже постгреса. Вы бы для приличия документацию почитали.
В монгу завезли транзакции и rollback? Киньте пруфом, пожалуйста. У меня экспертизы ноль
Гарантии консистенции - это черезвычайно сложная задача.Вынести их не получится. Если получится - вы напишите по сути базу данных (врядли).
Я сам начал писать новую БД и понял насколько это сложная задача.
> Гарантии консистенции - это черезвычайно сложная задача.
> Вынести их не получится. Если получится - вы напишите по сути базу
> данных (врядли).
> Я сам начал писать новую БД и понял насколько это сложная задача.Это такая же глупая идея, как написать свою ОС.
В мире БОЛЕЕ чем достаточно отличных движков, как в виде сетевых сервисов, так и встраиваемых (начиная от РСУБД SQLite, заканчивая goLevelDB в качестве NoSQL). Гарантии, скорость, гибкость, простота. Бери не хочу.
Только SQLite очень медленная.
А так всё верно.И в мире нет ни одной объектно-ориентированной БД (как интерфейс). Точнее кое какие попытки есть.
А для embedded, как sqlite, вообще ни одной.
Firebase - не локальная бд, Realm - кусок г...на, это не полноценная БД, нет SQL. Вот по сути и всё.
> Только SQLite очень медленная.
> А так всё верно.Распределённую SQLite на go пользу
> И в мире нет ни одной объектно-ориентированной БД (как интерфейс). Точнее кое
> какие попытки есть.
> А для embedded, как sqlite, вообще ни одной.
> Firebase - не локальная бд, Realm - кусок г...на, это не полноценная
> БД, нет SQL. Вот по сути и всё.
Т.е. мне тащить распределенную БД на Go в мобильное приложение?
> Т.е. мне тащить распределенную БД на Go в мобильное приложение?Если хотите -- никто вам не мешает.
Также вам никто не мешает использовать embeded storage на Go в вашем мобильном приложении (если ас распределённая не устраивает).
> Только SQLite очень медленная.
> А так всё верно.Распределённую SQLite на go пользуйте -- медленно не покажется
> И в мире нет ни одной объектно-ориентированной БД (как интерфейс). Точнее кое
> какие попытки есть.
> А для embedded, как sqlite, вообще ни одной.Я тут ниже 8 ссылок привёл. Там всякие есть.
> Firebase - не локальная бд, Realm - кусок г...на, это не полноценная
> БД, нет SQL. Вот по сути и всё.Ну, если вы в качестве примера приводите базу, которая во времена делфей считалась сложной -- это всё, что нужно знать об актуальности ваших знаний в области хранения данных.
Вы не очень понимаете что такое embedded.Для сервера сгодится. Для embedded - категорически нет.
Тащить свой runtime с garbage collection и произвольными задержками GC в мобильное / embedded приложение, где обычно уже есть свой runtime с GC в виде Java / JavaScript?
Ну это на уровне премии Дарвина.
Embedded рабочая есть только одна БД - это SQLite. Остальные только в проекте и очень сильно не дотягивают и по возможностям и по надёжности.
Надстройки над SQLite на Go - это не базы данных.
SQLite - это г...но мамонта, которое не учитывает все тенденции и улучшения в мире процессоров, алгоритмов, баз данных. Оно было спроектировано 30 лет назад.
Но это надёжное г...но мамонта, но очень медленное. Посмотрите тесты с MonetDB. Там просто катастрофа.
> Вы не очень понимаете что такое embedded.Судя по тексту это вы не понимаете.
> Для сервера сгодится. Для embedded - категорически нет.
Я ничего не понял что вы тут написали. Embeded DB -- это база данных, которая живёт в самом процессе.
> Тащить свой runtime с garbage collection и произвольными задержками GC в мобильное
> / embedded приложение, где обычно уже есть свой runtime с GC
> в виде Java / JavaScript?
> Ну это на уровне премии Дарвина.Вас никто не заставляет это делать. Напишите приложение на golang и скомпилируйте в нативный бинарник для Ведроид.
> Embedded рабочая есть только одна БД - это SQLite. Остальные только в
> проекте и очень сильно не дотягивают и по возможностям и по
> надёжности.Нет. Это не embeded. Это DLL/SO. Вы не понимаете, что такое embeded DB.
> Надстройки над SQLite на Go - это не базы данных.
Угу. Расскажите это тем ребятам, которые ACID гарантируют.
> SQLite - это г...но мамонта, которое не учитывает все тенденции и улучшения
> в мире процессоров, алгоритмов, баз данных. Оно было спроектировано 30 лет
> назад.
> Но это надёжное г...но мамонта, но очень медленное. Посмотрите тесты с MonetDB.
> Там просто катастрофа.SQLite покрыто тестами на 95%. Покажите мне ещё одну базу ,которая была на столько отлажена?
Я вам про NoSQL тут распинаюсь, про то, какие они быстрые, безопасные и масштабируемые, а вы упёрлись в SQL.
>>> Как хорошо нести чепуху, когда не разбираешься.
>> Ну давай, начинай))
> Ну тут, очевидно, про ACID. Да, без блокировок летает, и данные с
> высокой скоростью становятся кашей. Но при этом никто не запрещает пользоваться
> головой и гарантии консистентности данных выносить в собственный код. Местами становится
> сильно сложнее, но оно вполне может того стоить
>> Вот я то как раз отлично понимаю. И могу авторитетно заявить, что гарантии монги не хуже постгреса. Вы бы для приличия документацию почитали.
> В монгу завезли транзакции и rollback? Киньте пруфом, пожалуйста. У меня экспертизы
> нольhttps://tech.geekjob.ru/tranzaktsii-v-mongodb/
https://ru.wikipedia.org/wiki/MongoDB
С разморозкой. первая же ссылка ещё 2 года назад.
ACID в монгу подвезли ещё в бородатом 2018.Если вы не умеете готовить структуры данных, то вам стоит подучиться. Если бы вы знали теорию РСУБД, то знали бы, что консистентность данных вам не сможет гарантировать ни одна РСУБД в единственном экземпляре. минимум -- 2 реплики, а ещё лучше 3 в разных ЦОДах. Ребята из монги это усвоили. Вы -- нет.
>Да, без блокировок летает, и данные с высокой скоростью становятся кашей В монгу завезли транзакции и rollbackтебе не ссылочки, а санитар нужен. транзакции в монге уже несколько лет как есть, правда они не нужны, подрастёшь, поймёшь.
Всё верно. Во-первых это не гарантии. Ребята из монги откровенно наврали про свои транзакции.А ссылку что они делают я дал.
С таким же успехом можно просто писать в файл. Будет быстрее.
> Всё верно. Во-первых это не гарантии. Ребята из монги откровенно наврали про
> свои транзакции.
> А ссылку что они делают я дал.
> С таким же успехом можно просто писать в файл. Будет быстрее.Пруфов, как всегда не будет)) Ну, ок.
Запись в файл - это 1 IO.
В БД надо сначала записать в WAL, потом в файл БД. Это азы. Азы знать надо.Не нужны транзакции и консистентность (которой у Mongo нет) - вам и обычная БД не нужна. Пишите в файл.
> Запись в файл - это 1 IO.
> В БД надо сначала записать в WAL, потом в файл БД. Это
> азы. Азы знать надо.
> Не нужны транзакции и консистентность (которой у Mongo нет) - вам и
> обычная БД не нужна. Пишите в файл.Рука-лицо. В Монге уже 4 года как ACID есть. Транзакции -- не гарантируют консистентности, чтобы вы знали. Удачного вам отката по журналу, когда у вас один диск и он попорчен на физическом уровне. И консистентность в Монге (внезапно) есть. И появилась она раньше, чем появился ACID. А этот ваш WAL простите -- просто БЕКАП. А знаете зачем потребовался этот журнал предзаписи? Ваши хвалёные транзакционные, консистентые РСУБД -- ТЕРЯЮТ ДАННЫЕ при внезапном отказе. Который в Монге просто не нужен, потому что в любой нормальной системе -- три инстанса Монги. В один запись, из двух чтение (следствие оринтированности Монги на поток в одну сторону). Если один инстанс падает -- после его возвращения автоматически произойдёт синхронизация ключей.
Кстати, тот самый WAL для Постгреса -- написан на голанг. Теперь живите с этим.
Прежде чем WAL в качестве примера приводить -- вы бы подумали -- ПОЧЕМУ он стал нужен. У NoSQL таких болезней нет.Именно поэтому вам выше правильно написали -- транзакции в Монге есть, но они нафиг не нужны -- мажоритарный принцип голосования + 3 реплики. Это делает транзакции просто ненужными.
Ну, только если ваши босы не жмоты и дали денег только на одну Монгу, на одной равсберри пай.
Боже, что вы за бред пишите. WAL нужен для1. Быстрой записи. Вместо того чтобы искать блок куда записать (full scan или index scan) - это несколько чтений как минимум для нахождения блока, а может и несколько тысяч / миллионов чтений, зависит от размера таблицы. Тут пишется сразу в WAL.
2. Записали половину блока и питание потухло - данные попорчены, удачи в восстановлении.
3. Данные не пишутся синхронно, это ОЧЕНЬ медленно.
4. Isolation в ACID
Что значит WAL не нужен? И как же Mongo гарантирует консистентность записи?;)))
Те вы сравниваете performance записи в соседний файл WAL и транзакции / синхронизации на удаленных компьютерах и Mongo у вас быстрее?)))) Когда Mongo пишет в файл, а потом ещё по сети отправляет данные 2м компьютерам, которые тоже пишут данные в файл, и отправляют данные первому компьютеру. И когда он получает ответ - данные считаются записанными (распределённая транзакция).Это вот это вы называете "быстрым" в Mongo и рвёт всех????)))
Это просто испанский стыд какой-то.> Что значит WAL не нужен? И как же Mongo гарантирует консистентность записи?;)))
Мажоритарный принцип и автосинхронизация.
> 2. Записали половину блока и питание потухло - данные попорчены, удачи в восстановлении.
> 3. Данные не пишутся синхронно, это ОЧЕНЬ медленно.Питание не может пропасть в трёх разных ЦОДах одновременно. Чушь пишите.
В Монге не надо ждать ВСЕХ записей. Ответили 2 из 3 -- всё, данные надёжно зафиксированы.
Вы откровенно не понимаете о чём пишете. Ни про SQL, ни про NoSQL.> Это вот это вы называете "быстрым" в Mongo и рвёт всех????)))
Если мы говорим про надёжное хранение данных -- да, Монга рвет всех. Все эти ваши журналы и транзакции -- полная чушь, если нет фактора репликации ТРИ.
Начнём с азов. Если вы пишите данные надёжно - вам нужно сделать как минимум 3 записи. Именно настоящие записи в файл с синхронизацией.Чтобы уметь восстановить испорченные диском данные. Иначе вы просто не сможете определить какие данные корректные, какие нет (в простом случае, без специальных кодов или хешей).
Чтобы знать что другие инстансы что-то получили, нужно хотя бы получить от них ответ обратно. Это 2 RTT.
А если secondary не пишут реально на диск, и транзакция считается подтвержденной без записи, те данные в памяти - то какая же это надёжность?
И все эти записи и RTT по сети ГОРАЗДО медленнее чем обычная БД, которая пишет локально. Для надёжности за глаза Master-Slave, а для отказа диска - RAID. Это будет гораздо надёжнее и производительнее.
> Начнём с азов. Если вы пишите данные надёжно - вам нужно сделать
> как минимум 3 записи. Именно настоящие записи в файл с синхронизацией.Вы вообще читаете, что вам пишут? Ещё раз напишу: у нормальных людей Монга работает в ТРЁХ интсансах. И в разных ЦОДах. Ещё раз вам пишу6 НЕ НУЖНО делать ТРИ записи. Достаточно убедиться только в том, что сделано ОДНА запись в мастере, ОДНА запись в копии, при ТРЁХ командах записи.
> Чтобы уметь восстановить испорченные диском данные. Иначе вы просто не сможете определить
> какие данные корректные, какие нет (в простом случае, без специальных кодов
> или хешей).Читайте ещё раз выше. Вы правда думаете, что разрабы Монги такие тупые что ничего не слышали про хэши? Вы какой-то очень наивный и неумный.
> Чтобы знать что другие инстансы что-то получили, нужно хотя бы получить от
> них ответ обратно. Это 2 RTT.Нет. Только один.
> А если secondary не пишут реально на диск, и транзакция считается подтвержденной
> без записи, те данные в памяти - то какая же это
> надёжность?Вы знаете, как Монга работает? Вы понимаете ЗАЧЕМ нужно ТРИ инстанса в РАЗНЫХ ЦОДах?
> И все эти записи и RTT по сети ГОРАЗДО медленнее чем обычная
> БД, которая пишет локально. Для надёжности за глаза Master-Slave, а для
> отказа диска - RAID. Это будет гораздо надёжнее и производительнее.РАИД очень надёжно -- пожар в голландском ЦОДе подтвердил. Удар молнии в ЦОД при хреновом заземлении -- и обе реплики базы в одном ЦОДе приказали долго жить с вот этими вашими РАИДами (читайте на хабре). Вы пишите то, о чём понятия не имеете.
Ещё раз: читайте статью мажоритарный принцип. И тогда вы поймёте ,почему транзакции в РСУБД в отдельной базе -- это блеф.
Ну-ка, расскажите как вы с помощью hash будете восстанавливать данные? Я хочу это послушать.Hash только сможет вам показать что данные изменены, но не скажет как и где. Блок будет потерян.
Посмотрите курс по базам данных от CMU. Там Mongo затрагивается.
Грубо говоря ничего лучше реляционных баз данных не придумано.
Внутри Mongo работает более-менее как классические бд.
И Mongo давно не нужна, когда есть NewSQL БД, например YugaByte DB.
Такая бредятина делитанта.Дальше спорить просто не о чем. У NoSQL есть все проблемы SQL,если это реляционные БД.
Потому что SQL - это лишь язык запросов, никакого отношения к тому как внутри работают базы данных он отношения не имеет.
> Такая бредятина делитанта.
> Дальше спорить просто не о чем. У NoSQL есть все проблемы SQL,если
> это реляционные БД.
> Потому что SQL - это лишь язык запросов, никакого отношения к тому
> как внутри работают базы данных он отношения не имеет.Слово "делитант" пишется "дилетант". Две ошибки в одном слове, глаза вытекают. Всё что нужно знать о вашей экспертизе начиная с русского языка и заканчивая хранением данных. Если SQL не имеет отношение к тому, как внутри работают базы данных -- ок. Пусть для вас это так и будет. Но а всякий случай поинтересуйтесь, когда появлися SQL и для чего. Вы удивитесь -- SQL -- это родимое пятно РСУБД.
Начнём, пожалуй, с этого https://jepsen.io/analyses/mongodb-4.2.6.Для профессионалов этим можно и закончить.
>Для профессионалов этим можно и закончить.хихи, косяк в функционале которого вообще нет в слоне, какой плохой монго, особенно актуальный сейчас 5.4 )
Возможно монгу надо как-то готовить, но у нас на нескольких десятках тысяч документов с джойнами через агрегации уже еле ворочается, индексы вроде все есть. Скл бы даже не заметил никакой нагрузки
> Возможно монгу надо как-то готовить, но у нас на нескольких десятках тысяч
> документов с джойнами через агрегации уже еле ворочается, индексы вроде все
> есть. Скл бы даже не заметил никакой нагрузкиДжойны в монге не нужны. Вам нужен составной ключ и фильтр Блума. Также весьма полезно иметь шардинг для больших объёмов. SQL точно так же вешался бы.
Я так и думал что монга нужна для поиграться
Неужели суперсовременный молодежный PostgreSQL наконец-то сделал то, что появилось в IBM Db2 в 2013 году! LOLhttps://www.theregister.com/2013/06/05/ibm_db2_mongodb/
и десяти лет не прошло, а смузихлебы уже дышат в затылок Межделамаши своей пре пре альфа версией.
Молодёжный? Который начался в 1986 году? Ну-ну. Скорее, нормальным людям остоелозил весь этот движ с noSQL у особей, у которых в голове газированное говно и которые не могут осилить теорию множеств в объёме среднестатистического технического института. И эти люди сделали мэппинг (по возможности) этого говна в нормальную реляционную модель.
YesSQL тоже появился достаточно давно:
> Неужели суперсовременный молодежный PostgreSQL наконец-то сделал то, что появилось в IBM Db2 в 2013 году! LOLА еще в суперсовременный молодежный постгрес не внедрили игру квейк, пичалька... А по серьезному - наверное обществу это не надо было в постгресе в 2013-м году, потому что тогда у монги была удовлетворяющая это общество лицензия. Лицензия на монгу поменялась в конце 18-го года, а в начале 19-го эту лицензию народ внес в список несвободных. Вот тогда для принципиальных что-то и изменилось и стали пилить замену. Зачем эмуляция монги нужна была в постгресе (или в DB2) до 18-го года, если можно было использовать оригинал?
При чем тут постгрес? Вы тему не попутали?
На тот случай, когда неосиляторы от девляпса не могут осилить SQL?
Неосиляторы чего? Ты пробовал работать с неструктурированной big data на хайлоаде? Толку там от SQL, если нет связи у документов. Правда не понятно зачем использовать PostgreSQL для этих целей. Странные авторы этой поделки.
"Нет связи у документов" только в голове у "смузихлёбов", для которых бизнес-анализ - навсегда закрытая тема. Связи есть всегда, только выявление их - удел немногих.
Инженерный отдел гугля в курсе то? По комментам сразу видно человека, который никогда не работал с big data.
аналитики opennet расскажут что в гугле работают одни смузихлебы
Я тут с парой девляпсов пообщался недавно - у них логи от зоопарка всего в 100 машин - уже бихдата и надо целый аж многонодовый кластер эластика. Уточнил объёмы - @#$%ь, я это как-то без проблем на одной машине храню. Не в эластике. Ищется и анализируется прекрасно.
Жду новости о реализации Oracle поверх MSSQL, реализующего PostgreSQL поверх Oracle.
Ещё раз прочитай новость. Чуваки отвязывают интерфейсы от платной загубленной базы за бесплатно. Причём тут Оракл?
Зачем ждать, когда уже давно все сделано?IBM Db2 поддерживает синтаксис Oracle при желании.
Amazon открыл код Babelfish, расширений для замены MS SQL Server на PostgreSQL:
https://etersoft.ru/products/selta
SELTA@Etersoft: ваша свобода выбора СУБДТранслятор SELTA@Etersoft позволяет использовать свободную СУБД PostgreSQL в приложениях, ориентированных на работу с MS SQL (например, «1С: Предприятие 7.7»).
Postgres Plus Advanced Server (расширение PostgreSQL специальными возможностями для обеспечения совместимости с Oracle Database)
Oracle Compatibility Libraries (SSORC) for SQL Server and SQL Azure
Неплохое решение, но задачи решает явно очень узкоспециализированные, уж не знаю где оно применимо вообще.
> при сравнении и сортировке разных типовВ postgres можно заменить на свои функции сравнения и сортировки, для этого не обязательно выносить это на уровень приложения.
Но гошникам конечно виднее.
Почему просто не форкнули Mongo?
Как я тебе ее форкну, она ж не на go!
Гхм. В postgreSQL видимо предполагается sync для WAL отключать.
Чтобы получить сравнимую скорострельность (ну и надёжность, да).* Кроме шуток, бывают случаи когда это ок.
А оно поддерживает кластерные служебные команды? Ну т.е. чтобы можно было на mongos + пачке ferretdb собрать аналог кластерной монги