postgresql , hybriddb , htap , oltp , olap , 混合场景 , oracle , 企业痛点 , 数据库痛点
随着it行业在更多的传统行业渗透，我们正逐步的在进入dt时代，让数据发挥价值是企业的真正需求，否则就是一堆废的并且还持续消耗企业人力，财力的数据。
传统企业可能并不像互联网企业一样，有大量的开发人员、有大量的技术储备，通常还是以购买it软件，或者以外包的形式在存在。
数据的核心 - 数据库，很多传统的行业还在使用传统的数据库。
但是随着it向更多行业的渗透，数据类型越来越丰富（诸如人像、x光片、声波、指纹、dna、化学分子、图谱数据、gis、三维、多维 等等。。。），数据越来越多，怎么处理好这些数据，怎么让数据发挥价值，已经变成了对it行业，对数据库的挑战。
对于互联网行业来说，可能对传统行业的业务并不熟悉，或者说互联网那一套技术虽然在互联网中能很好的运转，但是到了传统行业可不一定，比如说用于科研、军工的gis，和互联网常见的需求就完全不一样。
除了对数据库功能方面的挑战，还有一方面的挑战来自性能方面，随着数据的爆炸，分析型的需求越来越难以满足，主要体现在数据的处理速度方面，而常见的hadoop生态中的处理方式需要消耗大量的开发人员，同时并不能很好的支持品种繁多的数据类型，即使gis可能也无法很好的支持，更别说诸如人像、x光片、声波、指纹、dna、化学分子、图谱数据、gis、三维、多维 等等。
那么我们有什么好的方法来应对这些用户的痛处呢？
且看apsaradb产品线的postgresql与hybriddb如何来一招左右互搏，左手在线事务处理，右手数据分析挖掘，解决企业痛处。
以oracle数据库为例，系统具备以下特点
通过redo日志提供可靠保障。
支持同步和异步模式，同步模式可以做到已提交的事务不丢失。
异步模式不保证已提交的事务不丢失，不保证一致性。
通过主备模式以及集群套件提供高可用支持
通过共享存储，rac集群套件提供高可用支持, 注意应用连接设计时，不同的instance连接的应用应该访问不同的数据块，否则可能会因为gc锁带来性能严重下降。
通过共享存储，主机集群套件提供高可用支持
通过存储层远程增量镜像提供异地容灾
通过主备模式以及增量复制提供异地容灾
通过归档和基础备份提供在线备份以及时间点恢复功能
awr报告，通常包括
top sql、wait event stats、io time、db time
pl/sql编程，c嵌入式sql，sql:2013标准
支持pl/sql开发语言
支持c嵌入式开发
sql: 2013
gis
多种索引支持
数据类型丰富
with, connect by, with, grouping set, rollup, cube
many building functions, op, aggs
sql hint、物化视图、rls（行安全策略）
通过rac和共享存储，扩展主机的方式扩展，支持cpu并行计算
注意应用连接设计时，不同的instance连接的应用应该访问不同的数据块，否则可能会因为gc锁带来性能严重下降。
比如oracle 12c提出的pdb
通常按核收费，按特性收费，license 昂贵
随着用户数据量的增长，数据库的处理能力逐渐成为瓶颈。
以oracle为例，传统的非mpp架构数据库，在执行大数据量运算时，受制于硬件限制，对于olap场景显得很吃力。
以oracle为例，传统的数据库没有机器学习套件，即使有，也受制于它的架构，无法发挥应对数据挖掘分析需求。
rac的扩展能力受到共享存储的限制，存储容易成为瓶颈
rac的模式下面，必须确保app不会跨实例访问相同的数据块，否则gc锁冲突严重，性能比单节点下面明显。
支持的服务端编程语言仅pl/sql,c。
不支持高级的类型扩展，函数扩展，op扩展，索引扩展。
不适合企业快速发展的it需求。
昂贵
除了对数据库基本的增删改查需求，备份恢复容灾需求外。企业对数据处理的要求越来越高。
比如很多时候，用户可能要实时的对数据进行清洗、分析、或者根据数据触发事件。
随着更多的业务接入it系统，用户需要存储越来越多的非结构化的数据、贴近实际需求的数据（比如人像、化学分子式、x光片、基因串、等等现实世界的数据属性），很多数据库在这种情况下显得力不从心，只能靠应用程序来处理，由于数据离计算单元越来越远，效率变得低下。
1. llvm、cpu并行计算
2. 聚合算子复用
3. brin索引接口
比如jsonb、图片、人像、化学分子式、基因串、gis、路由等。
使用pipelinedb可以与kafka, jstrom, postgresql无缝结合，以及标准的sql接口，兼容postgresql.
hybriddb基于开源的mpp数据库gpdb打造，有许多特点
支持弹性的增加节点，扩容时按表分区粒度进行，因此不堵塞其他表分区的读写
支持sql标准以及诸多olap特性，
支持行列混合存储、多级分区、块级压缩、多节点并行计算、多节点数据并行导入、
支持丰富的数据类型，包括json、gis、全文检索、语感、以及常见的文本、数值类型。
支持madlib机器学习库，有上百种常见的挖掘算法，通过sql调用udf训练数据集即可，结合mpp实现了多节点并行的挖掘需求
支持数据节点间透明的数据重分布，广播，在进行多表join时，支持任意列的join，
支持随机分布，或按列分布，支持多列哈希分布，
支持哈希分区表、范围分区表、多级分区
支持用户使用python \ java编写数据库端的udf
支持使用r客户端通过pivotalr包连接数据库，并将r的分析请求自动转换为madlib库或sql请求，实现r的隐式并行分析，同时数据和计算在一起，大幅提升了性能
支持hll等估算数据类型，
支持透明的访问阿里云高性能对象存储oss，通过oss ext插件，可以透明的并行访问oss的数据，
支持postgresql生态，吸纳更多已有的postgresql生态中的特性
在企业中，通常会有专门的分析师岗位，分析师在做建模前，需要经历很多次的试错，才能找到比较好的，可以固定的分析模型。
试错期间，根据分析师的想法，结合业务表现，分析师可能需要对数据反复的训练，这就对数据库有两种要求
1. 实时响应
2. 不干扰正常业务
实时响应对于mpp来说并不能，通常一个query下去，毫秒级就可以响应，不需要等待任务调度。
而不干扰正常业务，这一点，可能就需要好好商榷了，因为一个query可能把资源用光，当然，我们可以通过hybriddb的资源组来进行控制，比如给分析师的query资源优先级降到最低，尽量减少对业务的干扰。
另外我们还有一种更加彻底的方法，数据共享，你可以把需要试错的数据集放到oss中，然后启用一个空的postgresql实例或者hybriddb实例，这些实例与生产实例完全无关，但是它可以去访问oss的数据，建立外部表即可，分析师可以使用这些实例，对数据集进行分析，不会影响生产。
通过rds_dbsync, dts, 或者云上bi、etl厂商提供的etl接口，几乎可以将任意数据源的数据实时的同步到hybriddb进行分析。
通过 oss 高速并行导入导出
<a href="https://help.aliyun.com/document_detail/35457.html?spm=5176.8115115.382043.8.9yeco0">https://help.aliyun.com/document_detail/35457.html?spm=5176.8115115.382043.8.9yeco0</a>
<a href="https://github.com/aliyun/rds_dbsync">https://github.com/aliyun/rds_dbsync</a>
https://yq.aliyun.com/articles/66902
原理与oracle类似，同时支持用户自由选择同步或异步模式，异步模式牺牲了数据可靠性，提升性能，同时不影响一致性。
用户可以根据事务对可靠性的要求，选择副本数。
比如涉及用户账户的事务，至少要求2个副本。
而对于与用户无关的日志事务，1个副本，甚至异步都可以。
给用户设计应用时，提供了最大的灵活度。
postgresql的高可用的方案与oracle类似，支持共享存储的方案，同时还支持流式复制的多副本方案，可以做到数据的0丢失。
hybriddb的高可用方案，为mirror的方式，同步复制，数据0丢失。
master的fts负责数据节点的failover和failback。
master节点的ha则交由上层的集群应用来解决。
对于多机房容灾，postgresql和hybriddb在数据库层面支持流式的复制解决方案。
同时还支持传统的存储或文件系统层面的镜像容灾。
对于存储在oss对象存储中的数据，备份的只是ddl，即外部表的建表语句。
而对于存储在数据库中的数据，使用的备份方法与oracle类似，支持redo的增量备份，也支持数据块级别的增量备份(具体见我写过的块级增量备份文档)。
每个节点并行的进行。
与oracle类似，支持常见的指标top sql、wait event stats、io time、db time
同时支持对long query进行监控，包括long query的执行计划翻转，执行树中每个节点耗费的时间，对buffer产生的操作，物理读等
对于hybriddb，使用resource queue控制不同用户对资源的使用
数据库功能方面，postgresql超越了传统数据库所能cover的数据类型、检索、和数据的运算。
1. 数据库编程
服务端支持plpgsql、python、java、r、javascript、perl、tcl 等开发语言
plpgsql与oracle pl/sql功能不相上下
2. sql兼容性
3. 语法例子
with, connect by(用with支持), with, grouping set, rollup, cube
postgis、jsonb
sql plan hint、物化视图、rls（行安全策略）
多种索引支持(btree, hash, brin, gin, gist, sp-gist, rum, bloom)
支持全文检索、模糊查询、正则匹配（走索引）
数据类型丰富（常用类型、数组、范围、估值类型、分词、几何、序列、地球、gis、网络、大对象、比特串、字节流、uuid、xml、jsonb、复合、枚举、。。。。。。）
4. 支持oracle兼容包插件
5. 支持插件、支持fdw(透明访问外部数据)、支持language扩展
6. 支持多个聚合函数共用sfunc，提升性能
7. 扩展能力
支持用户自定义数据类型、操作符、索引、udf、窗口、聚合
服务端支持plpgsql、pljava等开发语言
内置丰富的函数、操作符、聚合、窗口查询
多种索引支持(btree)，支持函数索引，支持partial index
支持全文检索、字符串模糊查询（fuzzystrmatch）
数据类型丰富（数字、字符串、比特串、货币、字节流、时间、布尔、几何、网络地址、数组、gis、xml、json、复合、枚举、。。。。。。）
支持oracle兼容包插件orafunc
3. 支持列存、行存、混合存储
4. 支持隐式并行计算
5. 支持机器学习库
6. 支持支持oss_ext(透明访问oss对象数据)
7. 支持hll数据评估插件
8. 扩展能力
1. 计算能力
由于传统数据库，比如oracle并非mpp架构，在执行大数据量运算时，受制于硬件限制，对于10tb以上的olap场景很吃力。
1.1 解决办法
postgresql 多cpu并行计算，解决tb级本地实时分析需求
postgresql 数据通过redo日志实时流式同步到hybriddb，解决pb级别olap场景需求。
2. 数据挖掘分析能力
由于传统数据库，比如oracle没有机器学习套件，即使有，也受制于它的架构，无法发挥应对数据挖掘分析需求。
2.1 解决办法
postgresql和hybriddb都内置了madlib机器学习库，支持几百种挖掘算法。
通过r,python服务端编程，支持更多的挖掘需求。
3. 扩展能力
3.1 解决办法
postgresql fdw based sharding + multimaster，支持单元化和水平扩展需求
hybriddb mpp天然支持水平扩展
4. 可编程能力
4.1 解决办法
postgresql, hybriddb 支持plpgsql, c, python, java等多种语言的服务端编程。
支持数据类型、索引、函数、操作符、聚合、窗口函数等扩展。
在dt时代，让数据发挥价值是企业的真正需求，否则就是一堆废的并且还持续消耗企业人力，财力的数据。
使用本方案，可以让企业更加轻松的驾驭暴增的数据，不管是什么数据类型，什么数据来源，是流式的还是在线或离线的数据分析需求，统统都能找到合理的方法来处置。
1. 高度兼容传统数据库，如oracle
包括数据类型，过程语言，语法，内置函数，自定义函数，自定义数据类型
2. 解决了传统数据库如oracle方案的痛点
3. 计算能力
4. 数据挖掘分析能力
5. 扩展能力
hybriddb mpp 天然支持水平扩展
6. 可编程能力
7. 支持估值类型
快速的输出pv,uv,count(distinct)等估值。
8. 共享一份数据，构建多个分析实例
通常在企业中有分析师的角色，分析师要对数据频繁的根据不同的分析框架进行分析，如果都发往主库，可能导致主库的计算压力变大。
用户可以将历史数据，或者维度数据存放到共用的存储（如oss），通过fdw共享访问，一份数据可以给多个实例加载分析。可以为分析师配备独立的计算实例，数据则使用fdw从共享存储（如oss）加载，与主库分离。
9. hybriddb优势
支持ao列存，块级压缩，机器学习，混合存储，mpp水平扩展，隐式并行，r，java服务端编程语言支持，pb级别数据挖掘需求。
postgresql是一个 "很有爱" 的数据库，用心学习它，用心回报社会吧。
<a href="https://github.com/digoal/blog/blob/master/201612/20161228_01.md">《从天津滨海新区大爆炸、危化品监管聊聊 it人背负的社会责任感》</a>
<a href="https://github.com/digoal/blog/blob/master/201612/20161230_01.md">《postgresql 重复 数据清洗 优化教程》</a>
<a href="https://github.com/digoal/blog/blob/master/201612/20161231_01.md">《从难缠的模糊查询聊开 - postgresql独门绝招之一 gin , gist , sp-gist , rum 索引原理与技术背景》</a>
<a href="https://github.com/digoal/blog/blob/master/201612/20161227_01.md">《从真假美猴王谈起 - 让套牌车、克隆x 无处遁形的技术手段思考》</a>
<a href="https://github.com/digoal/blog/blob/master/201612/20161225_01.md">《恭迎万亿级营销(圈人)潇洒的迈入毫秒时代 - 万亿user_tags级实时推荐系统数据库设计》</a>
<a href="https://github.com/digoal/blog/blob/master/201612/20161224_01.md">《dba专供 冈本003系列 - 数据库安全第一,过个好年》</a>
<a href="https://github.com/digoal/blog/blob/master/201612/20161223_01.md">《聊一下postgresql优化器 - in里面有重复值时postgresql如何处理?》</a>
<a href="https://github.com/digoal/blog/blob/master/201612/20161222_02.md">《从相似度算法谈起 - effective similarity search in postgresql》</a>
<a href="https://github.com/digoal/blog/blob/master/201612/20161222_01.md">《一场it民工 与 人贩子 之间的战争 - 只要人人都献出一点爱》</a>
<a href="https://github.com/digoal/blog/blob/master/201512/20151215_01.md">《"物联网"流式处理应用 - 用postgresql实时处理(万亿每天)》</a>
<a href="https://github.com/digoal/blog/blob/master/201606/20160621_1.md">《为了部落 - 如何通过postgresql基因配对，产生优良下一代》</a>
<a href="https://github.com/digoal/blog/blob/master/201612/20161220_01.md">《流计算风云再起 - postgresql携pipelinedb力挺iot》</a>
<a href="https://github.com/digoal/blog/blob/master/201612/20161216_01.md">《分析加速引擎黑科技 - llvm、列存、多核并行、算子复用 大联姻 - 一起来开启postgresql的百宝箱》</a>
<a href="https://github.com/digoal/blog/blob/master/201612/20161213_01.md">《金融风控、公安刑侦、社会关系、人脉分析等需求分析与数据库实现 - postgresql图数据库场景应用》</a>
<a href="https://github.com/digoal/blog/blob/master/201612/20161205_02.md">《实时数据交换平台 - bottledwater-pg with confluent》</a>
<a href="https://github.com/digoal/blog/blob/master/201611/20161126_01.md">《postgresql 在视频、图片去重，图像搜索业务中的应用》</a>
<a href="https://github.com/digoal/blog/blob/master/201610/20161021_01.md">《基于 阿里云 rds postgresql 打造实时用户画像推荐系统》</a>
<a href="https://github.com/digoal/blog/blob/master/201611/20161124_02.md">《postgresql 与 12306 抢火车票的思考》</a>
<a href="https://github.com/digoal/blog/blob/master/201611/20161124_01.md">《门禁广告销售系统需求剖析 与 postgresql数据库实现》</a>
<a href="https://github.com/digoal/blog/blob/master/201611/20161114_01.md">《聊一聊双十一背后的技术 - 物流、动态路径规划》</a>
<a href="https://github.com/digoal/blog/blob/master/201611/20161115_01.md">《聊一聊双十一背后的技术 - 分词和搜索》</a>
<a href="https://github.com/digoal/blog/blob/master/201611/20161117_01.md">《聊一聊双十一背后的技术 - 不一样的秒杀技术, 裸秒》</a>
<a href="https://github.com/digoal/blog/blob/master/201611/20161118_01.md">《聊一聊双十一背后的技术 - 毫秒分词算啥, 试试正则和相似度》</a>
<a href="https://github.com/digoal/blog/blob/master/201610/20161001_01.md">《postgresql 9.6 引领开源数据库攻克多核并行计算难题》</a>
<a href="https://github.com/digoal/blog/blob/master/201609/20160929_02.md">《postgresql 前世今生》</a>
<a href="https://github.com/digoal/blog/blob/master/201609/20160906_01.md">《如何建立gis测试环境 - 将openstreetmap的样本数据导入postgresql postgis库》</a>
<a href="https://github.com/digoal/blog/blob/master/201610/20161004_01.md">《postgresql 9.6 单元化,sharding (based on postgres_fdw) - 内核层支持前传》</a>
<a href="https://github.com/digoal/blog/blob/master/201610/20161005_01.md">《postgresql 9.6 sharding + 单元化 (based on postgres_fdw) 最佳实践 - 通用水平分库场景设计与实践》</a>
<a href="https://github.com/digoal/blog/blob/master/201610/20161027_01.md">《postgresql 9.6 sharding based on fdw & pg_pathman》</a>
<a href="https://github.com/digoal/blog/blob/master/201610/20161024_01.md">《postgresql 9.5+ 高效分区表实现 - pg_pathman》</a>
<a href="https://github.com/digoal/blog/blob/master/201506/20150601_01.md">《postgresql 数据库安全指南》</a>
<a href="https://github.com/digoal/blog/blob/master/201605/20160523_01.md">《postgresql 9.6 黑科技 bloom 算法索引，一个索引支撑任意列组合查询》</a>
<a href="https://github.com/digoal/blog/blob/master/201607/20160725_01.md">《postgresql 使用递归sql 找出数据库对象之间的依赖关系》</a>
<a href="https://github.com/digoal/blog/blob/master/201612/20161203_01.md">《用postgresql描绘人生的高潮、尿点、低谷 - 窗口/帧 or 斜率/导数/曲率/微积分?》</a>
<a href="https://github.com/digoal/blog/blob/master/201612/20161201_01.md">《用postgresql找回618秒逝去的青春 - 递归收敛优化》</a>
<a href="https://yq.aliyun.com/articles/50922">《postgis 在 o2o应用中的优势》</a>
<a href="https://yq.aliyun.com/articles/2999">《postgresql 百亿地理位置数据 近邻查询性能》</a>