gp数据库正则表达式

gp数据库正则表达式

在gp数据库中使用正则表达式时需要使用关键字“~”，以表示该关键字之前的内容需匹配之后的正则表达式，若匹配规则不需要区分大小写，可以使用组合关键字“~*”；

相反，若gp数据库正则表达式需要查询不匹配这则表达式的记录，只需在该关键字前加否定关键字“!”即可。若正则表达式包含转义字符，则需在表达式前加关键字“E”。

大数据正在向我们奔来。尽管业务场景不会完全相同，但在其中一个最典型场景——模糊检索中，技术需求却出奇的一致。

比如说：

物联网，往往会产生大量的数据，除了数字数据，还有字符串类的数据，例如条形码，车牌，手机号，邮箱，姓名等。假设用户需要在大量的传感数据中进行模糊检索，甚至规则表达式匹配，有什么高效的方法呢？

医药，市面上发现了一批药品可能有问题，需要对药品条码进行规则表达式查找，找出复合条件的药品流向。但怎么才能在如此复杂的系统中，用高效方法来实现？

公安，侦查行动时，有可能需要线索的检索。如用户提供的残缺的电话号码，邮箱，车牌，IP地址，QQ号码，微信号码等进行交叉搜索，根据这些信息加上时间的叠加，模糊匹配和关联，最终找出罪犯。但这个流程，可有高效方法？

相同的需求还有很多。几乎每一个模糊匹配的场景下，都需要正则表达式匹配，这和人脸拼图有点类似，我们已经看到强烈的需求已经产生。但技术方面，要怎么做更好？

在我看来：正则匹配和模糊匹配通常是搜索引擎的特长，但是如果你使用的是PostgreSQL数据库照样能实现，并且性能不赖，加上分布式方案

(譬如 plproxy, pg_shard, fdw shard, pg-xc, pg-xl,

greenplum)，处理百亿以上数据量的正则匹配和模糊匹配效果杠杠的，同时还不失数据库固有的功能，绝对是一举多得。

首先对应用场景进行一下分类，以及现有技术下能使用的优化手段。

.1. 带前缀的模糊查询，例如 like 'ABC%'，在PG中也可以写成 ~ '^ABC'

可以使用btree索引优化，或者拆列用多列索引叠加bit and或bit or进行优化（只适合固定长度的端字符串，例如char(8)）。

.2. 带后缀的模糊查询，例如 like '%ABC'，在PG中也可以写成 ~ 'ABC$'

可以使用reverse函数btree索引，或者拆列用多列索引叠加bit and或bit or进行优化（只适合固定长度的端字符串，例如char(8)）。

.3. 不带前缀和后缀的模糊查询，例如 like '%AB_C%'，在PG中也可以写成 ~ 'AB.C'

可以使用pg_trgm的gin索引，或者拆列用多列索引叠加bit and或bit or进行优化（只适合固定长度的端字符串，例如char(8)）。

.4. 正则表达式查询，例如 ~ '[\d]+def1.?[a|b|0|8]{1,3}'

可以使用pg_trgm的gin索引，或者拆列用多列索引叠加bit and或bit or进行优化（只适合固定长度的端字符串，例如char(8)）。

PostgreSQL pg_trgm插件自从9.1开始支持模糊查询使用索引，从9.3开始支持规则表达式查询使用索引，大大提高了PostgreSQL在刑侦方面的能力。

代码见 https://github.com/postgrespro/pg_trgm_pro

pg_trgm插件的原理，将字符串前加2个空格，后加1个空格，组成一个新的字符串，并将这个新的字符串按照每3个相邻的字符拆分成多个token。

当使用规则表达式或者模糊查询进行匹配时，会检索出他们的近似度，再进行filter。

是的

PG索引类型

CREATE INDEX 在一个指定表或者物化视图的指定列上创建一个索引,索引主要用来提高数据库的效率(尽管不合理的使用将导致较慢的效率)选择性越好(唯一值个数接近记录数)的列，越适合b-tree。当被索引列存储相关性越接近1或-1时，数据存储越有序，范围查询扫描的HEAP PAGE越少。支持多列索引，默认最多32列，编译可改。（通过调整pg_config_manual.h可以做到更大，但是还有另一个限制，indextuple不能超过约1/4的数据块（索引页）大小，也就是说复合索引列很多的情况下，可能会触发这个限制）

---