目前3.2.3集群分布式ob-mysql数据库,有些业务是超一亿行的大表,如何给拆分成分区表
-
- 选择什么分区键取决于业务读和更新这个分区表的方式(也就是SQL),并结合分区表的功能选择。
-
- OB 3.2 不支持非分区表变分区表,所以得变相实现,类似以前 MySQL 5.5 不支持 ONLINE DDL 时 一些外部工具的实现方式:搞个临时表,然后数据同步过去,然后改表名。
在 OB 3.2 里非分区表变分区表思路也是如此。
- 如果业务能停止读写,直接建新的分区表,然后用 INSERT INTO SELECT FROM 语句分批并行将老表数据写入到新表。为了性能最好,分区表不要带索引(主键要提前建好,主键包含分区键),并且分区表的 PRIMARY_ZONE 设置为跟老表同一个 ZONE 。如果租户的 UNIT_NUM 为 2 ,这个性能可能也不好。做完后,老表和新表交换名字。
- 如果业务不能停止读写,那就使用 OMS 单独迁移老表数据到新表里(OMS 同步表时改一下映射的表名),并开启增量同步。到最后数据同步快赶上的时候,业务写短暂停一下。然后快速的将老表和新表换个名字。
- 最后补上分区表的索引,注意尽可能是 LOCAL 索引。
3 个赞
我们的租户的UNIT_NUM 为 2,根据业务选择Range分区或LIST分区一级分区,该划分多少分区数?
如果是 list 分区说明有固定的列表值了,这个分区数好确定,尽可能维持分区大小均衡。如果是 range 分区的话,看是什么 range 了。如果是时间,分区数没有限制,可以一直加,只有范围粒度原则问题。
由于你还是没有描述业务,所以这个问题不会有具体的答案。
2 个赞
具体分区数评估下业务,比如要用range分区,业务如果查最近一个月或者最近一年的数据哪就直接实现就可以,不用去关注分区数了