Re: Why we lost Uber as a user
От | Merlin Moncure |
---|---|
Тема | Re: Why we lost Uber as a user |
Дата | |
Msg-id | CAHyXU0yF5+6yYZV5ne3vp5PUS3Nj6mOZoucZ+3PZLCj62xXbUw@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: Why we lost Uber as a user (pgwhatever <michael@sqlexec.com>) |
Ответы |
Re: Why we lost Uber as a user
|
Список | pgsql-hackers |
On Thu, Jul 28, 2016 at 8:16 AM, pgwhatever <michael@sqlexec.com> wrote: > Statement-Based replication has a lot of problems with it like indeterminate > UDFs. Here is a link to see them all: > https://dev.mysql.com/doc/refman/5.7/en/replication-sbr-rbr.html#replication-sbr-rbr-sbr-disadvantages Sure. It's also incredibly efficient with respect to bandwidth -- so, if you're application was engineered to work around those problems it's a huge win. They could have used pgpool, but I guess the fix was already in. Taking a step back, from the outside, it looks like uber: *) has a very thick middleware, very thin database with respect to logic and complexity *) has a very high priority on quick and cheap (in terms of bandwidth) replication *) has decided the database needs to be interchangeable *) is not afraid to make weak or erroneous technical justifications as a basis of stack selection (the futex vs ipc argument I felt was particularly awful -- it ignored the fact we use spinlocks) The very fact that they swapped it out so easily suggests that they were not utilizing the database as they could have, and a different technical team might have come to a different result. Postgres is a very general system and rewards deep knowledge such that it can outperform even specialty systems in the hands of a capable developer (for example, myself). I'm just now hammering in the final coffin nails that will get solr swapped out for jsonb backed postgres. I guess it's fair to say that they felt mysql is closer to what they felt a database should do out of the box. That's disappointing, but life moves on. The takeaways are: *) people like different choices of replication mechanics -- statement level sucks a lot of the time, but not all the time *) hs/sr simplicity of configuration and operation is a big issue. it's continually gotten better and still needs to *) bad QC can cost you customers. how much regression coverage do we have of hs/sr? *) postgres may not be the ideal choice for those who want a thin and simple database merlin
В списке pgsql-hackers по дате отправления: