淘宝买卖家问题:订单号后四位的秘密

梦实
  • 收获赞:3
  • 擅长领域:这个同学很专业,但是有点神秘哟~

打开手机淘宝,查看您的订单编号,您会发现一个有趣的现象……本文教您如何使用PolarDB-X全局索引来解决淘宝买卖家问题的多维度查询。

淘宝订单号中的秘密

有一个很有趣的事情。

打开你的淘宝客户端或者PC端的淘宝,点开订单列表,打开几个订单,查看他们的订单号,你会发现什么?

比如这是我最近的3个订单,和10年前的3个订单。其订单号分别是: 1249511065364414810 1238822988656414810 1236446127134414810 103698817404810 107655289504810 103719620094810

也许你会惊奇的发现,订单号的后几位好像是一样的。比如我的账号,从10年前到今天,订单号的后四位一直是4810,那么为什么?这个其实和使用分布式数据库的一个最佳实践相关。

经典的买卖家例子

好多年前就流传着淘宝买卖家的案例...

淘宝中有一个非常重要的表,订单表,他里面存着订单的一些关键信息,例如订单号(order_id)、卖家ID(seller_id)、买家ID(buyer_id)、商品ID等等。有两类查询是这个表上的高频查询:

select * from orders where buyer_id = ?

select * from orders where seller_id = ?

这两个SQL的业务含义一目了然,分别是买家查询自己的订单列表和卖家查询自己的订单列表。

如果我们在单机数据库中做这两条SQL,都知道怎么做。嗯,在buyer_id和seller_id上分别建个建索引就可以了:

create index idx_buyer_id on orders (buyer_id);

create index idx_seller_id on orders (seller_id);

在数据库中,空间换时间是一个非常基本的思路,例如加索引。

如果你是用一些分库分表中间件,例如MyCAT之类的产品,对这个表做了分库分表,就需要面临一个跟单机数据库完全不一样的一个问题,该如何选择分库分表键?

一般此类中间件都会告诉你,你哪个列查的最多,就选哪个列做拆分键,例如MyCAT的最佳实践:

但问题来了,这两类SQL都很高频,选了buyer_id做分库分表键,那按seller_id查就会全库全表扫描;如果按seller_id做分库分表键,那按buyer_id查就会全库全表扫描。

难道鱼和熊掌不可兼得?

一般解决这类的问题的方案是,使用两套订单表,其中一套使用buyer_id做分库分表建,另一套使用seller_id做分库分表键,中间使用binlog来做同步,类似下面的样子:

这个方案是OK的,能够落地的,只不过做的过程会有些小痛苦要解决,例如:

  1. 这个同步怎么搞啊...,用开源的binlog订阅组件比如canal吗?那这个canal怎么运维啊...好烦

  2. 这个同步是有延迟的,延迟代表了数据死不一致的,应用需要有一些容错机制来避免不一致带来的影响,好烦+1

  3. 需要在业务里自己控制应该访问哪个表,好烦+2

  4. 分库分表下面有很多的mysql,要同时同步这么多的mysql...,好烦+3

  5. 做DDL要有些技巧,比如加列先加目标端,减列先减源端...,很多的潜规则,好烦+4

  6. 这才是一张表呢!我有一堆类似的场景怎么办!!好烦+10086

我们先不管这些缺点,假设我们已经这样做到了,我们成功的解决了买卖家订单问题。

买卖家问题进阶

我们现在又有了一个新的要考虑的SQL:

select * from orders where order_id = ?

这个SQL作用太简单了,根据订单ID查订单详情嘛!

为了做这个SQL,单机里给order_id建索引即可,分库分表应该怎么做?

抢答一个!把订单表再复制一份,使用order_id做分库分表键。

听起来可以,应该能解决问题。但是,这个表多复制一份,就是多一份的代价,比如空间,比如同步链路的维护。所以,有没有更好的方法?

我们能关注到一个事情,订单id,是由我们程序控制生成的。在生成订单的时候,我们一定知道它的买家id,假如我们将买家id隐藏在订单id里,有了订单id就能算出买家id,有了买家id就可以去查买家维度的订单表了。

这样,我们还是只需要存两份数据(买家维度和卖家维度),就能同时解决三个维度的查询(买家维度、卖家维度、订单维度)。

所以现在应该明白了,为什么同一个人的淘宝订单后4位是相同的了吧。

小花絮:

我发现我11年7月10的订单号还是4810结尾,但11年6月28号及之前的订单并没有遵循这个规律。呃...这说明,淘宝应该是在11年的6.28-7.10之间做了这个优化。

PolarDB-X中如何实现

OK,回到我们的云原生分布式数据库PolarDB-X。

如果我们在PolarDB-X中要解决上述买卖家问题,应该怎么做?

答案是,我们只需执行以下几条SQL即可:

create partition table orders (order_id primary key)

create clustered index idx_buyer_id on orders (buyer_id);

create clustered index idx_seller_id on orders (serller_id);

然后?没有然后了啊,这就可以了。

真的可以了,你不用改SQL,不用研究Canal(其实canal作者就坐我旁边,要考虑下来玩玩吗),不用维护同步链路,不用担心数据不一致,就O!K!了!

至于按订单id查?订单id本来就是orders的主键,默认就是orders表的分区键,所以没问题的。

这么简单就OK了?为什么?

PolarDB-X中的全局索引

这两条语句发生了什么?实际上,他们在orders表上,创建了两条全局索引。全局索引和单机索引的原理差不多,也是空间换时间的思想,只不过它的数据以索引的key分布在整个集群中。

全局索引的创建、维护,都在PolarDB-X内核中完成的,完全不需要用户去操心。 其实现原理请关注我们后续的文章,会专门来介绍,这里就不展开了。

有一个小问题,建索引的语句里面,有个clustered关键字,这是什么意思?

我们先看,如果不加clustered,会发生什么,例如:

create index idx_buyer_id on orders (buyer_id);

主表:

PolarDB-X会定义这样的一个索引结构:

这个索引中,会包含索引的key以及主键两个列,也即order_id与buyer_id。

PolarDB-X在执行select * from orders where buyer_id = ? 的时候,会先根据buyer_id在索引idx_buyer_id上扫描出order_id,再使用order_id到主表上进行回表操作。

听起来好像没有什么问题。

但是,有一点需要考虑。请打开你的订单列表,看一下,你有多少订单:

呃...,我有126页订单,数了下,每页15个,也就是大约1800个订单。

淘宝的订单表的分区数大约是数千这个量级,你会发现,这1800个订单的回表,要覆盖相当比例的分区,似乎跟全表扫描的代价没有什么太大的差异了。

怎么办?

我们为什么要回表?其实是因为,我们的查询是SELECT *,需要这个表所有的列,而我们的索引里只包含了索引key和主键,因此需要到主表中找到剩下的列。

所以为了不回表,我们想到的一个办法,是在索引表中冗余主表的所有列,用更多的时间来换取空间。

所以,一个合格的分布式数据库,不仅需要有全局索引,还需要有聚簇的(clustered)全局索引

Clustered index就是PolarDB-X中的概念,它相对于普通的全局索引的区别就是,它包含了表的所有列,可以避免回表的代价。

PolarDB-X中如何实现进阶

上面的实现里,我们orders表有三个索引(主键order_id,buyer_id,seller_id),能否使用一些技巧干掉其中一个呢,其实也是可以的。直接贴demo,相信你肯定能明白:

create table orders (order_id primary key)  partition by hash(buyer_id);
create clustered index idx_seller_id on orders (seller_id);

select * from orders where buyer_id=?   //主表
select * from orders where seller_id=?   //idx_seller_id
select * from orders where order_id=? and buyer_id=substr(?, 0, 10)  //使用order_id算出buyer_id

小结

OK,总结几条这个例子告诉我们的PolarDB-X的最佳实践:

  1. 使用全局索引来解决类似买卖家问题的多维度查询的问题

  2. 当索引与主表是一对多的关系的时候,考虑使用clustered index来消灭回表的代价

  3. 巧妙设计一些列(例如订单id),有时可以节省一些空间

怎么样,PolarDB-X用起来是不是非常简单,欢迎持续关注我们,我们正在写全局索引的详细原理介绍(我去催下稿)。

文档来源:https://polardbx.com/realTimeInfoDetail?id=dzVWnKyObp