怎么实现在海量分库分表数据中进行分页查询

有些头部电商的数据规模达到一定程度之后,比如淘宝或者美团的日订单量可能有几千万。在这样数据规模下,数据库面临很大的压力。通常,当数据库达到一定规模后需要对数据进行切分,对数据库或者表进行切分,有的需要纵向切分,有的需要横向切分。伴随着库表切分之后,对于数据库的查询就增加很大的难度,比如我们常会遇到分页查询。通常我们把分表使用的字段称作shardingkey,比如订单表按照用户ID,那么如果查询条件中不带用户ID查询怎么做分页?

一、唯一主键

一般我们数据库的主键都是自增的,那么分表之后主键冲突的问题就是一个无法避免的问题,最简单的办法就是以一个唯一的业务字段作为唯一的主键,比如订单表的订单号肯定是全局唯一的。

常见的分布式生成唯一ID的方式很多,最常见的雪花算法Snowflake、滴滴Tinyid、美团Leaf。以雪花算法举例来说,一毫秒可以生成4194304多个ID。

第一位不使用,默认都是0,41位时间戳精确到毫秒,可以容纳69年的时间,10位工作机器ID高5位是数据中心ID,低5位是节点ID,12位序列号每个节点每毫秒累加,累计可以达到2^12 4096个ID。

怎么实现在海量分库分表数据中进行分页查询

 

 

二、分表

第一步,分表后要怎么保证订单号的唯一搞定了,现在考虑下分表的问题。首先根据自身的业务量和增量来考虑分表的大小。

举个例子,现在我们日单量是10万单,预估一年后可以达到日100万单,根据业务属性,一般我们就支持查询半年内的订单,超过半年的订单需要做归档处理。

那么以日订单100万半年的数量级来看,不分表的话我们订单量将达到100万X180=1.8亿,以这个数据量级部分表的话肯定单表是扛不住的,就算你能扛RT的时间你也根本无法接受吧。根据经验单表几百万的数量对于数据库是没什么压力的,那么只要分256张表就足够了,1.8亿/256≈70万,如果为了保险起见,也可以分到512张表。那么考虑一下,如果业务量再增长10倍达到1000万单每天,分表1024就是比较合适的选择。

通过分表加上超过半年的数据归档之后,单表70万的数据就足以应对大部分场景了。接下来对订单号hash,然后对256取模的就可以落到具体的哪张表了。

 

怎么实现在海量分库分表数据中进行分页查询

 

那么,因为唯一主键都是以订单号作为依据,以前你写的那些根据主键ID做查询的就不能用了,这就涉及到了历史一些查询功能的修改。不过这都不是事儿对吧,都改成以订单号来查就行了。这都不是问题,问题在我们的标题说的点上。

三、C端查询

说了半天,总算到了正题了,那么分表之后查询和分页查询的问题怎么解决

首先说带shardingkey的查询,比如就通过订单号查询,不管你分页还是怎么样都是能直接定位到具体的表来查询的,显然查询是不会有什么问题的。

如果不是shardingkey的话,上面举例说的以订单号作为shardingkey的话,像APP、小程序这种一般都是通过用户ID查询,那这时候我们通过订单号做的sharding怎么办?很多公司订单表直接用用户ID做shardingkey,那么很简单,直接查就完了。那么订单号怎么办,一个很简单的办法就是在订单号上带上用户ID的属性。举个很简单的例子,原本41位的时间戳你觉得用不完,用户ID是10位的,订单号的生成规则带上用户ID,落具体表的时候根据订单号中10位用户ID hash取模,这样无论根据订单号还是用户ID查询效果都是一样的。

当然,这种方式只是举例,具体的订单号生成的规则,多少位,包含哪些因素根据自己的业务和实现机制来决定。

那么无论你是订单号还是用户ID作为shardingkey,按照以上的两种方式都可以解决问题了。那么还有一个问题就是如果既不是订单号又不是用户ID询怎么办?最直观的例子就是来自商户端或者后台的查询,商户端都是以商户或者说卖家的ID作为查询条件来查的,后台的查询条件可能就更复杂了,像我碰到的有些后台查询条件能有几十个,这怎么查???别急,接下来分开说B端和后台的复杂查询。

现实中真正的流量大头都是来自于用户端C端,所以本质上解决了用户端的问题,这个问题就解了大半,剩下来自商户卖家端B端、后台支持运营业务的查询流量并不会很大,这个问题就好解。

四、其他端查询

针对B端的非shardingkey的查询有两个办法解决。

双写,双写就是下单的数据落两份,C端和B端的各自保存一份,C端用你可以用单号、用户ID做shardingkey都行,B端就用商家卖家的ID作为shardingkey就好了。有些同学会说了,你双写不影响性能吗?因为对于B端来说轻微的延迟是可以接受的,所以可以采取异步的方式去落B端订单。你想想你去淘宝买个东西下单了,卖家稍微延迟个一两秒收到这个订单的消息有什么关系吗?你点个外卖商户晚一两秒收到这个订单有什么太大影响吗?

这是一个解决方案,另外一个方案就是走离线数仓或者ES查询,订单数据落库之后,不管你通过binlog还是MQ消息的都形式,把数据同步到数仓或者ES,他们支持的数量级对于这种查询条件来说就很简单了。同样这种方式肯定是稍微有延迟的,但是这种可控范围的延迟是可以接受的。

而针对管理后台的查询,比如运营、业务、产品需要看数据,他们天然需要复杂的查询条件,同样走ES或者数仓都可以做得到。如果不用这个方案,又要不带shardingkey的分页查询,兄弟,这就只能扫全表查询聚合数据,然后手动做分页了,但是这样查出来的结果是有限制的。比如你256个片,查询的时候循环扫描所有的分片,每个片取20条数据,最后聚合数据手工分页,那必然是不可能查到全量的数据的。

五、总结

分库分表后的查询问题,对于有经验的同学来说其实这个问题都知道,但是我相信其实大部分同学做的业务可能都没来到这个数量级,分库分表可能都停留在概念阶段,面试被问到后就手足无措了,因为没有经验不知道怎么办。

分库分表首先是基于现有的业务量和未来的增量做出判断,比如拼多多这种日单量5000万的,半年数据得有百亿级别了,那都得分到4096张表了对吧,但是实际的操作是一样的,对于你们的业务分4096那就没有必要了,根据业务做出合理的选择。

对于基于shardingkey的查询我们可以很简单的解决,对于非shardingkey的查询可以通过落双份数据和数仓、ES的方案来解决,当然,如果分表后数据量很小的话,建好索引,扫全表查询其实也不是什么问题。

  • 1
    点赞
  • 0
    收藏
    觉得还不错? 一键收藏
  • 0
    评论
### 回答1: 垂直分库分表指的是将一个大表按照数据类型或功能模块拆分为多个小表,分别存储在不同的数据库。 如果需要分页查询,可以使用 limit 和 offset 参数。例如: ``` select * from table limit 10 offset 20; ``` 这表示从第 21 条记录开始查询,查询 10 条记录。 如果分库分表后的数据不再存在于同一个数据库,可以使用分布式数据库系统,例如 sharding-jdbc,实现分页查询。 ### 回答2: 垂直分库分表是将数据库按照数据的类别或者业务进行划分,以减轻单个数据库的负载并提高系统性能。在垂直分库分表的情况下,如何进行分页查询是一个比较常见的问题。 在进行垂直分库分表后的分页查询,首先需要了解每个分库分表数据量和数据分布情况。根据具体的情况,可以选择以下几种不同的分页查询方法: 1. 单库单表分页查询:如果数据量比较小,可以直接在单个分库分表进行分页查询。通过使用LIMIT和OFFSET等数据库特定的语法,可以指定每页显示的记录数量和查询的起始位置。 2. 多库分页查询:如果数据量较大且分布在多个分库,可以进行多库分页查询。首先确定要查询的分页范围,即要查询的页数和每页显示的记录数量。然后,根据数据的分布情况,确定需要访问哪些分库,并在每个分库按照相同的方式进行分页查询。最后,将每个分库的查询结果合并并按照指定的顺序进行排序,得到最终的分页结果。 3. 跳跃查询:在某些特殊情况下,由于数据分布的原因,无法直接使用传统的分页查询方法。此时,可以通过跳跃查询的方式实现分页功能。跳跃查询是指通过在每个分库分表查询指定范围的数据,并在经过一定的处理后,得到最终的分页结果。 总体而言,垂直分库分表后的分页查询需要根据具体的情况灵活选择合适的查询方法。同时,还需要考虑分页查询的效率和性能问题,例如如何降低跨库查询的开销、如何利用缓存等。在实际应用,还需要根据实际情况进行性能测试和优化,以提供更好的用户体验。 ### 回答3: 垂直分库分表后的分页查询通常有两种方法。首先是在应用端进行分页查询,其步骤如下: 1. 计算每个分片的数据量:首先需要获取每个分片内的数据总量,可以通过统计每个分片的记录数量来获得。可以通过连接每个分片的元数据来查询。 2. 计算每个分片需要查询的页数:根据所需的总记录数和每页显示的记录数,可以计算每个分片所需查询的页数。例如,如果总记录数为1000,每页显示10条记录,则每个分片需要查询100页。 3. 在每个分片内进行分页查询:在应用端依次连接每个分片的数据库,按照预先计算好的页数,分别在每个分片内进行分页查询。例如,首先查询第一页的记录,在应用端显示给用户;然后查询第二页的记录,再显示给用户;依此类推,直至显示完所有页。 第二种方法是通过分片间件进行分页查询,其步骤如下: 1. 在分片间件进行配置:在分片间件,需要配置所需查询的总记录数,每页显示的记录数,以及每个分片的数据库连接信息等。 2. 发送分页查询请求:应用端发送分页查询请求到分片间件,同时将所需的页数和每页显示的记录数传递给分片间件。 3. 分片间件进行查询:分片间件根据接收到的查询请求,根据所需的页数,在每个分片的数据库进行相应的分页查询。 4. 返回分页查询结果:分片间件将每个分片查询的结果进行合并,然后返回给应用端。 总的来说,无论是在应用端还是分片间件进行分页查询,都需要预先计算每个分片的数据量和所需查询的页数,然后按照这些信息进行分页查询操作。
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值