Oracle业务适合用PostgreSQL去O的一些评判标准

本文涉及的产品
RDS MySQL DuckDB 分析主实例,集群系列 4核8GB
RDS AI 助手,专业版
RDS MySQL DuckDB 分析主实例,基础系列 4核8GB
简介:

标签

PostgreSQL , Oracle


背景

Oracle业务适合用PG去O的一些评判标准:

功能指标

如果评估出来的业务中具备这些特性,非常适合使用PostgreSQL。

1、业务使用的数据类型中出现

IP地址、GIS、数组、范围、全文检索、大对象、字节流、比特流、枚举、几何、自定义复合、UUID、XML、JSON、货币、字符串、数值、时间、加密数据类型

2、业务需求中出现

全文检索、模糊查询、相似查询

3、业务使用的SQL中出现

connect by、多维分析(grouping, grouping sets, rollup, cube)、多表JOIN、窗口查询(over partition by ())、聚合函数

4、业务使用的SQL中出现如下HINT

parallel   
  
hash hint  
  
left join  
  
right join  
  
outer join  
  
merge join  
  
hash agg  
  
group agg  
  
merge sort  
  
skip scan  

5、业务使用了存储过程

6、表的数据量

单表过亿

7、业务使用了dblink,外部表功能

8、业务使用了bitmap\btree索引

PostgreSQL 内置多种索引接口(hash, btree, gin, gist, sp-gist, brin, bloom)

9、业务中使用了约束

primary key, unique key, check, not null, default value

10、业务中使用了全局序列、局部序列

sequence

11、业务使用了翻转索引

12、业务使用了分区表

13、业务使用了触发器、规则功能

14、业务使用了混合负载

小事务和分析型事务并存。

PostgreSQL通过多核并行、JIT、算子复用等技术,加速分析事务。

15、业务使用了upsert(不存在则插入,存在则更新)

16、业务大量使用了GIS地理位置数据

17、业务有大量数据透视需求(BI分析)

18、业务大量使用了ORACLE的内置函数,(分析函数、聚合函数、窗口函数、数据处理函数等)

19、业务有任意列,任意条件筛选需求

20、业务有倒排索引需求

21、业务有空间数据检索需求

22、业务使用了物化视图

23、业务有多master需求

24、业务有流式计算需求

25、业务有图式搜索需求

26、业务有读写分离需求

27、业务有并行查询的需求

28、业务有加密数据类型需求

29、业务有数据采样需求

30、业务有链路加密需求

性能指标

单机(32 CORE, SSD, 512GB内存)

1、TPC-H性能

SF=100,100GB 裸数据。

2017-07-13 20:04:29 [1499947469] : running queries defined in TPC-H benchmark
2017-07-13 20:04:29 [1499947469] :   running query 1
2017-07-13 20:04:29 [1499947469] : run explain
2017-07-13 20:04:29 [1499947469] : run the query on background
2017-07-13 20:04:47 [1499947487] :     query 1 finished OK (17 seconds)
2017-07-13 20:04:47 [1499947487] :   running query 2
2017-07-13 20:04:47 [1499947487] : run explain
2017-07-13 20:04:47 [1499947487] : run the query on background
2017-07-13 20:08:13 [1499947693] :     query 2 finished OK (206 seconds)
2017-07-13 20:08:13 [1499947693] :   running query 3
2017-07-13 20:08:13 [1499947693] : run explain
2017-07-13 20:08:14 [1499947694] : run the query on background
2017-07-13 20:08:55 [1499947735] :     query 3 finished OK (41 seconds)
2017-07-13 20:08:55 [1499947735] :   running query 4
2017-07-13 20:08:55 [1499947735] : run explain
2017-07-13 20:08:55 [1499947735] : run the query on background
2017-07-13 20:09:02 [1499947742] :     query 4 finished OK (6 seconds)
2017-07-13 20:09:02 [1499947742] :   running query 5
2017-07-13 20:09:02 [1499947742] : run explain
2017-07-13 20:09:02 [1499947742] : run the query on background
2017-07-13 20:09:16 [1499947756] :     query 5 finished OK (14 seconds)
2017-07-13 20:09:16 [1499947756] :   running query 6
2017-07-13 20:09:16 [1499947756] : run explain
2017-07-13 20:09:16 [1499947756] : run the query on background
2017-07-13 20:09:21 [1499947761] :     query 6 finished OK (4 seconds)
2017-07-13 20:09:21 [1499947761] :   running query 7
2017-07-13 20:09:21 [1499947761] : run explain
2017-07-13 20:09:21 [1499947761] : run the query on background
2017-07-13 20:10:06 [1499947806] :     query 7 finished OK (35 seconds)
2017-07-13 20:10:06 [1499947806] :   running query 8
2017-07-13 20:10:06 [1499947806] : run explain
2017-07-13 20:10:06 [1499947806] : run the query on background
2017-07-13 20:10:38 [1499947838] :     query 8 finished OK (31 seconds)
2017-07-13 20:10:38 [1499947838] :   running query 9
2017-07-13 20:10:38 [1499947838] : run explain
2017-07-13 20:10:38 [1499947838] : run the query on background
2017-07-13 20:11:32 [1499947892] :     query 9 finished OK (54 seconds)
2017-07-13 20:11:32 [1499947892] :   running query 10
2017-07-13 20:11:32 [1499947892] : run explain
2017-07-13 20:11:32 [1499947892] : run the query on background
2017-07-13 20:11:49 [1499947909] :     query 10 finished OK (16 seconds)
2017-07-13 20:11:49 [1499947909] :   running query 11
2017-07-13 20:11:49 [1499947909] : run explain
2017-07-13 20:11:49 [1499947909] : run the query on background
2017-07-13 20:11:56 [1499947916] :     query 11 finished OK (7 seconds)
2017-07-13 20:11:56 [1499947916] :   running query 12
2017-07-13 20:11:56 [1499947916] : run explain
2017-07-13 20:11:56 [1499947916] : run the query on background
2017-07-13 20:13:37 [1499948017] :     query 12 finished OK (100 seconds)
2017-07-13 20:13:37 [1499948017] :   running query 13
2017-07-13 20:13:37 [1499948017] : run explain
2017-07-13 20:13:37 [1499948017] : run the query on background
2017-07-13 20:17:11 [1499948231] :     query 13 finished OK (213 seconds)
2017-07-13 20:17:11 [1499948231] :   running query 14
2017-07-13 20:17:11 [1499948231] : run explain
2017-07-13 20:17:11 [1499948231] : run the query on background
2017-07-13 20:17:15 [1499948235] :     query 14 finished OK (4 seconds)
2017-07-13 20:17:15 [1499948235] :   running query 15
2017-07-13 20:17:15 [1499948235] : run explain
2017-07-13 20:17:15 [1499948235] : run the query on background
2017-07-13 20:17:40 [1499948260] :     query 15 finished OK (25 seconds)
2017-07-13 20:17:40 [1499948260] :   running query 16
2017-07-13 20:17:40 [1499948260] : run explain
2017-07-13 20:17:40 [1499948260] : run the query on background
2017-07-13 20:18:41 [1499948321] :     query 16 finished OK (60 seconds)
2017-07-13 20:18:41 [1499948321] :   running query 17
2017-07-13 20:18:41 [1499948321] : run explain
2017-07-13 20:18:41 [1499948321] : run the query on background
2017-07-13 20:27:55 [1499948875] :     query 17 finished OK (552 seconds)
2017-07-13 20:27:55 [1499948875] :   running query 18
2017-07-13 20:27:55 [1499948875] : run explain
2017-07-13 20:27:55 [1499948875] : run the query on background
2017-07-13 20:49:57 [1499950197] :     query 18 finished OK (1317 seconds)
2017-07-13 20:49:57 [1499950197] :   running query 19
2017-07-13 20:49:57 [1499950197] : run explain
2017-07-13 20:49:57 [1499950197] : run the query on background
2017-07-13 20:50:09 [1499950209] :     query 19 finished OK (11 seconds)
2017-07-13 20:50:09 [1499950209] :   running query 20
2017-07-13 20:50:09 [1499950209] : run explain
2017-07-13 20:50:09 [1499950209] : run the query on background
2017-07-13 20:56:43 [1499950603] :     query 20 finished OK (393 seconds)
2017-07-13 20:56:43 [1499950603] :   running query 21
2017-07-13 20:56:43 [1499950603] : run explain
2017-07-13 20:56:43 [1499950603] : run the query on background
2017-07-13 20:58:19 [1499950699] :     query 21 finished OK (95 seconds)
2017-07-13 20:58:19 [1499950699] :   running query 22
2017-07-13 20:58:19 [1499950699] : run explain
2017-07-13 20:58:19 [1499950699] : run the query on background
2017-07-13 21:00:43 [1499950843] :     query 22 finished OK (143 seconds)
2017-07-13 21:00:43 [1499950843] : finished TPC-H benchmark  

2、TPC-C性能

3000仓库、256客户端。84.5万 tpmC。

《数据库界的华山论剑 tpc.org》

3、GIS(KNN检索)

100亿位置信息,近邻查询。

tps: 7.4万/s

rt: 0.848毫秒

《PostgreSQL 百亿地理位置数据 近邻查询性能》

4、模糊查询

前后模糊(like '%????%')

1亿数据量,前后模糊,0.2毫秒。

《PostgreSQL 模糊查询最佳实践》

5、全文检索

10亿随机值,返回2万条匹配记录,26毫秒。

《PostgreSQL 全文检索加速 快到没有朋友 - RUM索引接口(潘多拉魔盒)》

6、多表JOIN

2张1亿记录,10张1000万记录,1张1000记录的表进行JOIN,聚合查询。

23毫秒。

c 1000万
d 1000
e 1亿

postgres=# explain (analyze,verbose,timing,costs,buffers) 
select count(t1.*) from 
e t1 join e t2 on (t1.id=t2.id and t1.id<=1000) 
join c t3 on (t1.id=t3.id) 
join c t4 on (t1.id=t4.id) 
join c t5 on (t1.id=t5.id) 
join c t6 on (t1.id=t6.id) 
join c t7 on (t1.id=t7.id) 
join c t8 on (t1.id=t8.id) 
join c t9 on (t1.id=t9.id) 
join c t10 on (t1.id=t10.id) 
join c t11 on (t1.id=t11.id) 
join c t12 on (t1.id=t12.id) 
join d t13 on (t1.id=t13.id) ;


 Aggregate  (cost=3234.08..3234.09 rows=1 width=8) (actual time=23.665..23.665 rows=1 loops=1)
   Output: count(t1.*)
   Buffers: shared hit=48059
   ->  Nested Loop  (cost=5.76..3234.08 rows=1 width=28) (actual time=0.083..23.553 rows=1000 loops=1)
         Output: t1.*
         Join Filter: (t1.id = t13.id)
         Buffers: shared hit=48059

............

 Planning time: 7.943 ms
 Execution time: 23.782 ms
(116 rows)

7、单表聚合性能

单表8亿记录,avg,count,sum,min,max维度聚合查询。

32个并行度

5.3秒

postgres=# select count(*),sum(id),avg(id),min(id),max(id) from e;  
   count   |        sum        |          avg          | min |    max      
-----------+-------------------+-----------------------+-----+-----------  
 800000000 | 40000000400000000 | 50000000.500000000000 |   1 | 100000000  
(1 row)  
  
Time: 5316.490 ms (00:05.316)  

8、数据导入速度

并行写入,500万条记录/s 或 每秒1.8GB/s。

《PostgreSQL 如何潇洒的处理每天上百TB的数据增量》

小结

简单来说,PostgreSQL是Oracle的最佳替代产品,而且还有额外惊喜,参考应用案例一文。

参考资料

《PostgreSQL 应用案例 - 目录》

《数据库选型之 - 大象十八摸 - 致 架构师、开发者》

《数据库选型思考》

相关实践学习
使用PolarDB和ECS搭建门户网站
本场景主要介绍如何基于PolarDB和ECS实现搭建门户网站。
阿里云数据库产品家族及特性
阿里云智能数据库产品团队一直致力于不断健全产品体系,提升产品性能,打磨产品功能,从而帮助客户实现更加极致的弹性能力、具备更强的扩展能力、并利用云设施进一步降低企业成本。以云原生+分布式为核心技术抓手,打造以自研的在线事务型(OLTP)数据库Polar DB和在线分析型(OLAP)数据库Analytic DB为代表的新一代企业级云原生数据库产品体系, 结合NoSQL数据库、数据库生态工具、云原生智能化数据库管控平台,为阿里巴巴经济体以及各个行业的企业客户和开发者提供从公共云到混合云再到私有云的完整解决方案,提供基于云基础设施进行数据从处理、到存储、再到计算与分析的一体化解决方案。本节课带你了解阿里云数据库产品家族及特性。
目录
相关文章
|
关系型数据库 分布式数据库 数据库
PolarDB PostgreSQL版:Oracle兼容的高性能数据库
PolarDB PostgreSQL版是一款高性能的数据库,具有与Oracle兼容的特性。它采用了分布式架构,可以轻松处理大量的数据,同时还支持多种数据类型和函数,具有高可用性和可扩展性。它还提供了丰富的管理工具和性能优化功能,为企业提供了可靠的数据存储和处理解决方案。PolarDB PostgreSQL版在数据库领域具有很高的竞争力,可以满足各种企业的需求。
|
11月前
|
Oracle 关系型数据库 数据库
【赵渝强老师】在PostgreSQL中访问Oracle
本文介绍了如何在PostgreSQL中使用oracle_fdw扩展访问Oracle数据库数据。首先需从Oracle官网下载三个Instance Client安装包并解压,设置Oracle环境变量。接着从GitHub下载oracle_fdw扩展,配置pg_config环境变量后编译安装。之后启动PostgreSQL服务器,在数据库中创建oracle_fdw扩展及外部数据库服务,建立用户映射。最后通过创建外部表实现对Oracle数据的访问。文末附有具体操作步骤与示例代码。
881 6
【赵渝强老师】在PostgreSQL中访问Oracle
|
Oracle NoSQL 关系型数据库
主流数据库对比:MySQL、PostgreSQL、Oracle和Redis的优缺点分析
主流数据库对比:MySQL、PostgreSQL、Oracle和Redis的优缺点分析
3075 3
|
人工智能 Oracle 关系型数据库
一篇文章弄懂Oracle和PostgreSQL的Database Link
一篇文章弄懂Oracle和PostgreSQL的Database Link
|
SQL Oracle 关系型数据库
常用数据库的分页语句(mySQL、oracle、PostgreSQL、SQL Server)
常用数据库的分页语句(mySQL、oracle、PostgreSQL、SQL Server)
|
SQL Oracle 关系型数据库
Oracle,Postgresql等数据库使用
Oracle,Postgresql等数据库简单使用
323 0
Oracle,Postgresql等数据库使用
|
SQL Oracle 关系型数据库
Polar DB-O (兼容 Oracle 语法版本)和Polar DB PostgreSQL 版本概述(二)
Polar DB-O (兼容 Oracle 语法版本)和Polar DB PostgreSQL 版本概述(二)
3042 0
|
7月前
|
Oracle 关系型数据库 Linux
【赵渝强老师】Oracle数据库配置助手:DBCA
Oracle数据库配置助手(DBCA)是用于创建和配置Oracle数据库的工具,支持图形界面和静默执行模式。本文介绍了使用DBCA在Linux环境下创建数据库的完整步骤,包括选择数据库操作类型、配置存储与网络选项、设置管理密码等,并提供了界面截图与视频讲解,帮助用户快速掌握数据库创建流程。
583 93
|
6月前
|
Oracle 关系型数据库 Linux
【赵渝强老师】使用NetManager创建Oracle数据库的监听器
Oracle NetManager是数据库网络配置工具,用于创建监听器、配置服务命名与网络连接,支持多数据库共享监听,确保客户端与服务器通信顺畅。
333 0
|
9月前
|
存储 Oracle 关系型数据库
服务器数据恢复—光纤存储上oracle数据库数据恢复案例
一台光纤服务器存储上有16块FC硬盘,上层部署了Oracle数据库。服务器存储前面板2个硬盘指示灯显示异常,存储映射到linux操作系统上的卷挂载不上,业务中断。 通过storage manager查看存储状态,发现逻辑卷状态失败。再查看物理磁盘状态,发现其中一块盘报告“警告”,硬盘指示灯显示异常的2块盘报告“失败”。 将当前存储的完整日志状态备份下来,解析备份出来的存储日志并获得了关于逻辑卷结构的部分信息。

相关产品

  • 云原生数据库 PolarDB
  • 云数据库 RDS PostgreSQL 版
  • 推荐镜像

    更多