3 月全球数据库排名:PostgreSQL 再迎暴涨 - 开源中国社区
3 月全球数据库排名:PostgreSQL 再迎暴涨
王练 2018年03月05日

3 月全球数据库排名:PostgreSQL 再迎暴涨

王练 王练 发布于2018年03月05日 收藏 18

DB-Engines 发布了 2018 年 3 月份的数据库排名,排名前三的依然是 Oracle、MySQL 和 Microsoft SQL Server 。

前 20 名的数据库中,本月排名出现上升的只有 MariaDB ,从上个月的第 17 名上升至第 15 名。SAP Adaptive Server 和 HBase 则分别从第 15 名和第 16 名降至第 16 名和第 17 名。

PostgreSQL 继续保持上升趋势,本月迎来榜单中最高的涨幅,上涨 10.97 的百分点,远高于其他数据库。

完整排名请查看:https://db-engines.com/en/ranking

前三名走势

前三名数据库皆有小幅度的下降趋势。


PostgreSQL 和 MongoDB 走势:

二者均保持稳步上涨。

DB-Engines 排名的数据依据 5 个不同的因素:

  1. Google 以及 Bing 搜索引擎的关键字搜索数量

  2. Google Trends 的搜索数量

  3. Indeed 网站中的职位搜索量

  4. LinkedIn 中提到关键字的个人资料数

  5. Stackoverflow 上相关的问题和关注者数量

这份榜单分析旨在为数据库相关从业人员提供一个技术方向的参考,其中涉及到的排名情况并非基于产品的技术先进程度或市场占有率等因素。无论排名先后,选择适合与企业业务需求相比配的技术,才是最重要的。

本站文章除注明转载外,均为本站原创或编译。欢迎任何形式的转载,但请务必注明出处,尊重他人劳动共创开源社区。
转载请注明:文章转载自 开源中国社区 [http://www.oschina.net]
本文标题:3 月全球数据库排名:PostgreSQL 再迎暴涨
分享
评论(62)
精彩评论
28
我们的项目原先用MySQL,几张表的稍复杂点的join查询,1个小时都出不来结果;后来在我的强力建议下,换成了PostgreSQL,查询结果0.3秒左右(300多毫秒),目前使用PG最新的分区表特性,加上丰富的数据类型支持、丰富的内置函数,爽的飞起。
7
我们现在新项目全部改使用postgresql。
6
pgsql雄起
5
全球人民喜迎PostgreSQL暴涨
5
大爱pg
最新评论
0
感觉mysql其实对开发人员的要求高些,需要自己解决很多麻烦;
3

引用来自“Goopand”的评论

我们的项目原先用MySQL,几张表的稍复杂点的join查询,1个小时都出不来结果;后来在我的强力建议下,换成了PostgreSQL,查询结果0.3秒左右(300多毫秒),目前使用PG最新的分区表特性,加上丰富的数据类型支持、丰富的内置函数,爽的飞起。
好奇你什么SQL导致的差别这么大。虽然两个数据库各有优劣,但也不至于产生这么大的差距,肯定是你使用的姿势不对。
0

引用来自“jasonwu24”的评论

PG one!
pg one 已经凉凉

引用来自“Goopand”的评论

我们的项目原先用MySQL,几张表的稍复杂点的join查询,1个小时都出不来结果;后来在我的强力建议下,换成了PostgreSQL,查询结果0.3秒左右(300多毫秒),目前使用PG最新的分区表特性,加上丰富的数据类型支持、丰富的内置函数,爽的飞起。
加了索引也这样??
0
......不是所有的数据库默认设置 就是适合所有场景的 mysql本来不上索引读基本就属于顺带功能了
0

引用来自“Goopand”的评论

我们的项目原先用MySQL,几张表的稍复杂点的join查询,1个小时都出不来结果;后来在我的强力建议下,换成了PostgreSQL,查询结果0.3秒左右(300多毫秒),目前使用PG最新的分区表特性,加上丰富的数据类型支持、丰富的内置函数,爽的飞起。

引用来自“mark35”的评论

谁用谁知道。最好别让竞争对手知道~~
当然,一小时和0.3秒的差距有点匪夷所思……

引用来自“宏哥”的评论

有没有必要升级到10
我现在还在 9.5 .
生产环境大版本升级还是有点麻烦的
就产品来说尽量保持运行环境稳定。就技术积累来说尽量跟踪主流技术。
既然pg已经是核心组件,我觉得可以保持定期升级比较好。不然下次升级或者开新项目时变动太大还是需要花精力去研究。
0

引用来自“玛雅牛”的评论

负责的所有项目都使用 PostgreSQL数据。使用pg_pathman做分区,上亿条数据中查询,100毫秒出结果。
pg的窗口函数让你做统计的时候爽到不能自已
0

引用来自“LongRaindy”的评论

公司主用MongoDB,对PSQL也是充满好感。:smiley:
对Mongo满满的怨念
0

引用来自“Goopand”的评论

我们的项目原先用MySQL,几张表的稍复杂点的join查询,1个小时都出不来结果;后来在我的强力建议下,换成了PostgreSQL,查询结果0.3秒左右(300多毫秒),目前使用PG最新的分区表特性,加上丰富的数据类型支持、丰富的内置函数,爽的飞起。

引用来自“mark35”的评论

谁用谁知道。最好别让竞争对手知道~~
当然,一小时和0.3秒的差距有点匪夷所思……
有没有必要升级到10
我现在还在 9.5 .
生产环境大版本升级还是有点麻烦的
0
公司主用MongoDB,对PSQL也是充满好感。:smiley:
0
评论几乎清一色的贬低mysql,赞扬postgresql!
0

引用来自“Goopand”的评论

我们的项目原先用MySQL,几张表的稍复杂点的join查询,1个小时都出不来结果;后来在我的强力建议下,换成了PostgreSQL,查询结果0.3秒左右(300多毫秒),目前使用PG最新的分区表特性,加上丰富的数据类型支持、丰富的内置函数,爽的飞起。

引用来自“tulayang”的评论

只能说你们开发组太无知,也许 PostgreSQL 默认给你们建了索引你们不知道呢。讨论技术要从数学讨论,不要从感觉上

引用来自“乌龟壳”的评论

去了解下hash join,纯DB的OLAP本来就不是mysql强项

引用来自“mark35”的评论

mysql不支持集合运算,所以涉及到多表关联操作的肯定卡得比狗还慢

引用来自“dream_xz”的评论

数据库只是作为程序的一种输入输出,并不适应作大量运算

引用来自“mark35”的评论

资金业务表几千万条数据做统计分析,你让我不在数据库用存储过程而是在应用层做?
数据库既是数据的仓库,数据运算尤其是海量数据运算这本就应该是数据库的工作 。
年度结息,我们的同行是在应用层做的,在现场观摩的部里面下来领导面前跑了几个小时还没出结果。我们的系统用存储过程跑十分钟内搞定。
那是别人程序没写好
0

引用来自“Goopand”的评论

我们的项目原先用MySQL,几张表的稍复杂点的join查询,1个小时都出不来结果;后来在我的强力建议下,换成了PostgreSQL,查询结果0.3秒左右(300多毫秒),目前使用PG最新的分区表特性,加上丰富的数据类型支持、丰富的内置函数,爽的飞起。

引用来自“老范的自留地”的评论

一个小时跟300毫秒?求晒几个表的关系与数据量,个人感觉这么大的差异不太可能!

引用来自“Goopand”的评论

是未作任何优化、干预,未创建任何索引的情况下,pg优化器做出快速查询
补充下,pg那个叫做“执行规划器”,是根据多维度统计信息进行合理分析得出的可控的结果。mysql那个才叫做优化器,“优化”结果不可控~~
0

引用来自“Goopand”的评论

我们的项目原先用MySQL,几张表的稍复杂点的join查询,1个小时都出不来结果;后来在我的强力建议下,换成了PostgreSQL,查询结果0.3秒左右(300多毫秒),目前使用PG最新的分区表特性,加上丰富的数据类型支持、丰富的内置函数,爽的飞起。

引用来自“tulayang”的评论

只能说你们开发组太无知,也许 PostgreSQL 默认给你们建了索引你们不知道呢。讨论技术要从数学讨论,不要从感觉上

引用来自“乌龟壳”的评论

去了解下hash join,纯DB的OLAP本来就不是mysql强项

引用来自“mark35”的评论

mysql不支持集合运算,所以涉及到多表关联操作的肯定卡得比狗还慢

引用来自“dream_xz”的评论

数据库只是作为程序的一种输入输出,并不适应作大量运算
资金业务表几千万条数据做统计分析,你让我不在数据库用存储过程而是在应用层做?
数据库既是数据的仓库,数据运算尤其是海量数据运算这本就应该是数据库的工作 。
年度结息,我们的同行是在应用层做的,在现场观摩的部里面下来领导面前跑了几个小时还没出结果。我们的系统用存储过程跑十分钟内搞定。
1

引用来自“Goopand”的评论

我们的项目原先用MySQL,几张表的稍复杂点的join查询,1个小时都出不来结果;后来在我的强力建议下,换成了PostgreSQL,查询结果0.3秒左右(300多毫秒),目前使用PG最新的分区表特性,加上丰富的数据类型支持、丰富的内置函数,爽的飞起。

引用来自“tulayang”的评论

只能说你们开发组太无知,也许 PostgreSQL 默认给你们建了索引你们不知道呢。讨论技术要从数学讨论,不要从感觉上

引用来自“乌龟壳”的评论

去了解下hash join,纯DB的OLAP本来就不是mysql强项

引用来自“mark35”的评论

mysql不支持集合运算,所以涉及到多表关联操作的肯定卡得比狗还慢

引用来自“dream_xz”的评论

数据库只是作为程序的一种输入输出,并不适应作大量运算
分布式数据库就是为了解决这个问题的,应该数据库——程序——数据库这样去做复杂分析,开发效率很低。
0

引用来自“Goopand”的评论

我们的项目原先用MySQL,几张表的稍复杂点的join查询,1个小时都出不来结果;后来在我的强力建议下,换成了PostgreSQL,查询结果0.3秒左右(300多毫秒),目前使用PG最新的分区表特性,加上丰富的数据类型支持、丰富的内置函数,爽的飞起。

引用来自“tulayang”的评论

只能说你们开发组太无知,也许 PostgreSQL 默认给你们建了索引你们不知道呢。讨论技术要从数学讨论,不要从感觉上

引用来自“乌龟壳”的评论

去了解下hash join,纯DB的OLAP本来就不是mysql强项

引用来自“tulayang”的评论

别说 hash join,你确定这个差别是 hash join 在起作用?以前 lamp 流行,就是因为 mysql 的查询快于 pg。数据库的索引存储策略也不一样,有的考虑更节省内存,就存到磁盘,内存放个入口; 有的就直接仍在内存,把你内存挤满来换取更快的返回。
是Goopand说的hash join,而且确实hash join在OLAP中用处很大。你可以给表加索引,但是你没办法给某个查询的中间结果加索引,OLAP经常会有join好几个经过group by的子查询,如果没有hash join加临时索引NL效率是很低的。
当然,你可以把前面说的好几个group by的子查询先create table as select xxx group by xxx变成表,再加索引,再把这几个表连接起来查,但这个麻烦程度太大了。
0

引用来自“Goopand”的评论

我们的项目原先用MySQL,几张表的稍复杂点的join查询,1个小时都出不来结果;后来在我的强力建议下,换成了PostgreSQL,查询结果0.3秒左右(300多毫秒),目前使用PG最新的分区表特性,加上丰富的数据类型支持、丰富的内置函数,爽的飞起。

引用来自“tulayang”的评论

只能说你们开发组太无知,也许 PostgreSQL 默认给你们建了索引你们不知道呢。讨论技术要从数学讨论,不要从感觉上

引用来自“乌龟壳”的评论

去了解下hash join,纯DB的OLAP本来就不是mysql强项

引用来自“mark35”的评论

mysql不支持集合运算,所以涉及到多表关联操作的肯定卡得比狗还慢
数据库只是作为程序的一种输入输出,并不适应作大量运算
0

引用来自“Goopand”的评论

我们的项目原先用MySQL,几张表的稍复杂点的join查询,1个小时都出不来结果;后来在我的强力建议下,换成了PostgreSQL,查询结果0.3秒左右(300多毫秒),目前使用PG最新的分区表特性,加上丰富的数据类型支持、丰富的内置函数,爽的飞起。

引用来自“tulayang”的评论

只能说你们开发组太无知,也许 PostgreSQL 默认给你们建了索引你们不知道呢。讨论技术要从数学讨论,不要从感觉上

引用来自“乌龟壳”的评论

去了解下hash join,纯DB的OLAP本来就不是mysql强项

引用来自“tulayang”的评论

别说 hash join,你确定这个差别是 hash join 在起作用?以前 lamp 流行,就是因为 mysql 的查询快于 pg。数据库的索引存储策略也不一样,有的考虑更节省内存,就存到磁盘,内存放个入口; 有的就直接仍在内存,把你内存挤满来换取更快的返回。
mysql那个索引组织表设计在多表大数据复杂业务下面基本是个死字
0

引用来自“Goopand”的评论

我们的项目原先用MySQL,几张表的稍复杂点的join查询,1个小时都出不来结果;后来在我的强力建议下,换成了PostgreSQL,查询结果0.3秒左右(300多毫秒),目前使用PG最新的分区表特性,加上丰富的数据类型支持、丰富的内置函数,爽的飞起。
几年前网上见过一个场景,GIS数据分析。每天大概十多G的数据,某条查询(忘记了是查全库还是当前入库数据)mysql跑了一小时没结果,换成pg大概3分钟。
0

引用来自“Goopand”的评论

我们的项目原先用MySQL,几张表的稍复杂点的join查询,1个小时都出不来结果;后来在我的强力建议下,换成了PostgreSQL,查询结果0.3秒左右(300多毫秒),目前使用PG最新的分区表特性,加上丰富的数据类型支持、丰富的内置函数,爽的飞起。

引用来自“tulayang”的评论

只能说你们开发组太无知,也许 PostgreSQL 默认给你们建了索引你们不知道呢。讨论技术要从数学讨论,不要从感觉上

引用来自“乌龟壳”的评论

去了解下hash join,纯DB的OLAP本来就不是mysql强项
别说 hash join,你确定这个差别是 hash join 在起作用?以前 lamp 流行,就是因为 mysql 的查询快于 pg。数据库的索引存储策略也不一样,有的考虑更节省内存,就存到磁盘,内存放个入口; 有的就直接仍在内存,把你内存挤满来换取更快的返回。
顶部