Uber не всегда выигрывает

[@rrrav]

Другой причиной для полного отказа от Postgres является наличие проблем при выполнении различных операций и, как следствие, угроза потери ценной информации.

Любопытно, как-то всегда считал Postgres более серьезной базой, чем MySQL. Но раз такой монстр, как Uber предпочитает второе — есть о чем задуматься.

[@robert_ayrapetyan]

Интересно почитать соответсвтующие треды в мейл-листах постргреса. В кратце — сообщество (большая часть) признает существующие недостатки в репликации\апгрейде, но там были и надуманные причины, например баг многолетней давности, который пофиксили за пару дней.

[@Old_Chroft]

баг многолетней давности, который пофиксили за пару дней

Мне одному кажется, что это говорит явно не в пользу PostgeSQL? Я ничего не имею против PostgeSQL (даже наоборот), но если сами разработчики годами забивали на мелочной баг, который для кого-то между прочим мог быть критическим — ничего удивительного, что кто-то отказывается от использования этой СУБД.

[@Deosis]

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

[@robert_ayrapetyan]

Я не очень точно выразился — имелось ввиду баг сам очень старый, и был пофикшен на пару дней (сразу после того, как появился), но просочился уберу в продакшн и висел там много лет.

[@leo150]

Сегодня пролетало
https://www.postgresql.org/message-id/5797D5A1.5030009%40agliodbs.com

[@h31]

Большой пост по поводу перехода: http://use-the-index-luke.com/blog/2016-07-29/on-ubers-choice-of-databases
Если вкратце, там много факторов. В Uber использовалась очень старая версия Постгреса, в которой не было нормальной репликации. Пару проблем можно было решить чисто через тюнинг параметров. Многие разработчики абсолютно не понимали, как работает БД, и это тоже добавляло проблемы (в блоге Uber об этом сказано прямым текстом). Есть и пара вещей, которые действительно реализованы лучше в MySQL.
В общем, не стоит делать каких-то выводов из того, что Убер куда-то перешел. У каждого проекта свои потребности, и конкретно Uber может быть будет удобнее со своей БД поверх MySQL.

[@lovermann]

В свете последних трендов в области NoSQL, не удивлюсь, если и UBER перейдёт на elastic или MongoDB.

[@ydaf]

https://www.youtube.com/watch?v=b2F-DItXtZs

[@Deosis]

> 17,7% экономического интереса
Это что вообще такое? Если переводите промптом, то ставьте значок перевода.

[@Antervis]

речь о процентном доходе

[@iamAnton]

А может о беспроцентной прибыли?

[@zhigalin]

Свои карты? Поллярда долларов чтобы избавиться от гугл мепс?
Ну зачеееееем?
Ну OSM жё есть, нафига велосипеды?

[@rrrav]

А я не раз замечал, что карты гугл отстают порой на год и более. Иногда это создает проблемы при современных темпах строительства/разрушения. В наших городах яндекс-карты (да еще и с обратной связью) часто бывают более актуальны.
Думаю от гугл мепс избавиться нереально, но можно добавить к ним свой дифф там, где они поотстали.

[@jakshi]

Я думаю что Uber не перешел с PostgreSQL на MySQL, он перешел на Schemaless который (в данный период времени) использует MySQL/InnoDB как движок.

Они просто выросли из стандартных решений и начали разрабатывать свои, как Google и т.п. компании.

Кстати, забавный факт, в 2013ом Uber переходил с MySQL на PostgreSQL.

[@devpreview]

Извините, вопрос не по теме:

Представители Didi также отметили, что планируют объединить управленческий и технологический опыт двух команд, а также их экспертизу.

Чем отличается управленческий и технологический опыт команды от её экспертизы, если предположить, что команда состоит из управленцев и технологов?