有个表 biz_order 是单表的,目前已经 600W+数据,每日还在 30w 增长量
考虑把 biz_order 表分库分表,分成 10 库 100 表,根据 order_id hash 计算分表位
现在的问题是创建好表了,旧数据如何快速迁移到新的分表里面
用存储过程能快速迁移么?还是要写代码慢慢查询再插入?
1
plutome 2023-08-22 14:32:16 +08:00 1
600W 而已。insert into select xxxxx 也花不了多久。
|
2
qizheng22 2023-08-22 14:33:30 +08:00
shardingjdbc 分库分表,不是有个 sharding-ui 和 sharding-proxy 。
shardingproxy 相当一个中单件,用 mysql 客户端连接,再导入。 仅用 order_id 的 hash 分表,以后表不够,再扩展就麻烦了 |
3
dusu 2023-08-22 14:43:31 +08:00 via iPhone 1
按 1kw 分一次表 上线后等 id 满了切就行
不用考虑这次迁移 一个表不差几百 w 与其考虑迁移 不如多考虑分表后的数据聚合问题吧 |
4
yungeo 2023-08-22 14:47:41 +08:00
不考虑使用 datax 吗?
|
5
declandragon 2023-08-22 15:07:43 +08:00
写个小脚本,多线程分段处理数据很快的,我也是 3 楼的想法,聚合怎么办
|
6
T0m008 2023-08-22 15:10:20 +08:00
订单表难道不是把旧日期的分出去吗,过时的订单能有多少流量?
|
7
wqhui 2023-08-22 15:16:51 +08:00
不理解怎么会想要分 100 个表存储,有没想过如果查询条件里面没有带上分表键需要所有表扫一次,应该是把冷数据归档掉,分表只存热数据。除非规定每个查询一定要带分表键,或者把这些数据同步到别的组件比如 es 上
|
8
Granado 2023-08-22 15:25:55 +08:00
说下我的想法吧:
如果是有明显时间冷热的数据,建议的做法是定期归档然后,删除历史数据,查历史数据的时候就查归档。当然这么做也需要有一定的基建后比较轻松。 如果采用分表,以后非分表维度的查询(例如你文中提到的 order_id 分表,查询的时候需要查用户的订单,查询维度是 user_id )就会比较麻烦,要构建单独的查询索引(例如前面提到的 user_id ---> order_ids 的映射),这时候又会有额外的维护(索引维护,数据一致性问题,延迟问题)。 这时候我建议还是直接上 tidb 这种天然支持分表的,维护成本低很多,相对来说迁移也比较好迁移,前期数据量低可以停机迁移,数据量大先双写单读,再单写单读就好。 |
9
me1onsoda 2023-08-22 15:46:04 +08:00
2023 年还有人分库分表吗?这方案还是建立在以前 hhd 低速存储的前提下,以后 ssd 都比 hhd 便宜,速度再提升,要进历史的垃圾桶吧?
|
10
james2013 2023-08-22 15:50:47 +08:00
我觉得分库没有必要,直接在 1 个库里分 100 张表,使用和维护比较方便
存放分表数据采用代码提供的唯一的 id,然后使用代码分批插入,比如每次 3000 条 |
11
kanepan19 2023-08-22 15:55:13 +08:00
那个是怎么说来着, 分表分库是解决插入问题的。
|
12
kanepan19 2023-08-22 15:56:55 +08:00
接上面,分表分库是解决 插入性能不足问题的。
查询性能不行,加读库 或 olap |
13
lsk569937453 2023-08-22 15:58:54 +08:00
自己写程序迁移,有唯一 id 的好迁移。
|
14
dw2693734d 2023-08-22 16:31:28 +08:00
@me1onsoda 2023 年了,还有人不知道 shard 是很多公司(包括谷歌, 微软)在数据库管理中常用的技术吗?通过将数据分割成较小的部分,可以提高数据库的性能和可扩展性。
|
15
dw2693734d 2023-08-22 16:33:07 +08:00
说到分库分表 shard ,就不得不提一下 postgres 了,使用 citus 插件,一键分表,自动计算 hash
|
16
me1onsoda 2023-08-22 16:59:48 +08:00
@dw2693734d 你别光说好处,代价呢?
|
17
dw2693734d 2023-08-22 17:09:18 +08:00
@me1onsoda 用空间换时间,本来就是互联网公司常用的技术。缓存不也是一样的道理。
|
18
dailiha01sy 2023-08-22 17:50:03 +08:00
一年也才一个亿 分啥
|
19
gam2046 2023-08-22 18:36:38 +08:00
@dw2693734d #14 大佬,现在我正好遇到一个问题,现在有一个 postgres 表,存在一个 timestamp 类型的字段,而这个字段又是索引字段,很多地方需要通过这个来作为查询条件。同时这个字段更新又非常频繁,导致索引也需要频繁更新,进而导致 IO 性能低下。
针对这种场景,有什么优化建议嘛,目前索引类型是 btree |
20
poembre 2023-08-22 19:57:00 +08:00
我有个单表表 目前 7 亿+ 数据量, 一周差不多 2-3KW 写入量。
|
21
lovelylain 2023-08-22 20:29:52 +08:00 via Android
按 uid hash 分库分表,将这个 hash 值塞到 order_id 里,这样既能通过 uid 从一个表找到用户的所有订单,又能通过 order_id 找到对应的表。至于已经存在的历史 order ,因为改 order_id 使其符合新规则可能有隐患,建议不迁移,这样一个用户最多查一次新表一次旧表就能找出所有订单,旧表没有新记录写入也不用担心性能下降,而且订单是有时效的,过段时间还能直接干掉旧表。
|
22
dw2693734d 2023-08-22 22:39:04 +08:00 via iPhone
@gam2046 用 brin 索引试试呢
|
23
phx13ye 2023-08-22 23:04:32 +08:00
新数据双写,历史数据迁移或归档
|
24
mmdsun 2023-08-22 23:50:23 +08:00
没多少数据直接 sql 插入。还是需要不停机维护?
分表分库注定要被淘汰,建议选择云数据库、分布式数据库。 |