Greenplum 2000亿 近似度查询 性能 以及注意事项
greenplum和PostgreSQL一样,都是通过pg_trgm来支持近似度查询的。
原理是将字符串前加2空格,末尾加1空格,然后按照3个连续的字符串为一组,打散成多个字符串。然后计算字符串的重复度来计算两个字符串的相似度。
计算重复度时,需要进行去重复的操作。
例如:
postgres=# select similarity('abcde','abcabc'); similarity
------------ 0.333333
(1 row)
Time: 0.413 ms
以上两个字符串被拆分成如下token(以下-代表空格)
--a, -ab, abc, bcd, cde, de-
--a, -ab, abc, bca, cab, abc, bc-
两者token去重后的集合为
--a, -ab, abc, bcd, cde, de-, bca, cab, bc-
重复的token为
--a, -ab, abc
所以abcde 和 abcabc 的近似度=3/9=0.333333
greenplum安装pg_trgm也很简单。
cd gpsrc/contrib/pg_trgm/
现在有个bug需要手工fix一下
vi trgm.h
#define TRGMINT(a) ( (*(((char*)(a))+2)<<16)+(*(((char*)(a))+1)<<8)+*(((char*)(a))+0) ) make && make install gpscp -f ./host /home/digoal/gphome/lib/postgresql/pg_trgm.so =:/home/digoal/gphome/lib/postgresql/pg_trgm.so
gpscp -f ./host /home/digoal/gphome/share/postgresql/contrib/uninstall_pg_trgm.sql =:/home/digoal/gphome/share/postgresql/contrib/uninstall_pg_trgm.sql
gpscp -f ./host /home/digoal/gphome/share/postgresql/contrib/pg_trgm.sql =:/home/digoal/gphome/share/postgresql/contrib/pg_trgm.sql psql -f /home/digoal/gphome/share/postgresql/contrib/pg_trgm.sql
测试
postgres=# create table t(info text);
NOTICE: Table doesn't have 'DISTRIBUTED BY' clause -- Using column named 'info' as the Greenplum Database data distribution key for this table.
HINT: The 'DISTRIBUTED BY' clause determines the distribution of data. Make sure column(s) chosen are the optimal data distribution key to minimize skew.
CREATE TABLE
postgres=# insert into t select md5(random()::text) from generate_series(1,100);
INSERT 0 100
postgres=# select * from t limit 10; info
---------------------------------- 2d33d6379b85eb7a3c4090dce7a0ebe2 75b4be956b90f8a8c528f847eddd34fe ae7f1bb726486fba174cfc27a90ea080 b714894688f9ef9272c61d09efebb361 d8774ded2bad3c4aafb85cc98fea7d06 afdc717a7e4c73e22a497db9c2812bfa eda761ac73f659072ae2084268d5f2fe e2660e7b3a9a7824611c4af93bc2c4d9 8659bdb87b3f5d3e6d7f269233e12d4b fd28ec09a46d2f35b3b3461ab48d1998
(10 rows)
当前的近似度阈值为0.3,当两个字符串的近似度小于0.3时,返回false。
postgres=# select show_limit(); show_limit
------------ 0.3
(1 row) postgres=# select '2d33d6379b85eb7a3c4090dce7a0ebe2' % 'eb7a3c409'; ?column?
---------- f
(1 row) postgres=# select * from t where info % 'eb7a3c409'; info
------
(0 rows)
使用set_limit可以设置近似度阈值
postgres=# select set_limit(0.1); set_limit
----------- 0.1
(1 row) postgres=# select '2d33d6379b85eb7a3c4090dce7a0ebe2' % 'eb7a3c409'; ?column?
---------- t
(1 row) postgres=# select * from t where info % 'eb7a3c409'; info
------
(0 rows)
为什么查询表的记录时没有起作用呢?
原因是set_limit()函数没有在segment上执行,它们还是0.3:
postgres=# select show_limit() from gp_dist_random('gp_id'); show_limit
------------ 0.3 0.3 0.3 0.3 ......
通过gp_dist_random强制在segment执行,
postgres=# select set_limit(0.1) from gp_dist_random('gp_id'); set_limit
----------- 0.1 0.1 0.1 ......postgres=# select * from t where info % 'eb7a3c409'; info
---------------------------------- 2d33d6379b85eb7a3c4090dce7a0ebe2
(1 row)
由于GP有会话缓存,释放后,又需要重新和segment建立连接,这时又回到0.3了。
postgres=# select * from t where info % 'eb7a3c409'; info
------
(0 rows)
postgres=# select show_limit() from gp_dist_random('gp_id'); show_limit
------------ 0.3 0.3 0.3 0.3 ......
以上就是greenplum的近似度查询的用法。
还支持索引哦 :
索引不受set_limit的影响,也就是说索引中不存储固定的limit值,是随时可调整的。
create index idx on t using gist (info gist_trgm_ops);
目前还不支持GIN,因为GP的GIN索引在AO表的使用方面有问题,存在同步的问题,可能导致数据不一致。
src/backend/commands/indexcmds.c
../* MPP-9329: disable creation of GIN indexes */if (accessMethodId == GIN_AM_OID)ereport(ERROR,(errcode(ERRCODE_FEATURE_NOT_SUPPORTED),errmsg("GIN indexes are not supported")));
..
预知2000亿的近似度查询性能,明天放出。
postgres=# select count(distinct info),count(*) from t_regexp_100billion ; count | count
------------+-------------- 2147475713 | 212600000000
(1 row) postgres=# explain select ctid,* from t_regexp_100billion where info >='3347597ec8' and info<'3347597ec9' and info like '3347597ec8%' limit 5; QUERY PLAN
------------------------------------------------------------------------------------------------------------------------------------------------------- Limit (cost=0.00..2479.65 rows=5 width=19) -> Gather Motion 240:1 (slice1; segments: 240) (cost=0.00..2479.65 rows=5 width=19) -> Limit (cost=0.00..2479.55 rows=1 width=19) -> Index Scan using idx_1 on t_regexp_100billion (cost=0.00..396651039.36 rows=3333 width=19) Index Cond: info >= '3347597ec8'::text AND info < '3347597ec9'::text AND info >= '3347597ec8'::text AND info < '3347597ec9'::text Filter: info ~~ '3347597ec8%'::text Settings: enable_seqscan=off
(7 rows)
Time: 55.146 ms postgres=# select ctid,* from t_regexp_100billion where info >='3347597ec8' and info<'3347597ec9' and info like '3347597ec8%' limit 5; ctid | info
--------------+-------------- (663830,524) | 3347597ec812 (704622,147) | 3347597ec812 (682224,472) | 3347597ec812 (644991,150) | 3347597ec812 (667081,662) | 3347597ec812
(5 rows)
Time: 57.635 ms postgres=# explain select ctid,* from t_regexp_100billion where info >='3347597' and info<'3347598' and reverse(info)>='218c' and reverse(info)<'218d' and info like '3347597%c812' limit 5; QUERY PLAN
----------------------------------------------------------------------------------------------------------------- Limit (cost=0.01..304985.33 rows=5 width=19) -> Gather Motion 240:1 (slice1; segments: 240) (cost=0.01..304985.33 rows=5 width=19) -> Limit (cost=0.01..304985.23 rows=1 width=19) -> Index Scan using idx_2 on t_regexp_100billion (cost=0.01..99181639.41 rows=7 width=19) Index Cond: reverse(info) >= '218c'::text AND reverse(info) < '218d'::text Filter: info >= '3347597'::text AND info < '3347598'::text AND info ~~ '3347597%c812'::text Settings: enable_seqscan=off
(7 rows)
Time: 55.338 ms postgres=# select ctid,* from t_regexp_100billion where info >='3347597' and info<'3347598' and reverse(info)>='218c' and reverse(info)<'218d' and info like '3347597%c812' limit 5; ctid | info
--------------+-------------- (704622,147) | 3347597ec812 (731733,400) | 3347597ec812 (774593,650) | 3347597ec812 (739526,433) | 3347597ec812 (779749,565) | 3347597ec812
(5 rows)
Time: 104.845 ms
Greenplum 2000亿 近似度查询 性能 以及注意事项相关推荐
- PgSQL · 应用案例 · 惊天性能!单RDS PostgreSQL实例支撑 2000亿
背景 20亿用户,每个用户1000个标签,基于任意标签组合圈选.透视(业务上的需求是一次最多计算100个标签的组合). 相当于要处理2000亿记录. 1.实时求标签组合的记录数.(即满足标签组合的用户 ...
- 加码 2000 亿新基建还不够,阿里云再放话:今年招 5000 人!
作者 | 伍杏玲 出品 | CSDN(ID:CSDNnews) 在 2019 年双 11 里,创下天猫全天成交额 2684 亿记录让人记忆犹深,彼时阿里从技术上经历"全面上云"的大 ...
- 今日科技联播:阿里巴巴宣布2000亿美金全球进口计划;iPhone XR需求低迷致供应商停止增产...
点击关注云栖社区,置顶公众号 专业的行业热点新闻及技术干货,不容错过 ---------------- 今日热点 双十一前霸气宣言,阿里宣布2000亿美金大进口计划,全球化战略迈出重要一步:iPhon ...
- 透视鹏程.盘古:首个2000亿参数中文大模型是怎样炼成的?
2021-05-19 10:21:00 机器之心原创 机器之心编辑部 给足算力和数据,就能训练出千亿参数的大模型?事实没有那么简单. 「70 年的人工智能研究史告诉我们,利用计算能力的一般方法最终是最 ...
- currenttimemillis 毫秒还是秒_Elasticsearch如何做到数十亿数据查询毫秒级响应?
如果面试的时候碰到这样一个面试题:ES 在数据量很大的情况下(数十亿级别)如何提高查询效率? 这个问题说白了,就是看你有没有实际用过 ES,因为啥?其实 ES 性能并没有你想象中那么好的. 很多时候数 ...
- Oracle Spatial分区应用研究之一:分区与分表查询性能对比
1.名词解释 分区:将一张大表在物理上分成多个分区,逻辑上仍然是同一个表名. 分表:将一张大表拆分成多张小表,不同表有不同的表名. 两种数据组织形式的原理图如下: 图 1分表与分区的原理图 2.实验目 ...
- 使用 SQL Server 2000 索引视图提高性能1
什么是索引视图? 许多年来,Microsoft SQL Server" 一直都提供创建虚拟表(称为视图)的功能.在过去,这些视图主要有两种用途: 提供安全机制,将用户限制在一个或多个基表中的 ...
- Elasticsearch如何做到数十亿数据查询毫秒级响应?
如果面试的时候碰到这样一个面试题:ES 在数据量很大的情况下(数十亿级别)如何提高查询效率? 这个问题说白了,就是看你有没有实际用过 ES,因为啥?其实 ES 性能并没有你想象中那么好的. 很多时候数 ...
- SQL Server 查询性能优化——创建索引原则(一)
索引是什么?索引是提高查询性能的一个重要工具,索引就是把查询语句所需要的少量数据添加到索引分页中,这样访问数据时只要访问少数索引的分页就可以.但是索引对于提高查询性能也不是万能的,也不是建立越多的索引 ...
最新文章
- 织梦内容管理系统修改
- 云服务器能否申请多个IP?
- deepin-wine-qq无法加载图片解决方案
- 在ORACLE中对存储过程加密
- node+ejs模板引擎的应用
- 《php入门很简单,PHP入门速成(1)
- git简介 http://msysgit.github.io/
- android 解决Error:This Gradle plugin requires Studio 3.0 minimum
- console.dir有很多浏览器,系统的兼容性问题,不要随便用!
- STM8学习笔记---NTC热敏电阻的使用
- DSP28335学习记录(三)——ePWM
- css实现时间数字特效字体格式
- Android 高德地图No implementation found for long com.autonavi.amap.mapcore.MapCore
- 基于FPGA的电子计算器设计(中)
- 单片机仿真器和烧写器的区别
- 国内常用开源镜像站点【推荐使用阿里巴巴开源镜像站】
- Python分析双色球,中大奖指日可待
- markman,让设计更有爱!
- 网格设计版式设计_网页设计展示精美的版式
- 淘宝插旗备注|物流发货接口
热门文章
- ICLR要搞深度生成模型大讨论,Max Welling和AAAI百万美元大奖得主都来了,Bengio是组织者之一...
- 小米副总裁崔宝秋:智能手机是今天AI技术最大的平台,AIoT又让AI无处不在 | MEET 2021...
- 马斯克用实力赢得信任!SpaceX获NASA批准,可用“二手”火箭和飞船载人航天
- RPA+AI这个278亿市场规模的赛道,IDC的这份报告讲清楚了
- window.postMessage实现网页间通信
- MSSQL 2000 错误823恢复数据案例
- jquery 设置checkbox的checked属性 总是出问题
- Windows Phone开发(41):漫谈关键帧动画之下篇
- Nokia House”或“NoHo
- 设计模式 — 结构型模式 — 代理模式