Schemaless：Uber基于MySQL的可扩展数据库（一）

Mezzanine项目描述了我们如何从单独的Postgres实例中将Uber的核心trip数据提取出来，就成了Schemaless这个具备容错性和高可用性的数据库。本文进一步描述了Schemaless的架构，及其在Uber基础结构中的详细角色，以及它如何成为这样的角色。

我们关于新数据库的努力

2014年初，由于业务增长迅猛，我们的数据库空间终告耗尽。随着扩张，每次新入驻城市，每次里程增长形成里程碑都将我们推向险境，直到我们发现，到年末Uber的基础架构将无法继续发挥功用：Postgres没办法再存储trip数据了。我们的使命是实现Uber的下一代数据库，这个任务花了数月时间，将近快一年，全世界有多个办公室的多名工程师参与了这项任务。

不过首先，在大量商用与开源可选方案存在的情况下，为什么还要自己打造一个可扩展数据库呢？对于新trip数据库，我们有五个关键的要求：

• 新的解决方案要有能力通过增加服务器而线性地增加容量，这是原有的Postgres所缺乏的。增加服务器不但要增加可用的硬盘容量，还要减少系统的响应时间。
• 需要写入能力。之前我们曾用Redis实现了一个简单的缓存机制，因此如果写入Postgres的做法失败的话，可以稍后再重试，因为trip在Redis中有缓存备份。不过用Redis时，trip无法从Postgres中读取，没有类似计费之类的功能。很烦人，不过至少数据没丢。随着时间推移，Uber成长起来，我们基于Redis的解决方案无法扩展。Schemaless必须支持类似Redis的机制，不过最好包含写入功能。
• 需要通知下游依赖关系的方式。在现有系统中，我们同时处理多个trip组件，比如计费、分析等。这个过程很容易出错：如果某一步出错，必须整个重来，即便有些组件已经成功处理。这将无法扩展，因此我们想要将这些步骤拆分成独立的步骤，由数据变更启动。我们确实有一个异步的trip事件系统，不过是基于Kafka 0.7的。由于不能无损运行，我们需要一个新系统，其中某些是类似的，但却可以无损运行。
• 需要二级索引。由于要从Postgres迁移过去，新的存储系统必须支持Postgres索引，也就是说在搜索trip时使用二级索引。
• 系统运营需要有可靠度，因为其中包含了trip数据的关键任务。如果凌晨3点我们收到叫车需求，而数据库无法响应查询并挂起业务，我们是否有相关的操作知识能快速修复问题呢？

鉴于以上因素，我们分析了常用可选系统（Cassandra、Riak、MongoDB等等）的优势与潜在的局限性。为了说明，下面将列出不同系统的功能差异：

这三个系统都能通过在线增加新节点，而执行线性扩展；其中二个可以在故障时接受写入命令；三个系统均缺少内置的下游依赖通知机制，需要借助应用层面实现；三者都包含索引功能，但如果针对不同的值进行索引，查询会很缓慢，因此使用了scatter-gat