12月2日，甲骨文在官网正式上线“MySQL数据库服务与分析引擎”。作为对MySQL产品的重大增强，这个特性是相当引人注目的。我抽空做了一个简单的了解，大家可以一窥究竟。（本文部分资料和插图来自Oracle官网）1、MySQL的天然短板“数据分析”MySQL作为最流行的开源数据库，得到了广泛的应用。从最新的db-engines索引可以看出，它在数据库领域占有重要地位。但是作为一款流行的数据库产品，它在数据分析方面有着明显的短板。相信MySQL的用户都有这种感觉，MySQL在数据量大的情况下有些力不从心。虽然它的内核在不断加强这方面的能力（比如最新的8.0支持hashjoin、直方图等），但相对于其他数据库还是有一定的劣势。核心是MySQL本来就是为OLTP场景设计的，没有考虑OLAP场景。虽然一些厂商通过扩展存储引擎来增强数据分析能力，但总体上还是不尽如人意。因此，一个常见的选择是在数据分析时将数据迁移到另一个数据库/大数据架构中。通过后者，完成数据分析工作。在这个过程中，开发者需要定义自己的ETL逻辑（可能基于日志解析或者逻辑数据抽取）来完成数据迁移。同时需要注意运行过程中的数据同步，保证数据的有效性。在使用中，还需要编写单独的语句（异构数据源的语句）来完成数据分析动作。整个过程对于用户来说无疑是有一定门槛的，解决这个问题需要付出额外的努力。相信Oracle原厂也看到了这个问题，所以推出了MySQLAnalyticsEngine。2.什么是MAE？MySQLAnalyticsEngine（简称MAE），通俗的说就是一个内置的分析引擎。通过与MySQL数据库的结合，数据库管理员和应用程序开发人员可以直接将MySQL数据库用作OLTP和OLAP工作负载的统一服务。其提供的“带分析引擎的MySQL数据库服务”由一个MySQL数据库实例和多个分析节点组成。开启分析功能后，会在DB实例上安装分析服务，负责集群管理、数据加载、查询执行等，从用户角度，可以通过标准的MySQL连接使用JDBC/ODBC连接器。让我们详细看一下。首先，从整体使用的角度，对外提供统一的MySQLDatabaseService。用户仍然以传统方式使用它，无论是OLTP还是OLAP场景。在该服务内部，它包括传统的OLTP引擎和新的分析引擎。在数据方面，也有两份。前者仍然存储在InnoDB等存储引擎中，后者存储在节点集群的内存中。正常事务操作带来的数据变化会透明传播到后续的分析集群，加速分析处理。这允许客户在单个数据库平台上同时运行OLTP和OLAP工作负载。简而言之，有两个计算引擎和两个数据存储。MAE的核心工作思路是“化大为小”。通过分区机制，将数据打散，由独立的CPU资源处理。处理后的结果统一返回。MAE内部，由多个分析节点组成。具体节点数可以通过MySQL分析引擎提供的自动配置顾问自动获取。在节点中，数据以混合列压缩格式存储。这有助于矢量化以获得非常好的查询性能。数据在内存中运行之前被编码和压缩。这种压缩和优化的内存使用，特别是对于数字和字符串数据，提高了性能并减少了内存占用，从而降低了客户的成本。在每个节点中同时使用并行操作技术，这为分析提供了高缓存命中率，并提供了良好的节点间可扩展性。集群中的每个分析节点和节点中的每个核心都可以并行处理分区数据，包括并行扫描、连接、分组、聚合和top-k处理。MySQL分析引擎实现了最新的分布式内存分析处理算法。可以使用矢量化构建和探测连接内核快速处理分区内的连接。分析节点之间的网络通信通过使用异步批处理I/O进行了优化。该算法的设计使得计算时间与跨节点的数据通信重叠，这有助于实现良好的可扩展性。MySQL分析引擎与MySQL数据库服务的集成为企业的所有OLTP和分析需求提供了一个单一的数据管理平台。MySQL分析引擎设计为MySQL可插拔存储引擎，对最终用户完全屏蔽了存储层的所有底层实现细节。用户和应用程序通过集群中的MySQL数据库节点与MySQLAnalytics交互。用户通过标准工具和基于标准的ODBC/JDBC连接器连接到MySQL分析引擎。MySQL分析引擎支持与MySQL相同的ANSISQL标准和ACID属性，并支持不同的数据类型。这允许现有应用程序利用MySQL分析引擎，而无需对其应用程序进行任何更改，从而实现轻松快速的集成。一旦用户向MySQL数据库提交查询，MySQL查询优化器将透明地决定是否将查询卸载到分析集群以加快执行速度。这是基于MySQL分析引擎是否支持查询中引用的所有运算符和函数，并且使用分析引擎处理查询的估计时间比MySQL少，查询将被下推到分析节点进行处理。处理后将结果传回MySQL数据库节点，返回给用户。由于MySQL分析引擎是内存处理引擎，所以数据持久化到MySQLInnoDB存储引擎。对表的任何更新都会实时自动传播到分析节点的内存中。这使得后续查询始终可以访问最新数据。这是在后台使用轻量级更改传播算法完成的，该算法可以跟上MySQL的数据更新率。同步原理就不解释了吗？3、MAE能给我们带来什么？从产品的角度来看，MySQLAnalyticsEngine是OracleCloudInfrastructure中专门提供的云原生服务，可为分析工作负载提供极具吸引力的性能和成本。使用MySQL数据库管理企业数据的组织现在可以使用MySQL分析引擎运行分析查询，性能显着提高，成本更低，不需要ETL，并支持实时分析。该服务可以仅部署在云中，也可以部署在混合环境中，它简化了交易和分析应用程序的管理。从其推出的产品来看，可以归纳为以下几个概念：ONEDB的核心价值是场景的统一处理。以往MySQL在处理混合业务场景时，不得不采用如下方式（如下图）：通过引入MAE，增强MySQL能力，达到统一的效果。ONESQL的第二个价值点在于，它不仅统一了平台，而且使用了相同的交互方式。原有逻辑不需要任何改动。无论是前端的交易场景，还是后端的数据可视化分析，都无需改动。这对于用户来说无疑是非常有吸引力的，能够有效保护用户现有的软件资产。对于NOETL，用户不再需要关心数据同步的细节，也不需要编写额外的ETL作业。这将大大减轻用户的负担。NOTUNING在MAE之前，如果用户想解决数据分析问题，只有两种。要么在图书馆里面解决，要么在图书馆外面解决。如果在库中解决，需要对MySQL做大量的优化工作或者采用存储引擎进行分析场景，带来了优化的工作量。库外方案也是如此，需要用户自行完成优化工作。使用MAE，您无需担心这一点。它利用Oracle实验室开发的自动化机器学习(AutoML)功能来自动化服务的各个方面。由于这种自动化基于机器学习，因此系统可以智能地预测各种场景并采取行动，包括自动估计工作负载所需的分析节点数量。服务启动时，需要将运行分析查询的数据库表加载到MySQL分析集群内存中。所需集群的大小取决于加载所需的表和列，以及为此数据实现的内存压缩。在传统配置中，用户需要猜测集群的大小。由于空间限制，低估可能导致数据加载或查询执行失败。高估可能导致不必要资源的额外成本。结果，用户重复直到确定了正确的簇大小，并且当表被更新时，这个大小估计变得不准确。MAE可以自动完成上述过程。HIGHPERFORMANCEMAE是一种分布式、可扩展、内存中、混合列式查询引擎，通过内存中矢量化处理和大规模节点间和节点内并行处理实现极致性能。同时，针对Oracle云基础设施优化了查询处理，包括节点间的网络带宽优化。通过以上能力，MAE提供了强大的分析能力。以下是其主要竞争对手的性能对比。MySQLAnalyticsvsMySQLMySQLAnalyticsvsAmazonAuroraMySQLAnalyticsvsAmazonRedshift成本低使用MySQL数据库服务和分析引擎的成本取决于配置的分析节点的数量。分析集群的大小取决于数据集的大小和工作负载的性质。一个分析节点可以容纳大约400GB的数据。当客户迁移到使用AnalyticsEngine的MySQL数据库服务时，他们的成本有望显着降低。与AmazonAurora和Redshift相比，MySQLAnalyticalEngine的成本是其成本的1/3。EASYSCALEMAE目前支持集群最多24个分析节点（千Core），处理能力约为10TB的分析数据。10TB是在给定时刻可以放入分析节点内存的大约数据量。MySQL数据库中存储的数据量没有限制，客户可以选择从MySQL数据库模式中加载哪些表或列到分析节点的内存中。如果查询不再需要这些表，用户可以从内存中删除这些表以为其他数据腾出空间。EASYUSEMAE背后隐藏了很多细节，对于前端客户来说非常好用。您只需要按照推荐大小配置分析集群，配置预加速查询的对象，手动完成第一次加载即可。之后就可以享受分析集群带来的加速能力了。通过查看执行计划，可以直观的看出是否使用了分析集群（下图中UsingsecondaryengineRAPID）。另外，对于混合云场景（即无法将数据部署到云端的客户），可以使用MySQL复制将本地MySQL数据复制到MySQL分析引擎，也不需要ETL。目前MAE仅适用于OracleCloudInfrastructure(OCI)Gen2硬件平台。写在最后，MAE的出现很好的弥补了MySQL原生数据分析场景的不足。相信这一特性将进一步扩大MySQL的用途，为其更大、更重要的企业应用铺平道路。遗憾的是，目前MAE只能在OCI中使用，国内广大线下用户还无法使用。
