背景
1、产品的问题点
- PG 不支持分区索引
2、问题点背后涉及的技术原理
- PG的索引支持到表级别, 如果是分区表那么每个分区创建对应索引, 索引不能单独进行分区. 例如一个100亿条记录的单表, 如果要创建索引只能创建普通索引, 索引本身不能分区.
3、这个问题将影响哪些行业以及业务场景
- 当单表较大时
4、会导致什么问题?
- 单表较大时, 索引也会非常庞大, 可能带来一些问题:
- 创建索引的耗时变长,
- 索引深度变大导致性能下降,
- 索引的垃圾回收时间变长.
- 如果系统中有多个块设备、多个表空间, 由于1个索引只能存放在1个表空间内, 那么无法很好的利用多个块设备的性能.
5、业务上应该如何避免这个坑
- 避免单表(或单一分区)的数据量过大, 例如不超过10亿条记录(经验). 超过后建议分区.
- 如果更新频率巨大, 例如建议单个分区不超过1亿条(经验)
6、业务上避免这个坑牺牲了什么, 会引入什么新的问题
- 管理成本增加
7、数据库未来产品迭代如何修复这个坑
- 内核层面支持分区索引, 如果是分区表则可以支持指定其他索引分区键.
- 根据某些表达式、字段HASH、范围分区
- 每个索引分区可以指定不同的表空间.
