正文
在我看来，Uber 的文章基本上在说他们发现 MySQL 比 PostgreSQL 更适合他们的环境。然而，原文在传递这一消息时却表现的非常差劲。举例来说，原文并没有写“ PostgreSQL 在 update-heavy 的使用场景下有一些局限”，而是写到“它对于写入（write）来说是一个非常低效的架构”。当你没有 updata-heavy 的使用场景时，不必担心 Uber 的文章中描述的问题。
在本文中，我将会解释：①为什么我认为 Uber 的文章并不能作为我们在选择数据库的一个普适性建议，②为什么 MySQL 仍旧适用于 Uber，③为什么这样的成功迁移案例可能会引起更多的问题，而不是扩展了数据库。
在更新方面的问题
Uber 的文章所出现的第一个问题是， 在更新表中的行时，PostgreSQL 通常需要更新表上的所有索引，原文对这方面做了大篇幅的描述，但细节又不够充分。另一方面，对于具有 InnoDB 的 MySQL 来说，只需要更新那些包含有更新列的索引。在更新改变了非索引列之时（原文中的「Write Amplification」部分），PostgreSQL 的方法需要占用更多的磁盘 IO。如果这对 Uber 来说是一个大问题，那这些更新对于他们来说，或许是其整个工作量中的很大一部分。
然而，我有一些猜测，是 Uber 文章并没有提到的。原文并没有提及 PostgreSQL 的 Heap-Only-Tuples( HOT )。从 PostgreSQL 源码来看，HOT 对于一些特殊场景非常有用，即“当一个元组进行了重复更新时，不需要对它的索引列进行更新”。在这个场景中，如果新的行版本能够和之前的版本存储在同一个页面中，PostgreSQL 能够做出一些不需要触及任何索引的更新。后一种情况可以使用 fillfactor 来进行调谐。假设 Uber 的工程认为 HOT 不能够解决他们的问题，是因为这些频繁的更新影响了不止一个索引列。
这个假设也在文章中的下列语句得到了支持：“如果我们有一张定义了十几个索引的表，那么只覆盖了一个指标的领域的更新就必须涉及到整整12个指标来反映新的行中的 ctid ”。它明确地指出“只覆盖了一个指标，”只有一个索引这是一种极端情况，否则 PostgreSQL 的 HOT 是可以解决这一问题的。
【旁注：我比较关心他们所拥有的索引的数量能否减少— index redesign 是我的一个挑战。无论如何，对于那些使用的很少但在使用时又非常重要的索引来说，这是完全有可能的。】
看起来他们似乎运行着许多更新，这些更新改变了不止一个索引列，但这和表中所有索引相比来说，这算不上啥。如果这是一个主要的用例，那么原文建议用 MySQL 来取代 PostgreSQL 就能够说得通了。
关于 Select 的问题
还有一个关于他们用例的声明引起了我的注意：原文解释了 MySQL/InnoDB 使用了 clustered indexed ，并且承认了“这种设计意味着在做二次关键值查找时和 Postgres 相比 InnoDB 的优势并不明显”。关于这个问题（the clustered index penalty），我之前写过在 SQL Server 环境下的文章。
他们写到 clustered index penalty 的优势很小，这引发了我的兴趣。在我看来，当你运行了很多使用二次索引的查找时，这个优势是很大的。如果对于他们来说这总种优势很小，那这可能说明这些索引使用得很少。这将意味着他们在大多数情况下使用了 primary key 来进行查找（那么就不需要付出 clustered index penalty 了）。注意我写的是“查找”而不是“选择”。这其中的原因在于 clustered index penalty 会影响具有 where 字句的声明，而不仅仅是选择。这也意味着高频率的更新大多基于primary key。
