这是一个创建于 493 天前的主题，其中的信息可能已经有所发展或是发生改变。
有个表 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 插入。还是需要不停机维护？
分表分库注定要被淘汰，建议选择云数据库、分布式数据库。 |
Select Language