Uber 系统从 Postgres 迁移到 MySQL

Uber 最近在博客中详细阐述了他们为什么要使用MySQL 来替代PostgreSQL 。Uber 遇到的主要困难源于Postgres 的写入放大问题。写入放大是在对涉及索引的单行数据进行更新时，需要更新所有的索引，从而导致大量对磁盘的写操作，在使用固态硬盘时这个问题更加严重。 HOT(Heap-Only-Tuples) 特性可以缓解这个问题，这在一些用例中也许是一个解决方案。因此，写入放大问题泄漏到了复制过程中，造成为了一些简单的更新而在副本间传播多个更新操作。在灾难恢复的场景中，由于数据中心之间可能相距较远，并且无法获得廉价、便利的带宽，就会导致重大问题。

在 Postgres 9.2 的一次常规更新中，一个 bug 导致了一些表的数据损坏。这是由于没有标记一些应该被标记为不活跃的数据所导致的。无法计算这个 bug 这所影响到的数据总数，而且由于复制是发生在物理层，这也就存在着损坏数据库索引的风险。

Postgres 的副本并没有真正支持多版本并发控制（MVCC）。副本必须和主节点使用一致的预写式日志（WAL: Write Ahead Log ）。加上如果更新操作涉及其他事务中已打开的行，Postgres 会将其阻塞，这在很大程度上会影响长事务（long running transaction）。一旦长事务阻塞了预写式日志线程，就会被 Postgres 终止，如果应用开发人员没有意识到这点，特别是在使用事务边界不透明的对象关系映射（ORM）时，就会带来问题。

再一次由于复制过程是工作在物理层，数据库更新不得不在所有副本间同时进行，不然复制无法正常工作。这意味着就 Uber 的规模来说，升级到当时的新版本真的会造成很多问题。这个问题已经自 9.4 版本之后使用 pglogical 修复了。

在决定 Uber 案例的设计方案时，设计者看重 MySQL 的优势有：拥有灵活的副本、每个连接使用轻量级的线程而不是进程、廉价的缓存。应对磁盘存储上的主要问题，则使用 InnoDB 存储，使压缩更高效而不会影响大量索引或引起 Postgres 中的写入放大问题。

Markus Winand 、 Simon Riggs 和 Robert Haas 针对 Uber 用例提出了一些很好的反驳。他们详细阐述了在诸多用例中如何解决上述问题，以及为什么并不是对每个案例都应该抛弃 Postgres 而使用 MySQL，反之亦然。

查看英文原文： Uber Engineering Moving from Postgres to MySQL

感谢百占辉对本文的审校。

给InfoQ 中文站投稿或者参与内容翻译工作，请邮件至 editors@cn.infoq.com 。也欢迎大家通过新浪微博（ @InfoQ ， @丁晓昀），微信（微信号： InfoQChina ）关注我们。