背景原大众点评的订单单表早就已经突破两百 G,由于查询维度较多,即使加了两个从库,优化索引,仍然存在很多查询不理想的情况。去年大量抢购活动的开展,使数据库达到瓶颈,应用只能通过限速、异步队列等对其进行保护;业务需求层出不穷,原有的订单模型很难满足业务需求,但是基于原订单表的 DDL 又非常吃力,无法达到业务要求。随着这些问题越来越突出,订单数据库的切分就愈发急迫了。 这次切分,我们的目标是未来十年内不需要担心订单容量的问题。 垂直切分先对订单库进行垂直切分,将原有的订单库分为基础订单库、订单流程库等,本文就不展开讲了。 水平切分垂直切分缓解了原来单集群的压力,但是在抢购时依然捉襟见肘。原有的订单模型已经无法满足业务需求,于是我们设计了一套新的统一订单模型,为同时满足 C 端用户、B 端商户、客服、运营等的需求,我们分别通过用户 ID 和商户 ID 进行切分,并通过 PUMA(我们内部开发的 MySQL binlog 实时解析服务)同步到一个运营库。 切分策略1. 查询切分将 ID 和库的 Mapping 关系记录在一个单独的库中。 优点:ID 和库的 Mapping 算法可以随意更改。 2. 范围切分比如按照时间区间或 ID 区间来切分。 优点:单表大小可控,天然水平扩展。 3. Hash 切分一般采用 Mod 来切分,下面着重讲一下 Mod 的策略。 数据水平切分后我们希望是一劳永逸或者是易于水平扩展的,所以推荐采用 mod 2^n 这种一致性 Hash。 以统一订单库为例,我们分库分表的方案是 32*32 的,即通过 UserId 后四位 mod 32 分到 32 个库中,同时再将 UserId 后四位 Div 32 Mod 32 将每个库分为 32 个表,共计分为 1024 张表。线上部署情况为 8 个集群 (主从),每个集群 4 个库。 为什么说这种方式是易于水平扩展的呢?我们分析如下两个场景。 场景一:数据库性能达到瓶颈方法一按照现有规则不变,可以直接扩展到 32 个数据库集群。 方法二如果 32 个集群也无法满足需求,那么将分库分表规则调整为 (322^n)(32/2^n),可以达到最多 1024 个集群。 场景二:单表容量达到瓶颈(或者 1024 已经无法满足你)方法:假如单表都已突破 200G,2001024=200T(按照现有的订单模型算了算,大概一万千亿订单,相信这一天,嗯,指日可待!),没关系,32(32*2^n),这时分库规则不变,单库里的表再进行裂变,当然,在目前订单这种规则下(用 userId 后四位 mod)还是有极限的,因为只有四位,所以最多拆 8192 个表,至于为什么只取后四位,后面会有篇幅讲到。 另外一个维度是通过 ShopID 进行切分,规则 8*8 和 UserID 比较类似,就不再赘述,需要注意的是 Shop 库我们仅存储了订单主表,用来满足 Shop 维度的查询。 唯一 ID 方案这个方案也很多,主流的有那么几种: 1. 利用数据库自增 ID优点:最简单。 2. 利用数据库集群并设置相应的步长(Flickr 方案)优点:高可用、ID 较简洁。 3. Twitter Snowflake优点:高性能高可用、易拓展。 4. 一大波 GUID、Random 算法优点:简单。 我们的方案为了减少运营成本并减少额外的风险我们排除了所有需要独立集群的方案,采用了带有业务属性的方案:
有下面几个好处:
当然也有一些缺点,比如长度稍长,性能要比 int/bigint 的稍差等。 其他问题#
数据迁移数据库拆分一般是业务发展到一定规模后的优化和重构,为了支持业务快速上线,很难一开始就分库分表,垂直拆分还好办,改改数据源就搞定了,一旦开始水平拆分,数据清洗就是个大问题,为此,我们经历了以下几个阶段。 第一阶段
第二阶段
第三阶段
总结并非所有表都需要水平拆分,要看增长的类型和速度,水平拆分是大招,拆分后会增加开发的复杂度,不到万不得已不使用。 在大规模并发的业务上,尽量做到在线查询和离线查询隔离,交易查询和运营 / 客服查询隔离。 拆分维度的选择很重要,要尽可能在解决拆分前问题的基础上,便于开发。 数据库没你想象的那么坚强,需要保护,尽量使用简单的、良好索引的查询,这样数据库整体可控,也易于长期容量规划以及水平扩展。
|
|