请教一些分库分表的问题

245 天前
 jiobanma

目前线上数据库中一个大表大概有 2k 万条数据。 这 2 千万数据大概是 1 年的量。之后业务量变大,可能会更高一点。 准备对这个表进行分表,有两点问题想咨询一下大佬们。

  1. 大概分多少个表,能够支持未来几年的业务量。
  2. 分表后,旧表的数据如何迁移到新表内(可停服,不用考虑过渡阶段数据)。 写代码/canal/LogStatsh/flink-cdc
3101 次点击
所在节点    程序员
40 条回复
imokkkk
245 天前
感觉既然决定了分就一次性分到位 要不后面再扩 迁移数据头大
cubecube
245 天前
分区表,分个毛线。现在全闪存,大内存服务器,非国内 top10 的公司,放弃分库分表吧
flashBee233
245 天前
分布式数据库 OceanBase 咋样
richangfan
245 天前
建新表,写 SQL 转移数据,再把新旧表的名字改了
raphaell2e
245 天前
如果数据分布时间均匀的话,可以按年月分表,按你的数据量描述一个月 200 万左右的数据量,搓搓有余。数据迁移的话,提前写好 migrate 脚本,设定数据冻结时间,先跑脚本迁移数据,然后上线,上线后再同步冻结时间到上线时间之间产生的数据。
Hurriance
245 天前
尝试看有没有可能从垂直增强(机器配置)的角度加强下?

因为我发现,引入分库分表带来的不止是开发过程中的心智成本的增加,还会需要运维团队的支持,不充分的考虑引入可能会带来更大的隐患和成本,如果你需要考虑这个的话。
iyaozhen
245 天前
其实 mysql 的表分区还是很好用的,可以按一个字段,比如日期分表,对应用层还是一张表。预先把未来的分区都建好就行
nash1000
245 天前
两千万一点数据一点都不多,找个字段建个分区,常用的一些字段加一些索引就行了
opengps
245 天前
硬盘速度快,查询简单,那么 2k 万数据并不多,结合合理的索引就行
查询如果复杂,那么有必要提升下硬盘速度,或者表结构上拆分一下了
NoobNoob030
245 天前
我这公司一张表 6e 数据,三个月 1e 条,频繁读写,索引建好查询很快,不太影响性能盒业务,根本没打算分库分表
jiobanma
245 天前
@NoobNoob030 #10 这个好夸张
@nash1000 #8
@opengps #9 问题是这只是 1 年的数据量。之后逐年增加,明年可能就 5 千万了,这也不需要分吗
RainCats
245 天前
讨论技术问题前先整明白业务要求。
- 如果这个业务相关的历史数据不怎么访问的,那直接按年或者年月去开新表存放旧数据得了。然后程序上稍作调整即可
- 如果必须要新旧数据都混在一块的,那再看看用啥技术,分库分表带来的问题可太多了
ashe900501
245 天前
我觉得你可以详细描述一下业务场景. 不同场景方案不同.
分表后期查询非常麻烦.尤其是聚合查询.
通用的分表,可以翻倍分表.从一个翻倍成两个.从两个翻倍成 4 个.直接用主键区余数.
完全不停机方法:先把从库变成全变成主库,然后修改业务逻辑.然后再把所有的主库重新挂载新的从库.
当然也可以用中间件,我没用过

我觉得可以部分表.把事务操作留在数据库,然后把查询放到 es.感觉数据量再大,也不会有太大问题.数据库只做基于主键的增删改查.查询全都放 es.
jiobanma
245 天前
@RainCats #12 目前是这样的,数据可能不太好按照时间做拆分,因为有业务需要访问整体的数据。因为我对分库分表的东西接触的不多,目前我们的业务其实不需要分库,只是分表。所以分库分表带来的分布式事务问题应该可以先按下不表。其他的我能想到问题好像也没其他的了。使用的是 shardingsphere 框架,代码上基本没改动,我感觉复杂程度也不高,框架都帮忙做好了。唯一不清楚的就是性能什么的,也许是我了解的坑比较少。还希望大佬们可以给点建议...
opengps
245 天前
@jiobanma 我看到已经有人建议了,首先考虑下表分区,如果分区字段合理,表分区最大优势是本身用法等同于单表,几乎不对原有代码逻辑造成任何影响。
单表不行的时候再考虑分表-减少索引时间
单机 io 扛不住了在考虑分库-分不同服务器
yc8332
245 天前
按用户分表。。不过感觉 N 年的也不需要了啊。
jiobanma
245 天前
@ashe900501 #13 es 这个方式到是也不错,但是有一点我不太清楚,虽然查询走 es ,es 数据量大无所谓,但是基础数据依然在 mysql 中的单表存放,按照现在的数据增长率,数据量可能在两三年后就破亿了,真的不会影响数据库压力或者单表的增删改效率吗。
ashe900501
245 天前
@jiobanma 数据库只做基于主键的增删改查.我觉得你可以再测试环境弄几亿数据测试一下.这个我不敢保证.但是我感觉应该没啥问题.索引的效率还是很高的.
wqhui
245 天前
shardingsphere 这个我有在用,也是单纯做了分表没分库
遇到比较麻烦的问题有两个
1.查询如果不带上分片键会导致所有分表执行一遍查询语句,对于频繁执行的查询必须带分片键,不然容易炸,跟其他表聚合、统计也会遇到这问题,有时候需要做些骚操作去维持性能,比如做个关系表让你通过查询条件获取分片键
2.这框架的文档跟实际代码有点对不上,应该是文档维护不及时,每个版本都会有些不兼容改动,升级版本、初次开发遇到问题都需要自己一边看文档一边看源码摸索

迁移数据的方法跟 5 楼讲的差不多,先把历史数据按规则刷进新表,这时新数据入的是旧表,然后代码切换到新版本,新数据进新表,上次还没迁的增量旧数据迁到新表
yaodong0126
245 天前
2000w 根本不多,我觉得没必要分

这是一个专为移动设备优化的页面(即为了让你能够在 Google 搜索结果里秒开这个页面),如果你希望参与 V2EX 社区的讨论,你可以继续到 V2EX 上打开本讨论主题的完整版本。

https://www.v2ex.com/t/971425

V2EX 是创意工作者们的社区,是一个分享自己正在做的有趣事物、交流想法,可以遇见新朋友甚至新机会的地方。

V2EX is a community of developers, designers and creative people.

© 2021 V2EX