【DB吐槽大会】第35期 - “富人”的烦恼?PG 不会自动选择索引类型
简介:
大家好,这里是DB吐槽大会,第35期 - “富人”的烦恼?PG 不会自动选择索引类型
背景
1、产品的问题点
2、问题点背后涉及的技术原理
- PG 支持很多种类的索引, hash, btree, gin, gist, sp-gist, brin, bloom, 还有外置的rum, pase, zombodb等.
- 每种索引的存储结构都不一样, 可以加速的场景也不一样
- 《PostgreSQL 9种索引的原理和应用场景》
- btree,适合任意单值类型,可用于
=, >, <, >=, <=
以及排序。
- hash,当字段超过单个索引页的1/4时,不适合b-tree索引。如果业务只有
=
的查询需求,使用hash index效率更高.
- gin,倒排存储,(column value: row IDs tree|list)。适合多值列,也适合单值列。例如数组、全文检索、JSON、HSTORE等类型。
- gist,适合数据有交错的场景,例如 全文检索、range类型、空间类型(点、线、面、多维对象... ...)。
- sp-gist,空间分区索引类型,适合不平衡数据集(例如xxxyyyzzz??????组成的VALUE,xxx, yyy, zzz,每个值包含一些数据集,每个数据集的数据量不平衡可能导致TREE不平衡)。
- brin,块级索引,记录每个或每连续N个数据块的数据边界。
- bloom,支持被索引字段的任意组合的等值搜索。
- rum,支持全文检索类型,支持单值列+全文检索列,支持近似文本搜索。
- zombodb,PG与ES搜索引擎结合的一种索引,在PG数据库中透明使用ES。
- bitmap,支持1000~10000个唯一值的列。适合多个值的 与或 条件搜索。
3、这个问题将影响哪些行业以及业务场景
- 通用, 但是这是富人的烦恼, 别的库没这么多索引种类
4、会导致什么问题?
- 一般用户不懂那么多, 通常只使用默认的btree, 使得无法达到最优化的数据库使用, 浪费资源
5、业务上应该如何避免这个坑
- 自己掌握这些索引的原理, 根据实际的业务需要进行选择.
6、业务上避免这个坑牺牲了什么, 会引入什么新的问题
7、数据库未来产品迭代如何修复这个坑