前言 && 感想
本年度Oralce Open World会议从十月25号到29号,在美国旧金山举行。数万来自全球各地的从业人员涌入Moscone Center,见证一年一度的Oracle生态系统盛事。
本次OOW2015的主题都是围绕在Oracle Cloud,云服务应该是Oracle之后的发力点。几场Oracle CTO(前Oracle CEO)Larry的主题演讲也围绕cloud,详细阐述了Oracle Cloud的设计原则,及相关的云产品,其目标直指Amazon和Microsoft的云服务。
我在OOW的关注点主要是几场KeyNote以及MySQL相关的Topic。先总结下参会的感受吧:
- Oracle的主场还是集中在Oracle database, Oracle Cloud以及Java。而“不太会赚钱”的MySQL主题则安排的比较少,会场也都是最小的;
- 关于MySQL,前几天MySQL5.7版本在前几天刚刚宣布GA,因此本次会议的官方主题都是关于新版本的特性介绍,新的版本带来了大量新特性(例如GIS、Build-in JSON、新的Fulltext Parser、Generated Column)以及性能优化(复制性能、InnDB读写性能),大量内部锁竞争的移除,使得新版本MySQL能够在多核环境下更好的Scale Up,发挥硬件的性能;
- 大部分内容都是已有的技术,并没有什么新的黑科技;
- 也有几家美国公司来介绍他们如何使用MySQL,但类似Facebook、Twitter这样的MySQL重度用户且对社区有很大贡献的公司却集体缺席,不得不说是个很大的遗憾;
- 从这几家公司使用MySQL的情况来看,我感觉阿里在MySQL领域的工作绝对是首屈一指的,没有多少公司像我们这样把MySQL玩的这么深入,这么深度的修改源码来适应我们的环境。明年如果有机会,不管谁去参加,我觉得都可以考虑去做几个主题演讲,宣传公司在MySQL社区的影响力;
- 从交流了解到,美国很多互联网公司都选择把服务器托管在AWS上。未来阿里云的国际化,需要把我们的技术影响力扩展到国外,才能争取到这样的用户。
以下是这五天期间我关注的几个Topic,主要从Oracle 、MySQL官方演讲、业界使用三个方面划分。
Oracle主题
Oracle OpenWorld Welcome Keynote [KEY10818]
Larry Ellison, Executive Chairman of the Board and Chief Technology Officer, Oracle
Brian Krzanich, CEO, Intel Corporation
当天第一场重磅keynote,由intel的CEO主持,这次会议着重强调Intel和Oracle的深度合作带来的价值,顺便开刷了下IBM在云计算领域的落伍。最后压轴的是Larry的演讲,主题是Oracle Cloud服务,他明确指出了其在SAAS领域的对手是Salesforce,PaaS领域的对手是微软而不是IBM,IaaS领域的对手是Amazon(Aliyun在美国还是籍籍无名啊…)。相对于这些竞争对手,Oracle要做全平台的云服务提供商:在SaaS提供全部种类的商业应用,例如CX、HCM、ERP、EPM等;在PaaS领域提供完全符合工业标准的平台服务;在IaaS领域突出安全性、可靠性、低开销,标准化的基础设施服务。
为了达成上述目标,Larry从以下几个角度阐述了Oracle云服务的设计目标:
第一是低成本(cost),包括价格上具备竞争优势,通过自动化降低人力成本和人为误差,更轻易的创建和使用应用来减少成本。
第二是高可用性(reliability),实现零宕机时间。两个方面:
- fault tolerant,通过冗余设计,hot patching及备份,即时恢复来实现;
- 自动化(automation),消除在部署、补丁、备份及恢复期间的人为错误。
第三是高性能,从三个方面阐述:
- 数据库,in-memory in-flush的列式数据库,部署在云中的Exadata;
- 中间件,In-memory speed-of-thought Analytics; 3.Sale-out架构,弹性能力,和按需获的性能。
第四是标准化,支持工业标准的SQL、Hadoop、NoSQL等等,让用户能够无锁定的自由迁移到其他云服务平台。
第五是兼容性,能够自动迁移负载和数据。例如从公有云和私有云之间自由迁移。
第六是安全性,能够持续的抵御黑客攻击。最新发布的SPARC M7处理器在硬件层支持实时的安全监测;另一方面也提供数据加密。
在阐述上述观点后,随后发布了一大堆的云产品,Oracle强势宣布了其正式进入了云计算领域。
Exploring Oracle Database 12c New Features Best Practices for DBAs and Developers [UGF7904]
Ami Aharonovich, CEO, DBAces-ilOUG
介绍了Oracle 12c的一些新特性,以及如何使用这些特性,作为一名MySQL开发,最让我感兴趣的是MySQL中没有的功能,以及是否能将Oracle的这些功能也实现到MySQL中去。以下是几个笔记的点。
隐藏列属性:定义为“column_name TYPE INVISIABLE”。当设置该属性后,这个列的内容对客户端而言就是不可见的,但如果显式的指定列名的话,则可以对该列进行操作,主要用于类似应用迁移之类的场景,例如增加新的列,不影响老的应用,同时新的应用也可以通过指定列的方式进行操作。MySQL可以考虑把这个特性Port过来。这个文档 有对该特性的描述。
默认的sequence值:可以默认获取一个新的sequence值(定义为column_name TYPE DEFAULT seq_name.nextval),另外一种方式是在列上定义一个IDENTIFY属性(id NUMBER GENERATED ALWAYS AS IDENTITY)仔细想想,这货不就是MySQL的Auto-Increment属性么。
Data Redaction:顾名思义,就是数据修订的意思,对返回给客户端的值进行修订,例如将敏感信息用”*“代替返回。有FULL Redaction、Partial Redaction、Regular expression、Random Redaction、No Redaction几种。如下图所示:
具体介绍参阅这篇文章。
下图描述了这个特性的一个典型应用。感觉是个比较有意思的特性,后面看看怎么做的,可以考虑实现到MySQL里
更好的加列操作:如果列的值允许为NULL,加列操作不会产生表上所有记录更新,而是修改元数据。当查询到这个列时,如果尚未有数据,则从元数据中获得其default值,并返回给客户端。同样的思路可以应用于MySQL。
Adaptive Execution PLan:运行过程中自动调整执行计划,最终的计划取决于执行过程中看到的行数。
在该演讲slide的最后贴了大量关于Oracle 12c相关的链接,感兴趣的可以点开了解下。
General Session: Software in Silicon and SPARC Outlook—Secure, Smarter Database/Applications [GEN6421]
Masood Heydari, SVP, Hardware Development, Oracle
介绍新发布的SPARC M7 处理器,其性能强悍,号称有32个core,256线程,4.13GHZ,64MB的L3 Cache, 支持最大2TB的物理内存,支持4路DDR4 内存控制器; 并且相比前一代有3倍IO带宽提升;该处理器还支持Silicon Secured Memory, DB query Acceleration,Inline Decompression,将软件功能集合到硬件中,从而最大化发挥效率。其号称世界上最快的微处理器,其基于硬件的内存安全防护,能够防止黑客非法访问内存内容
MySQL官方演讲
How to Analyze and Tune SQL Queries for Better Performance [TUT3411]
Oystein Grovlen, Senior Principal Software Engineer, Oracle
演讲者为MySQL团队优化器模块的开发人员,重点介绍了优化器的相关知识,包括优化器的执行过程, MySQL 5.7引入的cost model ,5.6版本之后引入的物化统计信息。
其中比较有意思的点是cost model,介绍了用户如何通过设置cost model来影响优化器的行为。
通过实例介绍了索引选择的类型,介绍了join和子查询是如何进行优化器选择的,以及排序和聚合操作。 该演讲的slide干货满满,对优化器感兴趣的同学非常值得一看。
MySQL Replication Tips and Tricks [TUT5467]
Joao Gramacho, Software Developer, Oracle
详细介绍了MySQL的复制模块,以及大量的使用技巧及5.7的新特性,从浅显的知识到更深入的讨论都有涉及,适合对复制模块感兴趣的各个层次人群阅读。
InnoDB: What’s New in MySQL 5.7 [CON3716]
Sunny Brain, InnoDB Developer Manager
暂无PPT
InnoDB的开发主管Sunny Brain介绍了MySQL5.7对InnoDB模块的改进,总的来说,主要包括以下几点:
General tablespace: 一种用户定义的表空间,在磁盘上会生成一个ibd文件,可以指定表空间名来创建表,这些表的数据都存储到一个ibd文件中。
Virtual column:支持虚拟列,即用户通过预设的表达式定义的列,这样的列不存储数据,但支持基于其上建立索引。一种典型的应用是基于Json类型数据之上,使用json相关函数创建虚拟列。隔天Jimmy Yang有个演讲专门介绍这一块。
native partition:将分区表的引擎接口从Server层转移到InnoDB层,这意味着之前每个分区都需要一个存储引擎接口,现在则只需要一个引擎接口,对于包含大量分区的分区表而言,可以减少不少内存消耗。另外这种改变,也使得未来基于分区表做并行查询更加简单。
全文索引:改进了全文索引,可以更好的支持中文全文索引分词,这极大的弥补了5.6版本InnoDB全文索引的不足之处,从5.7版本开始,MySQL用户可以完全抛弃MyISAM引擎的全文索引
R-Tree Index(GIS Support):开始支持GIS空间数据类型,弥补了MySQL和其他数据库(如PostgreSQL)相比的一大缺憾,GIS对当前基于地理空间的应用是非常重要的功能。
性能优化:在5.7版本对读写性能做了大量的优化,例如优化了读写事务链表的管理,Read View缓存(两个只读查询之间没有新的读写事务,则认为read view是可重用的),消除了大量的事务锁瓶颈。基于这些改进,新版本的性能(尤其是读性能)能够在多核场景下获得更好的性能。 在讨论到Read view缓存时,我发现在RC隔离级别下,这一优化策略并没有生效,和Sunny讨论了下这个问题,他表示认同。
索引锁优化:引入SX Lock,在对btree做分裂或合并操作时,不再锁住整棵btree,从而降低对读负载的影响。
事务生命周期特性: (主要用于支持5.7另外一个新特性:Group Replication),包括高优先级事务,高优先级获取记录锁(可以从记录锁队列中往前跳),kill其他低优先级事务。目前这几个特性还对终端用户不直接可见。
DDL优化:对于索引创建,在之前的版本中使用先排序数据,再执行插入到新btree中的方式,而新版本则使用自低向上的索引构建方式,即先构建叶子节点,再从叶子节点开始构建非叶子节点,这样具有极高的索引创建效率。
Intrinsic table:主要被优化器使用,在之前版本中使用的是MyISAM引擎来作为查询过程中产生的临时表引擎;在5.7版本中,InnoDB对临时表(intrinsic table)做了大量优化,包括独立的临时表表空间,独立的undo回滚端,减少redo log的记录。下图是他们的性能比较图,可以看到InnoDB在高并发下能获得更好的性能。
Memcached: 由于消除了大量的性能瓶颈,MySQL5.7的Memcached Plugin相比5.6有了数倍的提升,而在稳定性上,也修复了大量的bug,相信5.7版本能够改变5.6版本Memcached plugin无人问津的窘境。
其他还包括诸如大Page Size支持,CRC32的Redo log校验,多个Page cleaner线程及buffer pool刷脏逻辑优化。
总的来说,MySQL5.7是个非常值得期待的版本。
Building Scalable, High-Availability Systems Using MySQL Fabric [CON4975]
Mats Kindahl, Senior Principal Software Developer, Oracle
暂无PPT
介绍了MySQL新组件Fabric,主要用于构建高可用,可扩展的系统。Fabric本质上是一组脚本,算是官方出品的HA和Sharding工具。由于阿里在这一块已经非常的成熟,我对Fabric本身并不感兴趣,感兴趣的可以参阅官方文档。而对为了支持fabric对服务器端代码做的改动比较感兴趣。
总的来说,为了支持Fabric,MySQL本身做了几点改动:
实现一种新的方法来清理session的状态,可以reset 已有的会话,例如清理其内容并释放资源(WL#6797),这在我们RDS里也有类似的实现。
允许MySQL服务器进入一种离线状态,让已有的连接优雅的断开(SUPER账户除外),这主要用于升级或者维护服务器。该特性也用于fabric来辅助管理MySQL集群。(WL#3836)
增加一个服务器层的flag来判断是否有一个新的事务开启了,主要用于连接池的负载均衡,如果一个session未开启事务,就可以把它的请求调度给别的连接。 (WL#6631)
另外在29号也有另外一个关于Fabric的主题演讲,参阅PPT。
MySQL 5.7: What Is New in the Optimizer? [CON3379]
Manyi Lu, Senior engineering manager, Oracle
负责MySQL服务器层的开发主管介绍了MySQL5.7版本对Optimizer模块的优化,主要包括如下几个方面的改进。
Generated Column:用户可以在建表或ALTER时创建的一种新的列类型,列的数据可以通过一个预设的表达式来进行计算,如下建表语句:
CREATE TABLE order_lines
(orderno integer,
lineno integer,
price decimal(10,2),
qty integer,
sum_price decimal(10,2) GENERATED ALWAYS AS (qty * price) STORED );
最后一个列的值为qty列和price列相乘得到。STORED属性表示在插入或更新时计算该列的值并存储到物理文件中。你也可以选择VIRTUAL属性,这样就只在查询时计算。这可以满足一些特殊的需求:例如实现基于方法的索引,物化缓存复杂的条件,简化查询SQL表达式。
JSON Support:支持内建的JSON类型的数据存储,并提供一组JSON函数。使用也比较简单,直接将列类型定义为JSON。
对于JSON类型的数据,在插入或更改时,会进行格式检查,通过新的语法和函数,也可以更方便的操作JSON数据。
和Generated Column相结合,我们还可以对json中的数据进行索引创建,从而索引json中的某个数据段。
PS:当天有另外一个演讲专门对JSON做了介绍
Cost Model:用户可以根据自己的硬件场景来配置cost model,进而影响优化器的选择。基于5.7的cost model,解决了如下几个问题:
- 对于JOIN操作的记录数估计不准确;
- hard-code的代价常量;
- 不准确的record-per-key,使用浮点数代替;
- 使用json输出explain的结果。Manyi Lu强调在下一个版本中,他们会着重解决优化的cost model自动调整功能,而不是依赖人来配置。
新的HINT表达式:在插叙中使用 /+ …/ 来开启一些优化器或者其他选项,例如BKA, BNL, MRR, ICP, SEMIJOIN, SUBQUERY,MAX_EXECUTION_TIME等等常用HINT。
Query Rewrite Plugin:一种新的插件类型,主要解决的问题是在不修改应用的情况下,更改其SQL的行为,例如如果优化器总是为这个SQL选择错误的执行计划,就可以为其加上hint做强制索引选择。
UNION ALL问题:在5.7版本终于解决了臭名昭著的UNION ALL总是创建临时表的问题,多个表做UNIALL ALL时,数据先存储到临时表,然后再发送,但UNION ALL并不需要结果集的顺序性和唯一性,没有必要构建临时表来作去重。
IN表达式优化:在之前的版本中,对于这样的表达式WHERE (a, b) IN ((0, 0), (1, 1)),即时(a,b)上存在索引,也无法使用IN表达式中的值去查询索引,在5.7解决了这个问题,可以使用索引做range scan。
EXPLAIN:可以去查看一个正在运行的SQL的执行计划,这个特性对我们诊断问题非常有用。
最后Manyi Lu罕见的给出了下一个版本优化器模块的RoadMap(Oracle的开发人员通常不会对下一阶段的开发发表评论),包括:
- 改进对存储过程的支持;
- 增加类似oracle的直方图;
- 支持并行查询;
- 公用表表达式(Common table expression) 。
在后面的讨论中,Manyi Lu也透露了“查询计划缓存”也在开发的计划中(尽管这里没有列出来)。
从优化器的进化可以看出来,MySQL的优化器模块开始变的越来越像Oracle了。希望新版本的MySQL5.7能够改变人们一向的“MySQL优化器很弱”的印象。
Update Everywhere with the MySQL Group Replication Plugin [CON5349]
Nuno Carvalho, Principal Software Engineer, Oracle
暂无PPT
介绍了MySQL的一种新的插件类型:Group Replication plugin,主要用于类似active-active复制拓扑结构的集群管理,支持多个节点更新,自动冲突检测,自动增删节点等功能,类似MariaDB的Galera。Group Replication目前已经到了0.6.0版本,但还没有正式GA。
使用Group Replication,需要保证使用的表都是InnoDB表,并且定义了主键。Binlog需要使用Row模式。
Group Replication的分布式一致性协议基于XCom,一种PaxOS协议的变种。
关于冲突检测,开发了一组Group Communication 工具集,提供了完全有序的广播,也就是说,消息在所有的节点都按照同样的顺序进行应用。当产生一个新的更新消息时(以类似binlog row格式存储):
- 在当前实例上完成,但block在commit阶段;
- group communcattion组件会负责将消息发送到所有依然活跃的节点。
- 最关键的是决定本地事务是该提交还是回滚。这就涉及到如何进行冲突检测,每个行记录都有一个版本信息,在行被更新时,版本也会递增。主要通过节点间行记录的版本信息来进行冲突检测;
- 如果不存在冲突,则全部提交;否则全部回滚。
版本信息是通过GTID维护的,所有实例的UUID是全局统一的,并保证了所有节点产生的GTID不会重复。有两个版本信息,一个是database version,也就是本地的version(dbv),另外一个是确认模块的version(cv),下图是一个典型的冲突解决场景:
关于一个事务在Group Replication集群中的生命周期,参阅这篇博客
关于节点踢出和重新加入的逻辑,参阅这篇文章
在官方博客上还有不少文章介绍Group Replication,感兴趣的可以深入研究下。
What’s New in MySQL 5.7 Security [CON1559]
Georgi Kodinov, Senior Software Development Manager, Oracle
主要介绍了MySQL 5.7 包含的一些安全特性。包括:
企业版特性:
- SQL防火墙用于包含实例免受预期外的SQL注入侵害;
- 企业版数据加密。
账户管理:
- 增加ALTER USER语法来修改用户权限。
- 临时权限禁止功能;
- 基于时间的权限失效策略;
- 服务器提供offline模式。
重构及新功能:
1. 新的权限表格式;
2. 提供基于AES的加解密函数;
3. mysql_secure_install/mysql_install_db使用c语言进行了重构;mysql_upgrade不再调用外部程序。
业界使用
MyRocks: MySQL on RockDB
Yoshinori Matsunobu, database developer at facebook
由于26号没有什么比较值得关注的主题,我们应facebook的邀请,26号下午去拜访了Facebook的MySQL开发团队,了解了下之前我们一直关注的MyRock开发情况,他们的开发Yosh专门为我们做了介绍。
说到MyRock,需要先介绍下RockDB。RockDB是facebook基于LevelDB的一个分支,他们在其上做了大量的优化,目前已经集成到Mogodb 作为一个plugin,Percona公司也开始针对RockDB提供技术支持。RockDB基于LSM存储结构,能够有效的减少磁盘擦写的次数,这对Facebook非常重要,因为在他们那里flash设备已被广泛使用,通过rockdb能够有效的控制磁盘成本。另外更大的SST 文件块大小相比InnoDB获得更好的压缩效果,减少磁盘的存储空间。
但是RockDB仅仅支持key-value,并没有SQL接口,如果想用rockdb取代已被广泛使用的InnoDB,应用修改的成本巨大,因此他们启动了MyRock项目,将RockDB包装成MySQL的一个存储引擎。Yosh透露预计明年会出一个GA版本,目前还处于开发状态,他们也在该项目上和MariaDB进行紧密合作。
为了进一步减少磁盘空间,他们实现了“prefix key encoding”,即对于具有相同前缀的行记录,这些相同的列值只存储一次。不过这样也带来了一些负面作用,即需要在建表时设定是正序存储还是逆序存储,因此需要和应用方商量好。
由于LSM具有分层结构,对查询并不友好,最差情况下每个level可能都需要查询一遍。一次带order by的range scan需要将多个level的结果进行merge,这不像基于Btree结构的InnoDB,直接做一次顺序扫描即可。为了优化该场景,他们在MyRock中引入了bloom filter来加速查询,快速确认某个level是否有需要的记录,减少不必要的IO。
目前MyRock还有一些限制,包括:不支持Online DDL、Foreign Key、Spatial Index、以及Fulltext;所有表必须有primary key;不支持next-key lock,并且必须使用row格式复制;不支持binlog和myrock的XA;ORDER BY DESC/ASC 由于prefix key encoding,总有一个会比较慢点;大量删除操作会影响到整体性能。
总的来说,他们并不期望myrock能完全取代InnoDB,只是期望在某些场景下能利用LSM的优点。目前该项目公布在github上,代码的开发进度、提交日志一目了然,不得不让人敬佩facebook的开源和社区合作精神。
A Global Transaction Identifier Rollout at Dropbox [CON4766]
Rene Cannao, MySQL DBA, Dropbox
David Turner, Database Administrator, Dropbox
Dropbox公司分享了他们如何使用GTID。没啥新东西,主要的问题还是GTID无法动态调整,导致整个MySQL集群无法升级到5.6及之后版本的问题,这个问题在社区(例如Facebook和booking)都做了些简单的patch来绕过这个问题,咱们的RDS MySQL也有相应的改动。 这个问题在5.7版本得到了彻底的解决。Gtid的开启和关闭被划分成了多个阶段,来保证整个复制拓扑的GTID一致性
Making MySQL More Efficient at Pinterest [CON3654]
Ernie Souhrada, Database Engineer, Pinterest
Robert Wultsch, Database Engineer, Pinterest
暂无PPT
Pinterest公司的两位数据库工程师(实际上他们整个team就两个人),一个是前Percona员工,一个是前Facebook员工。他们分享了Pinterest如何让MySQL更高效。
由于只有两名员工,他们选择更多的依靠已有的技术,例如备份使用MySQL Enterprice Backup。他们提到一个比较有意思的问题是,在数据库中他们存储了大量的JSON数据,这些数据列的大小平均为1.2kb。正好他们看到了我们以前分享的关于单列压缩的改进,在他们的场景下测试得出的结论是,列压缩在保证性能的基础上,依然能提供不错的压缩比。
他们在列压缩的基础上,对这个功能进行了扩展,方案交给Percona进行开发。也就是所谓的Predefined Compression dictionary。会后和他们交流了具体的方案,了解了这个改进的具体内容:
其本质是将需要压缩的数据预先定义好,然后在全局使用这个预先定义的数据词典进行压缩。定义两张系统表,一张系统表存储数据词典信息,另外一张表存储列与数据词典的映射。
由于预先定义好了压缩前缀词典,即时一个字符串在某个列中只出现了一次,也是可以被压缩的。
压缩前缀词典可以通过训练已有的数据集得到。这确实是一个非常有趣的思路,对他们的这种场景,减少了72%的磁盘占用。
Binlog Servers at Booking.com [CON4098]
Jean-François Gagné, Senior System Engineer, Booking.com
来自booking的开发人员介绍了他们的binlog server工具,根据其描述,其工作原理就是一个独立的server,从master上读取binlog,存储到本地;然后将自己当做一个“假”的master,将binlog分发到各个slave节点。
在阿里,我们早几年就有了类似的工具,例如DRC, Transfer,精卫等。不过booking结合binlog server实现了其生产环境的高可用,读扩展以及时间点恢复功能。
YouTube Vitess: Cloud-Native MySQL [CON11339]
Anthony Yeh, Software Engineer, Google
来自谷歌的工程师介绍了Youtube的开源项目Vitess。对分布式中间件不太了解。没啥感觉
Feed Your Streams: Zendesk’s Maxwell Generates Kafka Event Stream from MySQL Binlogs [CON3340]
Ben Osheroff, Principle Engineer, zendesk.com
zendisk的工程师分享了另外一款开源的工具,同样也是用于解析Binlog的,不同的是,把binlog的内容解析成了json的格式并复制到Kafka,算是玩出了新意。例如解析出来的数据如下图所示:
Yahoo Case Study: MySQL GTIDs and Parallel or Multithreaded Replication [CON5409]
Yashada Jadhav, MySQL DBA, Yahoo
Stacy Yuan, Sr. MySQL DBA, Yahoo
主要讲了Yahoo关于GTID的使用,介绍了下复制的相关知识以及如何使用Percona版本的MySQL实现online GTID开启。没啥新意,看在难得是妹子的份上听了一会就闪了。但对这块不了解的同学可以看看。
Database Defense in Depth [CON3554]
Geoffrey Anderson, Senior Database Operations Engineer, Box
Box公司的DBA阐述了他们如何使用各种工具来解决MySQL遇到的问题,以保证MySQL的正常运行。没啥新东西。