Author: 印风
本年度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。先总结下参会的感受吧：
以下是这五天期间我关注的几个Topic，主要从Oracle 、MySQL官方演讲、业界使用三个方面划分。
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)，实现零宕机时间。两个方面：
第三是高性能，从三个方面阐述：
第四是标准化，支持工业标准的SQL、Hadoop、NoSQL等等，让用户能够无锁定的自由迁移到其他云服务平台。
第五是兼容性，能够自动迁移负载和数据。例如从公有云和私有云之间自由迁移。
第六是安全性，能够持续的抵御黑客攻击。最新发布的SPARC M7处理器在硬件层支持实时的安全监测；另一方面也提供数据加密。
在阐述上述观点后，随后发布了一大堆的云产品，Oracle强势宣布了其正式进入了云计算领域。
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相关的链接，感兴趣的可以点开了解下。
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，将软件功能集合到硬件中，从而最大化发挥效率。其号称世界上最快的微处理器，其基于硬件的内存安全防护，能够防止黑客非法访问内存内容
Oystein Grovlen, Senior Principal Software Engineer, Oracle
演讲者为MySQL团队优化器模块的开发人员，重点介绍了优化器的相关知识，包括优化器的执行过程， MySQL 5.7引入的cost model ，5.6版本之后引入的物化统计信息。 其中比较有意思的点是cost model，介绍了用户如何通过设置cost model来影响优化器的行为。 通过实例介绍了索引选择的类型，介绍了join和子查询是如何进行优化器选择的，以及排序和聚合操作。 该演讲的slide干货满满，对优化器感兴趣的同学非常值得一看。
Joao Gramacho, Software Developer, Oracle
详细介绍了MySQL的复制模块，以及大量的使用技巧及5.7的新特性，从浅显的知识到更深入的讨论都有涉及，适合对复制模块感兴趣的各个层次人群阅读。
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是个非常值得期待的版本。
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。
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，解决了如下几个问题：
新的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的开发人员通常不会对下一阶段的开发发表评论），包括：
在后面的讨论中，Manyi Lu也透露了“查询计划缓存”也在开发的计划中（尽管这里没有列出来）。
从优化器的进化可以看出来，MySQL的优化器模块开始变的越来越像Oracle了。希望新版本的MySQL5.7能够改变人们一向的“MySQL优化器很弱”的印象。
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格式存储）：
版本信息是通过GTID维护的，所有实例的UUID是全局统一的，并保证了所有节点产生的GTID不会重复。有两个版本信息，一个是database version，也就是本地的version（dbv），另外一个是确认模块的version（cv），下图是一个典型的冲突解决场景：
关于一个事务在Group Replication集群中的生命周期，参阅这篇博客
关于节点踢出和重新加入的逻辑，参阅这篇文章
在官方博客上还有不少文章介绍Group Replication，感兴趣的可以深入研究下。
Georgi Kodinov, Senior Software Development Manager, Oracle
主要介绍了MySQL 5.7 包含的一些安全特性。包括：
企业版特性：
账户管理：
重构及新功能：
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的开源和社区合作精神。
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一致性
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%的磁盘占用。
Jean-François Gagné, Senior System Engineer, Booking.com
来自booking的开发人员介绍了他们的binlog server工具，根据其描述，其工作原理就是一个独立的server，从master上读取binlog，存储到本地；然后将自己当做一个“假”的master，将binlog分发到各个slave节点。
在阿里，我们早几年就有了类似的工具，例如DRC， Transfer，精卫等。不过booking结合binlog server实现了其生产环境的高可用，读扩展以及时间点恢复功能。
Anthony Yeh, Software Engineer, Google
来自谷歌的工程师介绍了Youtube的开源项目Vitess。对分布式中间件不太了解。没啥感觉
Ben Osheroff, Principle Engineer, zendesk.com
zendisk的工程师分享了另外一款开源的工具，同样也是用于解析Binlog的，不同的是，把binlog的内容解析成了json的格式并复制到Kafka，算是玩出了新意。例如解析出来的数据如下图所示：
Yashada Jadhav, MySQL DBA, Yahoo Stacy Yuan, Sr. MySQL DBA, Yahoo
主要讲了Yahoo关于GTID的使用，介绍了下复制的相关知识以及如何使用Percona版本的MySQL实现online GTID开启。没啥新意，看在难得是妹子的份上听了一会就闪了。但对这块不了解的同学可以看看。
Geoffrey Anderson, Senior Database Operations Engineer, Box
Box公司的DBA阐述了他们如何使用各种工具来解决MySQL遇到的问题，以保证MySQL的正常运行。没啥新东西。