好了，那我们如何把上述的行程模型映射到Schemaless?

　　行程数据模型

　　使用 斜体字 标注UUID，大写字母表示column name，下表展示了我们行程数据存储的简化版的数据模型。我们有两个行程(UUIDstrip_uuid1 和 trip_uuid2) 以及四列(BASE, STATUS, NOTES, and FARE ADJUSTMENT)。一个格子表示一个cell，带有一个数字以及一个JSON的 (以{…}缩写)。格子的覆盖代表不同版本 (也就是不同的ref keys)。

　　trip_uuid1 有三个cell：一个在BASE列，两个在STATUS列，FARE ADJUSTMENT列没有内容。trip_uuid2的BASE列有两个格子，NOTES列有一个，同样的FARE ADJUSTMENTS列也没有内容。在Schemaless中，列没什么不同;每列的语义都由应用层定义，本例中是 Mezzanine。

　　在Mezzanine中，BASE列的cell包含了行程的基础信息，比如司机的UUID和行程的时间。STATUS列包含行程现在的支付状态，每次我们尝试对行程支付的时候都会插入一个cell (由于信用卡额度不足或者逾期等问题尝试可能失败)。如果司机或者Uber的DOps(司机调度员)有行程相关的备注，会在NOTES列添加一个cell。最后的FARE ADJUSTMENT列的cell记录了行程价格的调整。

　　我们如此划分列是为了避免数据冲突 而且最小化更新时需要写的数据量。BASE列在行程结束时写入，基本只会写一次。当行程开始尝试支付的时候开始尝试写STATUS列，此时BASE已经写好了，如果支付失败可能会写多次。相似的NOTES列在BASE列写过后的一些节点可能会写多次，但是与STATUS列的写操作完全独立。类似的FARE ADJUSTMENTS列只在行程费用变更时会写，例如路况不好等原因。

　　Schemaless触发器

　　Schemaless的一个重要特性是触发器，提供了在Schemaless实例变更时可获得通知的能力。由于cell是不可变的，以及新的版本是追加的，所以每个cell都代表了一个修改或者一个版本，这允许一个实例的值变更可以像日志一样查看变化。对于一个给定实例，可以监听这些变化以及触发基于这些变化的函数，非常像类似Kafka这种事件总线系统。Schemaless的触发器使Schemaless成为一个完美的真实来源的数据存储，因为除了随机访问数据，下游的依赖可以运用触发器功能来监听并触发任何应用侧特定的代码(与LinkedIn’s的 DataBus类似)，进而实现数据创建与数据处理的解耦。