The OpenNET Project / Index page

[ новости /+++ | форум | теги | ]

форумы
правила/FAQ
поиск
регистрация
вход
слежка
RSS


Вариант для распечатки  
Пред. тема | След. тема 
Форум Разговоры, обсуждение новостей
Режим отображения отдельной подветви беседы [ Отслеживать ]

Оглавление

Выпуск FerretDB 0.1, реализации MongoDB на базе СУБД PostgreSQL , opennews (??), 05-Апр-22, (0) [смотреть все]

Сообщения [Сортировка по времени | RSS]


23. "Выпуск FerretDB 0.1, реализации MongoDB на базе СУБД Postgre..."  –2 +/–
Сообщение от kai3341 (ok), 05-Апр-22, 16:52 
Да уже конец конца

Начало конца было, когда лет 7 назад многие профессионалы, хлебнув г%вна, дружно сказали: "нет, спасибо" (в смысле монга как инструмент очень ОК, но кейсы, где она применима, всё ещё не нашли)

Года 4-5 назад, когда постгрешники хвастались, что работают с JSON быстрее, чем монга, стало ясно, что область, где монга ялвяется лучшим решением, сокращается ещё сильнее

Ответить | Правка | К родителю #6 | Наверх | Cообщить модератору

28. "Выпуск FerretDB 0.1, реализации MongoDB на базе СУБД Postgre..."  +3 +/–
Сообщение от лютый жабби___ (?), 05-Апр-22, 17:22 
>Года 4-5 назад, когда постгрешники хвастались

правда они 3.14здели как троцкие.

>сокращается ещё сильнее

скоро "сократится" до 99%

Вообще монга, это про удобство в первую очередь.

Ответить | Правка | Наверх | Cообщить модератору

30. "Выпуск FerretDB 0.1, реализации MongoDB на базе СУБД Postgre..."  +/–
Сообщение от kai3341 (ok), 05-Апр-22, 18:32 
Мне интересно, а какой у вас опыт (проекты, технологии) и стаж (года) разработки? С профессионалом мне было бы реально интересно пообщаться, так как монгу не тыкал ни разу. А с новичком религиозным фанатиком не хочу. Регулярное чтение е*****го сайта на итальянском домене не делает профессионалом
Ответить | Правка | Наверх | Cообщить модератору

39. "Выпуск FerretDB 0.1, реализации MongoDB на базе СУБД Postgre..."  +5 +/–
Сообщение от Брат Анон (ok), 05-Апр-22, 19:14 
У меня опыт есть. Чаты, знакомства, уведомления -- вот это вот всё.
Постгрес под нагрузкой в 50к РПС ложился. Монга втаскивала до 120..150к.
Так что разговоры про смерть NoSQL подходы мягко говоря преждевременны.
Дело было год назад.
Ответить | Правка | Наверх | Cообщить модератору

48. "Выпуск FerretDB 0.1, реализации MongoDB на базе СУБД Postgre..."  –1 +/–
Сообщение от cadmi (?), 05-Апр-22, 20:22 
> Чаты, знакомства, уведомления -- вот это вот всё.

ну то есть всё, что можно класть сразу прямо в /dev/null - в случае чего никто не хватится :)

Ответить | Правка | Наверх | Cообщить модератору

61. "Выпуск FerretDB 0.1, реализации MongoDB на базе СУБД Postgre..."  +3 +/–
Сообщение от Брат Анон (ok), 06-Апр-22, 09:02 
>> Чаты, знакомства, уведомления -- вот это вот всё.
> ну то есть всё, что можно класть сразу прямо в /dev/null -
> в случае чего никто не хватится :)

Не важно куда. Важно что такая возможность есть и она энергетически существенно выигрывает.
И если вы считаете, что транзакции в монге эквиваленты /dev/null -- значит монгу вы не знаете.

Более того, я вам открою тайну: на практике 80% данных в итоге отправляются в /dev/null. Это нормально.

Ответить | Правка | Наверх | Cообщить модератору

69. "Выпуск FerretDB 0.1, реализации MongoDB на базе СУБД Postgre..."  +/–
Сообщение от Павин Павлик (?), 06-Апр-22, 12:35 
> Постгрес ложился.

Вы просто не умеете его готовить

Ответить | Правка | К родителю #39 | Наверх | Cообщить модератору

74. "Выпуск FerretDB 0.1, реализации MongoDB на базе СУБД Postgre..."  +1 +/–
Сообщение от Брат Анон (ok), 06-Апр-22, 15:22 
>> Постгрес ложился.
> Вы просто не умеете его готовить

Угу. Я ничего не умею готовить, я уже понял. Сколько вы сделали бенчмарков лично на Постгресе?

Ответить | Правка | Наверх | Cообщить модератору

75. "Выпуск FerretDB 0.1, реализации MongoDB на базе СУБД Postgre..."  –1 +/–
Сообщение от Павин Павлик (?), 06-Апр-22, 15:49 
>>> Постгрес ложился.
>> Вы просто не умеете его готовить
> Угу. Я ничего не умею готовить, я уже понял. Сколько вы сделали
> бенчмарков лично на Постгресе?

Бенч бд у нас часть стресса, так что несколько раз в день.

Ответить | Правка | Наверх | Cообщить модератору

83. "Выпуск FerretDB 0.1, реализации MongoDB на базе СУБД Postgre..."  +/–
Сообщение от Брат Анон (ok), 06-Апр-22, 17:06 
>>>> Постгрес ложился.
>>> Вы просто не умеете его готовить
>> Угу. Я ничего не умею готовить, я уже понял. Сколько вы сделали
>> бенчмарков лично на Постгресе?
> Бенч бд у нас часть стресса, так что несколько раз в день.

Ну ка, ну ка. Как влияет на производительность базы увеличение RAM в 2 раза?)

Ответить | Правка | Наверх | Cообщить модератору

65. "Выпуск FerretDB 0.1, реализации MongoDB на базе СУБД Postgre..."  +2 +/–
Сообщение от лютый жабби___ (?), 06-Апр-22, 09:47 
>так как монгу не тыкал ни разу

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

Ответить | Правка | К родителю #30 | Наверх | Cообщить модератору

34. "Выпуск FerretDB 0.1, реализации MongoDB на базе СУБД Postgre..."  +/–
Сообщение от Брат Анон (ok), 05-Апр-22, 19:07 
Значит плохо искали ваши эксперты области применения. Почему-то мои эксперты сразу нашли. И реляционки вздрагивают от шороха нереляционок. СУБД такой скорости не достигнут никогда. Уметь надо кошек готовить.
Ответить | Правка | К родителю #23 | Наверх | Cообщить модератору

38. "Выпуск FerretDB 0.1, реализации MongoDB на базе СУБД Postgre..."  +/–
Сообщение от Аноним (38), 05-Апр-22, 19:13 
Как хорошо нести чепуху, когда не разбираешься.

Для начала надо понять что такое Mongo, и какие гарантии они дают, в отличие от реляционной БД.

И всё СРАЗУ станет понятно.

Как оно "летает" и за счёт чего.

Ответить | Правка | Наверх | Cообщить модератору

40. "Выпуск FerretDB 0.1, реализации MongoDB на базе СУБД Postgre..."  +2 +/–
Сообщение от Брат Анон (ok), 05-Апр-22, 19:18 
> Как хорошо нести чепуху, когда не разбираешься.

Ну давай, начинай))

> Для начала надо понять что такое Mongo, и какие гарантии они дают,
> в отличие от реляционной БД.
> И всё СРАЗУ станет понятно.
> Как оно "летает" и за счёт чего.

Вот я то как раз отлично понимаю. И могу авторитетно заявить, что гарантии монги не хуже постгреса. Вы бы для приличия документацию почитали.

И представьте себе, полно ситуаций когда всё эти ваши гарантии -- нафиг не нужны.

Ответить | Правка | Наверх | Cообщить модератору

43. "Выпуск FerretDB 0.1, реализации MongoDB на базе СУБД Postgre..."  +1 +/–
Сообщение от kai3341 (ok), 05-Апр-22, 19:31 
>> Как хорошо нести чепуху, когда не разбираешься.
> Ну давай, начинай))

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

> Вот я то как раз отлично понимаю. И могу авторитетно заявить, что гарантии монги не хуже постгреса. Вы бы для приличия документацию почитали.

В монгу завезли транзакции и rollback? Киньте пруфом, пожалуйста. У меня экспертизы ноль

Ответить | Правка | Наверх | Cообщить модератору

57. "Выпуск FerretDB 0.1, реализации MongoDB на базе СУБД Postgre..."  +/–
Сообщение от Аноним (38), 06-Апр-22, 02:01 
Гарантии консистенции - это черезвычайно сложная задача.

Вынести их не получится. Если получится - вы напишите по сути базу данных (врядли).

Я сам начал писать новую БД и понял насколько это сложная задача.

Ответить | Правка | Наверх | Cообщить модератору

64. "Выпуск FerretDB 0.1, реализации MongoDB на базе СУБД Postgre..."  +2 +/–
Сообщение от Брат Анон (ok), 06-Апр-22, 09:12 
> Гарантии консистенции - это черезвычайно сложная задача.
> Вынести их не получится. Если получится - вы напишите по сути базу
> данных (врядли).
> Я сам начал писать новую БД и понял насколько это сложная задача.

Это такая же глупая идея, как написать свою ОС.

В мире БОЛЕЕ чем достаточно отличных движков, как в виде сетевых сервисов, так и встраиваемых (начиная от РСУБД SQLite, заканчивая goLevelDB  в качестве NoSQL). Гарантии, скорость, гибкость, простота. Бери не хочу.

Ответить | Правка | Наверх | Cообщить модератору

70. "Выпуск FerretDB 0.1, реализации MongoDB на базе СУБД Postgre..."  +/–
Сообщение от Аноним (38), 06-Апр-22, 13:18 
Только SQLite очень медленная.
А так всё верно.

И в мире нет ни одной объектно-ориентированной БД (как интерфейс). Точнее кое какие попытки есть.

А для embedded, как sqlite, вообще ни одной.

Firebase - не локальная бд, Realm - кусок г...на, это не полноценная БД, нет SQL. Вот по сути и всё.

Ответить | Правка | Наверх | Cообщить модератору

78. "Выпуск FerretDB 0.1, реализации MongoDB на базе СУБД Postgre..."  +1 +/–
Сообщение от Брат Анон (ok), 06-Апр-22, 16:19 
> Только SQLite очень медленная.
> А так всё верно.

Распределённую SQLite на go пользу

> И в мире нет ни одной объектно-ориентированной БД (как интерфейс). Точнее кое
> какие попытки есть.
> А для embedded, как sqlite, вообще ни одной.
> Firebase - не локальная бд, Realm - кусок г...на, это не полноценная
> БД, нет SQL. Вот по сути и всё.

Ответить | Правка | Наверх | Cообщить модератору

79. "Выпуск FerretDB 0.1, реализации MongoDB на базе СУБД Postgre..."  +/–
Сообщение от Аноним (38), 06-Апр-22, 16:40 
Т.е. мне тащить распределенную БД на Go в мобильное приложение?
Ответить | Правка | Наверх | Cообщить модератору

84. "Выпуск FerretDB 0.1, реализации MongoDB на базе СУБД Postgre..."  +1 +/–
Сообщение от Брат Анон (ok), 06-Апр-22, 17:08 
> Т.е. мне тащить распределенную БД на Go в мобильное приложение?

Если хотите -- никто вам не мешает.
Также вам никто не мешает использовать embeded storage на Go в вашем мобильном приложении  (если ас распределённая не устраивает).

Ответить | Правка | Наверх | Cообщить модератору

81. "Выпуск FerretDB 0.1, реализации MongoDB на базе СУБД Postgre..."  +4 +/–
Сообщение от Брат Анон (ok), 06-Апр-22, 16:49 
> Только SQLite очень медленная.
> А так всё верно.

Распределённую SQLite на go пользуйте -- медленно не покажется

> И в мире нет ни одной объектно-ориентированной БД (как интерфейс). Точнее кое
> какие попытки есть.
> А для embedded, как sqlite, вообще ни одной.

Я тут ниже 8 ссылок привёл. Там всякие есть.

> Firebase - не локальная бд, Realm - кусок г...на, это не полноценная
> БД, нет SQL. Вот по сути и всё.

Ну, если вы в качестве примера приводите базу, которая во времена делфей считалась сложной -- это всё, что нужно знать об актуальности ваших знаний в области хранения данных.

Ответить | Правка | К родителю #70 | Наверх | Cообщить модератору

86. "Выпуск FerretDB 0.1, реализации MongoDB на базе СУБД Postgre..."  –1 +/–
Сообщение от Аноним (38), 06-Апр-22, 18:16 
Вы не очень понимаете что такое embedded.

Для сервера сгодится. Для embedded - категорически нет.

Тащить свой runtime с garbage collection и произвольными задержками GC в мобильное / embedded приложение, где обычно уже есть свой runtime с GC в виде Java / JavaScript?

Ну это на уровне премии Дарвина.

Embedded рабочая есть только одна БД - это SQLite. Остальные только в проекте и очень сильно не дотягивают и по возможностям и по надёжности.

Надстройки над SQLite на Go - это не базы данных.

SQLite - это г...но мамонта, которое не учитывает все тенденции и улучшения в мире процессоров, алгоритмов, баз данных. Оно было спроектировано 30 лет назад.

Но это надёжное г...но мамонта, но очень медленное. Посмотрите тесты с MonetDB. Там просто катастрофа.

Ответить | Правка | Наверх | Cообщить модератору

90. "Выпуск FerretDB 0.1, реализации MongoDB на базе СУБД Postgre..."  +1 +/–
Сообщение от Брат Анон (ok), 06-Апр-22, 22:30 
> Вы не очень понимаете что такое 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.

Ответить | Правка | Наверх | Cообщить модератору

62. "Выпуск FerretDB 0.1, реализации MongoDB на базе СУБД Postgre..."  +6 +/–
Сообщение от Брат Анон (ok), 06-Апр-22, 09:04 
>>> Как хорошо нести чепуху, когда не разбираешься.
>> Ну давай, начинай))
> Ну тут, очевидно, про ACID. Да, без блокировок летает, и данные с
> высокой скоростью становятся кашей. Но при этом никто не запрещает пользоваться
> головой и гарантии консистентности данных выносить в собственный код. Местами становится
> сильно сложнее, но оно вполне может того стоить
>> Вот я то как раз отлично понимаю. И могу авторитетно заявить, что гарантии монги не хуже постгреса. Вы бы для приличия документацию почитали.
> В монгу завезли транзакции и rollback? Киньте пруфом, пожалуйста. У меня экспертизы
> ноль

https://tech.geekjob.ru/tranzaktsii-v-mongodb/
https://ru.wikipedia.org/wiki/MongoDB
С разморозкой. первая же ссылка ещё 2 года назад.
ACID в монгу подвезли ещё в бородатом 2018.

Если вы не умеете готовить структуры данных, то вам стоит подучиться. Если бы вы знали теорию РСУБД, то знали бы, что консистентность данных вам не сможет гарантировать ни одна РСУБД в единственном экземпляре. минимум -- 2 реплики, а ещё лучше 3 в разных ЦОДах. Ребята из монги это усвоили. Вы -- нет.

Ответить | Правка | К родителю #43 | Наверх | Cообщить модератору

66. "Выпуск FerretDB 0.1, реализации MongoDB на базе СУБД Postgre..."  +2 +/–
Сообщение от лютый жабби___ (?), 06-Апр-22, 09:50 
>Да, без блокировок летает, и данные с высокой скоростью становятся кашей В монгу завезли транзакции и rollback

тебе не ссылочки, а санитар нужен. транзакции в монге уже несколько лет как есть, правда они не нужны, подрастёшь, поймёшь.

Ответить | Правка | К родителю #43 | Наверх | Cообщить модератору

71. "Выпуск FerretDB 0.1, реализации MongoDB на базе СУБД Postgre..."  –2 +/–
Сообщение от Аноним (38), 06-Апр-22, 13:21 
Всё верно. Во-первых это не гарантии. Ребята из монги откровенно наврали про свои транзакции.

А ссылку что они делают я дал.
С таким же успехом можно просто писать в файл. Будет быстрее.

Ответить | Правка | Наверх | Cообщить модератору

76. "Выпуск FerretDB 0.1, реализации MongoDB на базе СУБД Postgre..."  +5 +/–
Сообщение от Брат Анон (ok), 06-Апр-22, 16:12 
> Всё верно. Во-первых это не гарантии. Ребята из монги откровенно наврали про
> свои транзакции.
> А ссылку что они делают я дал.
> С таким же успехом можно просто писать в файл. Будет быстрее.

Пруфов, как всегда не будет)) Ну, ок.

Ответить | Правка | Наверх | Cообщить модератору

80. "Выпуск FerretDB 0.1, реализации MongoDB на базе СУБД Postgre..."  –2 +/–
Сообщение от Аноним (38), 06-Апр-22, 16:44 
Запись в файл - это 1 IO.
В БД надо сначала записать в WAL, потом в файл БД. Это азы. Азы знать надо.

Не нужны транзакции и консистентность (которой у Mongo нет) - вам и обычная БД не нужна. Пишите в файл.

Ответить | Правка | Наверх | Cообщить модератору

82. "Выпуск FerretDB 0.1, реализации MongoDB на базе СУБД Postgre..."  +4 +/–
Сообщение от Брат Анон (ok), 06-Апр-22, 17:00 
> Запись в файл - это 1 IO.
> В БД надо сначала записать в WAL, потом в файл БД. Это
> азы. Азы знать надо.
> Не нужны транзакции и консистентность (которой у Mongo нет) - вам и
> обычная БД не нужна. Пишите в файл.

Рука-лицо. В Монге уже 4 года как ACID есть. Транзакции -- не гарантируют консистентности, чтобы вы знали. Удачного вам отката по журналу, когда у вас один диск и он попорчен на физическом уровне. И консистентность в Монге (внезапно) есть. И появилась она раньше, чем появился ACID. А этот ваш WAL простите -- просто БЕКАП. А знаете зачем потребовался этот журнал предзаписи? Ваши хвалёные транзакционные, консистентые РСУБД -- ТЕРЯЮТ ДАННЫЕ при внезапном отказе.  Который в Монге просто не нужен, потому что в любой нормальной системе -- три инстанса Монги. В один запись, из двух чтение (следствие оринтированности Монги на поток в одну сторону). Если один инстанс падает -- после его возвращения автоматически произойдёт синхронизация ключей.

Кстати, тот самый WAL для Постгреса -- написан на голанг. Теперь живите с этим.
Прежде чем WAL в качестве примера приводить -- вы бы подумали -- ПОЧЕМУ он стал нужен. У NoSQL таких болезней нет.

Именно поэтому вам выше правильно написали -- транзакции в Монге есть, но они нафиг не нужны -- мажоритарный принцип голосования + 3 реплики. Это делает транзакции просто ненужными.
Ну, только если ваши босы не жмоты и дали денег только на одну Монгу, на одной равсберри пай.

Ответить | Правка | Наверх | Cообщить модератору

87. "Выпуск FerretDB 0.1, реализации MongoDB на базе СУБД Postgre..."  –4 +/–
Сообщение от Аноним (38), 06-Апр-22, 18:38 
Боже, что вы за бред пишите. WAL нужен для

1. Быстрой записи. Вместо того чтобы искать блок куда записать (full scan или index scan) - это несколько чтений как минимум для нахождения блока, а может и несколько тысяч / миллионов чтений, зависит от размера таблицы. Тут пишется сразу в WAL.

2. Записали половину блока и питание потухло - данные попорчены, удачи в восстановлении.

3. Данные не пишутся синхронно, это ОЧЕНЬ медленно.

4. Isolation в ACID

Что значит WAL не нужен? И как же Mongo гарантирует консистентность записи?;)))


Те вы сравниваете performance записи в соседний файл WAL и транзакции / синхронизации на удаленных компьютерах и Mongo у вас быстрее?)))) Когда Mongo пишет в файл, а потом ещё по сети отправляет данные 2м компьютерам, которые тоже пишут данные в файл, и отправляют данные первому компьютеру. И когда он получает ответ - данные считаются записанными (распределённая транзакция).

Это вот это вы называете "быстрым" в Mongo и рвёт всех????)))

Ответить | Правка | Наверх | Cообщить модератору

91. "Выпуск FerretDB 0.1, реализации MongoDB на базе СУБД Postgre..."  +3 +/–
Сообщение от Брат Анон (ok), 06-Апр-22, 22:36 
Это просто испанский стыд какой-то.

> Что значит WAL не нужен? И как же Mongo гарантирует консистентность записи?;)))

Мажоритарный принцип и автосинхронизация.

> 2. Записали половину блока и питание потухло - данные попорчены, удачи в восстановлении.
> 3. Данные не пишутся синхронно, это ОЧЕНЬ медленно.

Питание не может пропасть в трёх разных ЦОДах одновременно. Чушь пишите.
В Монге не надо ждать ВСЕХ записей. Ответили 2 из 3 -- всё, данные надёжно зафиксированы.
Вы откровенно не понимаете о чём пишете. Ни про SQL, ни про NoSQL.

> Это вот это вы называете "быстрым" в Mongo и рвёт всех????)))

Если мы говорим про надёжное хранение данных -- да, Монга рвет всех. Все эти ваши журналы и транзакции -- полная чушь, если нет фактора репликации ТРИ.


Ответить | Правка | Наверх | Cообщить модератору

94. "Выпуск FerretDB 0.1, реализации MongoDB на базе СУБД Postgre..."  –1 +/–
Сообщение от Аноним (38), 07-Апр-22, 00:05 
Начнём с азов. Если вы пишите данные надёжно - вам нужно сделать как минимум 3 записи. Именно настоящие записи в файл с синхронизацией.

Чтобы уметь восстановить испорченные диском данные. Иначе вы просто не сможете определить какие данные корректные, какие нет (в простом случае, без специальных кодов или хешей).

Чтобы знать что другие инстансы что-то получили, нужно хотя бы получить от них ответ обратно. Это 2 RTT.

А если secondary не пишут реально на диск, и транзакция считается подтвержденной без записи, те данные в памяти - то какая же это надёжность?

И все эти записи и RTT по сети ГОРАЗДО медленнее чем обычная БД, которая пишет локально. Для надёжности за глаза Master-Slave, а для отказа диска - RAID. Это будет гораздо надёжнее и производительнее.

Ответить | Правка | К родителю #91 | Наверх | Cообщить модератору

95. "Выпуск FerretDB 0.1, реализации MongoDB на базе СУБД Postgre..."  +2 +/–
Сообщение от Брат Анон (ok), 07-Апр-22, 08:57 
> Начнём с азов. Если вы пишите данные надёжно - вам нужно сделать
> как минимум 3 записи. Именно настоящие записи в файл с синхронизацией.

Вы вообще читаете, что вам пишут? Ещё раз напишу: у нормальных людей Монга работает в ТРЁХ интсансах. И в разных ЦОДах. Ещё раз вам пишу6 НЕ НУЖНО делать ТРИ записи. Достаточно убедиться только в том, что сделано ОДНА запись в мастере, ОДНА запись в копии, при ТРЁХ командах записи.

> Чтобы уметь восстановить испорченные диском данные. Иначе вы просто не сможете определить
> какие данные корректные, какие нет (в простом случае, без специальных кодов
> или хешей).

Читайте ещё раз выше. Вы правда думаете, что разрабы Монги такие тупые что ничего не слышали про хэши? Вы какой-то очень наивный и неумный.


> Чтобы знать что другие инстансы что-то получили, нужно хотя бы получить от
> них ответ обратно. Это 2 RTT.

Нет. Только один.

> А если secondary не пишут реально на диск, и транзакция считается подтвержденной
> без записи, те данные в памяти - то какая же это
> надёжность?

Вы знаете, как Монга работает? Вы понимаете ЗАЧЕМ нужно ТРИ инстанса в РАЗНЫХ ЦОДах?

> И все эти записи и RTT по сети ГОРАЗДО медленнее чем обычная
> БД, которая пишет локально. Для надёжности за глаза Master-Slave, а для
> отказа диска - RAID. Это будет гораздо надёжнее и производительнее.

РАИД очень надёжно -- пожар в голландском ЦОДе подтвердил. Удар молнии в ЦОД при хреновом заземлении -- и обе реплики базы в одном ЦОДе приказали долго жить с вот этими вашими РАИДами (читайте на хабре). Вы пишите то, о чём понятия не имеете.
Ещё раз: читайте статью мажоритарный принцип. И тогда вы поймёте ,почему транзакции в РСУБД в отдельной базе -- это блеф.

Ответить | Правка | К родителю #94 | Наверх | Cообщить модератору

98. "Выпуск FerretDB 0.1, реализации MongoDB на базе СУБД Postgre..."  –1 +/–
Сообщение от Аноним (38), 07-Апр-22, 14:55 
Ну-ка, расскажите как вы с помощью hash будете восстанавливать данные? Я хочу это послушать.

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

Посмотрите курс по базам данных от CMU. Там Mongo затрагивается.

Грубо говоря ничего лучше реляционных баз данных не придумано.

Внутри Mongo работает более-менее как классические бд.

И Mongo давно не нужна, когда есть NewSQL БД, например YugaByte DB.

Ответить | Правка | К родителю #95 | Наверх | Cообщить модератору

88. "Выпуск FerretDB 0.1, реализации MongoDB на базе СУБД Postgre..."  –4 +/–
Сообщение от Аноним (38), 06-Апр-22, 18:42 
Такая бредятина делитанта.

Дальше спорить просто не о чем. У NoSQL есть все проблемы SQL,если это реляционные БД.

Потому что SQL - это лишь язык запросов, никакого отношения к тому как внутри работают базы данных он отношения не имеет.

Ответить | Правка | К родителю #82 | Наверх | Cообщить модератору

92. "Выпуск FerretDB 0.1, реализации MongoDB на базе СУБД Postgre..."  +3 +/–
Сообщение от Брат Анон (ok), 06-Апр-22, 22:39 
> Такая бредятина делитанта.
> Дальше спорить просто не о чем. У NoSQL есть все проблемы SQL,если
> это реляционные БД.
> Потому что SQL - это лишь язык запросов, никакого отношения к тому
> как внутри работают базы данных он отношения не имеет.

Слово "делитант" пишется "дилетант". Две ошибки в одном слове, глаза вытекают. Всё что нужно знать о вашей экспертизе начиная с русского языка и заканчивая хранением данных. Если SQL не имеет отношение к тому, как внутри работают базы данных -- ок. Пусть для вас это так и будет. Но а всякий случай поинтересуйтесь, когда появлися SQL и для чего. Вы удивитесь -- SQL -- это родимое пятно РСУБД.

Ответить | Правка | Наверх | Cообщить модератору

56. "Выпуск FerretDB 0.1, реализации MongoDB на базе СУБД Postgre..."  +/–
Сообщение от Аноним (38), 06-Апр-22, 01:58 
Начнём, пожалуй, с этого https://jepsen.io/analyses/mongodb-4.2.6.

Для профессионалов этим можно и закончить.

Ответить | Правка | К родителю #40 | Наверх | Cообщить модератору

85. "Выпуск FerretDB 0.1, реализации MongoDB на базе СУБД Postgre..."  +/–
Сообщение от лютый жабби___ (?), 06-Апр-22, 17:25 
>Для профессионалов этим можно и закончить.

хихи, косяк в функционале которого вообще нет в слоне, какой плохой монго, особенно актуальный сейчас 5.4 )

Ответить | Правка | Наверх | Cообщить модератору

47. "Выпуск FerretDB 0.1, реализации MongoDB на базе СУБД Postgre..."  +/–
Сообщение от ананоша (?), 05-Апр-22, 20:15 
Возможно монгу надо как-то готовить, но у нас на нескольких десятках тысяч документов с джойнами через агрегации уже еле ворочается, индексы вроде все есть. Скл бы даже не заметил никакой нагрузки
Ответить | Правка | К родителю #34 | Наверх | Cообщить модератору

77. "Выпуск FerretDB 0.1, реализации MongoDB на базе СУБД Postgre..."  +2 +/–
Сообщение от Брат Анон (ok), 06-Апр-22, 16:14 
> Возможно монгу надо как-то готовить, но у нас на нескольких десятках тысяч
> документов с джойнами через агрегации уже еле ворочается, индексы вроде все
> есть. Скл бы даже не заметил никакой нагрузки

Джойны в монге не нужны. Вам нужен составной ключ и фильтр Блума. Также весьма полезно иметь шардинг для больших объёмов. SQL точно так же вешался бы.

Ответить | Правка | Наверх | Cообщить модератору

101. "Выпуск FerretDB 0.1, реализации MongoDB на базе СУБД Postgre..."  +/–
Сообщение от ананоша (?), 09-Апр-22, 20:47 
Я так и думал что монга нужна для поиграться
Ответить | Правка | Наверх | Cообщить модератору

Архив | Удалить

Рекомендовать для помещения в FAQ | Индекс форумов | Темы | Пред. тема | След. тема




Партнёры:
PostgresPro
Inferno Solutions
Hosting by Hoster.ru
Хостинг:

Закладки на сайте
Проследить за страницей 		Created 1996-2024 by Maxim Chirkov
Добавить, Поддержать, Вебмастеру