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

下面来说背景。昨天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过，以保证它的准确性。点阅读原文可以看这个漫画连载。

参考备注

• 标题图：来自《架构师成长之路》漫画。

• WHY UBER ENGINEERING SWITCHED FROM POSTGRES TO MYSQL  https://eng.uber.com/mysql-migration/

• THE ARCHITECTURE OF SCHEMALESS https://eng.uber.com/schemaless-part-two/

本文来自霍炬的微信公共帐号“歪理邪说”，用微信添加 wxieshuo 公众号，或扫描二维码即可订阅。转载必须保留作者、公共帐号信息，内容必须与本文保持严格一致，不得修改/替换/增减本文包含的任何文字，不得擅自增加小标题、引语、摘要等。本公众号一切内容禁止摘编、衍生及演绎。