2018年盘点商业数据库VS.开源数据库 – Updated@2019-05-16 本文来源于DB-Engines的年度特别报告-Popularity of open source DBMS versus commercial DBMS。原文链接如下: https://db-engines.com/en/ranking_osvsc 被定义为开源系统的数据库,是全部能够自由获取源码,并且可以在遵循某种许可协议的情况下进行自由使用和改写的。 数据库个数 DB-Engines总共列出了347种数据库,其中178种为商业数据库,169种为开源数据库,基本上可以认为是五五开的局面。 数据库流行度 根据当年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宣布正式上线的自治数据仓库数据库)。 完整的发布会视频链接在这里。 全自动 Nothing to Learn, Nothing to Do. 这句宣传语在Larry的演讲中被重复了很多次。我们可以将自治数据库想象成自动驾驶,在没有自动驾驶之前,驾驶员要开一辆车从A地到B地,需要先考取驾照,还需要学习很多技巧,并且在开车的过程中仍然需要集中精力,否则容易出差错。但是有了自动驾驶(理想状态中的自动驾驶),我们不再需要驾驶员,乘客只需要告诉车辆我要从A地到B地,车辆就自动寻找最佳路线行驶了,在这个体验中,乘客完全不需要学些任何驾驶技巧,也不需要做任何驾驶的事情。这就是Nothing to Learn, Nothing to Do,那么在最新的Oracle自治数据库中,传统的DBA工作也不再需要了。安装、扩展、优化、安全、高可用、备份恢复等等,这些以往高深的技巧,现在统统不再需要学习,也不再需要DBA手工去做了。 恭喜大家,在传统DBA的职业道路上离失业又近了一步。 真.弹性 Larry在整个演讲中,不知道说了多少次AWS,基本上就是盯着AWS打。只会为使用到的基础架构资源付费,没用到的不用付钱。如果把数据库从AWS上迁移到Oracle Cloud上的自治数据库里,承担的成本将减半,特意重点标注了“Guaranteed”,Larry拍着胸脯保证,账单数字一定会减半。 是骡子是马拉出来遛 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便宜 整个演讲中间还有不少页,提及了Oracle自治数据库的优点,不过本来在这个世界上也确实没有比Oracle数据库单个解决方案更优秀的数据库产品了,因此Oracle数据库只是不断在超越自己,我们就不看了。我们总说,Oracle数据库除了贵没别的毛病,所以Larry在演讲快结尾的时候又再次提及了,这是我们写下来的承诺,能够满足客户业务负载的成本至少比Amazon便宜50%。 人干不过机器 Larry在演讲的最后几分钟,举了NetSuite的案例。虽然PPT上的数字有些语焉不详,比如原来的8151个索引和下面的人类专家使用的4663个索引是什么关系?专家调优过的运行时间1172秒是运行了上面全部17542的SQL的总时长吗?但是,没关系,Oracle想说的是,Oracle ATP能够全自动地分析负载并创建更少更合适的索引,获得跟专家调优相近甚至更优的性能。 虽然为了公平起见,我们还是要提一下NetSuite是Oracle收购了的ERP厂商,但是毋庸置疑,人类传统DBA们面临了越来越多的挑战,就像前几天看到的新闻,DOTA2专业电子竞技高手被AI控制的机器完爆,打得找不到北。 免费品尝 从Larry发表演讲的那一刻开始,就可以直接在Oracle Cloud网站申请免费测试Oracle ATP,但是在国内访问Oracle Cloud网站,特别是创建了免费账户以后登录进去的网站,遭遇了很强的阻碍。至少到目前为止,我还没有能成功地打开登录之后的第一个页面。欢迎期待我们测试以后的后续文章。 明年19c 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 [shell] sudo pcs resource update ag_cluster required_synchronized_secondaries_to_commit=0 [/shell] [sql] [Kamus@centos1 ~]$ sql 1> select name,required_synchronized_secondaries_to_commit from sys.availability_groups; 2> GO name required_synchronized_secondaries_to_commit —————————— ——————————————- ag1 0 (1 rows affected) [/sql] 现在三个节点都是正常状态。 [sql]…