4、 我们需要副索引。由于我们是从Postgre迁移的，那新的存储系统需要支持Postgre的索引，会按照习惯用副索引搜索行程数据。

　　5、我们需要运维够信赖的可靠系统，因为其中包含了行程数据的关键任务。如果凌晨3点我们接到叫车请求，但是这时数据存储无法响应查询，导致业务宕机，我们是否有相关操作知识可以快速解决这个问题。

　　鉴于以上种种，我们分析了几种常用的选择的优势和潜在的限制，比如Cassandra、Riak、MongoDB等。出于说明的目的，我们提供了如下图表，展示了不同系统选择下的不同功能组合:

　　所有的三个系统都可以通过在线增加节点线性扩容，只有一对系统可以在宕机时收到写操作。所有的解决方案中都没有内置的方式将变化通知下游依赖，因此可能需要在应用层实现该功能。它们都索引功能，但是如果你想索引多个不同的值，查询会变慢，因为他们使用分散查询并聚合结果的方式查询了所有节点。最后对于其中的一些系统有过单集群的使用经验，但不提供面向用户的在线流量，而且在我们的服务连接的时候有各种各样的运维问题。

　　最终我们的确定运维信赖为主要因素，因为它包含了行程数据的关键任务。 可供选择的解决方案理论上可能都是可靠的，但是我们是否有运维的知识来立即发挥其最大功效，基于此我们决定基于Uber的使用情况开发自己的解决方案。这不仅基于我们使用的技术，而且根据成员的经验。

　　需要注意的是我们对这些系统的研究持续了两年，没有发现适合行程数据存储的，但是我们已经在其它领域成功接受了Cassandra与Riak作为我们的基础服务，而且在生产环境使用这些为数百万级的用户提供服务。

　　在Schemaless中我们相信

　　由于以上的所有选择在规定的时间内都不能完全满足自己的需求，我们决定构建我们自己的系统使运维尽量简单，也参考了其它厂扩容的经验。这个设计的灵感来自于Friendfeed，运维的方面则参考了Pinterest。

　　最后我们决定构建一个键值存储，允许存储任何JSON数据而不需要严格的格式验证，一个非结构化的模式(命名的由来)。这是一个只扩展分片的MySQL， master节点都带有写缓冲在应对MySQL宕机，数据变更通知是一个订阅-发布的功能，我们称之为trigger。最后，Schemaless支持全局数据索引。下面我们将讨论一下数据模型概览以及一些关键特性，包括剖析Uber的一份行程数据，更深入的例子保留在接下来的文章中。