一次分表踩坑实践的探讨

媒介

之前不少人问我“可否分享一些分库分表相干的实践”，着实不是我不分享，而是真的履历不多;和大部门人一样都是逗留在理论阶段。

不外这次几多有些可以说道了。

先谈谈配景，我们出产数据库跟着营业成长量也逐渐起来;好几张单表已经打破亿级数据，而且保持天天 200+W 的数据量增进。

而我们有些营业必要举办关联查询、可能是报表统计;在这样的配景下大表的题目越发突出(好比一个查询成果必要跑好几分钟)。

也许许多人会说：为啥单表都过亿了才想方案办理?着实不是不想，而是因为汗青缘故起因加上错误预估了数据增添才导致这个排场。总之缘故起因较量伟大，也不是本次接头的重点。

姑且方案

因为需求紧、人手缺的环境下，整个处理赏罚的进程分为几个阶段。

第一阶段应该是客岁底，其时运维回响 MySQL 地址的主机内存占用很高，整体负载也居高不下，导致整个 MySQL 的吞吐量明明低落(写入、查询数据都明明减慢)。

为此我们找出了数据量最大的几张表，发明大部门数据量在7/8000W 阁下，少数的已经打破一亿。

通过营业层面举办说明发明，这些数据大都都是用户发生的一些日记型数据，并且这些数据在营业上并不是强相干的，乃至两三个月前的数据着实已经不必要及时查询了。

由于靠连年底，尽也许的不想去动应用，思量是否可以在运维层面缓解压力;首要的目标就是把单表的数据量低落。

本来是想把两个月之前的数据直接迁徙出来放到备份表中，但在筹备实验的进程中发明一个大坑。

表中没有一个可以排序的索引，导致我们无法快速的筛选出一部门数据!这真是一个深坑，为后头的一些优化埋了个地雷;即即是加索引也必要花几个小时(详细多久没敢在出产测试)。

假如我们强行凭证时刻举办筛选，也许查询出 4000W 的数据就得花上好几个小时;这显然是行不通的。

于是我们便想到了一个斗胆的设法：这部门数据是否可以直接不要了?

这大噶?鲱有用及最快的方法了，和产物雷同后得知这部门数据真的只是日记型的数据，即即是报表出不来此后补上也是可以的。

于是我们就简朴粗暴的做了以下工作：

• 修改原有表的表名，好比加上( _190416bak)。
• 再新建一张和原有表名称沟通的表。

这样新的数据就写到了新表，同时营业上也是行使的这个数据量较小的新表。

虽说进程不太优雅，但至少是办理了题目同时也给我们做技能改革预留了时刻。

分表方案

之前的方案虽说可以缓解压力，但不能基础办理题目。

有些营业必需得查询之前的数据，导致之前那招行不通了，以是正好我们就借助这个机遇把表分了。

我信托大部门人虽说没有做过现实做过度表，但也见过猪跑;网上一搜各类方案层出不穷。

我以为最重要的一点是要团结现实营业找出必要 sharding 的字段，同时尚有上线阶段的数据迁徙也很是重要。

时刻

也许各人城市说用 hash 的方法分派得最匀称，但我以为这照旧必要行使汗青数据的场景才用哈希分表。

而对付不必要汗青数据的场景，好比营业上只查询近三个月的数据。

这类需求完成可以采纳时刻分表，凭证月份举办分别，这样窜改简朴，同时对汗青数据也较量好迁徙。

于是我们起首将这类需求的表筛选出来，凭证月份举办拆分，只是在查询的时辰拼接好表名即可;也较量好领略。

哈希

适才也提到了：必要按照营业需求举办分表计策。

而一旦全部的数据都有也许查询时，凭证时刻分表也就行不通了。(也能做，只是假如不是凭证时刻举办查询时必要遍历全部的表)

因此我们打算回收 hash 的方法分表，这算是业界较量主流的方法就不再赘述。

回收哈希时必要将 sharding 字段选好，因为我们的营业较量纯真;是一个物联网应用，全部的数据都包括有物联网装备的独一标识(IMEI)，而且这个字段自然的就保持了独一性;大大都的营业也都是按照这个字段来的，以是它很是得当来做这个 sharding 字段。

在做分表之前也调研过 MyCAT 及 sharding-jdbc(现已进级为 shardingsphere)，最终思量到对开拓的友爱性及不增进运维伟大度照旧抉择在 jdbc 层 sharding 的方法。

但因为汗青缘故起因我们并不太好集成 sharding-jdbc，但基于 sharding 的特点本身实现了一个分表计策。

这个简朴也好领略：

int index = hash(sharding字段) % 分表数目 ; 
select xx from 'busy_'+index where sharding字段 = xxx; 

着实就是算出了表名，然后路由已往查询即可。

只是我们实现的很是简朴：修改了全部的底层查询要领，每个要领都里都做了这样的一个判定。

并没有像 sharding-jdbc 一样，署理了数据库的查询要领;个中还要做 SQL理会-->SQL路由-->执行SQL-->归并功效 这一系列的流程。

假如本身再做一遍无异于从头造了一个轮子，而且并不专业，只是在现有的技能前提下选择了一个快速实现告竣结果的要领。

不外这个进程中我们节减了将 sharding 字段哈希的进程，由于每一个 IMEI 号着实都是一个独一的整型，直接用它做 mod 运算即可。

尚有一个是必要一个同一的组件生陈法则，分表后不能再依靠于单表的字段自增了;要领照旧挺多的：

• 好比时刻戳+随机数可满意大部门营业。
• UUID，天生简朴，但没法做排序。
• 雪花算法统平天生主键ID。

各人可以按照本身的现实环境做选择。

营业调解

由于我们并没有行使第三方的 sharding-jdbc 组件，全部没有步伐做到对代码的低侵入性;每个涉及到分表的营业代码都必要做底层要领的改革(也就是路由到正确的表)。

思量到后续营业的成长，我们抉择将拆分的表分为 64 张;加上后续引入大数据平台足以应对几年的数据增添。

这里尚有个小细节必要留意：分表的数目必要为 2∧N 次方，由于在取模的这种分表方法下，即即是此后再必要分表影响的数据也会只管的小。

再修改时只能将表名称举办全局搜刮，然后加以修改，同时按照修改的要领倒推到示意的营业并记录下来，利便后续回归测试。

虽然无法停止查询时操作非 sharding 字段导致的全表扫描，这是全部分片后城市碰着的题目。

因此我们在修改分表要领的底层查询时同时也会查察是否有走分片字段，假如不是，那是否可以调解营业。

好比对付一个上亿的数据是否尚有须要存在凭证分页查询、日期查询?这样的营业是否真的具故意义?

我们尽也许的引导产物凭证这样的方法来计划产物可能做出调解。

但对付报表这类的需求确实也没步伐，好比统计表中某种范例的数据;这种我们也可以操作多线程的方法去并行查询然后汇总统计来进步查询服从。

偶然也有一些另类场景：

好比一个万万表中有某一非凡范例的数据只占了很小一部门，好比说几千上万条。

这时页面上必要对它举办分页查询是较量正常的(好比某种投诉动静，客户必要一条一条的单独处理赏罚)，但假如我们凭证 IMEI 号可能是主键举办分片后再分页查询那就较量蛋疼了。

以是这范例的数据提议单独新建一张表来维护，不要和其他数据殽杂在一路，这样不管是做分页照旧 like 都较量简朴和独立。

验证

代码改完，开拓也单测完成后怎么来验证分表的营业是否正常也较量贫困。

一个是测试贫困，再一个是万一那边改漏了照旧查询的原表，但这样在测试情形并不会有非常，一旦上线发生了出产数据到新的 64 张表后想要再修复就较量贫困了。

以是我们取了个巧，直接将原表的表名修改，好比加一个后缀;这样在测试进程中调查前靠山有无报错就较量轻易提前发明这个题目。

上线流程

测试验收通事后只是分表这个需求的80%，剩下怎样上线也是较量头疼。

一旦应用上线后全部的查询、写入、删除城市先走路由然后达到新表;而老数据在原内外是不会产生改变的。

数据迁徙

以是我们上线前的第一步天然是必要将原有的数据举办迁徙，迁徙的目标是要分片到新的 64 张表中，这样才会对原有的营业无影响。

因此我们必要特殊筹备一个措施，它必要将老内外的数据凭证分片法则复制到新表中;

在我们这个场景下，出产数据有些已经上亿了，这个迁徙进程我们在测试情形模仿发明耗时长短常久的。并且我们老表中对付 create_time 这样用于筛选数据的字段没有索引(早年的技能债)，以是查询起来就越发慢了。

最后没步伐，我们只能和产物协商奉告用户对付之前发生的数据短期也许会查询不到，这个时刻最坏也许会一连几天(我们只能在破晓迁徙，白日会影响到数据库负载)。

总结

这即是我们这次的分表实践，虽说不少进程都不优雅，但受限于前提也只能折中处理赏罚。

但我们后续的打算是，修改我们底层的数据毗连(今朝是本身封装的一个 jar 包，导致集成 sharding-jdbc 较量贫困)最终逐渐迁徙到 sharding-jdbc .

（编辑：河北网）

【声明】本站内容均来自网络，其相关言论仅代表作者个人观点，不代表本站立场。若无意侵犯到您的权利，请及时与联系站长删除相关内容!