关于Uber选择MySQL的思考

在数据库圈子，大家都知道2016年 Uber 干出来一件大事件，把 PostgreSQL 切换到了 MySQL，当时社区里一阵喧哗。这里想带着大家思考一下选择的背后。

在该事件中，Uber 提出来迁移的一个重要原因是：在大量更新的业务场景下 PostgreSQL 的 IO 方面有过多的开销（主要是从存储结构上说明），对于使用 SSD 或是 PCI-E 卡的设备基本无法容忍写放大，同时又提出了以下需求：

• 需要有写缓冲能力，万一持久化到数据库失败时，仍可以稍后重试。
• 需要通知下游依赖关系的方式，数据变更要能无损的通知出去。
• 需要二级索引。
• 系统要足够健壮，可以支持 7X24 服务。
• 最重要一点，需要 SchemaLess 的存储支持
• 要有能力通过增加服务器动态扩容。增加服务器不但要增加可用的硬盘容量，还要减少系统的响应时间。

Uber 针对这些需求也和其它互联网厂家一样，尝试过Cassandra， Riak，MongoDB，也想过自研，但最终选择了MySQL 作为存储层。 这里反问一下： MySQL 能满足上面的需求吗？ 例如：

• SchemaLess 存储支持
• 写缓冲能力，较快的故障切换
• 较好的扩容能力

大家的印象里第一条 Schemaless 都可以把MySQL秒了，但从文章里看 Uber 技术负责人：Jakob Thomsen 最终使用了 MySQL 做 Schemaless 存储方案。我的神啊，大家没看错，就是使用的 MySQL 做的 schemaless 存储方案。

带着好奇心驱动，再来看一下 MySQL，你会发现从 MySQL 5.7 引入了两个重量级的特性，正好符合 Uber 的需求：

• DocumentStore
• X-协议

下面分别说明一下：

1. DocumentStore 从 MySQL 5.7 后可以认为 MySQL 也开始 NoSQL 了，支持 json 类型，加入更多的 json 支持 。感受一下：

支持 CRUD 等传统 SQL 操作。为了更好的支持 NoSQL 接口,在此基础又推出了另一个重量级的协议:X-协议。以及围绕着推出一堆的 mysqlsh ,各种程序的 Driver。如果你现在还不去了解,可能很快就 Out 喽

1. X-协议 全新的协议, 减少交互开销， 减少消息大小，支持管道处理，支持通知处理 对 NoSQL 支持更友好，更丰富的数据处理接口，考虑到数据 Sharding 实现 更高速的 Query 响应

上面这两个功能也是 MySQL 8.0 要重点发力的两个功能。知识更新很快，如果还不知这两个的特性的朋友，要抓紧时间更新一下知识了。MySQL 开始要发威了，最近更新非常的快。

也正是这两个特性，正好满足 Uber 的需求，基于 NoSQL 接口存储，底层数据保障使用 MySQL 的 Replication 复制（MySQL Group Replication 马上也 GA 了）。在 NoSQL 接口层很容易做到数据的拆分及路由设制，底层复制又较好的保证的数据可用安全性。

MySQL 已经不是当初的那个关系型数据库了,现在有更多特性需要你去深入挖掘。