fields: # The fields in the cell to denormalize

　　– { field: driver_partner_uuid, type: UUID}

　　– { field: city_uuid, type: UUID}

　　– { field: trip_created_at, type: datetime}

　　使用这个索引，通过筛选city_uuid或者trip_created_at，我们能够找出指定driver_partner_uuid的行程。在这个例子中我们只用到BASE列的中的字段，但是Schemaless支持从多个列中非标准化数据，相当于上面column_def列表中的多个实例。

　　像上文提到的Schemaless高效的索引得益于基于分片字段将索引分片。因此一个索引的唯一需求是索引中有一个字段是分片字段(例如上例中最先给出的driver_partner_uuid)。该分片字段决定了索引实体应该在哪个分片写入或者读取。原因是我们在查询索引的时候需要提供分片字段。这意味着在查询时，我们只需要查询一个分片来获取索引实体。关于分片字段有一点需要注意的是要选一个分布好的字段。UUID最佳，其次是city ids，不要选状态字段(枚举值)。

　　除分片字段外，Schemaless还支持相等、不等以及范围查询的过滤器，同时支持只查询索引字段的一个子集以及根据索引实体指向的row key获取特定列或所有列。现在分片字段必须是不可修改的，因此Schemaless只需跟一个分片交互，但是我们正在探寻如何在没有太大性能开销的情况下让他成为可变的。

　　索引具备最终一致性，无论何时我们写入一个cell，我也更新这个索引实体，但是这不发生在同一个事务中。Cell与索引实体通常不在同一个分片上，因此如果我们想要提供一致的索引，就需要在写入操作中引入 2PC ，这会明显加大开销。通过最终一致性的索引，我们避免了这项开销，但是Schemaless的用户可能会看到过期的数据。多数情况下cell变化与相关索引变化之间的延迟能控制在20ms之内。

　　总结

　　我们给出了一个数据模型、触发器以及索引的概览，这些都是Schemaless的关键功能，我们行程存储引擎的主要组成部分。在后续的文章中，我们将看到一些Schemaless的其它特性来阐明在Uber的基础设施中，它是如何成为服务的好伙伴的：更多的架构，使用MySQL作为一个存储节点，以及我们如何使触发器在客户端成为可容错的。