基于PGSQL的OLAP全场景轻量级数据库实践之路

如果无法正常显示，请先停止浏览器的去广告插件。

1. 基于PGSQL的OLAP全场景轻量级数据库实践之路⺟延年录信数软创始人&CTO

2. • PG实践之路 • 架构及特性 • 关键技术点 • 应用场景 • 未来计划

3. 个人简介 apache lucene 15年铁杆粉丝职场阶段 2006年~2011年新浪:播客搜索阅读了市面上所有lucene字样的书籍专心阅读lucene源码600多篇研读笔记 2011年阿里巴巴:开源项目mdrill 将lucene与流计算storm进行结合总量4000亿数据 2014年录信创始人&CTO 母延年腾讯Hermes系统的开发人员将lucene与hdfs进行结合 10000亿/天创业阶段创业后第一年:LSQL 将spark与lucene+hdfs结合 500+部署,最大集群1000节点,50p 创业后第二年:hbaseSQL 将hbase的底层存储hfile更换为lucene 用以支撑高并发点查与全文检索创业后第三年:LXDB 将lucene与postgres做了深度结合 mpp模式:产品最求轻量但功能丰富解决场景:即席查询与即席分析-adhoc

4. 录信的产品打磨之路 LSQL的运维 Hadoop kafka HSQL Spark 1.上百个配置项,配错一个都不行 2.大数据运维人员很贵,懂源码的运维更贵,能改源码的更更贵 3.甲乙丙三方都累的要死客户的这500个项目的直接成本投入 1:300人的大数据研发团队 2:200人的项目实施团队 3:全国各地无数的驻场运维人员 Hadoop Hbase LXDB Spark 我心目中最完美的架构以为是我最终版的全栈数据库 1.比LSQL多了个Hbase,现场一旦出问题需要同时精通hadoop,hbase,spark 2.现在项目大规模上云,还要懂 docker,K8S 3.还要懂你的lucene 但你告诉我去哪去找这些大神? postgres lucene 1.轻量化产品,抛去了繁重的hadoop,一个rpm -ivh 搞定单机1分钟,集群5分钟部署完毕 2.麻雀虽小五脏俱全:功能齐全 3.postgres接口,标准postgres SQL 大部分人员都会用,周边配套非常完善. 4.录信也能从繁琐的项目支撑中解脱，大部分精力用在lucene层的研发应届生就能用

5. 录信的产品打磨之路 LSQL的运维 Hadoop kafka TO B与TO C关注点截然不同 HSQL 像阿里腾讯可以几百号人维护一套集群 Hadoop Spark Hbase Spark 而TO B则是一个人维护很多套集群 1.上百个配置项,配错一个都不行 2.大数据运维人员很贵,懂源码的运维更贵,能改源码的更更贵 3.甲乙丙三方都累的要死我心目中最完美的架构以为是我最终版的全栈数据库 1.比LSQL多了个Hbase,现场一旦出问题需要同时精通hadoop,hbase,spark 2.现在项目大规模上云,还要懂 docker,K8S 3.还要懂你的lucene LXDB postgres 1.轻量化产品,抛去了繁重的hadoop,一个rpm -ivh 搞定单机1分钟,集群5分钟部署完毕 2.麻雀虽小五脏俱全:功能齐全 3.postgres接口,标准postgres SQL 大部分人员都会用,周边配套非常完善. 4.录信也能从繁琐的项目支撑中解脱，大部分精力用在lucene层的研发产品可大可小大:可以上百台机器组成一个集群小:可以一个笔记本4G内存分析上亿数据客户的这500个项目的直接成本投入 1:300人的大数据研发团队 2:200人的项目实施团队 3:全国各地无数的驻场运维人员但你告诉我去哪去找这些大神? lucene 应届生就能用

6. 解决postgres那些问题 postgres:长项是成熟稳定,生态友好,插件多在即席场景我们可对其可加强的地方 A B 索引太多入库太慢更新耗盘点查询/精确查询 1.原生pg索引过多会导致入库效率变得极差 . 150 条/s VS 8万/s； 2.更新效率较差, 原生pg 因为频繁更新SSD硬盘长期负载100%, 换成LXDB 后<20% 1.没有那么多索引可用； 2.现场经常需要对不同维度的索引组合查询,仅少量索引不够用； 3.倒排索引的强项,现场经常500+索引。 C D 全文检索与单机百亿统计分析集群万亿 1.在日志分析里，全文检索是必备功能； 2.全文检索是lucene的强项,但是PG对于全文检索的支持的则比较有限。 1.单机百亿级的秒级检索响应； 2.有一定的并发承载能力； 3.集群版要能够承载万亿数据的规模。

7. 为什么数据格式没选clickhouse 最主要的原因还是 clickhouse的长项是OLAP统计我对lucene比较熟,能自由修改在即席查询与即席分析场景存在的问题 clickhouse 与lucene一样优秀 1.更新与时效性 clickhouse不擅长实时的一条一条的更新,适合批量。而lucene适合实时更新。 2.点查与全文检索并发效率 clickhouse的点查询并发效率远远低于lucene 的倒排索引； clickhouse的全文检索能力较弱。 3.单列的统计是lucene 强项多列可改进单列的基于bitmap的统计效率比clickhouse高, 尤其是大量null值的稀疏列。我们自研的kdi索引,他的倒排特性可以补缺 lucene在多列统计上的性能不足。 4.地理位置轨迹空间查询人脸识别 clickhouse在地址位置轨迹、空间查询和人脸识别方面还不支持。

8. postgres里面不是有ES插件么? 为了集成而集成并不完善 SQL功能有限 A B 仅是一个查询请求的转发接口：1.无集群功能 2.通过网络连接到es效率低,还得维护一个es集群 3.集成度有限,看起来还是两个产品 1.where条件的查询匹配, 传递的还是es的query,跟 sql是两码事 2.查询也仅仅是简单功能, 统计跑不起来,无法通过 PG做大规模的数据导出本体还是es pg里仅是引用 C 建表还是通过es来创建,pg里本质还是一个 dblink,需要配置pg与es 的表名列明映射，查询条件不是where,还是传递的es的query

9. LXDB的架构业务层 Postgresql LXDB 协调节点 LXDB 协调节点 SQL接口 LXDB 协调节点 COPY/INSERT 数据文件 LXDB分片 LXDB分片 LXDB分片 LXDB分片索引层倒排索引 bitmap索引空间索引基础设施层（物理集群/云平台/容器） KDI统计索引

10. 安装部署第一步 : 安装 lxdb 第二步 : 初始化 , 启动 , 停止数据库 rpm -ivh lxdb-2.0.0-1.x86_64.rpm 初始化数据目录:sh init_lxdb.sh 启动 sh start_lxdb.sh 停止 sh stop_lxdb.sh 第三步 : 建表与导入数据 CREATE FOREIGN TABLE example ( ukey text i1 int, i2 int, txt1 text, txt2 text ) SERVER lxdb options(store 'is'); INSERT INTO example(ukey,i1, i2, txt1,txt2) VALUES ('1111',0, 2, 'txt2', 'txt2'); 第四步 : 查询 select * from example limit 10; select count(*) from example ; select * from example where txt1 in ('txt1','txt2') limit 10; select * from example where txt1 not in ('txt1','txt2') limit 10; select * from example where txt1 like 'txt1' limit 10; select * from example where txt1 not like 'txt1' limit 10; select * from example where i2 between 0 and 103 limit 10; select * from example where i2 >= 103 limit 10; select * from example where i2 < 103 limit 10;

11. 支持两种集群模式

12. 麻雀虽小但五脏俱全 LXDB的一些特性 1.支持ARM,支持X86 9.支持全文检索,内置支持多种分词器 2.支持单机版,支持集群 10.支持bitmap统计-50亿/秒/节点 3.单节点最小4G内存,最大4T内存 11.支持采用倒排表统计-10亿/秒/节点 4.默认快照,误删数据可恢复 12.支持kdi通用统计->1亿/秒/节点 5.内存表/硬盘加速/分级缓存 13.支持稀疏列快速统计-null值不占存储不参与运算 6.支持图片与文件存储 14.支持lucene的docvalues进行统计分析 7.地理位置检索\时空碰撞\轨迹匹配 15.支持汇聚列,复制列 8.向量匹配\人脸检索 16.支持高并发更新\累加更新\多值列追加

13. 内存表/硬盘加速/分级缓存索引层倒排索引 bitmap索引存储层空间索引 KDI统计索引 1.每种格式都可单独按表加速； 2.加速介质可以是内存也可以是固态硬盘； 3.可以随时动态热切。行存储列存储大文件存储 1.大领导来视察,要演示,将重要的表加载到内存里； 2.高频访问的表,索引部分放在固态硬盘里； 3.频繁更新的表,将更新索引放在内存里。

14. 多维统计浙江 2010二季度 2010三季度上海 2010一季度保有量（万）大众 56 奔驰 35 宝马 40 大众 58 奔驰 36 宝马 43 大众 62 奔驰 40 宝马 44 大众。。奔驰。。宝马。。品牌维度 56 58 62 35 36 40 40 43 44 2010一季度品牌时间地区时间维度

15. 单列统计上的优势在单列统计分析的场景上,性能非常高-数据结构可选doclist或bitmap 标签分析用户画像稀疏列词典词典里按列的值组织重复的词只存储一份,空值不存储遍历完倒排表,即完成统计倒排表倒排表里,采用跳跃表实现 1.可以结合筛选条件跳跃不需要的数据 2.按块读取,count统计性能非常高 3.性能与lucene的检索性能相当,速度超快,毫秒级,每秒30~50亿

16. 单列统计上存在的问题词典当词典的值的个数太多的时候性能急剧下降 lucene不擅长遍历太长的倒排表涉及太多的词典指针指向变换倒排表当有筛选条件的时候,倒排表的跳跃表存在列存按块存储同样的问题,不能有效的进行skip掉数据块.

17. 解决办法 LXDB也借助这个block, 结合kd tree可以用来排序与分页将字典进行编号将一个block内的倒排表合并并标记上 docid:字典编号每一万个编号组成一个字典BLOCK 这里构建KD TREE进行存储,而因为是倒排存储,故命名为KDI block1 1:2 2:2 3:1 4:2 5:2 block2 9:2 12:2 13:1 84:2 25:2 block3 15:2 32:2 93:1 74:2 45:2

18. KD TREE在统计分析与排序上的优势数据存储份数较少,无需像projection存储多份数据计算过程,采用成块,全数值型计算,无字符串运算参与, 适合CPU,效率高具备列存储的全部优势,也具备倒排索引的全部优点

19. 采用倒排索引实现的人脸索引

20. 采用倒排索引实现的人脸索引 faiss annoy IVF_SQ8H 采用lxdb倒排索引实现的人脸向量索引常规人脸算法的缺点 1.需要经过聚类,计算复杂需要GPU来提升速度 2.索引粒度太粗查询很大程度是暴力扫描 1.入库速度快,512维/1W张人脸,资源占用低 2.有着lucene倒排索引的高效性能,单机50 亿数据,TOP人脸相似度检索,3~5秒 3.目前提供余弦距离与欧式距离两种相识度匹配

21. 峰谷索引合并在索引合并业务中，可以实现类似电力“峰谷电”的 70000 索引合并机制，在峰值较大时，自动延缓大索引的合并来提升入库速度，在峰值较小时再通过后台对大索延缓索引合并存储多个小索引文件 60000 引进行合并。同时采用动态可变的索引合并方式，当入库频率很高时，存储多个小索引文件，而后通过归档进行小索引的合并。 50000 40000 并发量 30000 20000 10000 较为空闲时对小索引文件进行归档合并 0 09:00 10:00 11:00 12:00

22. 区域检索地理位置数据临近存储通过地理位置临近数据临近存储的方式构造硬盘上的连续读取，大幅度的减少随机读取的次数，从而提升查询响应的速度。随机读变顺序读

23. 产品性能数据量入库性能 l 单机版：300-500亿条 l 集群版：万规模实时更新速度：80列/5~8万/秒/节点追加性能:30列 20w+/节点秒, 80列 10w+/节点秒 l 点查:15000次/秒/节点并发性能 l 任意维度多维筛选： 2000次/秒/节点 l 全文检索:500次/秒/节点查询性能统计分析单机百亿数据规模:1~10秒内响应单机十亿数据规模:100ms~1秒内单机一亿数据规模:1~100ms内 bitmap统计处理性能 50亿+/节点秒采用倒排表统计处理性能 10亿+/节点秒 kdi多列统计处理性能 1亿+/节点秒 lucene自身docvalues处理性能取决于硬盘类型与缓存命中率最快是内存盘1亿+/节点秒

24. 应用场景：公安公安云搜通过对海量结构化和非结构化数据进行横向关联与查询，实现文字、图像、声音、视频的无缝对接和立体式展现，搜索方式支持精确检索、模糊检索、组合检索、二次检索，速度达到万亿级数据查询秒级响应。刑侦分析通过展现人员在一定时间内的关系圈，通过实时检索、关联碰撞，为各警种提供智能研判的关系网络，直观展现出与目标人关系密切的相关人，进而挖掘出潜在嫌疑同伙。同住同行同飞分析通过对时空数据的多维分析，实现对于多个人员的航班出行记录、轨道交通出行记录、酒店住宿记录的时空碰撞，找到其中经常同时乘坐同一个航班、同一轨道交通、入住同一酒店的同行人。在疫情防控背景下发挥了巨大作用，能够有效而快速的识别出确诊或疑似或者的接触对象。

25. 应用场景：军队话单分析/网络报文分析根据主要目标人物的话单浏览及话单统计，可以掌握其在某一时间区间内的通话对象，中心度，归属地，运营商，通话频率，通话次数，通话时间，平均通话时长，以及主被叫比例等通话特征。而后通过多维聚合统计、任意维度过滤筛选等功能，在缩短计算时间的同时将话单排列前30-50位的密切联系人作为关系调查的对象。

26. 应用场景：交通交通缉查布控 / 套牌车追踪 / 时空碰撞可供管理人员通过区域形状检索的方式分析车辆、船舶、飞机在一定时间的出行规律和出行轨迹，并且将结构化和非结构化等数据进行碰撞分析，实现对于套牌车的挖掘和追踪。另外，也可以通过轨迹碰撞对轨迹进行相似分析，寻找伴随轨迹。帮助管理人员进行区域交通管制以及可疑车辆的追查。

27. 应用场景：汽车尾气监控/油耗分析通过对海量安装在汽车中的T-BOX上采集的万亿数据进行分析，针对于国六标准的推行，对商用车的尾气数据、油耗数据、加油站地理位置信息进行监控，并提供整体存储和检索分析解决方案，为一汽解放、江淮汽车等主机厂的创新型应用提供坚实基础。

28. 应用场景：金融交易记录分析/决策支撑金融行业有着海量的交易数据，且数据具备高度的时效性，如果需要对这类数据进行多维度的统计分析，借助于facet统计，实时多维分析等功能，以此来实现对于海量数据的实时分析，帮助管理者快速发现交易风险，及时进行策略的调整。

29. 应用场景：电商用户画像/稀疏列/标签分析互联网尤其是电商企业的系统每天都会产生海量的日志数据，这些数据根据用户的个人特征、行为习惯被进行分类。如需对这些海量数据进行分析，就需要能够对数据进行分组统计，而分布式的多节点并行计算、内存计算就能够实现对于各类数据的快速计算分析，确保在1秒内能快速输出结果，以此来满足企业进行用户画像、标签分析的需求。

30. 应用场景：安防人脸撞库/人像比对在反恐场景中，通过对比出现在多个案发地的人脸图像数据，实现人脸撞库，快速比对寻找出反复出现的人员。同时可以通过结合时空碰撞对比，快速锁定在多一时间、同一地点、多次出现的可疑人员。也可实现将多个案发地周边的人像进行碰撞比对，从而发现是否存在同伙。在实时高并发支持下可以实现多办案人员快速检索有效信息，进而快速确定嫌疑人。

31. 未来计划 1.双表关联是lucene的强项；分组统计与计算本质还是hashmap, 性能远远低于bitmap： 1.遍历bitmap没必要按位遍历； 2.cpu的L1 L2 L3 CACHE。 2.多表目前还找不到好的方案；内存计算多表关联与图数据库 1.公安国安,基因生物等行业都可以使用； 2.不能使用字典,定长切词的膨胀率一直得不到很好的解决。基于KD- TREE的空间划分二进制搜索 3.bloomfilter结合kd tree尝试下； 4.图库本质也是关联。 1.兼具正排倒排列存的全部优点； 2.适合统计,检索,排序,关联； 3.空间划分成块,适合内存计算。

32. 联系我们专注大数据底层技术创新母延年微信 LSQL LXDB 迅禄一体机录信数软公众号数据解析系统网址：www.luxindb.com 邮箱：info@lucene.xin 联系方式：025-87736590 通讯地址：南京市江宁区天琪科技大厦2栋802

33.