数据库选型十八摸之PostgreSQL-致架构师、开发者

数据库选型⼗⼋摸之PostgreSQL-致架构师、开发者PostgreSQL,数据库特性,数据库应⽤场景分析,数据库选型背景数据库对于⼀家企业来说，相⽐其他基础组件占据⽐较核⼼的位置。有很多企业由于最初数据库选型问题，导致⼀错再错，甚⾄还有为此付出沉痛代价的。数据库的选型⼀定要慎重，但是这么多数据库，该如何选择呢？我前段时间写过⼀篇关于数据库选型的⽂章，可以参考如下另外，PostgreSQL这个数据库这些年的发展⾮常的迅猛，虽然国内还跟不上国外的节奏，但是相信国⼈逐渐会融合进去。所以我专门针对PostgreSQL提炼了它的⼀些应⽤场景（普通的应⽤场景就不举例了），希望对你的选型可以起到⼀定的参考作⽤。1任意字段组合查询-ERP、电商、⽹站、⼿机APP等业务场景在⼀些前端的⼈机交互页⾯中，经常会有很多选择框，让⽤户进⾏选择，这些选择框可能对应的是数据库表中的不同字段。这种画⾯经常出现在ERP，电商，⽹站，⼿机APP等场景中。对于开发⼈员来说是⼀件很头疼的事情，因为不知道该对哪些字段创建索引，或者⼲脆对所有字段都建⽴索引，给数据库带来较⼤的性能和维护的问题。PostgreSQL中有两个技术(gin,bloom索引)，可以完美的解决这类业务场景的问题。2⾼并发、⾼效率范围查询-⾦融、物联⽹、智能DNS等业务场景有些场景，经常要对值进⾏范围的⽐对。⽐如物联⽹，对传感器上传的值，进⾏范围⽐对。智能DNS，需要对来源IP进⾏判断，并找出其落在哪个IP地址段内。⾦融⾏业，经常要设置⼀些指标范围，时刻判断指数是否落在某个区间，当⼀些指数落在某个范围区间时，触发下⼀步的操作（⽐如买⼊或卖出）。传统的两个字段+复合B树的索引，效率低下，通常8核的机器只能达到3000多的QPS。PostgreSQL通过(range类型和gist,sp-gist索引)，可以将效率提升20多备，8核的机器可以达到8万的QPS。3⽹格化、⽮量化地图-地理类应⽤、LBS社交、导航等业务场景⼈们为了更好的描述⼀个东西，有⼀种将⼤化⼩的思路，⽐如时钟被分为了12个区域，每个区域表⽰⼀个⼩时，然后每个⼩的区域⼜被划分为更⼩的区域表⽰分钟。在GIS系统中，也有类似的思想，⽐如将地图划分成⽹格。通过编码来简化地理位置的判断（⽐如相交，包含，距离计算等），但是请注意使⽤⽹格带来的问题，⽐如精度的问题，⽹格的⼤⼩决定了精度，⼜⽐如相对坐标的问题，可能⽆法描述清楚边界的归属。PostgreSQL可以提供给你更好的选择，⽮量化的运算。1.在PostGIS中虽然也⽀持⽹格对象的描述⽅式，但是并不是使⽤这种⽅法来进⾏⼏何运算（⽐如相交，包含，距离计算等），所以不存在类似的精度问题，个⼈建议没有强需求的话，不必做这样的⽹格转换。2.如果是多种精度地图的切换（⽐如多个图层，每个图层代表⼀种地图精度），建议使⽤辐射的⽅式逐渐展开更精细的图层，以点为中⼼，逐渐辐射。（很多专业的地图软件是这样做的）4异步消息-物联⽹、WEB、⾦融等业务场景电波表是⼀个⾮常典型的⼴播应⽤，类似的还有组播（注意不是主播哦），类似的应⽤也很多，⽐如⼴播电视，电台等。在数据库中，其实也有类似的应⽤，⽐如利⽤PostgreSQL数据库的异步消息机制，往数据库的消息通道发送数据，应⽤程序可以监听对应的消息通道，获取异步消息数据。通过异步消息在数据库中实现了⼀对多的⼴播效果。在物联⽹中，也可以有类似的应⽤，例如结合PostgreSQL的流式计算，当传感器上报的数据达到触发事件的条件时，往异步消息通道发送⼀则消息，应⽤程序实时的接收异步消息，发现异常。这样做的好处很多，即节省了空间（结合流式处理，完全可以轻量化部署），⼜能提⾼传播的效率（⼀对多的传播），程序设计也可以简单化。在⾦融⾏业，也可以有类似的实现，⽐如对数据的实时流式监测，数据流经⼀系列的规则，触发异步消息。⼀个例⼦这个例⼦使⽤PostgreSQL的异步消息通知机制（notify/listen），以及数据库的触发器，PostGIS地理库插件，结合nodejs,socket.io实现了⼀个实时的客户端GPS坐标更新的⼩业务。1.在数据库中新增GPS坐标，数据库端编写的"⼩程序"会⾃动发送异步消息给客户端，客户端马上就展⽰了当前新增的坐标2.修改GPS坐标，数据库端编写的"⼩程序"会⾃动发送异步消息给客户端，客户端刷新了当前坐标3.删除GPS坐标，数据库端编写的"⼩程序"会⾃动发送异步消息给客户端，客户端刷新了当前坐标详见5流式实时数据处理-物联⽹、⾦融等业务场景在物联⽹、⾦融⾏业中，有⼤量的数据产⽣，同时需要实时的对数据进⾏处理。pipelinedb是基于PostgreSQL的⼀个流式计算数据库，纯C代码，效率极⾼(32c机器,单机⽇处理流⽔达到了250.56亿条)。同时它具备了PostgreSQL强⼤的功能基础，正在掀起⼀场流计算数据库制霸的腥风⾎⾬。在物联⽹(IoT)有⾮常⼴泛的应⽤场景，越来越多的⽤户开始从其他的流计算平台迁移到pipelineDB。pipelinedb的⽤法⾮常简单，⾸先定义stream(流)，然后基于stream定义对应的transform(事件触发模块)，以及ContinuousViews(实时统计模块)数据往流⾥⾯插⼊，transform和ContinuousViews就在后⾯实时的对流⾥的数据进⾏处理，对开发⼈员来说很友好，很⾼效。值得庆祝的还有，所有的接⼝都是操作，⾮常的⽅便，⼤⼤降低了开发难度。除此之外，PostgreSQL的undotable，batch调度,异步消息结合，也能达到与pipeline⼀样的效果。6GIS、图像近似度运算-互联⽹、AR红包、虚拟现实与GIS结合、⼴告营销等业务场景AR红包是GIS与图像、社交、⼴告等业务碰撞产⽣的⼀个全新业务场景。需要做⼴告投放的公司，可以对着⼴告牌，或者店铺中的某个商品拍照，然后藏AR红包。要找红包的⼈，需要找到这家店，并且也对准藏红包的物体拍摄，⽐较藏红包和找红包的两张图⽚，就可以实现抢红包的流程。可以想象的空间很多。使⽤的核⼼技术是GIS（地理位置）与图像近似度⽐较。PostgreSQL对于这两项技术都可以很好的⽀持。7相似内容搜索、去重-互联⽹、数据公司、搜索引擎等业务场景在搜索引擎、数据公司、互联⽹中都会有⽹络爬⾍的产品，或者有⼈机交互的产品。有⼈的地⽅就有江湖，盗⽂、盗图的现象屡见不鲜，⽽更惨的是，盗图和盗⽂还会加⼀些⽔印。也就是说，你在判断盗图、盗⽂的时候，不能光看完全⼀致，可能要看的是相似度。这给内容去重带来了很⼤的⿇烦，不过还好，PostgreSQL数据库整合了相似度去重的算法和索引接⼝，可以⽅便的处理相似数据。⽐如相似的数组、相似的⽂本、相似的分词、相似的图像的搜索和去重等等。⼜⽐如鉴黄。8任意字段模糊查询-互联⽹、前端页⾯、搜索引擎等业务场景在⼀些应⽤程序中，可能需要对表的所有字段进⾏检索，有些字段可能需要精准查询，有些字段可能需要模糊查询或全⽂检索。⽐如⼀些前端页⾯下拉框的勾选和选择。这种需求对于应⽤开发⼈员来说，会很蛋疼，因为写SQL很⿇烦，例⼦：之前写过⼀篇⽂章来解决这个问题使⽤的是全⽂检索，⽽当⽤户的需求为模糊查询时？如何来解决呢？PostgreSQL中可以很好的解决这个问题，适⽤于任意字符（包括英⽂、中⽂、等等）。9在线处理、离线分析、在线分析混合需求-互联⽹、传统企业、⾦融等业务场景随着IT⾏业在更多的传统⾏业渗透，我们正逐步的在进⼊DT时代，让数据发挥价值是企业的真正需求，否则就是⼀堆废的并且还持续消耗企业⼈⼒，财⼒的数据。传统企业可能并不像互联⽹企业⼀样，有⼤量的开发⼈员、有⼤量的技术储备，通常还是以购买IT软件，或者以外包的形式在存在。数据的核⼼-数据库，很多传统的⾏业还在使⽤传统的数据库。随着IT向更多⾏业的渗透，数据类型越来越丰富（诸如⼈像、X光⽚、声波、指纹、DNA、化学分⼦、图谱数据、GIS、三维、多维等等。。。），数据越来越多，怎么处理好这些数据，怎么让数据发挥价值，已经变成了对IT⾏业，对数据库的挑战。对于互联⽹⾏业来说，可能对传统⾏业的业务并不熟悉，或者说互联⽹那⼀套技术虽然在互联⽹中能很好的运转，但是到了传统⾏业可不⼀定，⽐如说⽤于科研、军⼯的GIS，和互联⽹常见的需求就完全不⼀样。除了对数据库功能⽅⾯的挑战，还有⼀⽅⾯的挑战来⾃性能⽅⾯，随着数据的爆炸，分析型的需求越来越难以满⾜，主要体现在数据的处理速度⽅⾯，⽽常见的hadoop⽣态中的处理⽅式需要消耗⼤量的开发⼈员，同时并不能很好的⽀持品种繁多的数据类型，即使GIS可能也⽆法很好的⽀持，更别说诸如⼈像、X光⽚、声波、指纹、DNA、化学分⼦、图谱数据、GIS、三维、多维等等。那么我们有什么好的⽅法来应对这些⽤户的痛处呢？且看ApsaraDB产品线的PostgreSQL与HybridDB如何来⼀招左右互搏，左⼿在线事务处理，右⼿数据分析挖掘，解决企业痛处。对传统企业来说，OLTP系统⼤多数使⽤的是Oracle等商业数据库，使⽤PostgreSQL可以与Oracle的功能、性能、SQL语法等做到⾼度兼容。⽽对于分析场景，使⽤MPP产品HybridDB(基于GPDB)，则可以很好的解决PB级以上的AP需求。对于中⼩型企业，数据量在10TB量级的，分析型的事务甚⾄也可以交给PostgreSQL来处理。因为它具备了多核并⾏处理的能⼒、列存储、JIT、算⼦复⽤、甚⾄向量化执⾏等技术，相⽐传统的数据库，在OLTP⽅⾯有10倍以上的性能提升。(同时还可以使⽤LLVM技术，GPU卡\FPGA卡来硬件加速分析)10⽤户群体搜索、根据标签圈⼈-电商、⼴告投放等业务场景电商推荐系统部分需求介绍⽐如⼀家店铺，如何找到它的⽬标消费群体？要回答这个问题，⾸先我们需要收集⼀些数据，⽐如：1.这家店铺以及其他的同类店铺的浏览、购买群体。我们在逛电商时，会产⽣⼀些⾏为的记录，⽐如在什么时间，逛了哪些店铺，看了哪些商品，最后在哪家店铺购买了什么商品。然后，对于单个商店来说，有哪些⽤户逛过他们的商店，购买过哪些商品，可以抽取出⼀部分⼈群。2.得到这些⽤户群体后，筛选出有同类消费欲望、或者具备相同属性的群体。对这部分⼈群的属性进⾏分析，可以获得⼀个更⼤范围的群体，从⽽可以对这部分群体进⾏营销。以上是对电商推荐系统的两个简单的推理。PostgreSQL,HybridDB解决了推荐系统的三个核⼼问题精准，属于数据挖掘系统的事情，使⽤PostgreSQL,Greenplum的MADlib机器学习库可以实现。实时，实时的更新标签，在数据库中进⾏流式处理，相⽐外部流处理的⽅案，节约资源，减少开发成本，提⾼开发效率，提⾼时效性。⾼效，使⽤PostgreSQL以及数组的GIN索引功能，实现在万亿USER_TAGS的情况下的毫秒级别的圈⼈功能。11位置信息处理、点⾯判断、按距离搜索、化学数据处理-危化品监管等业务场景危化品的种类繁多。包括如常见的易爆、易燃、放射、腐蚀、剧毒、等等。由于危化品的危害极⼤，所以监管显得尤为重要，1.⽣产环节将各个原来⼈⼯监控的环节数字化，使⽤传感器、流计算、规则（可以设置为动态的规则）代替⼈的监管和经验。2.销售环节利⽤社会关系分析，在销售环节挖掘不法分⼦，挖掘骗贷、骗保的虚假交易。利⽤地理位置跟踪，掌控整个交易的货物运输过程。3.仓储环节仓储环节依旧使⽤传感器、流计算、应急机制对仓管的产品进⾏实时的监管，⽽对于危化品本⾝，我们已经不能使⽤普通的数据类型来存储，很幸运的是在PostgreSQL的⽣态圈中，有专门⽀持化学⾏业的RDKit⽀持，⽀持存储化合物类型，以及基于化合物类型的数据处理（包括化学反应，分解等等）。4.运输环节⼩结⼀下，在危化品的运输环节，使⽤传感器对货车、集装箱内的危化品的指标进⾏实时的监控，使⽤流式数据库pipelineDB流式的处理传感器实时上报的数据；使⽤PostgreSQL+PostGIS+pgrouting对于货车的形式路径进⾏管理，绕开禁⾏路段、拥堵路段。当出现事故时，使⽤PostgreSQL的GIS索引，快速的找出附近的应急救助资源（如交警、消防中队、医院、120）。同时对危化品的货物存储，使⽤化学物类型存储，可以对这些类型进⾏更多的约束和模拟的合成，例如可以发现化学反应，防⽌出现类似天津爆炸事件。5.消耗环节增加剩余量的监控，在闭环中起到很好的作⽤，达到供需平衡，避免供不应求，或者供过于求的事情发⽣。6.动态指挥中⼼在给⽣产、仓库、物流配送、消耗环节添加了终端、传感器后，就建⽴了⼀个全⾯的危化品监管数据平台。构建实时的监管全图。7.缉毒、发现不法分⼦等通过社会关系学分析，结合RDKit插件，在数据库中存储了⼈的信息，存储了⼈与化学物的关系（⽐如购买过），然后，根据社会关系学分析，将⼀堆的化合物（原材料）结合起来，看看会不会发⽣反应，⽣成毒品或危化品。从⽽发现不法分⼦。12图式数据搜索-⾦融风控、公安刑侦、社会关系、⼈脉分析等业务场景⼈类是群居动物，随着⼈⼝的增长，联络⽅式越来越⽆界化，⼈与⼈，⼈与事件，⼈与时间之间形成了⼀张巨⼤的关系⽹络。有许多场景就是基于这张巨⼤的关系⽹络的，⽐如。1.猎头挖⼈作为IT⼈⼠或者猎头、HR，对Linkedin⼀定不陌⽣，领英⽹实际上就是⼀个维护⼈际关系的⽹站。通过搜索你的⼀度⼈脉，可以找到与你直接相关的⼈，搜索2度⼈脉，可以搜索到与你间接相关的⼈。当然你还可以继续搜索N度⼈脉，不过那些和你可能就不那么相关了。如果你知道和美⼥范冰冰隔了⼏度⼈脉，是不是有点⼼动了呢？其实在古代，就有这种社会关系学，还有这种专门的职业，买官卖官什么的，其实都是⼈脉关系⽹。看过红楼梦的话，你会发现那家⼦⼈怎么那么多亲戚呢？2.公安破案公安刑侦学也是⼀类⼈脉相关的应⽤，只是现在的关系和⾏为越来越复杂，这种关系也越来越复杂，原来的⼈能接触的范围基本上就靠2条腿，顶多加匹马。现在，⼿机，电脑，ATM机，超时，摄像头，汽车等等，都通过公路⽹、互联⽹连接在⼀起。⼀个⼈的⾏为，产⽣的关系会更加的复杂，单靠⼈⾁的关系分析，刑侦难度变得越来越复杂。3.⾦融风控⽐如银⾏在审核贷款资格时，通常需要审核申请⼈是否有偿还能⼒，是否有虚假消息，⾏为习惯，资产，朋友圈等等。同样涉及到复杂的⼈物关系，⼈的⾏为关系分析等等。图⽚来⾃互联⽹此类围绕⼈为中⼼，事件为关系牵连的业务催⽣了图数据库的诞⽣。⽬前⽐较流⾏的图数据库⽐如neo4j，等。详见PostgreSQL是⼀个功能全⾯的数据库，其中就有⼀些图数据库产品的后台是使⽤PostgreSQL的，例如OpenCog，Cayley等。除了这些图数据库产品，PostgreSQL本⾝在关系查询，关系管理⽅⾯也⾮常的成熟，⼗亿量级的关系⽹数据，3层关系运算仅需毫秒。还可以⽤于运算⼈与⼈之间的最短关系，穷举关系等。主要⽤到的技术plpgsql服务端编程、异步消息、数组、游标等。13⼤量数据的求差集、最新数据搜索,最新⽇志数据与全量数据的差异⽐对,递归收敛扫描-物联⽹、数据同步、数据清洗、数据合并等业务场景有⼀个这样的场景，⼀张⼩表A，⾥⾯存储了⼀些ID，⼤约⼏百个到万个。（⽐如说巡逻车辆ID，环卫车辆的ID，公交车，微公交的ID）。另外有⼀张⽇志表B，每条记录中的ID是来⾃前⾯那张⼩表的，但不是每个ID都出现在这张⽇志表中，⽐如说⼀天可能只有⼏⼗个ID会出现在这个⽇志表的当天的数据中。（⽐如车辆的⾏车轨迹数据，每秒上报轨迹，数据量就⾮常庞⼤，但是每天出勤的车辆有限）。那么我怎么快速的找出今天没有出现的ID呢。（哪些巡逻车辆没有出现在这个⽚区，是不是偷懒了？哪些环卫车辆没有出⾏，哪些公交或微公交没有出⾏）？selectidfromAwhereidnotin(selectidfromBwheretimebetween?and?);selecta.idfromaleftjoinbon(a.id=b.aid)whereb.*isnull;这个QUERY会很慢，通常需要⼏百秒到⼏⼗秒，有什么优化⽅法呢。通过PostgreSQL的递归查询，可以⾼效的解决这个问题(在⼏亿记录中筛选出与⼏万记录的逻辑差集)。优化后只需要10毫秒左右。同样的⽅法，还可以⽤于数据清洗与合并的场景，⽐如在物联⽹的环境中，每个传感器，每个⼩时会上报若⼲条数据（有新增的，有更新的，有删除的指标等），对于同⼀个KEY，后台的应⽤程序只关⼼最后⼀条记录。使⽤PostgreSQL的递归收敛，每秒可以清洗或合并千万量级的数据。除了物联⽹，同样适⽤于数据库之间的数据逻辑同步。14数据⼀致性分享、数据泵-跨业务平台实时分享数据等业务场景在IoT的场景中，有流式分析的需求，也有存储历史数据的需求，同时还有数据挖掘的需求，搜索引擎可能也需要同⼀份数据，还有⼀些业务可能也要⽤到同⼀份数据。但是如果把数据统统放到⼀个地⽅，这么多的业务，它们有的要求实时处理，有的要求批量处理，有的可能需要实时的更新数据，有的可能要对⼤数据进⾏分析。显然⼀个产品可能⽆法满⾜这么多的需求。就好⽐数据库就分了关系数据库，NOSQL，OLTP场景，OLAP场景⼀样。也是因为⼀个产品⽆法满⾜所有的业务需求。在企业中通常是借助数据冗余来解决各类场景的需求。那么如何才能够更好的分享数据，保证数据的⼀致性，提⾼分享的实时性呢？10万级别左右的机器，PostgreSQL的数据吞吐量可以达到100万条/s以上，同时数据库本⾝具备了严格的可靠性和⼀致性保证。PostgreSQL为分享数据提供了插槽的概念，每个插槽对应⼀个⽬标端，⽀持断点续传，⽀持多个⽬标端。⽤于流式的分享数据是⾮常好的选择。15分词搜索、模糊搜索、相似度搜索-电商、公安、传统企业等业务场景看刑侦剧经常有看到⼈物拼图，然后到图库搜索的，以前可能靠的是⼈⾁，使⽤PG，可以靠数据库的图形近似度搜索功能。⽽对于⽂本搜索，⼤家⼀定会想到分词，⽐如搜索引擎、淘宝的商品内容搜索、⽂章的关键字搜索等等。PostgreSQL内置了分词引擎，可以很好的满⾜这类搜索的需求。但是千万不要以为分词可以搞定⼀切需求，⽐如这样的需求就搞不定。helloworld打成了helloword或者hellow0rld，你要让数据库匹配出来，怎么搞？⼜或者你的业务需要写正则进⾏匹配，怎么搞？⽐如⼀些域名的查询，可能你只想输⼊其中的⼀个部分来搜索，如果firefox可以匹配。甚⾄更变态的fi[a-z]{1}e.*?.??，这样的查询。数据量⼩，并发⼩时，这种查询是可以忍受全表扫描和CPU处理过滤的。但是想想⼀下，你是⼀个⽇请求过亿的业务，或者数据量亿级别的，全表扫描和CPU的开销会让你疯掉的。PostgreSQL完美的解决了这类变态的需求。1.使⽤PostgreSQLregexp库，将正则转换为NFA样式（图形化词组）。2.将NFA样式再进⾏转换，转换为扩展的图形样式(trigrams)，包括拆分后的查询词组与NOT词组。3.简化，过滤不必要的trigrams。4.打包为TrgmPackedGraph结构，⽀持GIN,GIST索引的检索。还有⼀种场景，⽐如⼝⾳纠正、⼝⾳相似度搜索。16⽂本分析、⼈物画像-电商、公安、传统企业、⼴告商等业务场景在⽇常的⽣活中，我们可能会经常需要⼀些像相近、相仿、距离接近、性格接近等等类似这样的需求，对数据进⾏筛选。在PostgreSQL中，这些场景都⽀持索引排序和检索。⽐如收集了⼈群的各种喜好的数据，通过对关联数据的聚类分析，或者按喜好的重叠度进⾏排序，找出⽬标⼈群。这⾥就涉及到⽂本的近似度分析，PostgreSQL的⽂本分析功能可以很好的⽀持此类场景。17⾼并发更新少量记录-电商、票务系统等业务场景秒杀在商品交易中是⼀个永恒的话题，从双⼗⼀，到⼀票难求，⽐的仅仅是⼿快吗？其实对于交易平台来说，⾯对的不仅仅是⼈⾁，还有很多脚本，外挂⾃动化的抢购系统，压⼒可想⽽知。秒杀的优化⼿段很多，就拿数据库来说，有⽤排队机制的，有⽤异步消息的，有⽤交易合并的。今天我要给⼤家介绍⼀种更极端的秒杀应对⽅法，裸秒。⽬前可能只有PostgreSQL可以做到裸秒，也即是说，来吧，⼀起上。PostgreSQL提供了⼀种adlock，可以让⽤户尽情的释放激情，以⼀台32核64线程的机器为例，每秒可以获取、探测约130万次的adlock。试想⼀下，对单条记录的秒杀操作，达到了单机100万/s的处理能⼒后，秒杀算什么？100台机器就能处理1亿/s的秒杀请求。18实时⽤户画像-电商、实时⼴告、实时营销、⾦融等业务场景⽤户画像在市场营销的应⽤重建中⾮常常见，已经不是什么新鲜的东西，⽐较流⾏的解决⽅案是给⽤户贴标签，根据标签的组合，圈出需要的⽤户。通常画像系统会⽤到宽表，以及分布式的系统。宽表的作⽤是存储标签，例如每列代表⼀个标签，但是通常数据库到2000个列基本就是极限了，上万TAG的话，只能使⽤多表JOIN来实现，效率较差。另⼀⽅⾯，使⽤宽表(甚⾄列存储)，标签的筛选性能也⽐较差（⽆法达到实时级别）。以PostgreSQL数据库为基础，给⼤家讲解⼀下更加另类的设计思路，以BIT来存储⽤户，每⾏⼀个TAG的⽅式。10万亿级TAG/users，毫秒级圈⼈。19动态规划-物流配送、打车软件、导航软件、出⾏软件、⾼速、⾼铁等业务场景每年双⼗⼀的交易额都创新⾼，今年也不例外，双⼗⼀⼏乎成了各种IT系统的⼤考，物流也不例外。每次双⼗⼀快递⼏乎都被爆仓，但是随着技术的发展，今年，听说双⼗⼀刚过，⼩伙伴们的包裹都快收到了。今天，来给⼤家分享⼀下物流与背后的数据库技术，当然我讲的还是PostgreSQL,Greenplum,PostGIS⼀类，⼤伙了解我的。物流⾏业是被电⼦商务催⽣的产业之⼀。快件的配送和揽件的调度算法是物流⾏业⼀个⾮常重要的课题，直接关系到配送或揽件的时效，以及物流公司的运作成本。好的算法，可以提⾼时效，降低成本，甚⾄可以更好的调动社会资源，就像滴滴打车⼀样，也许能全民参与哦。以后也许上班路途还能顺路提供快递服务呢。以物流⾏业为例，PostgreSQL与Greenplum为物流⾏业应⽤提供了包括机器学习、路径规划、地理位置信息存储和处理等基础服务。20流式同步多副本、极致数据可靠性-⾦融、传统企业、互联⽹等业务场景传统的⾦融⾏业⾼度依赖共享存储来解决数据库的⾼可⽤，数据0丢失以及异地容灾的场景。共享存储的解决⽅案价格昂贵，对⼚商的依赖较⼤。PostgreSQL基于同步流复制的任意副本解决⽅案，在解决0丢失，⾼可⽤以及容灾的问题的同时，还可以提供只读的功能。相⽐传统的存储解决⽅案，优势更加明显。21块级瘦索引-物联⽹、⾦融、⽇志类数据等业务场景在物联⽹、⾦融、⽇志类型场景中，数据持续不断的产⽣，对于堆存储来说，有线性相关的特点。例如，时间字段往往和物理存储的顺序具有线性相关性。例如，有⼀些⾃增字段，也和堆存储的物理顺序线性相关。对与物理存储线性相关的字段（时间，⾃增字段），PostgreSQL提供了⼀种BRIN块级范围索引，索引中存储了对应数据块中的字段统计信息（例如最⼤值，最⼩值，平均值，记录数、SUM，空值个数等）这种索引很⼩，因为索引的粒度是连续的块，⽽不是每条记录。通常⽐BTREE索引⼩⼏百倍。如果字段的线性相关性很好，进⾏范围查询或者精确检索时，效率⾮常⾼。对于统计查询，也可以使⽤BRIN索引，提⾼分析统计的效率。22持续数据写⼊，⾼效、0丢失-运营商⽹关、物联⽹、IT系统FEED等业务场景在运营商⽹关、物联⽹的⼯业数据采集和处理，IT系统的FEED等业务场景中，数据产⽣的量⾮常庞⼤，这些数据要在保证可靠性的情况下，快速的⼊库。对于PostgreSQL来说，使⽤中端x86服务器(通常在10万以内，32核，SSD+SATA结合)上的数据插⼊速度（⽬标表包含⼀个brin索引），实际测试可以达到每天上百TB的写⼊。从⽽以较⾼的性价⽐，满⾜此类业务场景的需求。23时序数据有损压缩-时序、物联⽹、FEED数据、⾦融等业务场景在物联⽹、⾦融、FEED等场景中，往往有⼤批量的指标数据产⽣并进⼊数据库，通常包含时间、值两个字段。这些数据由于量⾮常庞⼤，⽽且就像⾳频⼀样，实际上是可以对其进⾏有损的压缩存储的。最为流⾏的是旋转门的压缩算法，在PostgreSQL中可以使⽤UDF，⽅便的实现这个功能。从⽽实现流式\时序数据的有损压缩。24会话级资源隔离-多租户、云、混合业务资源控制等业务场景在很多场景中，⽤户希望可以控制每个连接（会话）的资源使⽤情况，例如CPU\IOPS\MEMORY等。PostgreSQL是进程结构，可以通过cgroup很好的实现这个需求，不需要对数据库内核进⾏改造。另⼀⽅⾯，基于PostgreSQL的产品GPDB，则是在数据库的内核层⾯实施的控制。25基因⼯程-⽣命科学、医疗等业务场景PostgreSQL凭借良好的扩展性，不仅仅是⼀个数据库，同时也是具备⾮常强⼤的数据处理能⼒的数据平台。很多垂直⾏业的⽤户拿它来做各种和业务贴合⾮常紧密的事情。例如PostgreSQL在⽣命科学领域的应⽤案例-基因⼯程。通常的思维可能是这样的，把数据存在数据库，需要运算的时候，再把数据取出进⾏运算（例如配对），需要花费⾮常多的⽹络传输时间。PostgreSQL提供了基因⼯程相关的数据类型，操作类型，索引。满⾜基因⼯程业务的需求。⽤户可以直接在数据库中对基因数据进⾏处理。同时还可以利⽤MPP来解决更⼤数据量的问题（例如压缩后百TB级别）。26数据预测、挖掘-⾦融数据分析、机器学习等业务场景PostgreSQL、以及HybridDB(基于GPDB)，等PostgreSQL相关的数据库，都⽀持MADlib机器学习库，这个库⽀持机器学习领域常见的算法（例如聚类、线性回归、贝叶斯、⽂本处理等等）其中在数据领域⽤得较多的数据预测，可以使⽤MADLib的多元回归库，进⾏数据的预测。结合plR语⾔或者R+pivotalR、python+pythonR插件，可以⾃动将R\python语⾔的命令转换为MADlib库函数，对数据进⾏分析。⾮常适合使⽤R或者python对数据进⾏分析的数据科学家使⽤。其特点是⾼效（数据与运算⼀体，可以使⽤LLVM\向量计算等技术优化，同时不需要传播数据，节约了传播的开销）、易⽤（⽀持常见的SQL、r,python等编程）。27数据库端编程-ERP、电商、传统企业、电商、运营商等业务场景在传统企业、电商、运营商等涉及⽤户交互、或者多个系统交互的业务场景中，通常⼀个事务涉及到很复杂的业务逻辑，需要保证数据的⼀致性，同时还需要与数据库多次交互。⽐如银⾏开户，涉及的业务系统多，逻辑复杂。在传统企业中，通常使⽤商业数据库的过程函数，实现此类复杂的逻辑。PostgreSQL的数据库过程函数⽀持的语⾔⾮常丰富，⽐如plpgsql（可与Oraclepl/sql功能⽐肩)，另外还⽀持语⾔的扩展，例如⽀持python,perl,java,c,r等等作为数据库的过程函数语⾔。对于开发⼈员来说，⼏乎可以在PostgreSQL数据库中处理任何业务逻辑。28ECPG，C嵌⼊式开发-⾦融等业务场景在⾦融⾏业中，⽤得⾮常多的是嵌⼊式SQL开发，可能为了处理复杂的逻辑，同时还需要⾮常⾼的效率、以及⽅便的代码管理。所以此类场景就会⽤到嵌⼊式SQL开发，取代部分数据库过程语⾔的代码。PostgreSQL的ECPG，与Oracle的Pro*C功能对齐，是个⾮常好的选择。29数据库⽔平拆分、跨平台数据融合-⾦融、电商、互联⽹、物联⽹等业务场景PostgreSQL从2011年的9.1版本引⼊FDW开始，发展到现在已经⽀持⼏乎所有的外部数据源读写操作，例如mysql,oracle,pgsql,redis,mongo,hive,jdbc,odbc,file,sqlserver,es,S3,。开放的接⼝，允许⽤户⾃⼰添加外部数据源的⽀持。9.6针对postgres_fdw（即PostgreSQL外部数据源）再次增强，开始⽀持对sort,where,join的下推，⽀持remotecancelquery,⽤户使⽤FDW可以对应⽤透明的实现数据库的sharding，单元化需求。内核层⽀持sharding，这种分⽚技术相⽐中间件分⽚技术的好处：1.⽀持跨库JOIN2.⽀持绑定变量3.⽀持master(coordinator)节点⽔平扩展4.⽀持segment(datanode)节点⽔平扩展5.⽀持函数和存储过程6.⽀持sort,where,join的下推，⽀持remotecancelquery，10.x⽀持聚合算⼦的下推。ps:⽬前还不⽀持分布式事务（需要⽤户⼲预2PC），10.x的版本会增加内核层⾯的分布式事务控制。除了postgres_fdw，PostgreSQL还有很多FDW，也就是说，你可以在PostgreSQL数据库中，访问⼏乎任何外部数据。就像访问本地的表效果⼀样。31地理位置信息查询-LBS、社交、物流、出⾏、导航等业务场景在LBS、社交、物流、出⾏、导航等场景中，最为常见的⼀个需求是基于位置的搜索，⽐如搜索附近的⼈，并按距离由近到远排序。在PostgreSQL中，有专门的GiST,SP-GiST索引⽀持，可以做到⾮常⾼效的检索，100亿地理位置数据，查询某个点附近的点，普通硬件，单个数据库响应时间在1毫秒以内。PostgreSQL在位置信息近邻（KNN）查询⽅⾯的性能参考。32Oracle兼容性毫⽆疑问，Oracle在企业市场的份额依旧是⽼⼤哥的地位，市⾯上也有很多数据库对这块市场虎视眈眈。拥有43年开源历史的PostgreSQL数据库，是⽬前与Oracle兼容最为完美的数据库。业界也有许多⾮常成功的案例。⽐如丰⽥汽车、平安银⾏、邮储银⾏等。兼容性细节请参考33强⼤的社区⼒量PostgreSQL的开源许可⾮常友好，开发者遍布世界各地，各个⾏业，这也是PostgreSQL数据库⽤户⾏业覆盖⾯⾮常⼴的原因之⼀。PostgreSQL社区的内核研发实⼒⾮常强⼤，在功能⽅⾯⼀直引领开源数据库。开发节奏⾮常好，每年发布⼀个⼤版本，每个⼤版本都可以看到许多前沿的⼤特性。PostgreSQL⽤户组也⾮常活跃，⼏乎全年⽆休世界各地都能看到PostgreSQL⽤户组的活动。PostgreSQL的外围⽣态也⾮常的活跃，这也得益于友好的开源许可。⽐如:衍⽣产品GPDB,Greenplum,HAWQ,AWSRedshift,许多国产数据库,Postgres-XC,Postgres-XL,AsterData、matrixDB、Paraclle、Illustra,Informix,Ne