上一篇文章讲解了如何使用阿里云的GTS，进行全局分布式事务处理。这篇文章将介绍如何使用阿里云的PolarDB-X中间件进行分库分表的操作。
系统的重构，尤其是老系统的数据最后要转移到新系统中，而且数据量又是亿万级别的，处理起来真的是很棘手。
首先，也是最关键的就是要理清新系统的产品需求，其次要把老系统中的数据进行整理和筛选，然后整理出分库分表的思路和方案，最后要制定出新老数据库迁移的方案，这里根据快递驿站系统的把这些步骤具体化，并详细讲述如何使用PolarDB-X中间件进行分库分表。
一、整理新系统的产品需求
这是产品经理干的活，我这里就简单描述一下需要开发的新系统的一些要点。新系统大致上就是两大模块的结合，一个就是包裹系统模块，快递驿站接受快递入库，用户在驿站取件出库，驿站将信息同步给快递公司，通知给用户包裹状态，用户还可以在驿站寄件；第二个就是共配系统模块，不同快递在同一个仓库集中放货，这样一来可以节省成本，再者一起配送更加方便，尤其偏远农村，因为快递包裹少，每个快递公司隔三差五才送一次快递，如果有了共配系统，那一起配送的快递包裹就多了，可以实时送达。所以整个新系统是非常庞大的，软件架构详见第一篇文章中的插图。
二、对老系统中的数据进行筛选和整理
1、目前系统的情况说明
包裹订单表按照月份拆分，碰到双十一双十二购物大促期间，单表中存的数据量超大，导致门店、代理商后台查询或统计数据时很慢，造成系统瓶颈甚至宕机，客户要求赔偿损失，后果严重。
其他大数据量的表都未进行拆分，例如：取件短信通知表，日志表等等，严重影响系统性能，还有大量的慢SQL查询，都是导致系统变慢的原因。
2、新系统的规划和展望
根据公司近3-5年规划及展望：
1）包裹数据量的规划，每天稳定在1000万单，这样一个月就是3个亿数据，3个月就是9个亿，1年就是36亿；
2）短信、微信和语音通知量将会是订单量的2倍以上（入库、出库各一次），因为会存在多发的情况，这样1个月就是6个亿，3个月18亿，1年100亿；
3）操作记录根据门店、代理商、快递员、管理员、寄取件用户的每天操作，预估3000万次；
4）新系统也要记录寄取件用户信息，全国100万家门店，服务5个亿用户寄取件。
3、设计方案
根据上面所描述的，将数据分为3类：
1）热数据——3个月之内的数据，需要实时查询操作；
热数据存储在PolarDB中，数据量大的表，进行分库分表；
2）较冷数据——3-12个月的数据，需要存储，进行统计分析；
热+较冷数据存储在 AnalyticDB中，实时从PolarDB中同步，使用QuickBI进行数据的分析、处理和统计；
3）冷数据——12个月以上的数据，需要存储已备后查；
冷数据（基本不查）存储在HBase中，用于节约成本；
三、使用阿里云的PolarDB数据库进行数据的存储和管理
PolarDB是阿里巴巴自研的新一代云原生关系型数据库，在存储计算分离架构下，利用了软硬件结合的优势，为用户提供具备极致弹性、高性能、海量存储、安全可靠的数据库服务。100%兼容MySQL 5.6/5.7/8.0，PostgreSQL 11，高度兼容Oracle。
PolarDB采用存储和计算分离的架构，所有计算节点共享一份数据，提供分钟级的配置升降级、秒级的故障恢复、全局数据一致性和免费的数据备份容灾服务。PolarDB既融合了商业数据库稳定可靠、高性能、可扩展的特征，又具有开源云数据库简单开放、自我迭代的优势，例如PolarDB MySQL引擎作为“超级MySQL”，性能最高可以提升至MySQL的6倍，而成本只有商用数据库的1/10，每小时最低只需1.3元即可体验完整的产品功能。PolarDB MySQL引擎 100%兼容原生MySQL和RDS MySQL，您可以在不修改应用程序任何代码和配置的情况下，将MySQL数据库迁移至PolarDB MySQL引擎。
而且PolarDB最高100 TB，不再需要因为单机容量的天花板而去购买多个实例做分片，由此简化应用开发，降低运维负担。
说了这么多PolarDB的好处，心动不如心动，立马开始使用。
首先在阿里云进入PolarDB控制台进行购买，我们项目打算购买2个PolarDB，后期也可以根据业务需要变更配置，增加只读节点，进行扩容。
兼容性可以选择MySQL5.6，如果用最新MySQL8.0，后续要改配这个是改不了的，所以前期根据项目的情况进行选择；系列建议选择集群版，节点规格也根据自身的需求选择，我们这里选择的是8核64GB，当然有钱可以任性选择独占物理机😂。为了测试和演示，买了2核8GB。
在基本信息界面可以对创建的PolarDB进行白名单设置，添加集群账号，编辑主地址和集群地址，还可以增删节点，变更配置，具体的使用可以参考阿里云PolarDB使用指南，反正我是用了很爽。
其他再说一下慢SQL的查询功能，这个太好用了，可以查询到每个节点中，查询缓慢的SQL的信息，进行慢日志分析，可以根据时间进行查询，如果有慢SQL，会显示出来，并可查看该次慢SQL的详细信息。
四、使用阿里云的PolarDB-X进行分库分表
上面我们购买完PolarDB后，接下去就是要创建数据库，然后对数据量大的表，进行分库分表的操作。
第一步还是先要有分库分表的方案，下面列出了项目中部分分库分表的方案：
1、包裹订单表
根据门店ID分库，根据订单包裹ID分表 100张表
2、短信通知表、微信通知表
根据门店ID分库，根据短信ID分表 200张表
3、物流记录表
根据订单包裹ID分库，根据门店ID分表 100张表
4、寄取件用户表
根据用户ID分库，根据取件手机号码分表100张表
5、操作记录表：根据不同用户创建不同操作记录，门店操作记录表、代理商操作记录表、寄取件用户操作记录表、快递员操作记录表、管理员、其他人员操作记录表
可以选择用户ID与时间字段相结合作为拆分键，并按照一周七天进行分表
CREATE TABLE user_log ( userId INT(11) NOT NULL, name VARCHAR(64) NOT NULL, operation VARCHAR(128) DEFAULT NULL, actionDate DATE DEFAULT NULL) DBPARTITION BY HASH(userId) TBPARTITION BY WEEK(actionDate) TBPARTITIONS 7
6、其他数据量不大的表，就不进行分表操作了，单库单表是落在0库上。也可以只分库不分表，具体问题具体分析。业务逻辑实体通常与应用场景相关，下面的一些典型应用场景都有明确的业务逻辑实体（以此类推，其它应用场景也能找到合适的业务逻辑实体），其标识型字段可用来做拆分键。
面向用户的互联网应用，围绕用户维度来做各种操作，那么业务逻辑实体就是用户，可使用用户ID作为拆分键。
侧重于卖家的电商应用，围绕卖家维度来做各种操作，那么业务逻辑实体就是卖家，可使用卖家ID作为拆分键。
游戏类在线应用，围绕玩家维度来做各种操作，那么业务逻辑实体就是玩家，可使用玩家ID作为拆分键。
车联网在线应用，围绕车辆维度来做各种操作，那么业务逻辑实体就是车辆，可使用车辆ID作为拆分键。
税务类在线应用，围绕纳税人来进行前台业务操作，那么业务逻辑实体就是纳税人，可使用纳税人ID作为拆分键。
总之一点，先把分库分表方案设计好后，后面就可以使用PolarDB-X的工具来实现。
1）打开阿里云PolarDB-X控制台，购买产品，产品有1.0和2.0之分，1.0操作性更多，2.0封装的更好，根据自身的需要选择，我们选择的是PolarDB-X1.0。
这里要注意的是和PolarDB购买时选择的mysql版本要一致，否则不能使用，所以我们这里选择MySQL5。
点击实例名称进入后，选择点击“创建数据库”，进入创建数据库界面“填写基本信息”，选择“水平拆分”，输入数据库名称，密码，选择字符集后，点击“下一步”；
第二步，在界面中选择可用的PolarDB实例，当然MySQL的版本必须相同，才会显示可用，然后点击左边的PolarDB数据库移动到右边去。然后点击“下一步”；
第三步，预检，如果都显示成功，代表没问题，可以点击“下一步”到“建库预览”界面；
第四步，“建库预览”中显示了创建后的数据库列表，默认一个PolarDB数据库实例自动分成8个库，编号从00到07，两个PolarDB数据库实例就会自动分成16个库，以此类推；最后点击“下一步”进入到最后一个界面；
第五步，点击“下一步”按钮后，直接回到了“数据库管理”界面，显示数据库正在创建中，过几分钟后，状态显示正常；
这样就完成了数据库的创建，接下去我们用Navicat工具连接PolarDB-X看一下数据库结构
公网地址去PolarDB-X控制台去申请，然后配置白名单访问即可。
在Navicat中，输入show database，就能看到刚才分库创建成功的数据库了。如下图，一共有8个库。
接下去就是创建表格了，我们在Navicat中使用DDL语句进行操作，例如：包裹订单表，根据门店ID分库，根据订单包裹ID分100张表，见下图：
这样我们就让PolarDB-X的工具自动分好了800张表，每个库100张，总共8个库。方不方便，比个小心心❤️。不过有朋友可能会问，为什么要分100张表，不是200张，不是50张表呢？这里我想重点说一下如何选择分片数。
PolarDB-X中的水平拆分包含了分库和分表两个层次。在创建数据库时，选择拆分模式为水平拆分，则PolarDB-X为默认为每个私有定制RDS实例创建8个物理分库，每个物理分库上可以创建一个或多个物理分表，而分表数通常也被称为分片数。
计算公式：
一般情况下，建议单个物理分表的总容量范围在500万~5000万行数据（若单行记录超过4KB，建议总容量范围不超过500万），同时控制B+树的深度为3~4层。
您可以先预估1~2年内的数据增长量，用估算出的总数据量除以总的物理分库数，再除以建议的单个物理分表的最大数据量（本文以500万为例），即可得出每个物理分库上需要创建的物理分表数。
物理分库上的物理分表数=向上取整（估算的总数据量/（私有定制RDS实例数 x 8）/ 5,000,000）
因此，若计算出的物理分表数等于1时，当前分库即可满足需求，无需再进一步分表，保持当前每个物理分库上一个物理分表即可。若计算结果大于1，则建议既分库又分表，即每个物理分库上再创建多个物理分表。
例如我们的包裹订单表，每天稳定在1000万单，这样一个月就是3个亿数据，3个月就是9个亿，1年就是36亿，3年达到100亿，我们就做一个3年的规划，之前说过购买2个PolarDB实例，根据上面的公式我们可以计算：
物理分库上的物理分表数= CEILING(10,000,000,000 / ( 2 * 8 ) / 5,000,000) = CEILING(125) = 125
结果为125，那么建议既分库又分表，即需要在每个物理分库上再创建125张物理分表，所以我刚才分库分表的时候选择了100张表格。当然如果计算公式结果为1，那么您只需要分库而无需分表，即保持当前每个物理分库上1张物理分表即可。
例如：假设预估一张表在2年后的总数据量约为1亿行，您已购买了4个私有定制RDS实例，那么按照分片数公式进行如下计算：
物理分库上的物理分表数= CEILING(100,000,000 / ( 4 * 8 ) / 5,000,000) = CEILING(0.625) = 1
这种情况下，就只需分库还不用分表。
好了PolarDB-X的文章介绍差不多了，很多使用的方法和经验，需要大家多实践，多看看阿里云官方帮助文档，如果大家对本文感兴趣，或者碰到什么问题，可以在评论里面联系我，谢谢！
