Popularity of open source DBMS versus commercial DBMS (by DB-Engines)

2018年盘点商业数据库vs.开源数据库

本文来源于DB-Engines的年度特别报告-Popularity of open source DBMS versus commercial DBMS。原文链接如下: https://db-engines.com/en/ranking_osvsc

被定义为开源系统的数据库,是全部能够自由获取源码,并且可以在遵循某种许可协议的情况下进行自由使用和改写的。

数据库个数

DB-Engines总共列出了341种数据库,其中173种为商业数据库,168种为开源数据库,基本上可以认为是五五开的局面。

数据库流行度

根据当年DB-Engines每个月的数据库排名分数进行的分数计算,商业数据库险胜开源数据库,但是分数相差无几。

流行度趋势

从2013年开始统计了每一年的流行度,商业数据库一路下行,而开源数据库扶摇直上,从5年前只有1/3的流行度到今年跟商业数据库几乎平分天下,开源产品可谓是改变了世界。

按照数据库类型区分的流行度

在宽列数据库,时间序列数据库,文本数据库,键值数据库,搜索引擎,图像数据库这几类数据库中,开源产品均领先于商业产品,很明显,互联网和互联网应用的兴起,海量数据存储和非结构化数据存储的需求,极大地促进了开源产品的产出和受欢迎程度。而从传统的关系型数据开始往后,包括XML数据库,面向对象的数据库等,仍然是商业数据库更受欢迎。

排名前5的商业数据库

Oracle依然排名第一,但是微软在云端的更早发力,让SQL Server已经跟Oracle相差无几。

排名前5的开源数据库

MySQL仍然排名第一,但是不可否认从2017年开始,PostgreSQL正在迅速地获得更多关注。

Oracle Announces Availability of Oracle Autonomous Transaction Processing(ATP)

在8月7日,Oracle宣布在云上正式上线自治事务处理数据库,这个名词ATP应对于早前发布的ADW(今年3月份Oracle宣布正式上线的自治数据仓库数据库)。

完整的发布会视频链接在这里

全自动

Everything is Automated

Nothing to Learn, Nothing to Do. 这句宣传语在Larry的演讲中被重复了很多次。我们可以将自治数据库想象成自动驾驶,在没有自动驾驶之前,驾驶员要开一辆车从A地到B地,需要先考取驾照,还需要学习很多技巧,并且在开车的过程中仍然需要集中精力,否则容易出差错。但是有了自动驾驶(理想状态中的自动驾驶),我们不再需要驾驶员,乘客只需要告诉车辆我要从A地到B地,车辆就自动寻找最佳路线行驶了,在这个体验中,乘客完全不需要学些任何驾驶技巧,也不需要做任何驾驶的事情。这就是Nothing to Learn, Nothing to Do,那么在最新的Oracle自治数据库中,传统的DBA工作也不再需要了。安装、扩展、优化、安全、高可用、备份恢复等等,这些以往高深的技巧,现在统统不再需要学习,也不再需要DBA手工去做了。

恭喜大家,在传统DBA的职业道路上离失业又近了一步。

真.弹性

Truly Elastic

Larry在整个演讲中,不知道说了多少次AWS,基本上就是盯着AWS打。只会为使用到的基础架构资源付费,没用到的不用付钱。如果把数据库从AWS上迁移到Oracle Cloud上的自治数据库里,承担的成本将减半,特意重点标注了“Guaranteed”,Larry拍着胸脯保证,账单数字一定会减半。

是骡子是马拉出来遛

屏幕快照 2018-08-09 15.25.02

屏幕快照 2018-08-09 15.26.49

屏幕快照 2018-08-09 15.32.08

Larry接着连续用三页PPT叫板AWS,甚至在已经播放到下一环节以后,又请播放人员退回到上一页,持续嘲讽AWS。这就像60等级时候的魔兽世界,熟悉的“3破输出!”,Larry就是战士坦克,释放3个破甲,建立好仇恨,现在,DPS们可以输出了。

Oracle自治数据库,比AWS数据库快5-10倍。Larry,快5-10倍是什么意思?就是我用10秒钟干活的活儿,你AWS要干1分钟,在按照分钟计费的Cloud数据库中,这就意味着我比AWS要便宜5-10倍。

在纯的在线交易测试中,Oracle ATP比Aurora快12倍,在混合负载场景下,Oracle ATP比Aurora快100倍。在这一页上,Larry疯狂嘲讽了AWS,他说,AWS让别人用Aurora,用Redshift,但是他们自己却在用Oracle,在10年前,AWS就说要弃用Oracle数据库,但是到现在他们也没有做到。Larry还顺道一并嘲讽了SAP和Salesforce,他说这几个哥们儿都特别不想用Oracle数据库,但是怎么去也去不掉,因为这件事情真的很难很难,还因为Oracle数据库真的很优秀很优秀。

Oracle自治数据库可以在运行的同时实现安全补丁安装,可以让数据库获得99.995%的可用性,而AWS则做不到这一点,他们没办法在运行的时候为数据库打补丁。因此Oracle比Amazon稳定100倍。好吧,虽然我不知道这100倍的数字是怎么来的,但是Larry显得自信满满。

就是比AWS便宜

屏幕快照 2018-08-09 16.13.13

整个演讲中间还有不少页,提及了Oracle自治数据库的优点,不过本来在这个世界上也确实没有比Oracle数据库单个解决方案更优秀的数据库产品了,因此Oracle数据库只是不断在超越自己,我们就不看了。我们总说,Oracle数据库除了贵没别的毛病,所以Larry在演讲快结尾的时候又再次提及了,这是我们写下来的承诺,能够满足客户业务负载的成本至少比Amazon便宜50%。

人干不过机器

屏幕快照 2018-08-09 16.19.48

Larry在演讲的最后几分钟,举了NetSuite的案例。虽然PPT上的数字有些语焉不详,比如原来的8151个索引和下面的人类专家使用的4663个索引是什么关系?专家调优过的运行时间1172秒是运行了上面全部17542的SQL的总时长吗?但是,没关系,Oracle想说的是,Oracle ATP能够全自动地分析负载并创建更少更合适的索引,获得跟专家调优相近甚至更优的性能。

虽然为了公平起见,我们还是要提一下NetSuite是Oracle收购了的ERP厂商,但是毋庸置疑,人类传统DBA们面临了越来越多的挑战,就像前几天看到的新闻,DOTA2专业电子竞技高手被AI控制的机器完爆,打得找不到北。

免费品尝

屏幕快照 2018-08-09 16.16.58

从Larry发表演讲的那一刻开始,就可以直接在Oracle Cloud网站申请免费测试Oracle ATP,但是在国内访问Oracle Cloud网站,特别是创建了免费账户以后登录进去的网站,遭遇了很强的阻碍。至少到目前为止,我还没有能成功地打开登录之后的第一个页面。欢迎期待我们测试以后的后续文章。

明年19c

屏幕快照 2018-08-09 16.17.59

Larry简短地预报了Oracle数据库的路线图,在2019年一月份,将会发布Oracle 19c,还停留在11g时代的兄弟们,是不是应该感到惭愧了?

All Secondary die, Primary hang? – SQL Server 2017 on Linux

关于AVAILABILITY_MODE

需要注意的是,与Oracle Data Guard不尽相同的概念是,在Always On AG中每个replica上都可以设置自己的AVAILABILITY_MODE。
AVAILABILITY_MODE参数有三个可选值,分别是SYNCHRONOUS_COMMIT、ASYNCHRONOUS_COMMIT和CONFIGURATION_ONLY。

  • SYNCHRONOUS_COMMIT:同步提交,意味着主replica的事务必须等到备replica将变更日志写入磁盘中才可以提交。可以设置包括主replica在内的最多三个replica处于同步提交状态。
  • ASYNCHRONOUS_COMMIT:异步提交,意味着replica无需等待备replica的动作而可以直接提交成功。
  • CONFIGURATION_ONLY:仅同步AG配置元数据。设置为该值的replica仅会从主replica中将AF配置的元数据同步过来,不会同步任何用户表数据。

在一个多节点replica的AG环境中,如果:

  • 主库和其中任何一个备库设置为SYNCHRONOUS_COMMIT,则主库的日志提交必须等待该备库完成日志写入;
  • 主库设置为SYNCHRONOUS_COMMIT,而所有备库都设置为ASYNCHRONOUS_COMMIT,则主库无需等待;
  • 主库设置为ASYNCHRONOUS_COMMIT,则无视备库上该参数的设置,主库均无需等待。

在多节点的AG环境中,假设一个主库配置了两个同步的secondary,那么是不是要等待这两个secondary都完成日志写入才能提交事务呢?此时又引入了required_synchronized_secondaries_to_commit参数。

关于required_synchronized_secondaries_to_commit

required_synchronized_secondaries_to_commit参数是在SQL Server 2017中引入的,这个参数从直观意义上就可以看得出是指定当commit的时候需要有个几个同步的secondary replica存活。

这个参数在三节点的AG集群中,默认值为1,也就是如果至少要存活一个secondary replica,主库上的事务才可以提交,否则commit就会一直等待。这很好理解。
但是不好理解的是,该参数可以手工修改为0,从字面上看应该是说,即使所有secondary replica都不同步了,也是可以允许commit的。

但是实际情况却并非如此,修改为0是不起作用的。通过以下测试可以知道。

首先,设置required_synchronized_secondaries_to_commit参数为0

<br />sudo pcs resource update ag_cluster required_synchronized_secondaries_to_commit=0<br />

<br />[Kamus@centos1 ~]$ sql<br />1> select name,required_synchronized_secondaries_to_commit from sys.availability_groups;<br />2> GO<br />name required_synchronized_secondaries_to_commit<br />------------------------------ -------------------------------------------<br />ag1 0</p>
<p>(1 rows affected)<br />

现在三个节点都是正常状态。

<br />1> select r.replica_server_name,r.availability_mode_desc,r.session_timeout ,rs.connected_state_desc<br />2> from sys.availability_replicas r,sys.dm_hadr_availability_replica_states rs<br />3> where r.replica_id=rs.replica_id;<br />4> GO<br />replica_server_name availability_mode_desc session_timeout connected_state_desc<br />------------------------------ ------------------------------ --------------- ------------------------------<br />centos1 SYNCHRONOUS_COMMIT 10 CONNECTED<br />centos2 SYNCHRONOUS_COMMIT 10 CONNECTED<br />centos3 SYNCHRONOUS_COMMIT 10 CONNECTED</p>
<p>(3 rows affected)<br />

在主节点上进行Insert,可以成功,这很好。

<br />1> insert into t1 select * from sys.databases;<br />2> GO</p>
<p>(6 rows affected)<br />

停掉一个secodary replica。显示第二个节点已经DISCONNECTED。

<br />1> select r.replica_server_name,r.availability_mode_desc,r.session_timeout ,rs.connected_state_desc<br />2> from sys.availability_replicas r,sys.dm_hadr_availability_replica_states rs<br />3> where r.replica_id=rs.replica_id;<br />4> GO<br />replica_server_name availability_mode_desc session_timeout connected_state_desc<br />------------------------------ ------------------------------ --------------- ------------------------------<br />centos1 SYNCHRONOUS_COMMIT 10 CONNECTED<br />centos2 SYNCHRONOUS_COMMIT 10 DISCONNECTED<br />centos3 SYNCHRONOUS_COMMIT 10 CONNECTED</p>
<p>(3 rows affected)<br />

在主库上进行Insert,还是可以成功,这很好。

<br />1> insert into t1 select * from sys.databases;<br />2> GO</p>
<p>(6 rows affected)<br />

再停掉一个secodary replica。显示2、3节点都已经DISCONNECTED。

<br />1> select r.replica_server_name,r.availability_mode_desc,r.session_timeout ,rs.connected_state_desc<br />2> from sys.availability_replicas r,sys.dm_hadr_availability_replica_states rs<br />3> where r.replica_id=rs.replica_id;<br />4> GO<br />replica_server_name availability_mode_desc session_timeout connected_state_desc<br />------------------------------ ------------------------------ --------------- ------------------------------<br />centos1 SYNCHRONOUS_COMMIT 10 CONNECTED<br />centos2 SYNCHRONOUS_COMMIT 10 DISCONNECTED<br />centos3 SYNCHRONOUS_COMMIT 10 DISCONNECTED</p>
<p>(3 rows affected)<br />

在主库上执行Insert,此时hang住,这很不好。

<br />1> insert into t1 select * from sys.databases;<br />2> GO</p>
<p>

更讨厌的是,对于该表的查询也会hang住,这就更不好了。

<br />2> select count(*) from t1;<br />3> GO</p>
<p>

现在数据库中的等待是什么呢?确实是HADR_SYNC_COMMIT。

<br />1> select STATUS,COMMAND,DATABASE_ID,WAIT_TYPE,WAIT_TIME from sys.dm_exec_requests where command='INSERT';<br />2> GO<br />STATUS COMMAND DATABASE_ID WAIT_TYPE WAIT_TIME<br />------------------------------ ------------------------------ ----------- ------------------------------ -----------<br />suspended INSERT 5 HADR_SYNC_COMMIT 1670</p>
<p>(1 rows affected)<br />

如果我们更进一步做一个session的xevent trace,可以看到等待的是WaitForHarden,而Harden的意思即是remote replica的日志写入。现在主库在等待一个备库的日志完成写入,然后自己才能提交成功。在正常情况下,当主库不再需要等待备库而可以自行commit的情况下,在xevent trace中应该出现将备库的commit_policy标志为donothing状态,也就是在xevent中应该要出现hadr_db_partner_set_policy事件才是正常的,然而这里并没有出现。

但是我们明明把required_synchronized_secondaries_to_commit参数设置为0了,这很违反常识,不是吗?

结论

在SQL on Linux中如果设置了availability_mode为SYNCHRONOUS_COMMIT,那么必须至少有一个secondary replica(或者一个config node)是存活的,否则priamry replica中就不再允许任DML操作,而尝试对于某表进行DML之后,还会进一步阻塞对于该表的查询。即使设置了required_synchronized_secondaries_to_commit=0也是无效的。也许微软需要更新一下文档,明确说明在多个sync的secondary存在的情况下,该参数即使修改为0也仍然按照1来处理。
这是一个很奇怪的design,因为这强制去掉了当一个集群中所有备库都崩溃时,主库能够自动转为异步提交模式的功能,从而造成了所有备库失效则会影响主库业务正常进行这样一个大问题。
实际上这个design是在SQL on Linux 2017 CU1之后才修改的,在CU1之前还是允许当所有备库都失效以后,主库仍然是可以正常读写的。甚至在现在的文档中仍然保留了这样的描述。


以上文档描述来自:High availability and data protection for availability group configurations

这意味着在SQL Server 2017 CU 1之后,不再支持单纯的read-scale功能的AG了。虽然不太理解微软的SQL Server程序员是怎么考虑这个问题的,但是现状就是如此。

相比起Oracle的Data Guard而言,也就是现在SQL Server的AG只有同步(等同于DG的Maximum protection),异步(等同于DG的Maximum performance)这样两种方式,而缺少了DG的Maximum availability模式。
我只能认为这是一个设计理念的问题,微软的程序员更倾向于关注数据一致性,但是我期望在未来SQL Server可以对此进行改进。