震精 - 数据库还能这样玩 - 三十六计 (上)

    xiaoxiao2025-11-07  8

    标签

    PostgreSQL , 三十六计


    背景

    PostgreSQL 三十六计 - 上

    1. GIN复合倒排索引。

    前端人机交互,任意字段组合查询需求,根本不知道用户会对哪些字段进行检索,直击开发痛点。

    PostgreSQL GIN复合倒排索引,一个索引,解救开发人员。

    2. range类型。

    范围类型+GIST索引,传感器多条记录压缩为单条记录范围表述;支持智能DNS、金融、气象、传感器数据等高效范围匹配。

    例如1个传感器5分钟产生了10000条记录,在1.1-1.4之间波动,可以存储为[1.1, 1.4]一条记录,而不是1万条记录。

    匹配时支持 $? @< 字段 高效率索引检索。

    3. PostGIS。

    不仅有经纬度、点面判断、距离判断。还有栅格、路径规划、图层、拓扑、地址与经纬度MAPPING、空间类型索引与操作符。不仅有二维数据。还有多维数据。不仅支持串行。还有多核并行。PostGIS服务于军用、民用、科研几十年,覆盖面广、开发框架支持丰富,值得信赖。

    4. 异步消息。

    在物联网中,结合PostgreSQL的流式计算,当传感器上报的数据达到触发事件的条件时,往异步消息通道发送一则消息,应用程序实时的接收异步消息,发现异常。

    即节省了空间(结合流式处理,完全可以轻量化部署),又能提高传播的效率(一对多的传播),程序设计也可以简单化。

    例如zabbix监控系统,如果每秒产生千万级的新值(new values per second),传统的zabbix处理会非常吃力,除了插入吃力(实际上大部分插入是无用功,正常的值完全可以适应范围类型压缩插入,异常的值才是有效值),主动查询询问式的方式也很吃力。

    使用PostgreSQL流式计算功能,仅仅当值有问题(根据流规则判断)时,向异步消息通道发送异常消息,WEB服务仅需监控通道即可,无需频繁的查询数据库来获取是否有异常。PostgreSQL单机就可以支持更高的NVPS,例如百万级/s是非常轻松的。

    5. 流式实时数据处理。

    解决监控、物联网、金融 等业务场景实时计算和事件响应需求。

    定义stream(流),然后基于stream定义对应的transform(事件触发模块),以及Continuous Views(实时统计模块)

    数据往流里面插入,transform和Continuous Views就在后面实时的对流里的数据进行处理,对开发人员来说很友好,很高效。

    值得庆祝的还有,所有的接口都是SQL操作,非常的方便,大大降低了开发难度。

    6. PostGIS、图像特征值存储和处理(imgsmlr插件)。

    互联网、AR红包、虚拟现实与GIS结合、广告营销 等业务场景。既有地理位置数据,又有图像处理需求。

    例如AR红包是GIS与图像、社交、广告等业务碰撞产生的一个全新业务场景。

    需要做广告投放的公司,可以对着广告牌,或者店铺中的某个商品拍照,然后藏AR红包。

    要找红包的人,需要找到这家店,并且也对准藏红包的物体拍摄,比较藏红包和找红包的两张图片,就可以实现抢红包的流程。

    PostGIS处理地理信息,imgsmlr处理图像,完美支持以上场景。

    7. 火眼金睛,实时辨别相似数据。

    在搜索引擎、数据公司、互联网中都会有网络爬虫的产品,或者有人机交互的产品。

    有人的地方就有江湖,盗文、盗图的现象屡见不鲜,而更惨的是,盗图和盗文还会加一些水印。

    也就是说,你在判断盗图、盗文的时候,不能光看完全一致,可能要看的是相似度。

    这给内容去重带来了很大的麻烦。

    PostgreSQL数据库整合了相似度去重的算法和索引接口,可以方便、高效的处理相似数据。

    如相似的数组、相似的文本、相似的分词、相似的图像的搜索和去重,根据图片鉴黄等等。

    8. 任意字段模糊查询杀手锏,GIN, GiST索引。

    PostgreSQL可以针对整条记录、指定字段、多个字段,建立全文索引。

    支持高效的全文检索;支持%x%的前后全模糊查询;支持正则表达式查询;

    以上查询全部支持索引,亿级数据,毫秒级响应速度。

    9. 云端高招,冷热分离、多实例数据共享。

    助力分析师,快速建模与试错。

    对传统企业来说,OLTP系统大多数使用的是Oracle等商业数据库,使用PostgreSQL可以与Oracle的功能、性能、SQL语法等做到高度兼容。

    而对于分析场景,使用MPP产品HybridDB(基于GPDB),则可以很好的解决PB级以上的AP需求。

    OLTP与OLAP的数据,通过OSS_EXT共享,多个实例可以同一份数据,分析师在分析时,不影响生产实例。

    10. OLAP大补丸。多核并行、向量计算、JIT、列式存储、聚合算子复用。

    OLAP系统,单个任务需要对大量的数据进行运算。

    多核并行,解决大数据运算时的CPU瓶颈。

    向量计算,使用CPU缓存,批量进行向量化计算,不借助外力的情况下,提升10倍以上性能。

    JIT,大幅降低记录数庞大运算时,频繁函数式调用引入的切换开销。大幅提升性能。

    列存储,大幅降低行存储deform引入的开销。大幅降低扫描的数据量,大幅降低缓存的使用量。

    聚合算子复用,大幅降低多个聚合函数,CPU的计算开销。例如(sum,avg,count,min,max)

    11. 实时用户画像与圈人。

    助力广告主实时营销。

    推荐系统的三个核心问题

    精准,属于数据挖掘系统的事情,使用PostgreSQL MADlib机器学习库可以实现。

    实时,实时的更新标签,在数据库中进行流式处理,相比外部流处理的方案,节约资源,减少开发成本,提高开发效率,提高时效性。

    高效,使用PostgreSQL以及数组的GIN索引功能,实现在万亿USER_TAGS的情况下的毫秒级别的圈人功能。

    12. 危化品管理行业数据库痛点和解决之道。

    危化品的监管,包括位置信息处理、点面判断、按距离搜索、化学数据处理。

    危化品种类繁多。包括如常见的易爆、易燃、放射、腐蚀、剧毒、等等。

    由于危化品的危害极大,所以监管显得尤为重要,

    1. 生产环节

    将各个原来人工监控的环节数字化,使用 传感器、流计算、规则(可以设置为动态的规则) 代替人的监管和经验。

    2. 销售环节

    利用社会关系分析,在销售环节挖掘不法分子,挖掘骗贷、骗保的虚假交易。利用地理位置跟踪,掌控整个交易的货物运输过程。

    3. 仓储环节

    仓储环节依旧使用传感器、流计算、应急机制对仓管的产品进行实时的监管,而对于危化品本身,我们已经不能使用普通的数据类型来存储,很幸运的是在PostgreSQL的生态圈中,有专门支持化学行业的RDKit支持,支持存储化合物类型,以及基于化合物类型的数据处理 (包括化学反应,分解等等)。

    4. 运输环节

    在危化品的运输环节,使用传感器对货车、集装箱内的危化品的指标进行实时的监控,使用流式数据库pipelineDB流式的处理传感器实时上报的数据;使用PostgreSQL+PostGIS+pgrouting 对于货车的形式路径进行管理,绕开禁行路段、拥堵路段。

    当出现事故时,使用PostgreSQL的GIS索引,快速的找出附近的应急救助资源(如交警、消防中队、医院、120)。

    同时对危化品的货物存储,使用化学物类型存储,可以对这些类型进行更多的约束和模拟的合成,例如可以发现化学反应,防止出现类似天津爆炸事件。

    5. 消耗环节

    增加剩余量的监控,在闭环中起到很好的作用,达到供需平衡,避免供不应求,或者供过于求的事情发生。

    6. 动态指挥中心

    在给生产、仓库、物流配送、消耗环节添加了终端、传感器后,就建立了一个全面的危化品监管数据平台。 构建实时的监管全图。

    7. 缉毒、发现不法分子等

    通过社会关系学分析,结合RDKit插件,在数据库中存储了人的信息,存储了人与化学物的关系(比如购买过),然后,根据社会关系学分析,将一堆的化合物(原材料)结合起来,看看会不会发生反应,生成毒品或危化品。从而发现不法分子。

    相关资源:python入门教程(PDF版)
    最新回复(0)