面对订单表、朋友圈数据表等随着业务增长而无限增长的情况，通常采用按时间进行水平分表。然而，初期可能因业务量小导致单表数据量过低，后期活动可能导致数据量激增。为解决资源浪费和不足，提出了键值映射的解决方案。在数据量低时，可以手动合并表并使用键值映射查询；当数据量过大时，通过一致性哈希进行再分表，并维护更复杂的键值映射结构。这种方法能够动态适应数据变化，确保资源有效利用。
业务开发势必会遇到分表分库，列如订单表，朋友圈数据表这种，随着时间增长，势必会无限增长，这就逼着我们不得不按时间去进行水平分表，当你在后期维护的时候，你是否会遇到这种情况？例如：经过初步估算我们决定按着天分表，可是前期业务量并没有上来，导致一个表内的数据只有十几万，甚至更少？或者到了后期某个月或者某天，因为我们一个活动的开展，单子表单数据量激增至好几千万？这样势必会导致我们的资源浪费或者资源不足的情况。那我们改怎么办呢？
解决方案：
键值映射
首先说下，这是我想到的名词，不知道别家怎么定的，欢迎讨论！
先说资源浪费的情况，比如我们按天分表如：order_20210101，order_20210101，order_20210101,如果每个表中的数据都只有十几万的数据的话，我们是可以手动将他们进行合并，合并为order_202101，这样三张表的数据就合并到了一张表之中，表中的数据只有可能会修改，删除，查询，不会出现新增的情况了，我们原来查询的时候，是要通过订单号分析，得出订单所在的表的，才能对其进行操作查询，可现在我们通过分析，已经无法定位表的所在了，因为原表已经不存在了，怎么办？键值映射，我们可以维护一个键值表，通过分析订单号，如得到order_20210101，然后这个表名作为键，值为order_202101,这样在查询数据表的时候，我们实际上查询的是order_202101，通过这种方式，我们解决了单表数据量过低的麻烦，对于分库来说，也可以做响应的操作。
再来说下单表不够用了怎么办？比如双十一，单日数据激增！单表无法承载，我们肯定会想到把表再进行切分，列如，通过一致性hash取模，分成30张表，刚刚是单键值对，现在我们可以定义一个map 键还是order_20210101,值是一个map，map中有两个元素，一个是定义 键【type】值是hash，另一个是map 键值对出现， {“1”:order_20210101_1,“2”:order_20210101_2,…}，当我们通过订单号取模，得出对应表的位置，就可以对数据进行操作了（键值表一定要入库，可以通过缓存增加效率）。
总结：实际应用中，你还应该考虑到分库的情况，所以你的库也应该做键值映射，我们可以通过中一个插件的方式，来获取最终要操作的库和表！核心目标- 找到需要操作的表进行操作！！
扫一扫
1119
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
