霍炬:聊聊Uber公司迁移数据库这件事

先声明,我没有被盗号……只是想趁着周末没多少人看,今天来写写技术。是的,本帐号在极其偶然的情况下也会写一些纯粹的技术问题,虽然我知道我的读者并不都是技术从业者。不过……谁让我现在就这一个写文章的地方呢。所以还请大家略微容忍一下。虽然是纯技术文章,但我相信很多道理在不同行业是通用的。

下面来说背景。昨天Uber发了一篇blog,讲了他们为什么从PostgreSQL数据库迁移到MySQL。这是一个有点怪异的决定,因为我印象很深刻,2013年的时候Uber有过一个keynote,讲他们为什么从MySQL迁移到PostgreSQL。

新的这篇文章说的理由很细致,有不少关于PostgreSQL的实现原理(尽管我认为这些描述也并不都对),但最根本的原因,似乎指向了immutable结构设计最终引起的写放大问题,最后造成了“无法扩展到满足现在需求”(significant problems scaling Postgres with our growth)。这些描述让我觉得非常困惑,首先,这个时代大部分商业性服务的数据库都应该是immutable的,无论是从性能上说还是从业务逻辑上说,追加改动部分都比更新数据合理的多。尤其考虑到Uber这样的服务,大量数据都涉及到最终费用甚至证据,不能被随便修改,immutable的数据库系统从物理上限制了“不留痕迹神不知鬼不觉”的修改方式,就算数据库权限被破坏,越权之后的数据修改仍然会留下痕迹,这是非常好的特性。

这样的特性在写入方面当然会有一定代价,但直接更新数据同样也有代价。如前所述,用追加版本来替代更新这个行为是对的,所以如果我没理解错,似乎Uber这篇文章的意思是如果这种更新不在物理层解决,换到在逻辑层由自己实现会变得更可控。这个观点我可以有部分认同,但对于这个具体案例,则难以认同。我不太相信Uber自己能实现的比PostgreSQL本身的实现更好,事实上按照业界口碑,PostgreSQL是开源数据库中各方面指标最好的一个。把数据更新逻辑从物理层挪到逻辑层,本质上的资源耗费情况不会有变化,顶多能做一点点适合自己应用场景的优化,这种优化是否有效,是否有其他副作用,从这篇文章中看不出来。也没提供任何profiling的数据结果可以支持这种看法。

事实上,在我看来,架构相关的计算机科学领域无法就几件事,时间换空间或者空间换时间、性能换冗余或者冗余换性能…这些基本问题最终都会触及到现在科学的边界,没法逾越。一个特性的优点,背后一定有其对应的代价。在这个领域这么基础的问题不太可能出现“换一个数据库产品”就解决了架构问题的可能性。如果竟然真的出现了这种可能性,大部分情况下恐怕是什么地方弄错了。Uber的文章写了不少MySQL的优点,完全没讲这些优点背后的代价是什么,这就让整个决定变得更可疑。

无论是我自己所知道的模糊情况,还是业内其他使用PostgreSQL的公司使用体验,都很难支持Uber这篇文章的结论。更神奇的是他们竟然不是把MySQL当作关系型数据库用,而是在上面开发了自己的中间件,Schemaless,等于是把MySQL当一个纯粹的存储引擎,然后拿他当NoSQL用…这又何必折腾呢,直接用NoSQL库岂不是更好。今年年初的时候,Uber也在另外一篇文章里面写过为何,以及如何设计Schemaless这个中间件,它的确是自己实现了immutable,然后把一个JSON文件存到MySQL的InnoDB表里面。我看来看去,觉得他们唯一需要MySQL的地方是replication机制,这恰好是MySQL做的最不好的地方(之一)。

综合这些原因,我想说的是架构设计最主要的是场景,有应用场景才能针对性对齐优化,选型,以及正确的profiling以得到支持结论的数据。Uber的文章对于应用场景语焉不详,也很难判断。不过根据其2013年迁移到PostgreSQL的文章可以做一些猜测,当时他们说迁移到PostgreSQL最重要的理由是PostGIS。如果按照这个推荐测话,很大可能这次迁移的库是车辆实时位置的GIS库,这也比较符合前面说的为什么他们对写入量特别敏感。即使在这个场景下,迁移到MySQL看起来也不是一个好选择。综合几篇文章,我能得出的一个合理推测是Uber负责这部分工作的技术团队对MySQL非常熟悉,但对PostgreSQL不太熟悉。

如果是比较良好的架构设计,我相信使用这两个数据库的任何一个都能解决他们的问题。换数据库这种事是伤筋动骨的事,3年折腾一次确实显得财大气粗,在这个折腾劲儿上可能只有曾经的Twitter可以与之相比了。

促使我写这篇文章的一个主要原因是觉得原文理由基本站不住脚,比较虚。很想写一篇文章说说我对架构设计和选型的一些看法,顺便表达一下千万不要太相信这种“我们从xx换到xx“的文章的看法。因为现在主流开源产品的特性即使有面向不同侧重点的差异,也不会有换一个同类产品可以解决架构问题的可能性。大部分工作还是要看团队的能力范围和适应情况,所以很多正确的事情换到你的团队就未必正确。

另外,Uber这篇文章的分析角度和技术解释倒是可以一读,但我总觉得就算里面没有错误,这样的文章也应该写在选型之前,而不是基于一个理由切换了数据库,过几年才写出来。当然,我也很理解在公司不同阶段,考虑技术架构的方式也截然不同,但这个案例里面,2013年的Uber也已经是大公司了…

关于这件事情有两个非常有意思的评论,可以分享给大家。一个来自Reddit,It looks like Uber is just trolling everyone including themselves :) (看起来就是Uber这个钓鱼的家伙钓了所有人,最后把自己也钓上钩了)。另外一个来自python社区的ZoomQuiet,在讨论这个问题的时候,他对我们说“别想那么多,可能就是换了个领导”。分析完之后,我觉得很可能ZoomQuiet猜到了真正的原因…

我打算在我的帐号上开设一个新栏目,每次推荐一个我比较喜欢,但阅读量不高的帐号。同时这些推荐列表会放到我公众号菜单的推荐阅读菜单下。推荐标准是:我喜欢读、有一定历史、流量低、更新频率不太高、没有参加任何联盟。不接受推荐和自荐。这是为了改善目前大号过大造成的题材单一现象。让我们把更多的关注投给那些有趣的个人帐号吧。下面是本次推荐。

滴答滴答(公众号ID: AngelaTalk)

Angela(朱赟)是Airbnb的资深工程师,技术功底非常扎实。她把技术文章写的清晰又好读,非常厉害。有一天我偶然翻了认识她之前的的那些没看过的技术文章,一翻就读了一晚上,每一篇都很棒,当时感觉就像捡到了宝藏。她最近一篇文章《闲话数据库》写的也是这个话题,但跟我角度不一样,也强烈推荐一读。实际上如果不是一起聊了这个话题,她怂恿我写一篇,我大概是不会在我的公众号写纯技术文章的…谢谢Angela。

除了技术文章,她还会写一些关于湾区的事情,这可是一手体验,比道听途说的那些湾区访问记啊游记啊靠谱多了,对硅谷的生活、工作什么的有兴趣的同学也别错过。

对了,《神秘的程序员们》(公众号:coderstory <-上一期提到这个帐号的时候被OS X自动更正干掉了一个r,竟然发出来的是错的…这次终于写对了。)有一个连载叫做《架构师成长之路》这个连载的脚本基础是我写的。它体现了我这几年对于早期成长性企业的架构观,就是如何把云计算服务做为架构资源一部分融合到架构中。这样可以在成本和开发速度上获得很好的平衡。虽然这是和七牛云计算合作的系列,但它可不是仅仅是广告,而是真的讲了架构师如何成长和如何思考。我们在制作这个系列的时候,脚本也请资深架构师们Review过,以保证它的准确性。点阅读原文可以看这个漫画连载。

【文/霍炬 歪理邪说(微信号:wxieshuo)】

氧分子网(www.yangfenzi.com)是关注互联网生态圈的科技新媒体

·氧分子网(http://www.yangfenzi.com)延伸阅读:

➤ 霍炬:网络霸凌、收费阅读和内容创业

➤ 霍炬:某个特定的切面上,人人都是少数派

➤ 滴滴出行VS优步Uber:柳青说数据才是最大资产

➤ 曙光总裁历军:大数据网络是信息技术最大的推动力

➤ 涂子沛:传媒公司如何转型?做数据公司!

➤ 诺蓝:大数据创业,数据哪里来?需要跨过几道坎?

您可能还喜欢…

10 Responses

  1. 李晨说道:

    后年,又迁移到mongodb,然后继续走上oracle的不归路…无非就几件事,时间换空间或者空间换时间、性能换冗余或者冗余换性能…angela女神只有在写技术干货的时候偶尔阅读偏低,但是质量不是盖的,别想那么多,可能就是换了个领导
    哈哈哈同为完全懵逼的非it行业读者。祝好。

  2. 黄子韬说道:

    一个对IT界完全不懂的人怎么就关注了你呢
    看了标题就猜是换领导……
    播客里的老高原来是高春晖,老是抢话啊
    等等,这留言也跟这篇文章没啥关系…
    也许可能是商业利益或管理层换帅也许说不定是技术营销手段!
    冠冕堂皇的理由背后往往都是政治原因哈哈

  3. 罗志祥说道:

    我工作过的公司有几个经历过这个,几个原因都有 1 领导下令 2 公司有钱有资源,几个牛人想爽一把refactor一下顺便用自己喜欢的技术(我本人喜欢postgres多些) 3 公司没钱没资源,但是小,数据量也小。有几个自我感觉感觉很牛的人觉得换了数据库就解决性能问题了(但是数据量在这个level上的性能问题基本上是应用设计的问题) 话说硅谷公司是不是用MySQL的多些(相对于Postgres来讲)?这样在应用层上加逻辑的经验应该也是MySQL的专家多些吧?

  4. 王子文说道:

    正看着这篇我就在想文末会不会有滴答滴答呢
    滴答滴答还不是大号?这曝光已经很高了
    不管写什么题材,其实我都会看,我看的是你的思维方式,,,有木有和我一个想法的小伙伴?好文,顺便个人感觉 troll 翻译成欺骗/蒙骗/逗更有感觉,参见 Wikipedia 词条 “internet trolling”,有种“你逗我吧”的意思

  5. 张曦予说道:

    Troll这个词很难翻译出来意境。可能更接近于喷子,但是在这也不准确。。逗又觉得“包含的恶意”不够。
    “架构相关的计算机科学领域无法就几件事”,有错字,无法——>无非
    以前公司是每隔几年就做数据割接,说是割接,有很大一部分数据迁移工作是把数据从一个表迁移到另一个结构基本相同但表名字段基本不同的表…理由就是有预算

  6. 美国队长说道:

    哈哈,其实就是老大为了KPI和评级,大公司这种事经常发生。
    经历过Facebook和Uber两个公司,在硬底子上真的是高下立判。Uber喜欢重复造轮子来回折腾,本质原因就是对现有的成熟方案没怎么研究就瞎用,然后得出结论说这个方案不好要自己做一套。
    这次吧 嘀嗒嘀嗒 写错了 哈哈哈哈哈

  7. 妩媚开心粑粑说道:

    听说专车一个月收入1w多,专车大概就比快车赚多一倍,你说的八九百那是没减去油费和滴滴扣掉的百分之二十吧。假如一天跑900块,4.5百公里绝对有的,2.0t的车在市区跑4.5百公里,一天下来油费至少300,利润减去成本,撑死500一天。

  8. 徐子淇说道:

    现在网约车司机空闲时确实拼,不眠不休地接单,安全隐患很大.使用uber叫车 司机并没接到我 也没发生任何行程 就直接扣取了费用 这跟直接骗取钱财并无二意 车辆在成为uber合作伙伴时 uber是否经过了层层审核 去网上查了一下 类似的事情还蛮多的 反馈给uber到目前为止还未收到任何反馈 做为消费者 这种网络直接扣取钱的诈骗行为 我们又该如何维权呢?

  9. 姚晨说道:

    做过优步司机,一个字:亏。经济和精神都亏。乘客平均一趟费用9块钱/7公里,优步提走20%,回来不一定有乘客,自己去算。除去油钱,不够填补车辆磨损折价和保养。稀饭钱是有的,前提是 不能有违章 擦挂事故等。如果你想冒着被罚款,给出几块钱买上帝感觉的人机会的话,去吧!本来就不应该人人打的起车!

  10. 姚mix小露说道:

    我tm已经无力吐槽你你们了,不经过我原手机号和邮箱就直接修改我的账户,然后用我的信用卡付款。从4月25日至今,都这么久了 你们解决什么了?今天才收到一封邮件,还是我天天追问的结果。并且我都无法登录之前的账户,无法解除信用卡绑定,银行也需要从你们这边解除。tm信用卡就一直冻结着?17

发表评论

邮箱地址不会被公开。 必填项已用*标注

您可以使用这些HTML标签和属性: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>