Шел конец 2019 года Поддержка Json Path о которой говорится в середине 2017 года была добавлена только в 12 версии в конце 2019.... И то не до конца. Пользуйтесь, мы ведь все! поддерживаем ... прямо сейчас
Технически, ты прав. Но, концептуально - всё работает. И это правда зачастую бывает удобным, ведь у тебя есть возможность работать как с таблицами SQL, так и через это небольшое ухищрение баловаться с NoSQL.
Почему? На чтение масштабируется репликацией, на запись шардированием и партицированием, при дальнейшем масштабировании бизнес логика размазывается по микросервисам, всё как по учебнику
Спасибо за доклад, очень жаль что многие пробуют Монгу и живут с ней ограниченная себя в кайфе релационыки Постгриса, и верно сказал, что потом плачат что им тяжело реализовать проект. Постгрес очень круто запилили jsonb
Как сделать eventual consistency без acid ? Необходимо же атомарно сохранять состояние объекта и доменное событие. Использовать two-phase commit ? Или я чего не знаю?
Eventual consistency по сути означает отсутствие Consistency (в терминах ACID). Данные будут консистентными "когда-нибудь". Атомарность тут не при чем, разрешение конфликтов может происходить по разным стратегиям.
Когда рядовой программист по совместительству является "архитектором" проекта, а в ходе работы никто не замечает как из дева проект переехал в прод, то вопросов чем монга хуже постгреса в дальнейшем никогда не возникнет, за то с мыслью как мы будем переезжать на постгрес вы будете засыпать и просыпаться. Как в одной из крупнейших российских IT компаний, имя которой не буду рекламировать)
На самом деле. PostgreSql с jsonB нам бы очень подошел. Модель данных прям под него заточена. Есть небольшой набор фиксированых полей и много всякого разного. И между коллекциями надо поддерживать связь. А это просто жестяк в монго.
Хороший доклад, однако конструктор запросов в монге смотрится намного органичнее чем смесь с sql. Плюс не совсем понял по поводу бенчмарков - не увидел какие индексы были созданы в монге.
Если послушать много разных лекции на ютубах. То можно будет понять, что с Postgres у вас будет все хорошо. А с Монгой и Майскулей будет шаманство. Спрашивается зачем это нужно? В любом случае приложения должно быть абстрагировано от работы с базой данных. На многих языках есть куча разных библиотек для этого. При таком раскладе, когда на станет время X вы сможете достаточно спокойно пробовать разные базы данных. А база данных Postgres будет лучшим решением на текущий момент. И ее реально советуют очень многие. А те, кто сидят на майскулей они просто привыкли к ней и спецы у них по этой базе данных. Нужно переучиваться и мигрировать. А это иногда очень тяжело. Новый проект лучше начинать на Postgres.
@@klev1983 > В любом случае приложения должно быть абстрагировано от работы с базой данных в любом случае такого не бывает да и в принципе невозможно, когда речь идёт о больших проектах, потому как обеспечивать скорость приходится как на уровне приложения (запросы, ORM, драйвер), так и на стороне СУБД. И после всей этой магии переезд на другую СУБД невозможен. Можно, конечно, посвятить жизнь написанию приложения, которое будет работать на всех базах, но мы же пишем код, чтобы он приносил деньги, а не работал на всех базах, так? :)
@@greentubedog Посмотрите ORM для своего языка. Нужно разделять две вещи при проектировании. Бизнес логику и высокую нагрузку. И не когда не мешать это в одно. Для высокой нагрузки мы делаем систему кешей всего что можно. Для бизнес логики мы проектируем все использую по максимум ООП. Современные приложения состоят из обоих этих компонентов и являются максимально модульными использую по максимум API внутри себя.
@@klev1983 > Для высокой нагрузки мы делаем систему кешей всего что можно улыбнуло :) а народ то и не знает, что задачу высокой нагрузки можно решить с помощью кэшей и изобретают всякие разные базы, сервера, языки, диски, память и процессоры походу вы являетесь носителем сакрального знания или, что более вероятно, не понимаете, о чём пытаетесь рассуждать а по сути, речь идёт о мультитулах, которые, как вы заметили, лучше чем специальные инструменты и по этому вопросу вам опять же сказать нечего, отчего вы бросились в демагогию о бизнес-логике, ООП, кэшах и модульности
Олег очень сильно зациклен на постгре и плохо оценивает окружающей мир. Одно то что он думает, что добавление json в реляционную бд убьёт NoSQL говорит об это. NoSQL имеет массу преимуществ перед реляционными бд в ряде задач. Нужно выбирать инструмент под задачу, а не пытаться подогнать задачу под инструмент и допилить напильником инструмент, чтобы задача все же влезла в инструмент.
@@yahorsinkevich4451 странная у вас жизнь. Каким бы навороченный мультитул не был бы, нормальный инструмент всегда лучше, удобнее, эффективнее и надёжнее.
@@yahorsinkevich4451 на тему примеров, вот небольшой списочек NoSQL: RabbitMQ - очереди; Elasticsearch или Sphinx - поиск; Memcached - быстрое key-value хранилище; Redis - быстрое хранилище. Медленнее чем Memcached, но быстрее чем SQL решения; MongoDB или CouchDB - в некоторых кейсах быстрее SQL решений. Есть ещё графовые БД которые тоже справятся со своей задачей лучше любой SQL БД.
@@wcode404 Жизнь у меня Реальная. Попробуйте построить реальный проект с 10-ю базами заточенными под свои нужды и после поговорим. Расскажите про боль, learning curve разработчиков, support/maintenance/backup/provisioning/monitoring всех 10 систем, синхронизацию и много много много другого.
@@wcode404 Elastic и Rabbit (не дай боже адекватным людям его использовать) слабо вписываются в контекст беседы. CouchDB хорош только если вдруг понадобился multi master, лучше конечно иметь промежуточный лог на кафке или пульсаре
От ты ж! А я намедни тоже придумал HSTORE, хотел хранить всякие "ключ-значение" в текстовом поле в виде JSON. Но потом покумекал и решил хранить строковое представление MAP, благо в моём конкретном случае это проканало :)
Выглядит так, как-будто sql СУБД притираются к jsonb хранению, потому что это тренд. Как по мне - жизнь одна и времени мало, поэтому разбираться в и так навороченной СУБД очень не рационально. Я думаю что лучше докупить оперативки в проект и шардить базы. Postgres меня пугает временем на изучение, а я очень не люблю знать технологию не до конца.
Эм, что то я логику не уловил... вы не любите "не до конца в технологиях разбираться" и при этом намекаете что юзаете их много.... Напоминает рассказ про то, как "мыши кололись, но продолжали есть кактус".
Postgres vs Mongo воу! смотрю, понимаю тру фанат!... c 17 минуты: слон под кислотой умеет в json o_O )) На 19 минуте начинаю догадываться - про монгу ничего не скажут ((( На 22 минуте: Я Саша и Федя под Vodka придумали jsquery чтобы девочки смогли в красненькое ;) 24:36 мысли в слух: а как же монга!? будет? 27:26 твою дивизию ж... это кто-то юзает да? но json он сам по себе такой, не обессудьте ;) 32:05 снова мысли в слух: про монгу точно ничего не скажут! НИХЕРАЖ!!! 32:55 свершилось! Прогноз не оправдался! мы впервые коснёмся монги ихааа! Вот это вот зелёное на графичке - последняя монга с движком wt. Мы видим что монга гавно =) 35:13 а если включить параллельность... снова мысли в слух: а ЭТО кто-то использует без боли? дальше мы мерялись письками на рандомах... Мы отключили асинхронный коммит чтобы окончательно засрать монгу. 43:10 вот миллион картинок снова зелёненькое тут монга и писька у постгри больше! Снова вспышка разума о_О: А Вы в реале ЭТО использовали бы? ))) 45:13 да ладно? я не ослышался? мы начинаем проигрывать? ааа! так всё потому как строка длинная начинает "толстится" в дополнительную таблицу ))) чот ржу... 46:09 Постгря она получше чем монга серьёзно! Молодые, хотите тпс? а зачем? Ну Вы поняли, да? если не хватает, убейте свои мозги партишинингом! Всем прививку от НОУэскуэль там нету будущего! ))) Спасибо, братишка! Смеюсь от души! Жду слона под грибами!!!
@@Sashalexandros What are You talking about? He knows English enough fluent. The reason why he talks in Russian is that he is at Russian conference in Moscow. If conference were in non-Russian country he would talk in English. Russian laziness? Non-IT people even in another countries are lazy too. Did You even though that monopolizing English language is another kind of laziness? Come one learn Russian. It's not just Russian Federation. It's Ukraine, Belarusia, Azerbaijan, Kazakhstan and etc. post soviet countries. Also learning something new is good for self-development. And please don't mix politics in technology conference. He talks in his homeland. Same as at conference in Japan territory Nintendo developer would talk in Japanese.
чертов постгрес засел в головах рашакодеров. Как и спринг. Я не против этих инструментов, если уметь их использовать в ограниченных количествах. Причем постгрес бы вобще не использовать лучше.
Зашел на ютуб канал. Смотрю на первом кадре бабульку с длинными волосами и прочитал тему. Думаю нифига себе бабулька про Postgres vs Mongo будет рассказывать. Зашел, а оказывается это мужик :)))))))
Причем, тут молодые слова и так далее. MongoDB используют, не из-за маркенгово хода, а по многим другим причинам, на пример то, что java разработчик может писать не переходя на старый язык и медлительный SQL.
![Lp. Сердце Вселенной #60 РОЖДЕНИЕ ЛОЛОЛОШКИ [Финал] • Майнкрафт](http://i.ytimg.com/vi/YoR0pAV9FVQ/mqdefault.jpg)
Кадзима - гений. Больше нечего добавить
почему Кадзима?)
Миядзаки
@@hsv000 похож
"Мне никто не поверил, но на всякий случай похлопали" :)
на 50:20 тоже :)
Олег спасибо. Давно вас слушаю. Добавляете оптимизма )
2024 год просим новые ТЕСТЫ!
Фигасе это ж сам Дон Хуан=)) Человек Знания с Мескалито)) P.S. Доклад понравился.
Лол)) такая же мысль возникла
Насколько же все таки интересный докладчик
Вот как так-то? Было время на один вопрос и задать его получилось самому невнимательному слушателю? Закон подлости. =)
Лж
Ахаха, сорян))
да это капец
Прекрасный доклад!
Отличный доклад, спасибо
Узнал два новых слова: сёрвер и пузомерка :)
Обычно другими попугаями меряются, но доклад официальный, самоцезура, приходится вот такие эвфимизмы использовать
Екомерсия
очень интересно мне было слушать! спасибо!
Такому крутому чуваку вопрос не могли задать, бля, там еще кто-то спал????
Хороший доклад. Если тогда люди посмеивались, то сегодня некоторым уже не до смеха, и все больше возникает вопросов а как мигрировать на постгрес
Политическая ситуация заставила сделать шаг назад. Действительно ничего смешного. Для некоторых цена этого будет их бизнес.
Олег, я просто в восторге ;)
Вот прямо посмотрел и подумал, не заюзать ли постгресс вместо монги. Есть ли хороший кукбук, как сделать аналог gridfs на постгре (с шардами)?
Можно, но будет больно.
Да уж вопрос на миллион в конце ))
Олег Бартунов из тех людей которые работали ВНУТРИ баз данных. Прям физически ВНУТРИ. Возможно даже внутри индексов )
Ну вот. Захотел узнать, где лучше применять монгу и прочий ноу скулю, а узнал, что у монги уже в 16 году не было будущего.
Привет из ковидного 2020 🤕🤧😷
Шел конец 2019 года
Поддержка Json Path о которой говорится в середине 2017 года была добавлена только в 12 версии в конце 2019.... И то не до конца.
Пользуйтесь, мы ведь все! поддерживаем ... прямо сейчас
postgres как всегда лучший
Wow, kruto, pryamo na vse moi voprosi otvetil. Yea tut s odnoi problemoi vstretilsya i on pryamo v tochku tut raskozal. Molodzi. Silno uvazhayu.
Очень интересно
При всем уважении, Бартунов это фанатик ведущий агит проповоди в секту постгреса, для неокрепших ноэскюэльных душ.
Странное понимание nosql: прикрутить Json к SQL, а потом говорить: смотрите, мы теперь тоже NoSQL, только лучше.
Технически, ты прав. Но, концептуально - всё работает. И это правда зачастую бывает удобным, ведь у тебя есть возможность работать как с таблицами SQL, так и через это небольшое ухищрение баловаться с NoSQL.
да но кешируем все равно в памяти. redis и прочие. что не стоит key-value сбрасывать со счетов
Автор единственного вопроса проспал весь доклад ))
Лайк не глядя
Великолепно! :D
Справедливости ради, nosql это не только json, но и горизонтальное масштабирование. В реояционны бд с этим похуже.
Почему? На чтение масштабируется репликацией, на запись шардированием и партицированием, при дальнейшем масштабировании бизнес логика размазывается по микросервисам, всё как по учебнику
@@xdef42 угу, в потом надо будет внезапно сделать джоин по таблице, которая уехала в другой микросервис и здоровья погибшими.
Крутой чел.
По ссылке "Тезисы" выходит: "страница не найдена".
Спасибо за доклад, очень жаль что многие пробуют Монгу и живут с ней ограниченная себя в кайфе релационыки Постгриса, и верно сказал, что потом плачат что им тяжело реализовать проект. Постгрес очень круто запилили jsonb
Ядреных разработчиков- разработчиков ядра 😁😁😁
Но ведь реально так если задуматься!)
спасибо бабадзаки
Как сделать eventual consistency без acid ? Необходимо же атомарно сохранять состояние объекта и доменное событие. Использовать two-phase commit ? Или я чего не знаю?
Eventual consistency по сути означает отсутствие Consistency (в терминах ACID). Данные будут консистентными "когда-нибудь". Атомарность тут не при чем, разрешение конфликтов может происходить по разным стратегиям.
А никак. Смирись и живи.
cкажи ещё раз что постгрес лучьше...
кайфую
Когда рядовой программист по совместительству является "архитектором" проекта, а в ходе работы никто не замечает как из дева проект переехал в прод, то вопросов чем монга хуже постгреса в дальнейшем никогда не возникнет, за то с мыслью как мы будем переезжать на постгрес вы будете засыпать и просыпаться. Как в одной из крупнейших российских IT компаний, имя которой не буду рекламировать)
А если в проде схему хранения монговскую придётся менять по каким-то причинам? Ровно та же история получится.
На самом деле. PostgreSql с jsonB нам бы очень подошел. Модель данных прям под него заточена. Есть небольшой набор фиксированых полей и много всякого разного. И между коллекциями надо поддерживать связь. А это просто жестяк в монго.
Про merge join это легко. А вот лог транзакций самописный - это жестяк был еще тот.
Хороший доклад, однако конструктор запросов в монге смотрится намного органичнее чем смесь с sql. Плюс не совсем понял по поводу бенчмарков - не увидел какие индексы были созданы в монге.
Ненавижу это конструктор.
base -> это основание. Щелочь - всегда основание. Но основание не всегда щелочь.
топовый чувак!)
кайф) а я изобретал велосипед в виде hstor) оказывается все уже есть давно)
6:30 кто это "все", кто не любит json??? Бред.
+ видимо он по себе судит)
Доклад годный, спасибо, но про банки и транзакции такое лучше не рассказывать :) Там всё "немного" сложнее.
Согласен пример про банки неудачный
Кайф 💜🗒️
что насчёт шардинга?
Если послушать много разных лекции на ютубах. То можно будет понять, что с Postgres у вас будет все хорошо. А с Монгой и Майскулей будет шаманство. Спрашивается зачем это нужно?
В любом случае приложения должно быть абстрагировано от работы с базой данных. На многих языках есть куча разных библиотек для этого. При таком раскладе, когда на станет время X вы сможете достаточно спокойно пробовать разные базы данных. А база данных Postgres будет лучшим решением на текущий момент. И ее реально советуют очень многие. А те, кто сидят на майскулей они просто привыкли к ней и спецы у них по этой базе данных. Нужно переучиваться и мигрировать. А это иногда очень тяжело. Новый проект лучше начинать на Postgres.
Kirill Levunin да я сам уже 5+ лет на постгресе. шардинг - интересная тема
@@klev1983 > В любом случае приложения должно быть абстрагировано от работы с базой данных
в любом случае такого не бывает да и в принципе невозможно, когда речь идёт о больших проектах, потому как обеспечивать скорость приходится как на уровне приложения (запросы, ORM, драйвер), так и на стороне СУБД. И после всей этой магии переезд на другую СУБД невозможен.
Можно, конечно, посвятить жизнь написанию приложения, которое будет работать на всех базах, но мы же пишем код, чтобы он приносил деньги, а не работал на всех базах, так? :)
@@greentubedog Посмотрите ORM для своего языка. Нужно разделять две вещи при проектировании. Бизнес логику и высокую нагрузку. И не когда не мешать это в одно. Для высокой нагрузки мы делаем систему кешей всего что можно. Для бизнес логики мы проектируем все использую по максимум ООП. Современные приложения состоят из обоих этих компонентов и являются максимально модульными использую по максимум API внутри себя.
@@klev1983 > Для высокой нагрузки мы делаем систему кешей всего что можно
улыбнуло :)
а народ то и не знает, что задачу высокой нагрузки можно решить с помощью кэшей и изобретают всякие разные базы, сервера, языки, диски, память и процессоры
походу вы являетесь носителем сакрального знания или, что более вероятно, не понимаете, о чём пытаетесь рассуждать
а по сути, речь идёт о мультитулах, которые, как вы заметили, лучше чем специальные инструменты и по этому вопросу вам опять же сказать нечего, отчего вы бросились в демагогию о бизнес-логике, ООП, кэшах и модульности
Коммент из 2024. Как бы не мечталось реляционным гигантам Mongo все еще живет 😂
Олег очень сильно зациклен на постгре и плохо оценивает окружающей мир. Одно то что он думает, что добавление json в реляционную бд убьёт NoSQL говорит об это. NoSQL имеет массу преимуществ перед реляционными бд в ряде задач. Нужно выбирать инструмент под задачу, а не пытаться подогнать задачу под инструмент и допилить напильником инструмент, чтобы задача все же влезла в инструмент.
Можно с примерами. А вообще ждизнь говорить что хорошо бы иметь мультитул а не тьму разных.
@@yahorsinkevich4451 странная у вас жизнь. Каким бы навороченный мультитул не был бы, нормальный инструмент всегда лучше, удобнее, эффективнее и надёжнее.
@@yahorsinkevich4451 на тему примеров, вот небольшой списочек NoSQL:
RabbitMQ - очереди;
Elasticsearch или Sphinx - поиск;
Memcached - быстрое key-value хранилище;
Redis - быстрое хранилище. Медленнее чем Memcached, но быстрее чем SQL решения;
MongoDB или CouchDB - в некоторых кейсах быстрее SQL решений.
Есть ещё графовые БД которые тоже справятся со своей задачей лучше любой SQL БД.
@@wcode404 Жизнь у меня Реальная. Попробуйте построить реальный проект с 10-ю базами заточенными под свои нужды и после поговорим. Расскажите про боль, learning curve разработчиков, support/maintenance/backup/provisioning/monitoring всех 10 систем, синхронизацию и много много много другого.
@@wcode404 Elastic и Rabbit (не дай боже адекватным людям его использовать) слабо вписываются в контекст беседы. CouchDB хорош только если вдруг понадобился multi master, лучше конечно иметь промежуточный лог на кафке или пульсаре
что бы не гонять данные с монги на js клиент для разных джойнов, и тд... можно отправить js на монгу и на клиенте уже получить результат )))
В питоне Словарь - это фактически формат JSON, это очень удобно при обмене данными
Калмык сейчас во время войны бабло рубит нормально на импортозамесе, странно что его под санкции еще не пустили
Я люблю json!
Не плохой доклад)
От ты ж! А я намедни тоже придумал HSTORE, хотел хранить всякие "ключ-значение" в текстовом поле в виде JSON. Но потом покумекал и решил хранить строковое представление MAP, благо в моём конкретном случае это проканало :)
13:49 Что? JSON появился в 2008?! Что это за бред
В 2008 появилась первая официальная спецификация по JSON - RFC 4627
Аве, Постгрес!
Джон Ромеро - это ты? :0
ава в тему
Итог доклада: у MongoDB нет будущего 😆😆😆
Насчёт снятия денег в банкомате товарищ просто отжег.
12:34 - за это просто нагинали в одной большой ИТ-конторе))
Монги приходят и уходят, а Постгрес вечен!
Steve aoki рубит в базах
Почините скриптониту микрофон пожалуйста
Весьма спорный доклад, но интересно.
Хороший доклад и докладчик интересный, раздражает только авто трекинг камеры.
Че за автотрекинг камеры? Там живое тело рулит.
Это точно человеческие руки за камерой.
Выглядит так, как-будто sql СУБД притираются к jsonb хранению, потому что это тренд. Как по мне - жизнь одна и времени мало, поэтому разбираться в и так навороченной СУБД очень не рационально. Я думаю что лучше докупить оперативки в проект и шардить базы. Postgres меня пугает временем на изучение, а я очень не люблю знать технологию не до конца.
Эм, что то я логику не уловил... вы не любите "не до конца в технологиях разбираться" и при этом намекаете что юзаете их много.... Напоминает рассказ про то, как "мыши кололись, но продолжали есть кактус".
Почему такая прическа?
Внимательней перечитайте ещё раз документацию к крайнему обновлению Postgres SQL, там этот вопрос детально освещён.
51:45
48:19
Postgres vs Mongo воу!
смотрю, понимаю тру фанат!... c 17 минуты: слон под кислотой умеет в json o_O )) На 19 минуте начинаю догадываться - про монгу ничего не скажут ((( На 22 минуте: Я Саша и Федя под Vodka придумали jsquery чтобы девочки смогли в красненькое ;) 24:36 мысли в слух: а как же монга!? будет? 27:26 твою дивизию ж... это кто-то юзает да? но json он сам по себе такой, не обессудьте ;) 32:05 снова мысли в слух: про монгу точно ничего не скажут! НИХЕРАЖ!!! 32:55 свершилось! Прогноз не оправдался! мы впервые коснёмся монги ихааа! Вот это вот зелёное на графичке - последняя монга с движком wt. Мы видим что монга гавно =) 35:13 а если включить параллельность... снова мысли в слух: а ЭТО кто-то использует без боли? дальше мы мерялись письками на рандомах... Мы отключили асинхронный коммит чтобы окончательно засрать монгу. 43:10 вот миллион картинок снова зелёненькое тут монга и писька у постгри больше! Снова вспышка разума о_О: А Вы в реале ЭТО использовали бы? ))) 45:13 да ладно? я не ослышался? мы начинаем проигрывать? ааа! так всё потому как строка длинная начинает "толстится" в дополнительную таблицу ))) чот ржу... 46:09 Постгря она получше чем монга серьёзно! Молодые, хотите тпс? а зачем? Ну Вы поняли, да? если не хватает, убейте свои мозги партишинингом! Всем прививку от НОУэскуэль там нету будущего! ))) Спасибо, братишка! Смеюсь от души! Жду слона под грибами!!!
Че-то ты распезделся.
Вам бы рассказы писать, а не доклады про монгу смотреть ;)
Пересобери пгс со страницами в 64кб и в таблице запрети вынос значений в тосты, или доку читать глаза об доклад сломались?
Это отсылка к будущему альбому cypresses hill - elephants on acid
В Postgres для JSONB нет schema. А в Mongo есть.
Шах и Мат.
есть в виде extension к постргесу
Мы назвали это hstore..
Костыль воткнули по сути
English or Español please
sorry, only for russians! so, gtfo)))
that's a reason to learn Russian.
IMHO good for You, You'll be polyglot.
@@AnarJafarov if only russians would not be lazy and learn other languages and stop being so high and mighty.
@@Sashalexandros
What are You talking about?
He knows English enough fluent.
The reason why he talks in Russian is that he is at Russian conference in Moscow.
If conference were in non-Russian country he would talk in English.
Russian laziness?
Non-IT people even in another countries are lazy too.
Did You even though that monopolizing English language is another kind of laziness?
Come one learn Russian. It's not just Russian Federation. It's Ukraine, Belarusia, Azerbaijan, Kazakhstan and etc. post soviet countries.
Also learning something new is good for self-development.
And please don't mix politics in technology conference.
He talks in his homeland.
Same as at conference in Japan territory Nintendo developer would talk in Japanese.
MongoDB 2.6.0 ... вы что шутите, в 2017 году :) уже давно 3 версия есть.
Так и слайд был сделан в 2013 году.
Это в духе "не читал, но осуждаю". Это старый бенчмарк, потом рассказывается про актуальную ситуацию с последними версиями.
Согласен, не досмотрел, когда написал коммент.
Монго это вообще шляпа, Очень много оперативки жрет
Бедняга, даже жалко его стало, так он postgres свой хвалит (
Дети ненодуэ! )
даже сам поставленный вопрос Postgres vs Mongo - вызывает скепсис к автору
чертов постгрес засел в головах рашакодеров. Как и спринг. Я не против этих инструментов, если уметь их использовать в ограниченных количествах. Причем постгрес бы вобще не использовать лучше.
Если ты рукожоп - не стоит это вытаскивать на всеобщее обозрение...
Критикуешь - предлагай
@@EvgeniyFadeev он не рукожоп, а типовой клерк из корпорации. Для работы на корпs нужны другие качества.
@@steveharytonov2257 Неа. Рукожоп. Причём, судя по высказываниям - эталонный.
За подложенную ложь dislike
все сделали вид что не заметили, у чувака ширинка расстегнута
Всем насрать, мы ж не дебилы интересоваться ширинками ебучими.
На ширинки смотреть? Ты сайтом ошибся
Зашел на ютуб канал. Смотрю на первом кадре бабульку с длинными волосами и прочитал тему. Думаю нифига себе бабулька про Postgres vs Mongo будет рассказывать. Зашел, а оказывается это мужик :)))))))
4:00 чё сука за чунгачгук вы где его откопали? Отправьте обратно на оленье пастбище)
Причем, тут молодые слова и так далее. MongoDB используют, не из-за маркенгово хода, а по многим другим причинам, на пример то, что java разработчик может писать не переходя на старый язык и медлительный SQL.
java - это молодой и быстрый язык? :) А причины появления монги в докладе озвучили ;) явно не досмотрели или "пролистывали" доклад :D
Презентация, да будет здесь www.slideshare.net/profyclub_ru/postgres-vs-mongo-postgres-professional
Это мужчина или женщина рассказывает?