Schemaless:Uber基于MySQL的可扩展数据库(一)

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-gather方式来查询所有节点;我们用过的一些系统是单集群的,不提供面向用户的在线流量,并在连接服务时有各种各样的运营问题。

最终,我们决定着重考虑运营可靠度的问题,因为里面会包含trip数据的关键任务。可选方案理论上也许是可靠的,但我们是否掌握相关知识,能否立即发挥其最大功效,在很大程度上决定了我们开发自己的解决方案。不仅根据我们所使用的技术,还因为我们在团队中的经验。

应当注意,我们针对这些系统的调研持续了2年多,其中并没有适用于trip存储用例的。现在,在我们基础架构的其他部分采用了Cassandra和Riak,并在生产环境中服务于数百万用户。

在Schemaless中我们相信

在我们的时间表中,上述选项中没有一个能满足我们的需要,于是我们决定自行构建一个尽可能便于运行,又吸取了别家扩展经验的系统。设计的灵感来源于Friendfeed,运营方面的侧重点受到Pinterest的启发。

最终我们构建了一个键值存储库,可以存放JSON数据而无需严格的模式验证,完全的无模式风格(点题)。有一个只扩展分片MySQL,在MySQL主服务器故障时支持缓存写入,并有一个数据变更通知的发布-订阅功能(命名为trigger)。最后,Schemaless支持数据的全球索引。下面我们对这个数据模型还有一些关键功能进行概述,包括一个trip的剖析,更深入的例子会放在后面的一篇文章中。

Schemaless数据模型

Schemaless是一个只扩展的稀疏三维哈希表持久化实现,非常类似谷歌的Bigtable。在其中最小的数据实体被称为cell,是不可变数据。一旦写入,无法被覆盖或删除。而cell是一个JSON blob,被row key和column name引用,引用值被称为ref key;row key是一个UUID,column name是一个字符串,ref key是一个整数。
可以将row key想象成关系数据库中的一个主键,将column name当作一个列。但在Schemaless中,没有预定义或执行模式,每行无需分享column name;事实上column name完全由应用所定义;ref key用来指定row key和column的cell版本。因此如果一个cell需要更新,可以用更高的ref key写入一个新cell,最新的cell就是ref key最高的那个。ref key也可以用在列表的条目中,不过通常用于标注版本。通过应用程序决定使用哪个架构。

一般应用将相关数据按照列相同来分组,然后每列的所有cell应用端的架构基本相同。这种分组是很好的办法,可以将数据批量修改,并允许应用快速修改架构,而无需数据库停机。下面的实例阐述了更多相关内容。

实例:在Schemaless中的trip存储

在深入之前,我们看一下Uber中一个trip的剖析。Trip数据在不同的时间点生产,从上车下车到付费,这些不同的信息是异步的,伴随着旅客发送反馈,或者后台处理。下面的图标是一个简单的流程图,包含了一个Uber trip的不同部分:

图片描述

这张图表展示了我们trip流程的简化版本。*代表这部分是可选的,可能已经出现多次。

一个trip由乘客发起,司机接受,包含开始与结束的时间戳。该信息包含了基本的trip,从中我们计算trip的花费(费用),也就是司机的收费。在trip结束后,我们可能得调整费用,与司机产生或借或贷的关系。可能会添加备注,从乘客或司机处发出反馈(在图表中以星号标注)。或者在第一个过期或支付失败后,可能需要尝试从多个信用卡中选择付款。这个流程是一个数据驱动的过程。随着有可用或新增数据,执行特定流程。信息中的某些,比如乘客或司机评价可以在trip结束后数天后进行。

因此,我们如何将上述trip模型映射到Schemaless中?

Trip数据模型

用斜体代表UUID,上标代表column name,下面的表格显示了一个trip简化版的数据模型。我们有2个trip(UUID分别是trip_uuid1和trip_uuid2),还有4个colume(BASE、STATUS、NOTES、FARE ADJUSTMENT)。一个cell用一个方框代表,包含数字和JSON blob(以 {…}缩写)。叠放的方框代表版本(即不同的ref key)。

图片描述

trip_uuid1有三个cell:BASE列有一个,STATUS列有2个,FARE ADJUSTMENT列为空。trip_uuid2在BASE列有2个cell,NOTES列有一个,FARE ADJUSTMENT也是为空。对于Schemaless来说,这些列没什么区别;因此每列语义由应用来定义,在本例中是Mezzanine服务。

在Mezzanine中,BASE列的cell包含基本的trip信息,比如司机的UUID,trip时间。STATUS列包含trip的当前支付状态,我们在其中为每次支付插入一个cell,来支付trip。如果信用卡金额不足或者过期,支付会失败。 NOTES列包含一个cell,方便司机记录任何与trip关联的备注,或者Uber的DOps(雇佣司机)来记录。最后,FARE ADJUSTMENT列包含的cell用在trip费用修改的时候。

我们用这列避免数据冲突,并将需要在更新中写入的数据数量尽可能减到最少。BASE列在trip结束后写入,这样一般只用一次。STATUS列在尝试支付时写入,即在BASE列写入后才写入,而且可以在支付失败时执行多次写入。某种情况下,NOTES列也可以执行多次写入,也发生在BASE列写入之后,不过与STATUS列写入是完全分离的。类似的,FARE ADJUSTMENT列在trip费用变更后只会写入一次。

Schemaless Trigger

Schemaless的关键功能在于trigger——可以在Schemaless实例变更时获得通知。由于cell是不可变的,新版本只能添加,每个cell也代表一次变更或一个版本,因此实例中的值可视为一个变更日志,针对指定的实例,可以监听这些变化,或针对它们触发功能,很像Kafka这样的事件总线系统。

Schemaless trigger让Schemaless成为一个完美的来源真实数据库,因为除了随机访问数据,下流依赖也可以通过trigger功能来监听并触发任何应用特定代码(类似LinkedIn’s DataBus系统)。

在其他用例中,Uber在BASE列写入Mezzanine实例时,使用Schemaless trigger来支付trip。针对上面的实例,一旦trip_uuid1的BASE列有数据写入,我们的支付服务触发BASE列找到这个cell,尝试通过信用卡支付trip。支付结果无论是成功还是失败,都会返回Mezzanine,写入STATUS列。这种计费方式与trip创建相分离,而Schemaless扮演了异步事件总线。

图片描述

轻松访问索引

最后,Schemaless支持在JSON blob字段的索引定义。通过这些预定义字段执行索引查询,找到匹配查询参数的cell。这种索引查询非常高效,因为只需访问单个片区,找到要返回的cell组。事实上,查询可以进一步优化,因为在Schemaless中,索引可直接使用非规范化的cell数据。在索引查询中,非规范化数据代表着只需查询一个片区,便可查询并取回信息。事实上,我们通常推荐Schemaless用户在可能需要用到索引的部分中都使用非规范化数据,以防需要直接用row key查询并取回cell。在某种意义上,这样一来我们用存储交换来了快速查询的性能。

举个Mezzanine的例子,我们通过定义的二级索引可以找到指定的司机trip。我们将trip的创建时间与城市作为非规范化数据。这样就能按照指定的时间范围,找到某个城市中某个司机所有trip。下面我们用YAML格式定义driver_partner_index,作为trip数据库的一部分,定义在BASE列(实例中有注解)。

table: driver_partner_index # Name of the index.

datastore: trips    # Name of the associated datastore

column_defs:

 – column_key: BASE # From which column to fetch from.

   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的trip。在实例中,我们只用了BASE列的字段,不过Schemaless支持多个列的非规范化数据,相当于上面column_def列表中的多个条目。

就像刚才提到的,基于分片字段通过分片索引,Schemaless的索引可以达到很高的效率。因此对索引的唯一需求就是,索引中其中一个字段指定为一个分片字段(在上面的实例中是driver_partner_uuid)。这个分片字段确定了分片索引条目应当写入或取回。原因是,我们需要在查询索引时提供分片字段。也就是说在查询时,我们只需查询一个分片,就能取回索引条目。要注意:分片字段应当有一定的分布率。UUID最好,城市id次优,状态字段(enums)不好。

除此之外,Schemaless还支持equality/non-equality filtering和范围查询,并支持在索引中选择字段的子集,为索引条目指向的row key检索特定或所有的列。目前,分片字段必须是不可变的,因此Schemaless只需与一个片区对话。不过我们正在探索方法,找出如何在没有太大性能开销的情况下,让它成为可变的。

索引最终都是一致的;无论何时写入cell,都需要更新索引条目,不过不会在同一个事务中进行。一般来说,cell和索引条目不属于同一个片区。因此,如果我们打算给出一致的索引,就需要在写入时引入2PC,会带来很大的开销。最终,在索引一致且避免开销的情况下,Schemaless用户可能会在索引中看到旧数据。大多时候,cell变更与相应索引变更之间的延迟远远不到20毫秒。

总结

我们概述了数据模型、触发器和索引,这些都是定义Schemaless的关键功能,也是我们trip数据库引擎的主要组件。在后面的文章里,我们会看些Schemaless的其他功能,证明在Uber架构中这是一个多受欢迎的系统:更多内容将在架构上,作为存储节点的MySQL使用上,还有我们如何让客户端的触发容错上。

原文地址:DESIGNING SCHEMALESS, UBER ENGINEERING’S SCALABLE DATASTORE USING MYSQL(译者/孙薇 责编/仲浩)

Comments are closed.