很多人之前问过我，“是否有可能分享一些与子库分类相关的实践？”事实上，我不赞同，但我没有多少经验；和大多数人一样，我仍处于理论阶段。
但这一次有点争论。
我们先来谈谈背景。随着业务的发展，我们的生产数据库逐渐增多；几个单表已超过1亿级数据，每天的数据量增加了200 + W.
我们的一些企业需要执行关联查询或报告统计信息；在这种情况下，大表的问题更加突出（例如，查询函数需要运行几分钟）。
许多人可能会说，如果他们在单一陈述中超过1亿，他们想要解决问题。实际上，他们不想，但由于历史原因和不正确的估计，数据增长导致了这种情况。简而言之，原因更复杂，并不是本次讨论的重点。
临时计划
由于需求紧张和缺乏人员，整个过程分为几个阶段。
第一阶段应该是去年年底。那时，运行和维护MySQL主机的内存占用率很高，整体负载很高，导致整个MySQL的吞吐量显着降低（写入和查询数据明显变慢）。
为此，我们发现了一些数据量最大的表，发现大部分数据大约为7/8000W，少数已超过1亿。
通过对业务级别的分析，发现大多数数据是用户生成的一些日志类型数据，并且数据在业务中没有很强的相关性，甚至两三个月前的数据也不需要实时查询。
因为它接近年底，如果你不想尽可能多地使用它，考虑是否可以减轻操作和维护水平的压力；主要目的是减少单个表中的数据量。
最初，我想将数据从两个月前直接迁移到备份表中，但在准备过程中发现了一个很大的障碍。
表中没有可以排序的索引，这使我们无法快速过滤掉一些数据！这真的是一个深坑，它埋葬了一个矿井，用于后来的一些优化；即使它已编入索引，也需要几个小时（在生产测试中需要多长时间）。
如果我们按时间强制进行筛选，查询4000W数据可能需要几个小时；这显然不起作用。
所以我们提出了一个大胆的想法：这部分数据可以直接忽略吗？这可能是最有效和最快捷的方式。与产品通信后，我知道这部分数据实际上只是日志型数据，即使将来无法添加报表。
所以我们只做了以下事情：
修改原始表的表名，例如add（_190416bak）。
创建一个与原始表同名的新表。
这个新数据被写入新表，业务也在使用这个包含少量数据的新表。
虽然这个过程不是很优雅，但至少它解决了这个问题，也让我们有时间进行技术更改。
分区方案
虽然之前的计划可以缓解压力，但根本无法解决问题。
有些企业不得不查询以前的数据，这导致了之前的技巧，所以我们只是利用这个机会来划分表格。
我相信大多数人从来没有真正做过分表，但他们也看到了猪跑；在线搜索各种节目纷纷出现。
我认为最重要的是找出需要分片的字段与实际业务相结合，并且在线阶段的数据迁移也非常重要。
时间
也许每个人都会说哈希是最均匀分布的，但我认为仍然需要使用历史数据来使用哈希表。
对于不需要历史数据的方案（例如业务），仅查询近三个月的数据。
这些要求的完成可以按时间段进行分段，并根据月份进行划分，以便变更简单，并且历史数据可以更好地迁移。
所以我们首先筛选出这些需求的列表，根据月份进行拆分，在查询时只拼接表名；最好理解。
哈希
我之前也提到过：需要根据业务需求划分表策略。
并且一旦所有数据都可以查询，它将无法根据时间表工作。 （也可以，但如果你不按时间查询，你需要遍历所有表）
因此，我们计划使用哈希来划分表，这被认为是业界的主流方式。
使用散列时，您需要选择分片字段，因为我们的业务相对简单；它是一个物联网应用程序，所有数据都包含物联网设备（IMEI）的唯一标识符，这个字段是自然而独特的。大部分业务也基于此领域，因此非常适合此分片领域。
在进行子表之前，我还调查了MyCAT和sharding-jdbc（现在已升级到shardingsphere）。最后，考虑到开发的友好性而不是增加操作和维护的复杂性，决定在jdbc层中进行分片。
但是，由于历史原因，我们没有很好地集成sharding-jdbc，但是基于分片的特性，我们实现了子表策略

• 上一篇: 蓝盟IT外包，元宇宙：四梁八柱是什么
  下一篇: 人工智能也能得分吗？阿里巴巴规范竞赛是世界上第一个AI裁判

• 分享到：