最近有个维护的项目需要把 SQL Server 2012 的数据库迁移到 Azure SQL 上去。主要是因为租用的主机到期，而运营商停止了主机租赁业务，看来向云端的迁移是大势所趋啊！经过一番折腾最终成功迁移，但过程可谓是一波三折。故在此分享这次迁移中碰到的点点滴滴，希望对朋友们有所帮助。 Azure SQL 的版本 Azure SQL Database 是微软提供的 SQL 服务(PaaS)。最新的版本叫 Azure SQL Database V12，其实微软还是通过 SQL Server 2014 提供的数据库服务： 上图中第一个数据库服务器是本地安装的 SQL Server 2014，第二个和第三个则是云上的 Azure SQL Database。可以很清楚的看到，它们的版本是一样的。 但是可不要以为 Azure SQL Database 提供的数据库和本地安装版本是一样的噢。它们还是有不少差别的，这一点在迁移现有数据库时尤为重要。 由于提供的是在线的服务，所以 Azure SQL Database 可以快速的发布新特性，这些从不断更新的 MSDN 文档可见一斑。MS 也强烈建议我们在和 Azure SQL Database 打交道时一定要用最新版的工具。笔者在刚开始使用了 SQL Server 2014 中的 SSMS (SQL Server Management Studio) ，结果连接 Azure SQL 后发现显示的信息和 Azure portal 对不上，安装最新版的 SSMS 后问题消失。 下面进入正题，让我们把一个8G大小的陈年老库一步步的迁移到云上。看这过程中都需要什么样的工具，如何操作以及需要注意的事项。在此特别强调，旧数据库一般都是处于正在使用的状态，所以千万不要在真实的库上做各种实验。笔者所有的前期实验都是在通过恢复备份文件创建的测试库上完成的。 迁移要点分析 在云端创建Azure SQL Server Azure SQL Database 是运行在 Azure SQL Server 中的，所以我们要在 Azure 上先把 Azure SQL Server 创建好。操作比较简单，直接在 Azure 上添加 SQL Server (logical server) 就可以了，请注意选择合适的区域(主要影响访问速度)。 允许从本地访问 Azure SQL Server Azure SQL Server 创建好以后，我们通过 SSMS 测试一下能不能连上。当我们输入了正确的地址和用户信息后却弹出了一个提示框： 它提示我们当前的 IP 不能访问 Azure上的数据库服务器，并且让我以 Azure 账号登录并创建一条防火墙规则。 其实这是 Azure 提供的一个安全措施，它让你显式的指定都哪些IP地址或者IP网段可以访问 Azure SQL Server。此时我们有两种做法。 点击对话框中的 "Sign in"，用Azure账户登录。然后点击 "OK"，此时已经完成了防火墙规则的设置，SSMS 已登录 Azure SQL Server。这种方法一般用于开发和测试，只能添加当前客户端所使用的 IP。 更加通用的方法是登录 Azure portal，进入 Azure SQL Server 的配置界面，为防火墙添加规则。同样的，可以添加单个 IP 也可以一次添加一个网段：             兼容性处理 由于 MS SQL Server 版本众多，且云上的版本与本地版本也有差异。所以能不能迁移成功主要看能不能找到并解决数据库之间的兼容性问题。下面将详细的介绍笔者碰到的兼容性问题。 兼容性处理详情 数据库中设置的用户不存在 兼容性检查的报告显示下面的信息： Error SQL71564: Error validating element [xxxx]: The element [xxxx] has been orphaned from its login and cannot be deployed. 其中的 xxxx 是数据库中设置的用户名。这个错误的原因是用户被定义在本地的 SQL Server 中，数据库中只有使用用户的信息，把数据库迁移到云上后，就找不到对应用户的定义了。所以需要移除本地用户的信息。不用担心数据库的访问问题，因为完成迁移后你可以使用刚才创建的 Azure SQL Server 账号访问数据库。当然你还可以为一个数据库创建独立的访问账号，具体操作请参考 MSDN。 不支持Extended Property 兼容性检查的报告显示下面的信息： One or more unsupported elements were found in the schema used as part of a data package. Error SQL71564: The element Extended Property: [dbo].[xxxx].[MS_Description] is not supported when used as part of a data package (.bacpac file). 其中的 xxxx 是数据库中一张表的名称。这下可要了命了，不支持 Extended Property！在笔者的数据库中有好几处都用到了这个特性。怎么办？只好一遍又一遍的查看程序。最后发现程序中没有使用这个特性，好像当时只是有人用它做了一些说明。最终的结论是可以移除。 创建 clustered index 兼容性检查的报告显示下面的信息： One or more unsupported elements were found in the schema used as part of a data package. Error SQL71564: Table Table: [dbo].[xxxx] does not have a clustered index. Clustered indexes are required for inserting data in this version of SQL Server. 其中的 xxxx 是数据库中一张表的名称。需要给表创建 clustered index，看似不是一件小事情。因为任何对表的修改都可能会影响到程序逻辑，怎么办呢？网上的朋友们早就有了比较靠谱的解决方案，就是给表添加一列用来做 clustered index，这样原来表中的列就没有发生变化： ALTER TABLE [xxxx] ADD RowId int NOT NULL IDENTITY (1, 1) PRIMARY KEY CLUSTERED GO 其他 还有一些点，主要是和业务相关的，就不在此赘述。个人感觉绝大多数的问题在网上都有不同的解决方案，关键是要采用自己的业务能够接受的方式去解决问题。接下来把所有对数据库的变更写成一个脚本文件。在正式的迁移中，直接在正式库上执行脚本文件。 迁移过程 MS 提供了不同的工具进行兼容性检查、迁移等工作。我们这里统统使用 SSMS (SQL Server Management Studio) 。下面看看具体的操作步骤。在 SSMS 中右键需要迁移的数据库，选择 Tasks 中的"Deploy Database to Microsoft Azure SQL Database…"。 在打开的向导中点击 "next" 进入"Deployment Settings"界面。首先需要设置 Azure SQL Server 的连接地址和连接账号： 接下来设置迁移后的数据库名称和资源配置： 注意 Azure SQL Database settings，MS 把数据库使用的资源划分成了三个不同的类别：Basic, Standard, Premium。每个类别中又划分了不同的收费标准，简单说就是你要使用更多更好的资源就要掏更多的钱。当然也可以反过来说，如果我用的资源不多花一点点钱就够了！我们发现上图中的最后一行要求我们为 *.bacpac 文件指定一个存储路径。*.bacpac 文件是迁移过程中生成的中间文件，当兼容性检查通过后，就把数据库中的所有内容都导出到这个文件中。从这个信息我们可以得知，无论采用何种迁移方式，其核心操作都是两步：先从本地数据库生成 *.bacpac 文件，再从*.bacpac 文件恢复一个Azure SQL Database。单击 "Next" 显示配置的详情，再下一步就开始兼容性检查。如果没有兼容性问题，就执行迁移操作。我的数据库存在一些兼容性问题，所以显示了错误报告并终止了迁移操作： 点击 "Result" 列中的链接就能看到详细的报告，前面已经介绍过兼容性问题，直接执行我们处理兼容性问题的脚本文件，然后再试一次！ 这次的执行已经没有错误提示了，其实后台已经开始了迁移过程。比较不爽的是这个过程没有详细的进度提示，只能黑等。我的经验数据是8G的库完成迁移大概是 8-12小时。当然这和你连接 Azure 的带宽有很大的关系… 总结 由于整个迁移过程涉及的方方面面实在太多，本文只是概要式的介绍笔者认为迁移过程中的要点和自己碰到的问题。总的感觉是 MS 提供的工具还算比较完善，网络上的各种已知问题解决方案也很详尽。所以尽管笔者碰到了很多的问题，但没有卡壳的地方，总算磕磕绊绊的完成了数据库迁移的任务。 本文转自sparkdev博客园博客，原文链接：http://www.cnblogs.com/sparkdev/p/6783574.html，如需转载请自行联系原作者

本科学生要做学习项目，使用的是sql server 数据库，iis应用服务器。要外网能访问的域或域名，希望能坚持至少一年。经费不多，希望尽量便宜。数据量不大，所以大小不必太大。然而对此完全一窍不通，老师要求报预算，租用多少价位的空间比较合适？

AG扩展事件 SQL Server 2012定义了一些关于AlwaysOn的扩展事件。你可以监控这些扩展事件来帮助诊断AG的根本问题。你也可以使用以下语句查看扩展事件： SELECT * FROM sys.dm_xe_objects WHERE name LIKE '%hadr%' 1.AlwaysOn健康(AlwaysOn_health)会话 AlwaysOn_health扩展会话当你在创建AG并捕获AlwaysOn相关事件的子集。这个会话被配置为有用的，方便的工具来帮助你开启调试AG。创建AG窗口在每个特定可用性副本配置窗口中自动启动会话。 如果你没有使用新建AG对话框，AlwaysOn_health会话可能不会自动启动，如果会话没有启动，不能再问题发生的时候捕获每个数据。你应该手动启动会话并且配置会话来自动会话。 通过查看AlwaysOn_health会话的定义： 1.SSMS，展开扩展事件，会话 2.右击AlwaysOn_health,然后创建脚本 更多关于ALwaysOn_health的信息查看：AlwaysOn Extended Events Reference. 2.调试扩展事务 如果要有额外的事件覆盖AlwaysOn_health会话，SQL Server定义了一大集合的调试事件。需要作一下步骤： 1.在SSMS，展开扩展事件，会话 2.右击创建时间，或者右击AlwaysOn_health，选择属性 3.选择事件页面 4.在library，目录列，选择alwayson并且清除所有目录 5.在Channel列，选择调试，所有相关事件，没有被选择的都会显示在event library 6.event library选中一个，然后点击”>”按钮 7.当完成会话，点击OK关闭。保证会话已经启动了。 3.AlwaysOn扩展事件引用 AlwaysOn扩展事件被用来跟踪AG 3.1 availability_replica_state_change 当AG的状态发生变化。AG的创建或者加入一个可用副本。可以用来诊断错误自动故障转移。可以用来跟踪转移步骤。 3.2 availability_gruop_lease_expired 当集群和可用组出现连接问题和租用过期。这个事件说明AG和WSFC集群连接断开。如果连接问题发生在primary副本。事件可能会自动转移或者导致AG offline。 3.3 availability_replica_automatic_failover_validation 当自动故障转移验证AG作为primary副本的必要性，显示是否目标可用副本已经做好了成为新primary副本的准备。比如，当并不是所有数据库都是被同步的，或者不是已被加入的，故障转移验证返回错误。这个事件被设计用来提供在故障转移的时候提供错误点。可以根据这个信息检查为什么自动故障转移发生。 3.4 error_reported:对于传输或链接问题 每个过滤事件说明一个连接问题发生，数据库镜像endpoint发生错误 3.5 data_movement_suspend_resume 当数据库副本movement挂起或者恢复的时候触发事件。 3.6 alwayson_ddl_executed 当发生AlwasOn DDL语句，包括Create，Alter,Drop语句。事件的主要目的说明AG中用户的行为，或者说明用户操作行为的开始点。事件可以跟踪手动故障转移，强制故障转移，中断和恢复数据移动。 3.7 alwayson_replica_manager_stat 当可用性副本管理状态修改触发。这个事件说明可用性副本管理的心跳。当可用性副本管理没有心跳状态，SQL Server实例中的所有可用性副本都会下线。 3.8 error_reported，数据库副本角色修改 这个过滤的，AG角色变化的时候，error_reported事件被异步触发。这个说明哪个可用性数据库在修改故障转移时修改角色失败。    

AG扩展事件 SQL Server 2012定义了一些关于AlwaysOn的扩展事件。你可以监控这些扩展事件来帮助诊断AG的根本问题。你也可以使用以下语句查看扩展事件： SELECT * FROM sys.dm_xe_objects WHERE name LIKE '%hadr%' 1.AlwaysOn健康(AlwaysOn_health)会话 AlwaysOn_health扩展会话当你在创建AG并捕获AlwaysOn相关事件的子集。这个会话被配置为有用的，方便的工具来帮助你开启调试AG。创建AG窗口在每个特定可用性副本配置窗口中自动启动会话。 如果你没有使用新建AG对话框，AlwaysOn_health会话可能不会自动启动，如果会话没有启动，不能再问题发生的时候捕获每个数据。你应该手动启动会话并且配置会话来自动会话。 通过查看AlwaysOn_health会话的定义： 1.SSMS，展开扩展事件，会话 2.右击AlwaysOn_health,然后创建脚本 更多关于ALwaysOn_health的信息查看：AlwaysOn Extended Events Reference. 2.调试扩展事务 如果要有额外的事件覆盖AlwaysOn_health会话，SQL Server定义了一大集合的调试事件。需要作一下步骤： 1.在SSMS，展开扩展事件，会话 2.右击创建时间，或者右击AlwaysOn_health，选择属性 3.选择事件页面 4.在library，目录列，选择alwayson并且清除所有目录 5.在Channel列，选择调试，所有相关事件，没有被选择的都会显示在event library 6.event library选中一个，然后点击”>”按钮 7.当完成会话，点击OK关闭。保证会话已经启动了。 3.AlwaysOn扩展事件引用 AlwaysOn扩展事件被用来跟踪AG 3.1 availability_replica_state_change 当AG的状态发生变化。AG的创建或者加入一个可用副本。可以用来诊断错误自动故障转移。可以用来跟踪转移步骤。 3.2 availability_gruop_lease_expired 当集群和可用组出现连接问题和租用过期。这个事件说明AG和WSFC集群连接断开。如果连接问题发生在primary副本。事件可能会自动转移或者导致AG offline。 3.3 availability_replica_automatic_failover_validation 当自动故障转移验证AG作为primary副本的必要性，显示是否目标可用副本已经做好了成为新primary副本的准备。比如，当并不是所有数据库都是被同步的，或者不是已被加入的，故障转移验证返回错误。这个事件被设计用来提供在故障转移的时候提供错误点。可以根据这个信息检查为什么自动故障转移发生。 3.4 error_reported:对于传输或链接问题 每个过滤事件说明一个连接问题发生，数据库镜像endpoint发生错误 3.5 data_movement_suspend_resume 当数据库副本movement挂起或者恢复的时候触发事件。 3.6 alwayson_ddl_executed 当发生AlwasOn DDL语句，包括Create，Alter,Drop语句。事件的主要目的说明AG中用户的行为，或者说明用户操作行为的开始点。事件可以跟踪手动故障转移，强制故障转移，中断和恢复数据移动。 3.7 alwayson_replica_manager_stat 当可用性副本管理状态修改触发。这个事件说明可用性副本管理的心跳。当可用性副本管理没有心跳状态，SQL Server实例中的所有可用性副本都会下线。 3.8 error_reported，数据库副本角色修改 这个过滤的，AG角色变化的时候，error_reported事件被异步触发。这个说明哪个可用性数据库在修改故障转移时修改角色失败。       本文转自 Fanr_Zh 博客园博客，原文链接：http://www.cnblogs.com/Amaranthus/p/4986409.html，如需转载请自行联系原作者

本节书摘来自华章社区《DBA修炼之道：数据库管理员的第一本书》一书中的第1章，第1.12节新技术对DBA的影响，作者（美）Craig S. Mullins，更多章节内容可以访问云栖社区“华章社区”公众号查看 1.12　新技术对DBA的影响每当企业引进做生意的新方法和新技术时，DBA都要行动起来。数据是任何应用程序的心脏，随着大多数的新技术为程序开发人员所采用，它们也对数据产生了影响。实际上，数据是现代商业的生命线，数据库容纳数据，而DBA是数据库技术尤其数据库集成技术方面的专家。接下来研究三种具体的新技术，它们在某种程度上都依赖数据库管理的有效部署：数据库耦合的应用程序逻辑、互联网电子商务开发和手持计算。 1.12.1　过程DBA：管理数据库逻辑传统的数据库管理系统作用的域中规中矩，包括存储、管理和访问数据。尽管这些核心功能依然适用于现代DBMS产品，一些额外的程序功能正慢慢成为很好的必需功能。如触发器、用户定义的函数和存储过程，都能够为DBMS而非单独的应用程序定义业务规则。这些功能使得应用程序逻辑与数据库服务器紧密耦合。由于所有最流行的RDBMS产品都提供了复杂的功能来促进数据库耦合程序逻辑，所以就需要额外的工作来管理并使用这些功能。这需要对数据库管理的管理准则进行扩展。通常情况下，当有新功能添加时，管理、设计以及对这些新功能的管理统统都是DBA的任务。如果没有适当的规划和准备，可能就会导致混乱。首先研究DBMS中数据库逻辑是如何存储的。存储过程可以认为存储过程是在数据库中的程序。存储过程的程序逻辑是通过一些数据库命令进行维护、管理和执行的。使用存储过程主要是为了将应用程序代码从客户端转移到数据库服务器。存储过程通常在客户端/服务器环境中消耗较少，因为一个客户端调用存储过程就会运行多个SQL语句。而直接运行多个SQL语句的替代方案的效率相对较低，因为其增加了网络流量却降低了应用程序的性能。存储过程是独立的数据库对象，它本质上不与数据库中的其他任何对象相关。一个存储过程可以访问和/或修改多个表的数据。触发器触发器是一种关联到数据库表的事件驱动的特殊程序。数据库的数据改变时，触发器代码会自动在RDBMS中运行。每个触发器都关联到一张单个的、指定的表。触发器可以看作一种高级形式的规则或使用程序逻辑编写的约束。触发器不能直接调用或执行，一旦对它所关联的表进行插入、更新或删除操作，它将在RDBMS中自动运行。触发器一旦创建，就始终在它的“导火索”事件出现时运行了。用户自定义函数用户自定义函数（UDF）提供了一个基于一系列输入值的结果。UDF是一种可以代替标准的、内置SQL标量或列函数执行的程序。标量函数将结果集的每一行数据进行变换；列函数计算结果集中每一行的特定列的值，并返回一个单个的值。一旦写入且在RDBMS中定义，UDF就变得像任何其他内置的数据库函数一样。表1-2概述了存储过程、触发器和用户自定义函数之间的差异。 存储过程、触发器和UDF一旦为应用程序和开发人员所用，就要采取措施确保它们得到恰当的管理。DBA必须要解决质量问题、可维护性问题、效率问题和可用性问题。如何以及何时测试这些程序对象？测试一旦失败将影响整个企业，而不是单一的应用程序。这无形中增加了这些对象的可见性和关键性。一旦失败谁将为之负责？答案无疑就是：DBA。管理程序数据库逻辑的重担应落在熟知该准则的人身上。此时，需要一种新型的DBA来管理数据库程序逻辑。这种新的角色可以称作过程DBA。过程DBA应为那些需要程序逻辑支持的数据库管理任务负责。他们的主要职责就是确保存储过程、触发器和用户自定义函数能有效地规划、部署、共享和重用。他们也负责对所有触发器、存储过程和用户自定义函数进行编码与测试，当然，编码主要是由应用程序开发人员负责的，而过程DBA负责其准确度和性能。过程DBA应参与并主导对所有程序数据库对象（触发器、存储过程和UDF）的审查和管理。尽管过程DBA不可能像应用程序开发人员或系统分析师那样精通编程，他们也要能适当地编写并审查程序代码。要求的技能水平依赖DBMS使用何种语言创建程序对象，该语言在企业内部接受的程度如何，以及是否存在内部组织专门创建通用且可重用的程序。表1-3给出了一个过程DBA参与每种程序对象的合理比重。此外，过程DBA要能在生产环境的数据库程序对象出现问题时随传随到。表1-3　过程DBA对每种对象的参与度 过程DBA应参与并主导对所有程序数据库对象（触发器、存储过程和UDF）的审查和管理。对于过程DBA来说，沟通技巧与技术敏锐性同样重要（详见图1-10）。除了管理并优化数据库程序对象，过程DBA还必须告知开发人员存在新的触发器、存储过程和UDF，此外，他们还要提升这些对象的重用性。如果这些对象不为程序员所知，它们将永远不被使用。过程DBA也可能会有其他的程序管理职责，根据DBA的数量以及正在开发的应用程序的数量，他们可能被分配额外的工作，比如：参与应用程序代码设计审查；审查并分析SQL访问路径（根据EXPLAIN或SHOWPLAN）；调试SQL；编写并分析复杂的SQL语句；重写最佳查询。将编码相关的工作交由过程DBA分担有助于其他DBA专注于实际的物理数据库设计和部署，从而才会有更好的数据库。但过程DBA要与传统DBA向同一个管理单元报告，如此可以更好地在过程DBA和传统的关注数据的DBA之间共享技能，当然，这需要两者之间更多的协作。过程DBA的一种典型职业路径就是他们本身来自开发团队，因为那里才是编码技能的根基。 1.12.2　互联网：从DBA到eDBA尽管现在互联网已不能看作一种趋势，企业和技术人员仍需调整他们的进程来适应电子商务的发展。各种类型和规模的企业都在使用互联网技术来加快业务进程，并且数据库管理的实践和流程也因互联网应用程序和数据库的采用而受到影响。电子商务必须能够适应不断变化并为之作出反应。在线的生意永不打烊。人们期望访问的网站一直可用，无论什么时间在什么地方。纽约可能是凌晨两点，但在世界的某些地方却是黄金时间。电子商务需要一直营业且一天24小时一年365天（闰年366天）和顾客打交道，否则就会造成损失。一个网站出了问题，顾客就会转战它处，因为所谓竞争就是简单地点一下鼠标。所以，管理电子商务的人一定要是内行、前瞻且时刻保持警惕。接受电子商务的疯狂节奏需要经营者为之作出改变，DBA就极受电子商务的影响。将网络与传统的IT服务（如DBMS）相结合，对数据库管理员提出了更高的期望。DBA能够管理基于网络的应用程序，且因懂得互联网引发的特殊问题而称作eDBA。eDBA同样需要传统DBA具备的所有知识和进行的所有培训。但需要将这些技能进行调整以适应互联网驱动下的应用程序和数据库。网络加上传统的应用程序和数据库，产生了一种复杂的基础设施（详见图1-11）。eDBA要能驾驭这种复杂且异形的基础设施，并能够在数据库受到此基础设施影响时提供专业的建议。 DBA能够管理基于网络的应用程序，且因懂得互联网引发的特殊问题而称作eDBA。实际上，当互联网与数据库技术结合时，会有多种因素影响数据库的管理，一些问题包括：24/7全天候数据可用性。新技术的采用，如Java和XML。连接到网络。遗留数据与现代基于网络的应用程序的集成。数据库与应用程序架构。基于网络的管理。互联网的性能工程学。不可预知的工作荷载。 1.12.3　个人DBA与云计算个人设备，通常不仅指手机还包括掌上电脑，正在快速成为现代化管理者与商人的必需品。手机是一种手持式计算设备，有时也会有数据库管理系统。它为什么这么吸引眼球呢？它是否改变了你使用手机的方式呢？它又对IT部门意味着什么呢？流行的移动计算平台包括：Symbian操作系统、Windows Mobile、iPhone操作系统和Android。手机提供了许多便利。它体积小巧便于携带，不会干扰移动工作者的工作，而且目前几乎每个人都随身携带手机，提升它的计算能力是势在必行的。或许这些设备最大的好处是它们可以运行移动应用程序。不管何时何地，企业移动应用程序将从主机服务器获取的信息转发给遍布的移动设备，这种情况并不少见。移动应用程序使用云作为后端越来越流行。企业移动应用程序依赖从主机服务器获取的信息。什么是云计算云计算为用户IT资源交付提供了一种新的模式。云计算的主要定义特点造成了对无限的计算资源按需访问的错觉。一个很好的云计算服务的例子来自Salesforce.com，它提供了通过网络对CRM应用程序的访问。云计算服务的另一个普遍的现象是用户可以租用计算能力且不必承诺。你可以租用一台服务器而不需要购买，然后支付用到的计算能力的费用。这曾经称作效用计算，它模仿了人们如何支付公共设施，如水或电。因此这是一种“随需随用”的服务。从数据库的角度来看，有一些云服务，包括Amazon的SimpleDB，Google APP Engine数据存储。此外，Microsoft SQL Azure也支持云数据。云计算可以让即使是最小的企业甚至个人获得计算资源，这在以前是不可能的。 移动应用程序的设计与部署不像桌面个人计算机应用程序开发那样简单。对于移动应用程序的开发人员来说，考虑该应用程序将用于什么环境是很重要的。虽然带来的好处是显著的，但企业将个人设备融入基础设施也会面临挑战。设备上的数据必须得到专业的管理以确保其完整性和可靠性。由于该设备是远程的，数据共享可能比较困难。手机上的业务数据必须通过可靠的方式与现有的企业系统和数据库保持同步。从业务和合规性的角度来看，很难评估移动应用程序带来的风险。移动设备很容易保存不当且没有适当的安全措施可能会导致数据泄漏。所有的DBMS供应商都提供了各自旗舰产品的轻量级版本在个人设备上运行。例如，IBM投放市场的DB2个人版、Oracle销售的移动数据库、Microsoft提供的SQL Server精简版，以及Sybase提供的Adaptive Server Anywhere数据库。总体思路是将移动设备中的少量关键数据存储在数据库中。接下来，使本地数据库与企业数据库服务器上的长期数据同步。每种移动DBMS都提供了移动设备与企业服务器平台之间来回同步数据的技术。对DBA的影响DBA不需要对每个PDA的数据库进行管理，但DBA的工作会受到数据库开发的影响。不需要对那些存储在PDA上的数据库的大小进行深入调整和管理，企业数据库部署时才要求。然而，会要求DBA帮助设计适用于小型设备如PDA的数据库。当然，这不是最大的影响。对DBA的一个很大的影响来自规划如何管理数以百计或数以千计的PDA的数据同步。什么时候开始同步？将对使用大型生产数据库的应用程序造成什么影响？如何确保移动用户的数据可靠且按时同步？此外，对于云计算的部署，DBA可能要负责保证可靠数据的可用性。设计并调整云计算的数据库部署可以将重要的资源用于管理大量的数据并保证其全天候的可用性。这些都不是小问题。开始部署大批的移动数据库前，用户必须同步他们的数据以确保DBA人员已经为可能产生的影响做好了准备。与大多数其他的事情一样，准备不足也许会面临灾难，但是必须要准备。通过了解数据同步技术、云计算和企业内部远程数据库用户的潜在需要，DBA人员必须做好准备来支持移动工作人员。在为手持设备支持数据库做准备的过程中，还需要审查企业的应用程序并尝试确定哪些可能最先受到影响。那些有远程工作者的公司，如分布式的销售队伍或交付跟踪服务将最有可能首先受到影响。花些时间审查这些应用程序的数据需求，以及大量涌入的远程连接对现有的系统可能会造成的影响。普遍计算技术和移动工作者已是事实，DBA人员必须做好准备以一种有效的、共享数据的基础设施来支持这些移动工作者。 1.12.4　NoSQL、大数据和DBANoSQL是可以影响DBA工作的另一种趋势。正如其字面意思，NoSQL是一种最基本的动作。也就是说NoSQL DBMS不支持SQL。上升一个层面来说，NoSQL意味着非关系型的、分布式的、灵活的和可扩展的。大多数NoSQL产品还是开源的。NoSQL产生于对现代数据库系统支持网络这一举措的权衡需求。此外，NoSQL DBMS的一些常见属性包括：缺乏一种模式、使用简单、支持复制和“最终一致性”的能力（不是典型的ACID交易能力——原子性、一致性、独立性和耐久性）。它并不意味着没有SQL支持，实际上一些NoSQL产品已经开始支持SQL了，于是一些学者将NoSQL定义为“不只是SQL”。NoSQL产品的一些例子Cassandra: http://cassandra.apache.org/CouchDB: http://couchdb.apache.org/HBase: http://hbase.apache.org/mongoDB: www.mongodb.org/Riak: www.basho.com/ NoSQL运动是和大数据运动联系在一起的。NoSQL数据库是为了提供低成本的存储和对大量数据的访问。部署了NoSQL，通常情况下就只能以一种方式访问数据，几乎没有即兴地、临时查询的灵活性。对DBA的影响NoSQL的另一特点是它几乎不需要数据库管理。当然，必须建立DBMS并进行管理，数据也要备份。所以当有人告诉你任何数据库系统不需要数据库管理时，不要相信就是了。 1.12.5　新技术对DBA的影响企业引入新技术，通常DBA团队会率先研究使用。上述所列技术仅作为例子说明近期的一种发展趋势，以及管理并部署高效、有效数据库需要的技术。大多数新技术都会对DBA产生影响，或多或少。

Erbix 为构建和部署 JavaScript 应用程序的云端平台。除了支持 RinjoJS，CommonJS 模块，PostgreSQL 外，还支持具可伸缩性的按需调配主机。 Erbix is a platform for building and deploying JavaScript applications on the Cloud. It features support for RinjoJS,CommonJS modules, PostgreSQL and on-demand scalable hosting. Erbix 近来也启动了针对JavaScript 程序的市场，提供若干教程，和两个完全用 JavaScript 写好的开源程序，以供借鉴。 Also it has recently launched a marketplace for JavaScript Apps, featuring some tutorials and two new open-source applications written completely in JavaScript. InfoQ 就和来自 Erbix 团队的 Mihai Roman 进行了一次小型的交流，感谢他们的拨冗。 InfoQ had a small Q&A with Mihai Roman from the Erbix Team, regarding their offering:   InfoQ：能否介绍一下 Erbix 的构思是如何的，怎么演变为一种架构，以及其程序的结构大致如何？ InfoQ: Could you give us an architectural overview of how Erbix is setup and how an application is structured? 用户在Erbix创建、安装或租用服务端的JavaScript程序，首先要有一个Web账户。用户可以申请一个或使用OpenID来开始亦可。 各个账户之间是孤立开来的，不能直接共享资源。每个账户拥有以下的资源： Erbix offers web accounts that can be used for creating, installing or hosting server-side JavaScript apps. Users can sign up or simply log in with OpenID to get started. All accounts are isolated from each other and cannot share resources directly. Each account has the following resources: 一个虚拟化的文件系统（用于存放 JavaScript 代码、图片的这些静态资源）a virtual file system (used for storing the JavaScript code and static resources such as images) 专门的 PostgreSQL 数据库（存储程序数据）a dedicated PostgreSQL database (for storing apps data) 站点列表，每个站点描述 URL 前缀路径是如何映射到条目点函数的（我们采用 CommonJS JSGI 0.3 标准作为条目点）a list of sites, each describing how URL prefix paths are mapped to JS entry point functions (we use the CommonJS JSGI 0.3 standard as entry-points). 每次请求就有一个特定的 URL，对应加载一个映射好的模块，从而就会调用 JSGI 条目点的函数。根据 CommonJS 1.0的模块规范，还可以加载别的 JavaScript 模块。 Every time a request is made for a specific URL, a mapped module is loaded and the JSGI entry point function is called. Other JavaScript modules can be loaded according to CommonJS Module 1.0 specs. 这些模块文件打包到应用程序目录下。加入到该目录下的文件就可视作为符合 CommonJS 包规范1.0的文件（application.json），打包后就可以将程序发布到 Erbix Marketplace，与大家分享成果。 Several module files can be packed into an application folder. By adding in that folder a CommonJS Packages 1.0 specs file (application.json) it can then be published to the Erbix Marketplace and shared with others. 可以通过两种方式安装 Marketplace 的程序（发布者可选择其中的一种或两种都选）： Apps from the Marketplace can be installed in two ways (the publisher has the option to choose one or both possibilities): 负责文件到帐号 copy files into account 直接从 Marketplace 运行程序run app directly from the Marketplace 对于没有 JavaScript 编码经验的用户，也可以快速地安装 Marketplace 的程序。程序产生的所有数据都保存在 PostgreSQL 数据库。Users with no (JavaScript) coding experience can install and run apps from the Marketplace in seconds. All the data produced by those apps resides in the account's PostgreSQL database.   InfoQ:若与其他常见的 JavaScript 平台去比较，如 Node.js，Akshell，你会提供哪些方面的材料支撑？How does youroffering compare to the other JavaScript platforms out there, likeNode.js, Akshell, etc. Erbix 经过认真地考虑，才选择基于 Ringo 的 JavaScript 引擎，简单说，RingoJS乃是不错的 Mozilla RhinoJavaScript 编译器包装器。NodeJS 是 RingoJS 替选。RingoJSErbix is based on the RingoJavaScript engine, which was chosen after careful consideration; simplyput, RingoJS is a brilliant wrapper around Mozilla Rhino JavaScriptinterpreter. Node.JS is a RingoJS alternative. 技术上，Erbix 是兼容于 CommonJS 服务端 JavaScript 主机平台。我们没有限定厂商，而且从 Erbix 移植程序时候都是希望花最小的力气。用户能够导出它们的程序运行在私自的 RingoJS 主机或其他的服务端的 JavaScript 平台。。 Technically, Erbix is a CommonJS compliant server-side JavaScript hosting platform. There's no vendor lock-in and minimal to none effort is necessary to port apps to and from Erbix. Users will be able to export their apps on privately hosted RingoJS or other server-side JavaScript platforms. 不同于 Akshell 或 AppJet（现在由 JGate 寄存），Erbix 提供创建真正成熟 Web 程序的工具。专设有 PostgreSQL 数据库可访问，表示可以通过 SQL console 或代码的方式达到 SQL 全面的支持，不得不说，这是 Erbix 才有的功能。 Unlike Akshell or AppJet (currently hosted by JGate), Erbix provides the tools to create fully fledged web applications. The dedicated PostgreSQL database is accessible by the means of an SQL console or programaticaly with full SQL support; a feature found only in Erbix. InfoQ: Erbix 中，开发、调试、测试、部署和监控一个程序其典型的流程大概如何呢？What is the typical workflow for developing, debugging, testing, deploying and monitoring an app in Erbix? 可以通过在线编辑器或上传轻松创建文件和文件夹。文件夹可以以 .zip 或者 .tat.gz 的形式上传或下载。未来加入源码的版本控制功能。所以用户既可以在 Erbix.com 的在线环境中创建程序，也可以在离线的状态下，利用 IDE 完成。 Files and folders can be created using the online editor or can be uploaded easily. Folders can be uploaded/downloaded from/to a .zip or .tar.gz archive. Future source versioning support may be added. So users can choose to create the apps online on Erbix.com or offline in their IDE of choice. 通过映射URL前缀到JSGI条目点函数，应用程序可以立刻进行部署。 Apps are deployed instantly by mapping an URL prefix to the JSGI entry point function. 要调试或监控的话，单元测试和 logging 模块准备可用。我们在改善这些功能和模块。 Unit testing and logging modules are available for debugging and monitoring purposes. We are currently working on improving these features/modules. InfoQ: Erbix 适合拿来做什么呢，您看到了哪种用户案例？What are the common use cases you see Erbix being more suitable for? 对于小型企业创建或安装程序，Erbix 十分适合；对于开发者和消费者，Erbix 也很友好：我们为开发者提供极具生产力的工具（Marketplace、JS寄存主机、浏览器编辑器）来创建您的程序。于消费者而言，他们可以轻松地从 Marketplace 挑选并安装应用程序，从而保持控制属于他们的 PostgreSQL 账号中数据内容。 结合当前的服务端JavaScript生态而言，我们觉得Erbix将是测试、推广、分享服务端JavaScript程序的优秀不二的解决方案。 Erbix is a great environment to create or install apps for small businesses. Erbix is both developer and consumer friendly: we offer to developers excellent productivity tools (marketplace, JS hosting, browser editor) for creating great apps; the customers can easily install the apps from the marketplace and keep control of their data in their own PostgreSQL account. Given the current status for the server-side JavaScript, we consider Erbix to be the best solution for testing, promoting and sharing server-side JavaScript apps. InfoQ: 当前服务到了什么的状态，以及将来来说，会告诉我们什么的线路图？What is the current status of the service and what is your roadmap for the future? 我们现在公测 beta 之中。每一位有 OepnID 的用户可以享有我们的服务。好比运行着的 www.erbix.com 则是一个 Erbix 程序，还有两个通过在线编辑器构建的示范程序，而且我们打算下 次 major 发布的时候，就可摆脱 beta。 We are currently in open beta testing. Everyone can log in with OpenID and start using the service.  We are running www.erbix.com as an Erbix app, we've built two apps by only using the online editor and we expect to get out of beta in the next major release. 我们正在改进平台的以下几个方面：We are working on improving many aspects of the platform: 文档。documentation 可用性（为非技术用户感觉更直观）。usability (make it more intuitive for non technical users) 自定义域名的 UI 支持。UI support for custom domain names 更好的动态资源调配（针对高峰期）。better dynamic resource scaling (handle traffic peaks) 监视/统计。monitoring/statistics 同时，我们团队还有人负责开发现成可用的程序，发布到 Marketplace，让人人去用或者客制化。Meanwhile, part of ourteam will develop production-ready apps that will be published on theMarketplace for everyone to use and customize. Erbix 是一系列 JavaScript 云端平台中的一员，过去几个月不断出现这些平台，包括 Akshell，曾经由 InfoQ 报导过。 The Erbix offering is one of a series of JavaScript Cloud hosting platforms that have emerged in the last months, such asAkshell, which has been covered by InfoQ. 你在 InfoQ 这儿，找到有关 JavaScript,Node.js 和 CommonJS 更多的信息。 You can find more information regarding JavaScript,Node.js andCommonJS, right here on InfoQ!

浙江大学网络信息系统有限公司是国内最大的教育软件专业开发商、教育电子商务提供商之一，占据国内校校通、城域网软件平台50%以上市场份额。2004年8月，浙江大学网络信息系统有限公司率先顺利通过教育部《教育管理信息化标准》教育管理软件评测。        在拜访浙江大学网络信息系统有限公司（以下简称“浙大网络”）之前，笔者一直心有疑惑，这样一家以开发教育、教管软件著称的专业软件开发商，为何提议将网站生成系统作为采访的重点？那么多虚拟主机运营商都在提供形形色色的智能建站服务，市面上也不乏功能全面，适用广泛的建站系统，甚至还有不少免费、开源的软件可以选用，难道为学校搭建一个网站还有自出机枢的必要？ SQL Server支持ASP应用，网站生成系统结硕果        待见到浙大网络研发中心的姚辉明主任，他仅凭三言两语就打消了笔者心中的疑惑。他介绍说，做好网站建设对于教育信息化不仅十分重要，而且非常必要——学校网站可以最直接地展示校园风貌，构建学生、家长、教师交流的平台，也有利于实现教育系统内的统一管理。因此，虽然以中小学校为代表的教育单位在综合资源投入上往往不甚宽裕，但对网站界面的美观程度，资料更新时的便利性，以及自主修改的权限都有比较高的要求。而开源的CMS以及大多数商业建站系统在这些需求的设计上都有明显欠缺，并且无法支持多单位共同使用。 浙大网络网站生成系统是一套支持多单位共同使用的应用软件服务模式（Application Service Provider，简称“ASP应用模式”）的网站自动生成软件系统，完全基于.net环境开发，采用SQL Server数据库。它由主站管理单位提供高性能服务器并建设主站，下级用户登录到主站进行网站注册申请后，由主站管理员审核开通子站。子站成功创建后，子站管理员可登录本单位网站，创建和管理本单位主页，并实现本单位信息的发布、统计等一系列功能。由于采用ASP应用模式，子站用户在网站建设中不再需要负担购买、运维服务器的成本，只需专注于网站界面的设计、信息内容的维护等工作。主站管理单位也可通过本系统对所有下级子网站进行统一管理。 网站生成系统的主创人员，浙大网络研发五部的技术经理冯跃兵进一步向笔者介绍了这一产品的具体功能特点： l         支持在线备份功能，可以及时恢复被修改的过程。 l         支持多等级用户管理和内外网控制功能，可以通过统一的登录界面区分家长、学生，老师等不同身份的用户，并且可以根据IP进行内外网管理。 l         提供了专门的功能模块对上传的文件进行统一管理，并且引入生命周期的概念，避免失效文件持续占用空间。 l         灵活的开放性，可以提供统一的登录平台，和其他教学管理系统自由对接，在框架内集成其他管理系统的数据。 …… 据介绍，之所以采用SQL Server数据库，是因为采取ASP运营模式后一台主机需要同时运行成百上千个数据表。此时SQL Server支持大容量数据和大用户量并发访问，以及集成虚拟缓存技术的优势得以充分体现。“SQL Server的用户基础好，能够更好地保护用户在软件上的投资；对于浙大网络来说，完全基于.net环境开发也有利于统一知识，降低成本。这些因素综合起来，再加上ASP运营模式的灵活性和易用性，就是我们网站生成系统的特点和优势。”姚辉明主任介绍说。        “这是一个非常灵活的平台，用户对于各种功能的发挥甚至超越我们最初的设计”。2006年5月18日，采用浙大网络网站生成系统建设的福建省教育厅网站（fjedu.gov.cn）上线。除了整合各级子站的内容，网站还通过开放的接口加载了四大功能平台：网络办公平台、视频会议系统、家校互联、学籍管理平台。从而在全省教育系统内实现了统一的公文流转，统一的学籍信息上报，统一的视频会议系统，以及统一的农校互联，俨然已是一个功能完备的教育综合服务门户。“这些完全都是他们自己实现的”，冯跃兵说。 但在浙大网络对于“软件加服务”模式的探索中，网站生成系统只是累累硕果中的一枚。 由售变租，SaaS模式辟“校校通”蹊径 “校校通”推动之初，+中小学教育信息化建设的重点主要落实在多媒体教室、学习软件、教务管理系统等具体的应用上，很少有人意识到学校和学校之间需要资源共享，各级教育主管部门需要和学校做实时无缝的数据对接。抓住这个时机，浙大网络提出了全程网络管理的理念，并在1999年推出了校园网软件平台3.0版。系统部署后，可以从学校到县/地市教育局，再到省教育厅，实现所有数据一体化的全程网络管理。 领先的意识为浙大网络的发展创造了良机，但热销几年后，校园网软件平台很快又遇到了市场瓶颈。浙大网络总裁申屠祖斌在接受采访时告诉51CTO记者，当时的难点不仅在于启发用户认知教育管理软件的价值，而且不同地区、学校之间的资金实力也差距巨大。“实现真正的系统部署谈何容易，就拿学籍管理来说，只要有一个学校买不起软件，整个地区的数据统计就会出现偏差。结果是花了钱的也没用好，真正在地方教育系统中全面实施的成功案例凤毛麟角。” 穷则思变，既然一次性投资购买教育软件平台的门槛太高，那么换一种按需租用，分期付款的方式如何？很快浙大网络又推出了ASP（Application Service Provider，应用软件服务）模式的城域综合信息平台。在这一平台上，运营商通过设立公共数据中心建设一个功能强大的网络和应用系统平台，以“出租”的方式为各级教育单位构建网络门户以及教学、办公和管理的应用程序和教学资源库，提供各种网络应用和增值服务。 这一运营模式既减轻了学校购买应用软件的压力，也降低了维护计算机系统的成本，而且可以根据教育政策的调整作灵活的业务变更。仅就2008年4月30日正式启动的广州市教育综合管理系统改造与扩建项目而言，采用浙大网络基于SaaS模式的集群部署方案后，未来至少可以节省2000台服务器和相关维护人员。 当年的ASP模式，也就是如今SaaS的前身；为了将之推广，也为了兑现“源于教育，回报教育”的承诺，申屠祖斌屡次将价值数百万元的城域综合信息平台赠送给地方教育主管部门。“我们送给山西省的‘校校通’系列软件就价值140万”。 在浙大网络的引领和支持下，一些地方教育系统开始转换思路，跳出原来“天网、地网、人网，三网合一”观念的桎梏。福建省教育厅应用浙大网络方案，把软硬件设备集中安装在省教育管理信息中心，建立起强大、易用、安全、统一的应用系统平台，为各级教育单位构建网络门户，提供教学、办公管理的应用系统，承担教育应用服务提供商的角色。 由于平台统一，福建省教育厅与各级教育单位在横向和纵向的管理、应用、交流等方面都没有任何障碍，克服了教育信息化中“蜂窝煤”状态的顽疾。由于平台统一，福建省形成了多位一体的教育城域网应用环境，实现优质教学资源无障碍分享，大大提高了教与学、管与用的效能。 软件加服务，克服“建网容易用网难” 听申屠祖斌回顾基础教育信息化的方方面面，从政府到民间持续巨大的投入后，“建网容易用网难”仍然是普遍突出的问题。“无论是企业开发还是学校采购，都缺乏对深层次应用需求的细致分析，缺少应用的核心价值思想，这些是产生应用障碍的最重要原因。” 申屠祖斌转述了一位教育局长的评语。 那么，教育信息化网络应用的核心价值到底是什么呢？ 很多教育界的专家已经意识到，网络应用应该重点考虑如何解决用户的需求。也有人更准确地指出，软件应用环境中的“三大孤岛”导致了用户需求无法满足，是‘应用难’的根源。这三个孤岛分别是‘资源孤岛’——资源是静态的，不能实现自由流通，实际上的利用率甚至不到10%；‘应用孤岛’——企业产品各自为阵，为求市场份额甚至不惜自建樊篱；和‘信息孤岛’——网络应用中的信息无法得到回应。 怎样才能打通“孤岛”，从根源上解决“应用难”问题？ 申屠祖斌总裁早在2002年就敏锐地意识到了各地教育城域网画地为牢的发展瓶颈和教学资源建设投入大、效率低的问题。2003年9月，他带领浙大网络推出了以打破教育行业资源壁垒为目标的“教育互联”，致力于整合优秀的教育资源，营造教育部门、学生、家庭三方互动的平台——这也是中国教育应用统一平台，万朋网最初的由来。 申屠祖斌介绍说，基于过去“校校通”工程积累的数百个教育局城域网和数以万计的学校用户，万朋网拥有空前庞大的客户基础。在中心数据库和统一认证、应用平台的基础上搭设起从教学管理到校园自主建站的丰富应用，万朋网可以为不同身份的用户提供数字校园、家校互联、教育博客、教育资源等功能强大，内容丰富的教育信息化服务。 “根据教育消费的特征，制定出一套完整的实名认证、用户评价、计费与支付系统，用户为服务付费。万朋的目标是做全民终身教育网站，我们颠覆了教育行业传统的信息化模式。这是万朋的创新，也是我们在‘软件加服务’上的实践”，申屠祖斌说。虽然万朋网呈现在用户面前的是所见即所得的应用，但在后台却整合了许多原本自成一家的软件。“目前我们所有的软件产品都在向SaaS模式转型，为推出万朋网所作的技术升级历时三年”。 有用户资源，有技术实力是万朋网取得成功的关键；同样关键的是，万朋网采取了开放共赢的策略——和电信运营商共建“数字校园”、“家校互联”，广泛发展区域代理、加盟伙伴，和微软持续进行紧密的技术合作。 教育信息化在2008步入应用元年，‘软件加服务’特别适合教育信息化”，申屠祖斌说。 本文转自 alifafa 51CTO博客，原文链接：http://blog.51cto.com/chenghong/101024 ，如需转载请自行联系原作者

本文通过描述关系型数据库发展的背景以及云计算的时代特征，分享了数据库计算力的螺旋式上升的进化理念，另外结合阿里云 RDS 产品的发展路径，阐述了自主研发的新一代云托管关系型数据库 PolarDB 的产品整体设计思想，对一些关键技术点进行了解读。 关系型数据库 谈到关系型数据库，在这个知识日新月异的 TMT 时代，听起来有些“古董”，这个起源于半个世纪以前的 IT 技术，事实上一直处于现代社会科技的核心，支撑着当今世界绝大多数的商业科技文明。CPU、操作系统、数据库这三大核心领域，基本上就是 IT 时代的缩影，同时也是一切信息化处理、计算力和智能化的基石。 从 1970 年 E.F.Codd 发表了一篇里程碑论文“A Relational Model of Data for Large Shared Data Banks”，到 80 年代初期支持 SQL 的商用关系型数据库 DB2，Oracle 的面市，以及 90 年代初 SQL-Server 的诞生，都是关系型数据库成功的代表。 时至今日，随着全球互联网的发展，大数据技术的广泛应用，涌现出越来越多的新型数据库，然而关系型数据库仍然占据主导地位。最主要的原因之一就是关系型数据库采用了 SQL 标准，这种高级的非过程化编程接口语言，将计算机科学和易于人类理解认知的数据管理方式完美的衔接在了一起，目前还难以超越。 SQL 语言 SQL(Structured Query Language) 语言是 1974 年由 Boyce 和 Chamberlin 提出的一种介于关系代数与关系演算之间的结构化查询语言，其本质是用一种类似于自然语言的关键字和语法来定义和操作数据，进行可编程的数据存储、查询以及管理。 这种抽象编程接口，将具体的数据问题与数据的存放、查询实现的细节解耦开来，使得商业业务逻辑以及信息管理的计算模式能够被大量复制和应用，解放了生产力，也极大的促进了商业化关系型数据库自身的发展。从 SQL 后来不断发展和丰富来看，SQL 已经成为关系型数据库语言的标准和王者。到今天这种编程语言还没有更加完美的替代品。 OLTP 1976 年，Jim Gray 发表了名为"Granularity of Locks and Degrees of Consistency in a Shared DataBase"的论文，正式定义了数据库事务的概念和数据一致性的机制。而 OLTP 是关系型数据库涉及事务处理的典型应用，主要是基本的、日常的事务处理，例如银行交易。 事务处理需要遵循 ACID 四个要素来保证数据的正确性，包括原子性（Atomicity）、一致性（Consistency）、隔离性（Isolation）和持久性（Durability）。而衡量 OLTP 处理能力的性能指标主要有响应时间、吞吐率等。 开源数据库生态 在我们简要的回顾了关系型数据库的历史、地位和发展阶段后，我们不难看到 Oracle、SQL-Server、DB2 等关系型数据库仍然占据着全球商业数据库的主导地位，虽然曾经耳熟能详的 Informix、Sybase 已经淡出大众的视线。 然而，从 20 世纪 90 年代开始，另一股推崇知识分享、自由开放的软件精神成为趋势和潮流，尤其以 Linux、MySQL、PostgreSQL 等为代表的开源软件，开始以强大的生命力不断发展壮大，释放出巨大的社会进步力量，这些被自由分享的科技红利，孕育和促进了全球互联网高科技公司的飞速发展。 这是整个人类社会的进步，我们要感谢那些开源软件的斗士们，Richard Stallman，Linus Torvalds，Michael Widenius 等。当然，最近几年国内涌现出越来越多积极参与到开源主流社区的中国公司，也在不断地将技术分享回馈给开源世界。 根据 DB-engines 网站的最新统计，不难发现，当把开源数据库 MySQL 和 PostgreSQL 加在一起，开源数据库就已经超越了商业数据库 Oracle，成为世界上最流行的关系型数据库。 云计算当前的阶段 如果说关系型数据库是 IT 时代的产物。那么在互联网时代的云计算，关系型数据库目前正处于一个什么阶段呢？IT 时代从某种程度上讲，更多是创造了计算力，那么进入互联网时代的云计算，则是专注于用户和计算力的连接，提供无处不在的计算力，这个其实是云计算商业模式的成功所在，可以称之为 1.0 版本。而云计算 2.0 版本，需要在云环境下，重新进化和升级计算力，这种进化体现了社会计算力的整合以及计算资源能效的进步。 为了顺应绿色计算以及共享经济的发展潮流，不仅仅需要云服务器，云数据库，网络互联，硬件芯片等等各个软硬件系统领域的融合以及演进升级，还需要坚持科技以需求为本、服务以用户为根的科技普惠大众的理念来进一步促进计算效率和计算智能的提高。 我们正处在一个蓬勃发展的云计算 2.0 阶段。在这个阶段，关系型数据库在云托管环境逐渐暴露出一些问题，作为在云计算时代的先行者，Amazon 于 2014 年 11 月 12 日 的 AWS re:Invent 2014 大会，发布 Aurora 云托管关系型数据库就是为了解决这些问题。这个新一代的数据库的发布，也昭示着云计算时代，传统的 IT 技术核心产品将揭开自我进化的序幕。 而 2017 年 SIGMOD 数据大会， Amazon 发布了论文”Amazon Aurora: Design Considerations for High Throughput Cloud Native Relational Databases”, 更加开放的解释了基于云环境的 Cloud-Native 设计的关系型数据库是如何应孕而生的。 为什么阿里云研发 PolarDB ? 在我们回顾了关系型数据库以及云计算的背景之后，我们不难发现, 云计算 1.0 虽然解决了用户和计算的连接的问题，但是还需要进一步解决在一个共享计算的环境下，传统关系型数据库和公有云服务环境的融合问题。 云计算 1.0 用低廉的成本，灵活快速的部署、弹性和扩展能力，获得了传统 IT 计算上云的转换动力。在低成本享受普惠科技成为常态之后，随着用户业务的增长，用户新的痛点开始出现，例如，如何从根本上解决用持续低的成本，享受和传统 IT 计算力一样，甚至更好的云服务，成为迫切需要。 这初看起来像伪命题，仔细分析之后，却淋漓尽致的体现了螺旋式上升的哲学思想。就好像在 PC 服务器涌现的时代，PC 服务器首先用低廉的价格提供了和小型服务器接近的计算能力，然后在保持成本和性价比优势的基础上，实现了超越小型服务器的性能优势，直至终结了小型服务器时代，开始了 PC 服务器时代。 所以说云计算时代还远远没有到达鼎盛时期，除非它通过自身进化演变，在不断保持性价比优势的同时，在具有快速灵活弹性的内在属性基础上，拥有超过传统 IT 计算力的能力之后，云计算才会真正进入它所主宰的时代，这只是个时间问题。 也就是说今天不只是阿里云要做这样一款关系型数据库，而是所有的云计算厂商都不可避免的要经历这样一个阶段。那就是云计算时代传统 IT 计算力的重建和进化！只不过 Amazon 走在了最前面，而阿里云紧跟其后，都需要经历这进化到蜕变的过程。 在这个过程中，新一代关系型数据库是关键的里程碑之一。同理，接下来应该有更多更加高级的云服务，比如智能云操作系统出现，来融合为云时代设计的硬件芯片和网络互联等等。 在 IT 时代，传统的计算力（例如用关系型数据库来处理结构化数据等）是服务于系统硬件隔离环境下的多用户使用场景的。而云计算时代是多客户 Self-Service 租用环境，各种计算负载场景更加复杂，在这种计算负载变迁的环境下，如何解决 IT 时代的技术产物和云计算时代应用环境的适配矛盾，正是云计算自我进化的内在推动力。 例如，在公有云环境下，随着用户的增多，以及用户业务和数据的增长，备份、性能、迁移、升级、只读实例、磁盘容量、Binlog 延迟等相关问题渐渐显现出来。这背后大部分原因是由于 I/O 瓶颈（存储和网络）导致，亟须通过技术革新以及新的产品架构解决这个问题。另一方面，从产品形态来讲，阿里云 RDS 目前的产品形态各具优势，在下一节会详细介绍。 但是从产品架构的发展来看，除去数据库存储引擎的类型之外，对于关系型数据库，考虑到工程效率以及运维成本，最好有一种通用的产品技术架构能兼顾不同用户场景的需求，而不是针对每一个场景都实现一种对应的技术架构。在接下来的内容，通过讲述阿里云 RDS 的不同产品形态的特点，我们会更加清晰的了解到，PolarDB 的产品形态正是在吸收了之前几种产品形态的优点而孕育而生的。 PolarDB 的设计思想 用户需求和公有云自身发展的选择 作为云托管的关系型数据，除了关系型数据库的核心特征之外。PoalrDB 更多的关注于如何提供满足用户业务需求的云服务，并且通过技术革新，不断进化，在提供更好的数据库计算力的同时，满足用户以下业务需求：上云成本、OLTP 性能、业务连续性、在线业务扩展、数据安全。另一方面云计算除了成本优势之外，弹性和可扩展性也是云计算的天然属性。为了用户业务的扩展，更好的 Scale Up 以及故障恢复，计算和存储分离的架构成为云资源环境更好的选择。这一点将在下一节 RDS 产品架构的演进中得到进一步的诠释。 阿里云 RDS 产品架构的演进 范例 如上所述，阿里云 PolarDB 和 Amazon Aurora 数据库进化的方向是一致的，然而进化的路径各有不同。本身来讲，这是由于各自的数据库云服务实现方式不同所决定的。阿里云 RDS MySQL 有如下几个版本。这些产品形态满足不同的用户业务场景，具有不同的特点，可以进行优势互补。 MySQL 基础版MySQL 基础版采用数据库计算节点和存储节点分离的方式，利用云盘数据本身的可靠性和多副本的特性，同时也利用了 ECS 云服务器虚拟化来提升标准化部署、版本和运维的管理效率，能够满足低端用户不太注重高可用服务的业务场景。同时这种架构对于数据库的迁移，数据容量的扩容，计算节点的 Scale Up，计算节点故障恢复都有天然的优势，根本原因就是计算和存储的分离。后面也会讲到，PolarDB 也采用了存储和计算分离的设计理念。 MySQL 高可用版 MySQL 高可用版则是针对企业级用户提供的高可用数据库版本，提供 99.95% 的 SLA 保障。采用 Active-Standby 的高可用架构，主节点和备节点之间通过 MySQL Binlog 进行数据的 Replication。当主节点发生故障，备节点接管服务。 同时还支持多个只读节点，支持负载均衡的数据读写分离的访问方式。采用 Shared-Nothing 架构，计算和数据位于同一个节点，最大程度保障性能的同时又通过数据的多副本带来可靠性。 MySQL 金融版MySQL 金融版可以说是针对金融行业等高端用户设计的高可用、高可靠云服务产品，采用分布式 Raft 协议来保证数据的强一致性，拥有更加优异的故障恢复时间，更加满足数据容灾备份等业务场景的需求。 PolarDB 的进化PolarDB 采用存储与计算分离的技术架构，同时可以支持更多的只读节点。主节点和只读节点之间是 Active-Active 的 Failover 方式，计算节点资源得到充分利用，由于使用共享存储，共享同一份数据，进一步降低了用户的使用成本。下一节我们将进一步从细节上描述 PolarDB 的关键特性。 PolarDB 的设计思想有几个大的革新。一是通过重新设计特定的文件系统来存取 Redo log 这种特定的 WAL I/O 数据，二是通过高速网络和高效协议将数据库文件和 Redo log 文件放在共享存储设备上，避免了多次长路径 I/O 的重复操作，相比较 Binlog 这种方式更加巧妙。 另外在 DB Server 设计上，采用 MySQL 完全兼容的思路，完全拥抱开源生态，从 SQL 的编译、性能优化器和执行计划等等都保留了传统关系型数据库的特色。并且针对 Redolog 的 I/O 路径，专门设计了多副本共享存储块设备。 我们知道，分布式数据库一直是数据库领域的热点，具有非常大的实现难度。不管是遵循 CAP 理论，还是 BASE 思想，通用的分布式关系型数据库基本上很难做到技术和商用的完美平衡。与 SQL 标准以及主流数据库兼容，OLTP ACID 事务 100% 支持，99.99% 的高可用，高性能低延迟并发处理能力，弹性 Scale Up，Scale out 可扩展性，备份容灾和低成本迁移等等，能够完美兼顾所有这些特点的商用关系型数据库还没有出现。 阿里云 PolarDB 和 Amazon Aurora 的一个共同设计哲学就是，放弃了通用分布式数据库 OLTP 多路并发写的支持，采用一写多读的架构设计，简化了分布式系统难以兼顾的理论模型，又能满足绝大多数 OLTP 的应用场景和性能要求。 总之，100% MySQL 的兼容性，加上专用的文件系统和共享存储块设备设计，以及在下文中提到的多项高级技术的应用，使得新一代关系型数据库 PoalrDB 在云时代必将大放异彩。 PolarDB 产品关键技术点剖析 范例 在讲述了阿里云 RDS 的不同产品形态之后，我们再从整体上看一看 PolarDB 的产品架构。下图勾画了 PolarDB 产品的主要模块，包括数据库服务器，文件系统，共享块存储等。 PoalrDB 产品架构 如图所示，PolarDB 产品是一个分布式集群架构的设计。它集众多高级的技术实现于一身，使得数据库 OLTP 处理性能有了质的飞跃。PoalrDB 采用了存储与计算分离的设计理念，满足公有云计算环境下用户业务弹性扩展的刚性需求。数据库计算节点和存储节点之间采用高速网络互联，并通过 RDMA 协议进行数据传输，使得 I/O 性能不在成为瓶颈。 数据库节点采用和 MySQL 完全兼容的设计。主节点和只读节点之间采用 Active-Active 的 Failover 方式，提供 DB 的高可用服务。DB 的数据文件、redolog 等通过 User-Space 用户态文件系统，经过块设备数据管理路由，依靠高速网络和 RDMA 协议传输到远端的 Chunk Server。 同时 DB Server 之间仅需同步 Redo log 相关的元数据信息。Chunk Server 的数据采用多副本确保数据的可靠性，并通过 Parallel-Raft 协议保证数据的一致性。 在描述了 PolarDB 的产品架构之后，我们再分别从分布式架构，数据库高可用，网络协议，存储块设备，文件系统和虚拟化等方面逐一介绍下 PolarDB 使用的关键技术点。 Shared Disk 架构 分布式系统的精髓就在于分分合合，有时候为了并发性能进行数据切分，而有时候为了数据状态的一致性而不得不合，或者由于分布式锁而不得不同步等待。 PolarDB 采用 Shared Disk 架构，其根本原因是上述的计算与存储分离的需要。逻辑上 DB 数据都放在所有 DB server 都能够共享访问的数据 chunk 存储服务器上。而在存储服务内部，实际上数据被切块成 chunk 来达到通过多个服务器并发访问 I/O 的目的。 物理 Replication 我们知道，MySQL Binlog 记录的是 Tuple 行级别的数据变更。而在 InnoDB 引擎层，需要支持事务 ACID，也维持了一份 Redo 日志，存储的是基于文件物理页面的修改。 这样 MySQL 的一个事务处理默认至少需要调用两次 fsync() 进行日志的持久化操作，这对事务处理的系统响应时间和吞吐性能造成了直接的影响。尽管 MySQL 采用了 Group Commit 的机制来提升高并发下的吞吐量，但并不能完全消除 I/O 瓶颈。 此外，由于单个数据库实例的计算和网络带宽有限，一种典型的做法是通过搭建多个只读实例分担读负载来实现 Scale out。PolarDB 通过将数据库文件以及 Redolog 等存放在共享存储设备上，非常讨巧的解决了只读节点和主节点的数据 Replication 问题。 由于数据共享，只读节点的增加无需再进行数据的完全复制，共用一份全量数据和 Redo log，只需要同步元数据信息，支持基本的 MVCC，保证数据读取的一致性即可。这使得系统在主节点发生故障进行 Failover 时候，切换到只读节点的故障恢复时间能缩短到 30 秒以内。 系统的高可用能力进一步得到增强。而且，只读节点和主节点之间的数据延迟也可以降低到毫秒级别。从并发的角度来看，使用 Binlog 复制现在只能按照表级别并行复制，而物理复制只按照数据页维度，粒度更细，并行效率更加高。 最后一点，引入 Redolog 来实现 Replication 的好处是，Binlog 是可以关闭来减少对性能的影响，除非需要 Binlog 来用于逻辑上的容灾备份或者数据迁移。 总之，在 I/O 路径中，通常越往底层做，越容易和上层的业务逻辑和状态解耦而降低系统复杂度。而且这种 WAL Redo log 大文件读写的 I/O 方式也非常适用于分布式文件系统的并发机制，为 PolarDB 带来并发读性能的提高。 高速网络下的 RDMA 协议 RDMA 之前是在 HPC 领域被使用多年的技术手段，现在开始被使用到云计算领域，也证实我的一个判断。云计算 2.0 时代，将重建人们对于云计算的认识，云端也能够创造超越传统 IT 技术的计算力，这将是一个越来越严谨的工业实现。 RDMA 通常是需要有支持高速网络连接的网络设备（如交换机，NIC 等），通过特定的编程接口，来和 NIC Driver 进行通讯，然后通常以 Zero-Copy 的技术以达到数据在 NIC 和远端应用内存之间高效率低延迟传递，而不用通过中断 CPU 的方式来进行数据从内核态到应用态的拷贝，极大的降低了性能的抖动，提高了整体系统的处理能力。 Snapshot 物理备份 Snapshot 是一种流行的基于存储块设备的备份方案。其本质是采用 Copy-On-Write 的机制，通过记录块设备的元数据变化，对于发生写操作的块设备进行写时复制，将写操作内容改动到新复制出的块设备上，来实现恢复到快照时间点的数据的目的。 Snapshot 是一个典型的基于时间以及写负载模型的后置处理机制。也就是说创建 Snapshot 时，并没有备份数据，而是把备份数据的负载均分到创建 Snapshot 之后的实际数据写发生的时间窗口，以此实现备份、恢复的快速响应。PolarDB 提供基于 Snapshot 以及 Redo log 的机制，在按时间点恢复用户数据的功能上，比传统的全量数据结合 Binlog 增量数据的恢复方式更加高效。 Parallel-Raft 算法 谈到分布式数据库的事务一致性，我们很容易想到 2PC（2 Phases Commit），3PC（3 Phases Commit）协议。而论数据状态一致性，我们就不得不提到 Leslie Lamport 发明的 Paxos 协议，在 Paxos 为 Google 等互联网厂商所广泛应用到多个分布式系统实现之后，Paxos 成为了最受关注的数据状态一致性算法之一。可是由于 Paxos 算法论文的理论和实现过于复杂，导致难以被快速应用到工程技术上。 Paxos 解决的问题之一是，在多个机器的集合中，集合中初始状态相同的任何机器能否通过相同的命令序列到达同样相同的状态点，形成一个一致的收敛的状态机。另一个问题是，作为集群中的一员，通过微观的时间串行通讯方式，需要找到一个始终有效的协议，当一个机器的某个数据状态需要改变时，需要和整个集群（包括其他机器）靠通讯和协议达成相同的认知，一起认同这个机器上的某个状态的改变。 基于这两点，基本上就解决了分布式集群架构中，不同角色的机器，达成一致性状态机的问题。也就可以进一步设计出绝大多数分布式系统的框架。 Paxos 可以堪称是 P2P（Peer to Peer）的对等设计，更加抽象和通用，也更难以理解。而 Raft 则是选举出 Leader，再经由 Leader 发起对其他角色进行状态一致性更新的实现，更容易理解。而协议本身的实现流程和 Paxos 有相似之处。 Parallel-Raft 是在 Raft 协议的基础上，针对 PolarDB chunk Server 的 I/O 模型，进行改良的一致性算法。Raft 协议基于 Log 是连续的，log#n 没有提交的话，后面的 Log 不允许提交。而 PolarDB 实现的 Parallel-Raft 允许并行的提交，打破了 Raft 的 log 是连续的假设，提高并发度，通过额外的限制来确保一致性。 Docker 容器虚拟化技术最早的出现是 Linux 内核为了解决进程在操作系统之间，或者在进程运行过程当中做迁移，通过进程和操作系统之间的解耦，来达到进程运行时的上下文和状态能够保存，复制和恢复的目的。可是 LXC 的实现，却促成了曾红极一时的 Docker 的诞生。 从原理上讲，容器虚拟化的实现相对于 KVM 等虚拟化技术而言，更加轻量级。如果用户不需要感知整个操作系统的功能，那么用容器虚拟化技术理论上应该能够获得更好的计算能效比。 其实 LXC 加上 Cgroup 这种进程虚拟和资源隔离的方式已经被使用很多年，在 HPC 领域就常被应用到 MPI 超级任务的 checkpoint 和 restart 恢复上。PolarDB 采用 Docker 环境来运行 DB 计算节点，用更轻量的虚拟化方式，解决了资源的隔离和性能的隔离，也节省了系统资源。 User-Space 文件系统 谈到文件系统，就不得不提一下 IEEE 发明的 POSIX 语义（POSIX.1 已经被 ISO 所接受），就像说到数据库要谈到 SQL 标准。通用分布式文件系统实现的最大挑战就是在完全兼容 POSIX 标准的基础上提供强劲的并发文件读写性能。 可是 POSIX 的兼容势必会牺牲一部分性能来获得对于标准的完全支持，同时系统实现的复杂度也极大的增加。说到底是通用设计和专有设计的取舍和区别，也是易用性和性能之间的平衡，这是个经典问题。分布式文件系统是 IT 行业最经久不衰的技术，从 HPC 时代，云计算时代，互联网时代，大数据时代一直在推陈出新，其实更严格的说应该是针对不同应用 I/O 场景涌现出很多定制化的实现，再说白点，就是不去支持 POSIX 标准。 这一点上，只能说知难而退，不过只服务于专门的 I/O 场景时，不适用 POSIX 也不是什么问题。这一点，和从 SQL 到 NoSQL 的发展如出一辙。支持 POSIX 的文件系统，需要实现兼容标准的文件读写操作的系统调用接口，这样对于用户而言，就无需修改 POSIX 接口实现的文件操作应用程序。这样一来就要求通过 Linux VFS 层来铆接具体的文件系统内核实现。这也是导致文件系统工程实现难度加大的原因之一。 对于分布式文件系统而言，内核模块还必须和用户态的 Daemon 进行数据交换，以达到数据分片以及通过 Daemon 进程传送到其他机器上的目的。而 User-Space 文件系统提供用户使用的专用 API，不用完全兼容 POSIX 标准，也无需在操作系统内核进行系统调用的 1:1mapping 对接，直接在用户态实现文件系统的元数据管理和数据读写访问支持即可，实现难度大大降低，并且更加有利于分布式系统的进程间通讯。 小结：通过以上的介绍，我们不难发现，PolarDB 采用了从计算虚拟化，高速网络互联，存储块设备，分布式文件系统，数据库物理 Replication 等全方位的技术手段，可以说是众多热点技术的集大成。正式这些关键技术的整合创新，才使得 PolarDB 的性能有了质的飞跃。 来源：阿里技术原文链接

本文通过描述关系型数据库发展的背景以及云计算的时代特征，分享了数据库计算力的螺旋式上升的进化理念。并且结合阿里云 RDS 产品的发展路径，阐述了自主研发的新一代云托管关系型数据库 PolarDB 的产品整体设计思想，同时也对一些关键技术点进行了解读。 背景 关系型数据库 谈到关系型数据库，在这个知识日新月异的TMT时代，听起来有些“古董”，这个起源于半个世纪以前的IT技术，事实上一直处于现代社会科技的核心，支撑着当今世界绝大多数的商业科技文明。CPU、操作系统、数据库这三大核心领域，基本上就是IT时代的缩影，同时也是一切信息化处理、计算力和智能化的基石。从1970年E.F.Codd发表了一篇里程碑论文“A Relational Model of Data for Large Shared Data Banks”，到80年代初期支持SQL的商用关系型数据库DB2，Oracle的面市，以及90年代初SQL-Server的诞生，都是关系型数据库成功的代表。 时至今日，随着全球互联网的发展，大数据技术的广泛应用，涌现出越来越多的新型数据库，然而关系型数据库仍然占据主导地位。最主要的原因之一就是关系型数据库采用了SQL标准，这种高级的非过程化编程接口语言，将计算机科学和易于人类理解认知的数据管理方式完美的衔接在了一起，目前还难以超越。 SQL语言 SQL(Structured Query Language)语言是1974年由Boyce和Chamberlin提出的一种介于关系代数与关系演算之间的结构化查询语言，其本质是用一种类似于自然语言的关键字和语法来定义和操作数据，进行可编程的数据存储、查询以及管理。这种抽象编程接口，将具体的数据问题与数据的存放、查询实现的细节解耦开来，使得商业业务逻辑以及信息管理的计算模式能够被大量复制和应用，解放了生产力，也极大的促进了商业化关系型数据库自身的发展。从SQL后来不断发展和丰富来看，SQL已经成为关系型数据库语言的标准和王者。到今天这种编程语言还没有更加完美的替代品。 OLTP 1976年，Jim Gray发表了名为"Granularity of Locks and Degrees of Consistency in a Shared DataBase"的论文，正式定义了数据库事务的概念和数据一致性的机制。而OLTP是关系型数据库涉及事务处理的典型应用，主要是基本的、日常的事务处理，例如银行交易。事务处理需要遵循ACID四个要素来保证数据的正确性，包括原子性（Atomicity）、一致性（Consistency）、隔离性（Isolation）和持久性（Durability）。而衡量OLTP处理能力的性能指标主要有响应时间、吞吐率等。 开源数据库生态 在我们简要的回顾了关系型数据库的历史、地位和发展阶段后，我们不难看到Oracle、SQL-Server、DB2等关系型数据库仍然占据着全球商业数据库的主导地位，虽然曾经耳熟能详的Informix、Sybase已经淡出大众的视线。然而，从20世纪90年代开始，另一股推崇知识分享、自由开放的软件精神成为趋势和潮流，尤其以Linux、MySQL、PostgreSQL等为代表的开源软件，开始以强大的生命力不断发展壮大，释放出巨大的社会进步力量，这些被自由分享的科技红利，孕育和促进了全球互联网高科技公司的飞速发展。这是整个人类社会的进步，我们要感谢那些开源软件的斗士们，Richard Stallman，Linus Torvalds，Michael Widenius等。当然，最近几年国内涌现出越来越多积极参与到开源主流社区的中国公司，也在不断地将技术分享回馈给开源世界。 根据DB-engines网站的最新统计，不难发现，当把开源数据库MySQL和PostgreSQL加在一起，开源数据库就已经超越了商业数据库Oracle，成为世界上最流行的关系型数据库。 云计算当前的阶段 如果说关系型数据库是IT时代的产物。那么在互联网时代的云计算，关系型数据库目前正处于一个什么阶段呢？IT时代从某种程度上讲，更多是创造了计算力，那么进入互联网时代的云计算，则是专注于用户和计算力的连接，提供无处不在的计算力，这个其实是云计算商业模式的成功所在，可以称之为1.0版本。而云计算2.0版本，需要在云环境下，重新进化和升级计算力，这种进化体现了社会计算力的整合以及计算资源能效的进步。为了顺应绿色计算以及共享经济的发展潮流，不仅仅需要云服务器，云数据库，网络互联，硬件芯片等等各个软硬件系统领域的融合以及演进升级，还需要坚持科技以需求为本、服务以用户为根的科技普惠大众的理念来进一步促进计算效率和计算智能的提高。 我们正处在一个蓬勃发展的云计算2.0阶段。在这个阶段，关系型数据库在云托管环境逐渐暴露出一些问题，作为在云计算时代的先行者，Amazon于2014年11月12日 的AWS re:Invent 2014大会，发布Aurora云托管关系型数据库就是为了解决这些问题。这个新一代的数据库的发布，也昭示着云计算时代，传统的IT技术核心产品将揭开自我进化的序幕。而2017年SIGMOD数据大会， Amazon 发布了论文”Amazon Aurora: Design Considerations for High Throughput Cloud Native Relational Databases”,更加开放的解释了基于云环境的Cloud-Native设计的关系型数据库是如何应孕而生的。 为什么阿里云要研发新一代的关系型数据库PolarDB ? 在我们回顾了关系型数据库以及云计算的背景之后，我们不难发现, 云计算1.0虽然解决了用户和计算的连接的问题，但是还需要进一步解决在一个共享计算的环境下，传统关系型数据库和公有云服务环境的融合问题。 云计算1.0用低廉的成本，灵活快速的部署、弹性和扩展能力，获得了传统IT计算上云的转换动力。在低成本享受普惠科技成为常态之后，随着用户业务的增长，用户新的痛点开始出现，例如，如何从根本上解决用持续低的成本，享受和传统IT计算力一样，甚至更好的云服务，成为迫切需要。这初看起来像伪命题，仔细分析之后，却淋漓尽致的体现了螺旋式上升的哲学思想。就好像在PC服务器涌现的时代，PC服务器首先用低廉的价格提供了和小型服务器接近的计算能力，然后在保持成本和性价比优势的基础上，实现了超越小型服务器的性能优势，直至终结了小型服务器时代，开始了PC服务器时代。 所以说云计算时代还远远没有到达鼎盛时期，除非它通过自身进化演变，在不断保持性价比优势的同时，在具有快速灵活弹性的内在属性基础上，拥有超过传统IT计算力的能力之后，云计算才会真正进入它所主宰的时代，这只是个时间问题。 也就是说今天不只是阿里云要做这样一款关系型数据库，而是所有的云计算厂商都不可避免的要经历这样一个阶段。那就是云计算时代传统IT计算力的重建和进化！只不过Amazon走在了最前面，而阿里云紧跟其后，都需要经历这进化到蜕变的过程。在这个过程中，新一代关系型数据库是关键的里程碑之一。同理，接下来应该有更多更加高级的云服务，比如智能云操作系统出现，来融合为云时代设计的硬件芯片和网络互联等等。 在IT时代，传统的计算力（例如用关系型数据库来处理结构化数据等）是服务于系统硬件隔离环境下的多用户使用场景的。而云计算时代是多客户Self-Service租用环境，各种计算负载场景更加复杂，在这种计算负载变迁的环境下，如何解决IT时代的技术产物和云计算时代应用环境的适配矛盾，正是云计算自我进化的内在推动力。 例如，在公有云环境下，随着用户的增多，以及用户业务和数据的增长，备份、性能、迁移、升级、只读实例、磁盘容量、Binlog延迟等相关问题渐渐显现出来。这背后大部分原因是由于I/O瓶颈（存储和网络）导致，亟须通过技术革新以及新的产品架构解决这个问题。另一方面，从产品形态来讲，阿里云RDS目前的产品形态各具优势，在下一节会详细介绍。但是从产品架构的发展来看，除去数据库存储引擎的类型之外，对于关系型数据库，考虑到工程效率以及运维成本，最好有一种通用的产品技术架构能兼顾不同用户场景的需求，而不是针对每一个场景都实现一种对应的技术架构。 在接下来的内容，通过讲述阿里云RDS的不同产品形态的特点，我们会更加清晰的了解到，PolarDB的产品形态正是在吸收了之前几种产品形态的优点而孕育而生的。 PolarDB的设计思想 用户需求和公有云自身发展的选择 作为云托管的关系型数据，除了关系型数据库的核心特征之外。PoalrDB更多的关注于如何提供满足用户业务需求的云服务，并且通过技术革新，不断进化，在提供更好的数据库计算力的同时，满足用户的如下业务需求： 上云成本OLTP性能业务连续性在线业务扩展数据安全另一方面云计算除了成本优势之外，弹性和可扩展性也是云计算的天然属性。为了用户业务的扩展，更好的Scale Up以及故障恢复，计算和存储分离的架构成为云资源环境更好的选择。这一点将在下一节RDS产品架构的演进中得到进一步的诠释。 阿里云RDS产品架构的演进 如上所述，阿里云PolarDB和Amazon Aurora数据库进化的方向是一致的，然而进化的路径各有不同。本身来讲，这是由于各自的数据库云服务实现方式不同所决定的。阿里云RDS MySQL有如下几个版本。这些产品形态满足不同的用户业务场景，具有不同的特点，可以进行优势互补。 MySQL基础版 MySQL基础版采用数据库计算节点和存储节点分离的方式，利用云盘数据本身的可靠性和多副本的特性，同时也利用了ECS云服务器虚拟化来提升标准化部署、版本和运维的管理效率，能够满足低端用户不太注重高可用服务的业务场景。同时这种架构对于数据库的迁移，数据容量的扩容，计算节点的Scale Up，计算节点故障恢复都有天然的优势，根本原因就是计算和存储的分离。后面也会讲到，PolarDB也采用了存储和计算分离的设计理念。 MySQL高可用版 MySQL高可用版则是针对企业级用户提供的高可用数据库版本，提供99.95%的SLA保障。采用Active-Standby的高可用架构，主节点和备节点之间通过MySQL Binlog进行数据的Replication。当主节点发生故障，备节点接管服务。同时还支持多个只读节点，支持负载均衡的数据读写分离的访问方式。采用Shared-Nothing架构，计算和数据位于同一个节点，最大程度保障性能的同时又通过数据的多副本带来可靠性。 MySQL金融版 MySQL金融版可以说是针对金融行业等高端用户设计的高可用、高可靠云服务产品，采用分布式Raft协议来保证数据的强一致性，拥有更加优异的故障恢复时间，更加满足数据容灾备份等业务场景的需求。 PolarDB的进化 PolarDB采用存储与计算分离的技术架构，同时可以支持更多的只读节点。主节点和只读节点之间是Active-Active的Failover方式，计算节点资源得到充分利用，由于使用共享存储，共享同一份数据，进一步降低了用户的使用成本。下一节我们将进一步从细节上描述PolarDB的关键特性。 PolarDB的设计思想有几个大的革新。一是通过重新设计特定的文件系统来存取Redo log这种特定的WAL I/O数据，二是通过高速网络和高效协议将数据库文件和Redo log文件放在共享存储设备上，避免了多次长路径I/O的重复操作，相比较Binlog这种方式更加巧妙。另外在DB Server设计上，采用MySQL完全兼容的思路，完全拥抱开源生态，从SQL的编译、性能优化器和执行计划等等都保留了传统关系型数据库的特色。并且针对Redolog的I/O路径，专门设计了多副本共享存储块设备。 我们知道，分布式数据库一直是数据库领域的热点，具有非常大的实现难度。不管是遵循CAP理论，还是BASE思想，通用的分布式关系型数据库基本上很难做到技术和商用的完美平衡。与SQL标准以及主流数据库兼容，OLTP ACID事务100%支持，99.99%的高可用，高性能低延迟并发处理能力，弹性Scale Up，Scale out可扩展性，备份容灾和低成本迁移等等，能够完美兼顾所有这些特点的商用关系型数据库还没有出现。 阿里云PolarDB和Amazon Aurora的一个共同设计哲学就是，放弃了通用分布式数据库OLTP多路并发写的支持，采用一写多读的架构设计，简化了分布式系统难以兼顾的理论模型，又能满足绝大多数OLTP的应用场景和性能要求。总之，100% MySQL的兼容性，加上专用的文件系统和共享存储块设备设计，以及在下文中提到的多项高级技术的应用，使得新一代关系型数据库PoalrDB在云时代必将大放异彩。 PolarDB产品关键技术点剖析 在讲述了阿里云RDS的不同产品形态之后，我们再从整体上看一看PolarDB的产品架构。下图勾画了PolarDB产品的主要模块，包括数据库服务器，文件系统，共享块存储等。 PoalrDB产品架构 阿里云关系型数据库PoalrDB集群 如图所示，PolarDB产品是一个分布式集群架构的设计。它集众多高级的技术实现于一身，使得数据库OLTP处理性能有了质的飞跃。PoalrDB采用了存储与计算分离的设计理念，满足公有云计算环境下用户业务弹性扩展的刚性需求。数据库计算节点和存储节点之间采用高速网络互联，并通过RDMA协议进行数据传输，使得I/O性能不在成为瓶颈。 数据库节点采用和MySQL完全兼容的设计。主节点和只读节点之间采用Active-Active的Failover方式，提供DB的高可用服务。DB的数据文件、redolog等通过User-Space用户态文件系统，经过块设备数据管理路由，依靠高速网络和RDMA协议传输到远端的Chunk Server。同时DB Server之间仅需同步Redo log相关的元数据信息。Chunk Server的数据采用多副本确保数据的可靠性，并通过Parallel-Raft协议保证数据的一致性。 在描述了PolarDB的产品架构之后，我们再分别从分布式架构，数据库高可用，网络协议，存储块设备，文件系统和虚拟化等方面逐一介绍下PolarDB使用的关键技术点。 Shared Disk架构 分布式系统的精髓就在于分分合合，有时候为了并发性能进行数据切分，而有时候为了数据状态的一致性而不得不合，或者由于分布式锁而不得不同步等待。PolarDB采用Shared Disk架构，其根本原因是上述的计算与存储分离的需要。逻辑上DB数据都放在所有DB server都能够共享访问的数据chunk存储服务器上。而在存储服务内部，实际上数据被切块成chunk来达到通过多个服务器并发访问I/O的目的。 物理Replication 我们知道，MySQL Binlog记录的是Tuple行级别的数据变更。而在InnoDB引擎层，需要支持事务ACID，也维持了一份Redo日志，存储的是基于文件物理页面的修改。这样MySQL的一个事务处理默认至少需要调用两次fsync()进行日志的持久化操作，这对事务处理的系统响应时间和吞吐性能造成了直接的影响。尽管MySQL采用了Group Commit的机制来提升高并发下的吞吐量，但并不能完全消除I/O瓶颈。 此外，由于单个数据库实例的计算和网络带宽有限，一种典型的做法是通过搭建多个只读实例分担读负载来实现Scale out。PolarDB通过将数据库文件以及Redolog等存放在共享存储设备上，非常讨巧的解决了只读节点和主节点的数据Replication问题。由于数据共享，只读节点的增加无需再进行数据的完全复制，共用一份全量数据和Redo log，只需要同步元数据信息，支持基本的MVCC，保证数据读取的一致性即可。这使得系统在主节点发生故障进行Failover时候，切换到只读节点的故障恢复时间能缩短到30秒以内。系统的高可用能力进一步得到增强。而且，只读节点和主节点之间的数据延迟也可以降低到毫秒级别。 从并发的角度来看，使用Binlog复制现在只能按照表级别并行复制，而物理复制只按照数据页维度，粒度更细，并行效率更加高。 最后一点，引入Redolog来实现Replication的好处是，Binlog是可以关闭来减少对性能的影响，除非需要Binlog来用于逻辑上的容灾备份或者数据迁移。 总之，在I/O路径中，通常越往底层做，越容易和上层的业务逻辑和状态解耦而降低系统复杂度。而且这种WAL Redo log大文件读写的I/O方式也非常适用于分布式文件系统的并发机制，为PolarDB带来并发读性能的提高。 高速网络下的RDMA协议 RDMA之前是在HPC领域被使用多年的技术手段，现在开始被使用到云计算领域，也证实我的一个判断。云计算2.0时代，将重建人们对于云计算的认识，云端也能够创造超越传统IT技术的计算力，这将是一个越来越严谨的工业实现。 RDMA通常是需要有支持高速网络连接的网络设备（如交换机，NIC等），通过特定的编程接口，来和NIC Driver进行通讯，然后通常以Zero-Copy的技术以达到数据在NIC和远端应用内存之间高效率低延迟传递，而不用通过中断CPU的方式来进行数据从内核态到应用态的拷贝，极大的降低了性能的抖动，提高了整体系统的处理能力。 Snapshot物理备份 Snapshot是一种流行的基于存储块设备的备份方案。其本质是采用Copy-On-Write的机制，通过记录块设备的元数据变化，对于发生写操作的块设备进行写时复制，将写操作内容改动到新复制出的块设备上，来实现恢复到快照时间点的数据的目的。Snapshot是一个典型的基于时间以及写负载模型的后置处理机制。也就是说创建Snapshot时，并没有备份数据，而是把备份数据的负载均分到创建Snapshot之后的实际数据写发生的时间窗口，以此实现备份、恢复的快速响应。PolarDB提供基于Snapshot以及Redo log的机制，在按时间点恢复用户数据的功能上，比传统的全量数据结合Binlog增量数据的恢复方式更加高效。 Parallel-Raft算法 谈到分布式数据库的事务一致性，我们很容易想到2PC（2 Phases Commit），3PC（3 Phases Commit）协议。而论数据状态一致性，我们就不得不提到Leslie Lamport发明的Paxos协议，在Paxos为Google等互联网厂商所广泛应用到多个分布式系统实现之后，Paxos成为了最受关注的数据状态一致性算法之一。可是由于Paxos算法论文的理论和实现过于复杂，导致难以被快速应用到工程技术上。Paxos解决的问题之一是，在多个机器的集合中，集合中初始状态相同的任何机器能否通过相同的命令序列到达同样相同的状态点，形成一个一致的收敛的状态机。另一个问题是，作为集群中的一员，通过微观的时间串行通讯方式，需要找到一个始终有效的协议，当一个机器的某个数据状态需要改变时，需要和整个集群（包括其他机器）靠通讯和协议达成相同的认知，一起认同这个机器上的某个状态的改变。 基于这两点，基本上就解决了分布式集群架构中，不同角色的机器，达成一致性状态机的问题。也就可以进一步设计出绝大多数分布式系统的框架。Paxos可以堪称是P2P（Peer to Peer）的对等设计，更加抽象和通用，也更难以理解。而Raft则是选举出Leader，再经由Leader发起对其他角色进行状态一致性更新的实现，更容易理解。而协议本身的实现流程和Paxos有相似之处。 Parallel-Raft是在Raft协议的基础上，针对PolarDB chunk Server的I/O模型，进行改良的一致性算法。Raft协议基于Log是连续的，log#n没有提交的话，后面的Log不允许提交。而PolarDB实现的Parallel-Raft允许并行的提交，打破了Raft的log是连续的假设，提高并发度，通过额外的限制来确保一致性。 Docker 容器虚拟化技术最早的出现是Linux内核为了解决进程在操作系统之间，或者在进程运行过程当中做迁移，通过进程和操作系统之间的解耦，来达到进程运行时的上下文和状态能够保存，复制和恢复的目的。可是LXC的实现，却促成了曾红极一时的Docker的诞生。 从原理上讲，容器虚拟化的实现相对于KVM等虚拟化技术而言，更加轻量级。如果用户不需要感知整个操作系统的功能，那么用容器虚拟化技术理论上应该能够获得更好的计算能效比。其实LXC加上Cgroup这种进程虚拟和资源隔离的方式已经被使用很多年，在HPC领域就常被应用到MPI超级任务的checkpoint和restart恢复上。PolarDB采用Docker环境来运行DB计算节点，用更轻量的虚拟化方式，解决了资源的隔离和性能的隔离，也节省了系统资源。 User-Space文件系统 谈到文件系统，就不得不提一下IEEE发明的POSIX语义（POSIX.1已经被ISO所接受），就像说到数据库要谈到SQL标准。通用分布式文件系统实现的最大挑战就是在完全兼容POSIX标准的基础上提供强劲的并发文件读写性能。可是POSIX的兼容势必会牺牲一部分性能来获得对于标准的完全支持，同时系统实现的复杂度也极大的增加。说到底是通用设计和专有设计的取舍和区别，也是易用性和性能之间的平衡，这是个经典问题。分布式文件系统是IT行业最经久不衰的技术，从HPC时代，云计算时代，互联网时代，大数据时代一直在推陈出新，其实更严格的说应该是针对不同应用I/O场景涌现出很多定制化的实现，再说白点，就是不去支持POSIX标准。 这一点上，只能说知难而退，不过只服务于专门的I/O场景时，不适用POSIX也不是什么问题。这一点，和从SQL到NoSQL的发展如出一辙。支持POSIX的文件系统，需要实现兼容标准的文件读写操作的系统调用接口，这样对于用户而言，就无需修改POSIX接口实现的文件操作应用程序。这样一来就要求通过Linux VFS层来铆接具体的文件系统内核实现。这也是导致文件系统工程实现难度加大的原因之一。 对于分布式文件系统而言，内核模块还必须和用户态的Daemon进行数据交换，以达到数据分片以及通过Daemon进程传送到其他机器上的目的。而User-Space文件系统提供用户使用的专用API，不用完全兼容POSIX标准，也无需在操作系统内核进行系统调用的1:1mapping对接，直接在用户态实现文件系统的元数据管理和数据读写访问支持即可，实现难度大大降低，并且更加有利于分布式系统的进程间通讯。 小结：通过以上的介绍，我们不难发现，PolarDB采用了从计算虚拟化，高速网络互联，存储块设备，分布式文件系统，数据库物理Replication等全方位的技术手段，可以说是众多热点技术的集大成。正式这些关键技术的整合创新，才使得PolarDB的性能有了质的飞跃。 写在最后 阿里云PolarDB是云计算2.0时代产品进化的关键里程碑之一，也是开源数据库生态的积极推动力。PolarDB将于2017年9月底推出的公测版本，会和MySQL完全兼容。接下来，我们也会启动兼容PostgreSQL数据库引擎的研发。 作者 阿里云 贺军 点此免费试用云数据库POLARDB

《创新、进化、竞合、开放——阿里云自主研发云原生数据库POLARDB的开拓之路》 阿里云ApsaraDB数据库 高级产品专家 贺军 前言 数据库作为信息时代平台科技（CPU/芯片、PC/手机操作系统、数据库）最复杂最核心的技术之一，在数字化经济时代，成为了和“水电煤”一样不能缺少的数字化能源，是现代化社会经济运作的源动力。当今这些最核心的IT科技，还完全掌握在美国的高科技公司（如Intel、高盛、微软、苹果、谷歌、Oracle、IBM等）手中。 跻身于全球最顶级的高科技公司行列，中国互联网公司在应用创新层面的巨大成功，能否进化成核心科技自主研发的创新能力，是众多业界精英们相互“确认过眼神”后的普遍疑问。传统IT厂商数十年沉淀的技术壁垒能否被破局？云厂商近十年的技术积累和创新能否足以肩负核心科技自主研发的重任？云计算的商业模式和互联网的创新基因能否碰撞孕育出“换道超车”的时代机遇？ 互联网在“兵不血刃”的商业竞争中能否找到一条融合创新之路？ 带着这些问题，本文作者，尝试用不一样的个人视角，结合在阿里云自主研发云数据库产品创新之路上的思考、对云计算时代IT产业格局转变的理解，以及对于未来开放式竞合（Co-opetition）发展的展望等多个维度来思考。由于个人能力有限，认知偏颇之处难以避免。“嘤其鸣矣 求其友声”，更多的是希望能激发大家的共鸣，共同探讨和开拓未来之路。 1. 时代背景和使命 当下，我们享受着互联网时代的活色生香，商业模式“乱花渐入迷人眼”，新奇、有趣、刺激的流量变现无所不在，“眼球经济”迷倒众生一片，网罗了无数男女老少。人性和消费欲望在自由竞争的互联网新经济中不断被激发和放大，互联网应用在资本的推波助澜下繁花似锦，科技造富的神话亦不绝于耳。此起彼伏的互联网公司已经不是在满足需求，而是在创造需求。狄更斯的那句名言“这是一个最好的时代，也是一个最坏的时代”同样适用于描述今天的互联网。因为从来没有一个时代，把科技和经济联系得像今天这样紧密，也从来没有一个时代，像今天这样用追逐商业成功的梦想来催生和促进科技应用的创新和进步。对于快速奔跑的互联网人，其实内心需要更多的“慢下来”的思考，我们是想成为红极一时的互联网现象，还是成为经久不衰的时代经典？ 我们知道，互联网繁华的背后，是IT科技在支撑着（CPU，操作系统、数据库、算法、开源软件、工程管理、网络连接等）。放到今天来讲，云计算作为IT技术在互联网时代的演进形态，肩负着互联网服务大众、创新变革的使命。无论是大数据热潮，人工智能的方兴未艾，还是智慧星球的宏伟梦想，无不是构建在云计算、IT基础设施和科技平台之上的。 然而，互联网的喜新厌旧总会让繁华散场，能够沉淀下来的才是经典。作为核心科技之一的数据库，在IT技术发展浪潮中历久弥新，在数字化经济时代，更加焕发光彩，现代社会的商业和经济活动都离不开数据库。数据库在银行、证券、保险、互联网、电子商务、电子政务、移动支付、商品流通和售卖、共享经济、教育、泛娱乐服务等各行各业中发挥巨大作用，影响着商业活动和社会服务的健康高效运行，是城市运营、公司经营、商品交易和商业化服务的内在支撑。 所以云计算厂商，在互联网时代，都加大了对于数据库技术的研发投入，也找到了一条自主研发的新路——云原生数据库。云原生数据库，融合了云计算的服务能力和弹性架构、开源数据库的简洁易用和开放生态，以及传统数据库的SQL管理和处理性能等各方面的优势，通过融合创新，换道超车，在云环境下能够为用户提供更好的数据库服务。亚马逊作为云计算行业的先行者，在自研数据库方面已经进行了多年的投入和努力。亚马逊在2014年11月召开的AWS re:Invent 年度大会上，发布了云原生数据库Aurora，三年后在2017年SIGMOD数据库大会， 亚马逊发布了论文”Amazon Aurora: Design Considerations for High Throughput Cloud Native Relational Databases”，更加开放的解释了云原生（Cloud-Native）数据库Aurora的设计架构和实现方式。 而阿里云紧跟其后，经过三年的研发，于2017年9月发布了自主研发的云原生数据库POLARDB，经过半年多时间的公测，2018年4月正式商用，并且在ICDE数据库大会进行了阿里云自主研发云原生数据库的技术专题分享。 POLARDB商用以来，获得了业界人士的广泛关注，也收获了一大批用户的拥趸，让我们看到了自研数据库带来的商业价值和美好前景。在我们回顾过去、分析现在、展望将来的时候，为了更好的理解自主研发云数据库的选择之路，让我们先来看一看IT行业在云计算时代的产业格局。 2. 云计算时代的产业格局 2007年，云计算“Cloud Computing”这个新鲜词刚刚诞生，没有人会想到10多年后，云计算给整个IT行业会带来了如此深刻的产业变革。从10年前IT业界对云计算的犹疑、观望，到如今云计算已经服务于各行各业并逐渐赢得用户的信任。互联网和大数据，可以说对于云计算的变革起到了至关重要的作用。 在云计算服务出现之前，IT行业主要是两极生态，一类是传统IT科技公司，一类是ISV应用和系统服务厂商，在互联网和云计算成为主流之后，IT行业主要呈现出四极生态水乳交融的态势。如上图所示。由于云计算技术的不断融合渗透，四种类型的厂商在经营自己的主营业务的同时，都尝试在其他领域进行竞合创新，厂商之间的边界已经不再那么重要。传统厂商可以提供云服务，云服务厂商也能研发基于云环境的新的科技产品，网络和IT设备商建立全球化的网络，加速和拓展了云服务和云用户之间的连接，而基于云服务的应用服务商，能快速开发出更贴近用户的应用，或者是为企业用户提供的一揽子解决方案。边界一直在打破，传统的竞争被竞合的方式所取代。 原有的IT产业格局发生着巨大的行业变迁，这个变化将影响未来二、三十年的走向。云计算服务商一直在拓展商业服务的边界。亚马逊、阿里云等国内外云厂商一直在拓展基于云计算的商业服务边界，可以看到几乎各行各业都在云计算上开展着自己的商业服务。 其实历史总是惊人的相似，总是重复着各种各样的“变迁“。当20世纪40年代，IBM决定从打孔机、打字机跨界到电子计算机的时候，创始人Thomas·J·Watson也不会想到40年后IBM会成为世界上最大的工业公司。而20世纪80年代，当比尔盖茨还在从事BASIC程序解译器开发推广的时候，谁曾想把购买来的QDOS进行改进后，竟然成为被IBM PC选中的DOS操作系统，进而不断演化出后来的Windows，帮助微软成为软件帝国，市值在2000年左右一度超过6000亿美金。而上世纪60年代末创建于美国硅谷的Intel公司，最初的产品是半导体存储器芯片，1971年，英特尔通过购买专利，生产出世界上第一个通用可编程微处理器，而后在CPU处理器领域逐渐取得霸主地位。时至今日，CPU仍然是云计算时代无可取代的核心技术。1986年，当史蒂夫乔布斯被赶出自己于1976年创建的苹果公司时，他通过购买加州的一家电脑动画工作室跨界成立了“皮克斯动画工作室”在电脑动画领域取得巨大成功。1996年后乔布斯被请回经营陷入困局的苹果公司，并在2000年推出ITunes和iPod向音乐行业融合的科技产品，这个进一步演化出2007年的iPhone智能手机和应用商店，可以说乔布斯开启了互联网的移动时代，是现代IT科技史上最为传奇的人物。 回顾了这么多IT科技翘楚的发展历史，跨界融合无疑是时代演进的主旋律，商业和行业的边界一直在被拓展。对于云计算时代的IT产业格局而言，传统IT厂商一直拓展计算、存储和网络性能的边界。如Intel追寻CPU芯片的摩尔定律，微软追求极致算法的软件性能，谷歌追求信息搜索的性能，高通追求移动计算的性能。ISV应用和系统服务商一直在拓展应用和方案整合的边界。以苹果为代表的的智能手机，特斯拉的智能汽车等，都提供了整合应用创新的极致体验。而网络和IT设施提供和运营服务商一直在拓展网络连接的边界。中国三大电信运营商的通讯服务，华为公司的“网络管道”战略，光环新网、世纪互联、网宿等网络信息服务商等的IDC和内容加速服务，本质都是为了网络的连接无处不在而提供服务。 当四种科技形态在云环境下融合裂变，意味着巨大的思维方式的冲击，也意味着你中有我，我中有你的科技融合。无论是哪一类的科技公司，都将在云计算领域大有作为，如何避免认知的局限和偏见，形成更好的竞合关系。将会引领着资源、科技、服务和应用优势互补相互依存，通过利他而利己形成生态，打破纳什均衡的窘境，创造出更大的价值空间。 3. 什么是云原生数据库 作为云服务厂商，阿里云提供的数据库服务目前主要分为三类，一类是开源数据库（如MySQL，PostgreSQL，Redis，MongoDB，HBase等），一类是商业数据库（SQLServer，PPAS等），还有自主研发的数据库（POLARDB，HybridDB等）。 POLARDB是阿里云自主研发的云原生数据库品牌，它包含关系型数据库（兼容MySQL、PostgreSQL、Oracle等主流数据库）的服务，目前正在商用售卖的是MySQL兼容的版本，其他SQL类型兼容的版本正在开发之中。 云原生数据库是为了更好的服务于云环境下的应用而诞生的，它是一种融合了众多创新技术而跨界的云数据库服务，本质上是云的能力和SQL能力的融合。相比较于传统IT数据库的SQL管理和数据处理能力，云原生数据库还具有以下特征：  SQL in Cloud 在IT时代，传统的计算力（例如用关系型数据库来处理结构化数据等）是服务于系统硬件隔离环境下的多用户使用场景的。而云计算时代是多客户Self-Service租用环境，各种计算负载场景更加复杂，在这种计算负载变迁的环境下，如何解决IT时代的技术产物和云计算时代应用环境的适配矛盾，正是云原生数据库得以融合创新内在推动力。 例如，在公有云环境下，随着用户的增多，以及用户业务和数据的增长，备份、性能、迁移、升级、只读实例、磁盘容量、Binlog延迟等相关问题渐渐显现出来。这背后大部分原因是由于数据本地存储架构导致，亟须通过技术革新以及新的产品架构解决这个问题。 另外云原生数据库能够更好的衔接云上数据ETL以及迁移的工具，形成数据生命周期管理的闭环。 云的本质是弹性，只有实现了计算和存储的Serverless，把云作为一个“Single Image”的操作系统，完全不用关心硬件的单一故障点、性能瓶颈以及可用性，一切交给云来考虑。在这样一个完全透明的云环境下，高性能的运行SQL程序，这是“SQL in Cloud”提供给用户的核心价值。而目前绝大多数云数据库服务，还是“SQL on Cloud”。  产品即方案 云原生数据库的另一个显著特征是，提供满足企业级数据业务服务的解决方案能力，并把这种方案沉淀成产品能力。提供7*24小时的高可用服务，提供读写分离的自适应负载均衡能力，提供故障自动恢复的业务连续保障能力，提供数据存储容量自适应增长的能力，提供计算资源的即时在线扩展能力，还可以跨IDC以及区域实现数据的容灾能力，这些都是传统私有IT机房运行数据库需要通过构建方案才能组建的能力。而云原生数据库从诞生起，就具备企业级数据解决方案的能力。  全托管服务 云计算的全托管服务是指云服务厂商提供了IDC机房建设、资源供应链和部署、监控运维、以及售后服务支持等服务体系，相比于传统的IT数据库购买流程，更加简单快捷，即买即用，又极大的降低了购置成本和后期的维护成本，并且让用户把注意力关注于数据的定义、收集、处理和业务表达上。剩下的资源、性能、维护等等全部由云厂商完成。  普惠科技 云原生数据库的用户，共享的不一定是局限于物理服务器的计算资源，更多共享的是超高速的网络环境，以及具有先进绿色计算环境的IDC机房，还有足够可靠的安全防御体系和设施。在极大的降低了高科技产品的准入成本后，风险与故障成本也被共享分担，云服务商提供SLA协议来保障服务的质量，并对超出承诺的服务故障提供补偿。  从100到200 很多创新的产品都会经历一个从0到1的过程，就如同Peter Thiel在《从0到1》那本经典著作中描述的那样，一些新事物，新的表达方式，和产品新的形态，将经历一个从无到有，破茧成蝶的过程。这个从0到1的过程用来描述云计算早期的形态是非常合适的。然而，云计算服务已经经历近10多年的发展，云服务已经日臻完善，完善的这个过程可以看成从1到100的进程体现。那么云原生数据库的诞生是什么样的一个过程呢?它和之前的云数据库有什么本质区别呢？首先，云原生数据库可以看成是云数据库服务的内在进化，基于云数据库服务多年在技术、产品服务和运维能力的经验积累之上，追求安全、可靠、性能、容量、弹性等全方面的进步。这个进化的过程其实就是从100到200的过程。如果说云数据库是SQL能力（数据库技术）和云能力（Cloud is Computer）的叠加，那么云原生数据库就是SQL能力和云能力的融合。云原生数据库没有直接表现为一个从0到1不同的产品形态，但是内在要求驱动云原生数据库服务在能力、质量、效率各个维度做到超越，而这种超越是基于之前云数据库服务的能力基础上的。 4. POLARDB的融合创新 作为云原生数据库，POLARDB集众多创新技术于一身，并充分利用了最新的IT硬件发展技术，无论是高速网络还是存储设备。采用了自主研发分布式存储引擎设计，计算服务器和存储数据分离的架构，MySQL版本提供100%兼容，性能更快，弹性能力更佳，自带只读节点，数据自适应扩展，存储三副本，秒级备份，提供更高的可靠性。 接下来将着重分析POLARDB的产品架构和技术创新点。关于POLARDB详细的产品功能介绍，请参考官方文档。  POLARDB产品架构 提供高吞吐并发处理能力的POLARDB集群 如图所示，POLARDB产品是一个分布式集群架构的设计。它集众多高级的技术实现于一身，使得数据库OLTP处理性能有了质的飞跃。POLARDB采用了存储与计算分离的设计理念，数据库计算节点和存储节点之间采用高速网络互联，并通过RDMA协议进行数据传输，使得I/O性能不在成为瓶颈。 数据库节点采用和MySQL完全兼容的设计。主节点和只读节点之间采用Active-Active的Failover方式，提供DB的高可用服务。DB的数据文件、redo log等通过User-Space用户态文件系统，经过块设备数据管理路由，依靠高速网络和RDMA协议传输到远端的Chunk Server。同时DB Server之间仅需同步redo log相关的元数据信息。Chunk Server的数据采用多副本确保数据的可靠性，并通过Parallel-Raft协议保证数据的一致性。 多个ECS云服务器可以通过读写分离连接地址，通过自适应负载均衡能力，把请求转发到POLARDB的各个服务节点。 在描述了POLARDB的产品架构之后，我们再分别从分布式架构，数据库高可用，网络协议，存储块设备，文件系统和虚拟化等方面逐一介绍下POLARDB融合使用的如下技术创新点。 分布式共享存储 POLARDB采用自主研发的分布式存储系统，其根本原因是上述的计算与存储分离的需要。逻辑上DB数据都放在所有DB server都能够共享访问的数据chunk存储服务器上。而在存储服务内部，实际上数据被切块成chunk来达到通过多个服务器并发访问I/O的目的。 物理复制 如上图所示，POLARDB通过将数据库文件以及Redolog等存放在共享存储设备上，由于数据共享，只读节点的增加无需再进行数据的完全复制，共用一份全量数据和Redo log，只需要同步元数据信息，这使得系统在主节点发生故障进行Failover时候，切换到只读节点的故障恢复时间能缩短到30秒以内。系统的高可用能力进一步得到增强。而且，只读节点和主节点之间的数据延迟也可以降低到毫秒级别。 双25Gbps高速网络下的RDMA协议 RDMA通常是需要有支持高速网络连接的网络设备（如交换机，NIC等），通过特定的编程接口，来和NIC Driver进行通讯，然后通常以Zero-Copy的技术以达到数据在NIC和远端应用内存之间高效率低延迟传递，而不用通过中断CPU的方式来进行数据从内核态到应用态的拷贝，极大的降低了性能的抖动，提高了整体系统的处理能力。 Snapshot物理备份 Snapshot是一种流行的基于存储块设备的备份方案。其本质是采用Copy-On-Write的机制，通过记录块设备的元数据变化，对于发生写操作的块设备进行写时复制，将写操作内容改动到新复制出的块设备上，来实现恢复到快照时间点的数据的目的。Snapshot是一个典型的基于时间以及写负载模型的后置处理机制。也就是说创建Snapshot时，并没有备份数据，而是把备份数据的负载均分到创建Snapshot之后的实际数据写发生的时间窗口，以此实现备份、恢复的快速响应。POLARDB提供基于Snapshot以及Redo log的机制，在按时间点恢复用户数据的功能上，比传统的全量数据结合Binlog增量数据的恢复方式更加高效。 Parallel-Raft算法 Parallel-Raft是在Raft协议的基础上，针对POLARDB chunk Server的I/O模型，进行改良的一致性算法。Raft协议基于Log是连续的，log#n没有提交的话，后面的Log不允许提交。而POLARDB实现的Parallel-Raft针对非关联数据chunk允许并行的提交，在保证了多副本数据一致性的基础上，进一步提高了并发性能。 Docker容器虚拟化 容器虚拟化的实现相对于KVM等虚拟化技术而言，更加轻量级。如果用户不需要感知整个操作系统的功能，那么用容器虚拟化技术理论上应该能够获得更好的计算能效比。POLARDB采用Docker环境来运行DB计算节点，用更轻量的虚拟化方式，解决了资源的隔离和性能的隔离，也节省了系统资源。 User-Space文件系统 POLARDB采用User-Space文件系统设计数据库服务器专用的API接口，由于不用完全兼容POSIX标准，也无需在操作系统内核进行系统调用的1:1mapping对接，直接在用户态实现文件系统的元数据管理和数据读写访问支持，实现难度大大降低，并且更加有利于数据库服务器和分布式存储系统之间的高速数据传送。 5. 自主研发之路 技术的创新，是需要持续的研发投入，云原生数据库还需要不断解决云用户对于大容量数据处理速度的极致追求，对于云厂商而言，需要跨界，深入研究并借鉴传统数据库厂商在SQL编译、优化器、并行执行计划等方面的技术优势。这是一个充满极度挑战的过程。 云服务是自研数据库最好的催化剂 自主研发创新的背后，是长期苦练内功，厚积薄发的体现，不仅需要长期的研发投入，还需要快速找到商业变现的途径，找到一条能够自给自足的商业模式，并且持续投入到研发之中。幸运的是，云计算的商业模式，以及阿里云目前的数据库服务有能力支撑这种开拓进取的研发成本。已经商用的POLARDB也开始赢得越来越多的用户的青睐，云服务业务的自我造血能力，将支撑自主研发的更多投入，达到良性的闭环反馈。这是自主研发数据库需要解决的首要问题。 自主研发的云原生数据库，利用云计算的商业模式，反哺资源的长期投入，利用后发优势，在数据时代，不断赢得用户的信任。而这些在POLARDB上构建的用户业务需求反馈，也为POLARDB的自身演进提供了方向。我们非常欣慰的看到，在新金融，新教育，新媒体，泛娱乐等互联网+行业应用当中，已经有越来越多的用户正在使用POLARDB创建他们在数字化经济时代的价值传递。而这，正是自主研发数据库存在的根本意义。 自研数据库生于创新 回顾数据库发展史，在这个知识日新月异的TMT时代，听起来有些“古董”，这个起源于半个世纪以前的IT技术，事实上一直处于现代社会科技的核心，支撑着当今世界绝大多数的商业科技文明。CPU、操作系统、数据库这三大核心领域，基本上就是IT时代的缩影，同时也是一切信息化处理、计算力和智能化的基石。从1970年E.F.Codd发表了一篇里程碑论文“A Relational Model of Data for Large Shared Data Banks”，到80年代初期支持SQL的商用关系型数据库DB2，Oracle的面市，以及90年代初SQL-Server的诞生，都是商业数据库成功的代表，而其中Oracle占有绝对的市场地位。 自研云数据库如何应对商业数据库多达上千万行量级的数据库工程实现和复杂度，还有数千人的研发投入，所以云厂商在SQL核心层面的积累还不足以与商业数据库匹敌，唯有创新，尤其是基于云计算环境用户使用模式的融合创新，才是和传统商业数据库差异化共生的有效途径。从长远来讲，用今天来支撑明天。今天的融合创新，本质上是为了明天或者后天的颠覆式创新。不积硅步无以至千里。 自研数据库的挑战 自研数据库在云环境下的融合创新的确能够在云用户的需求引导下进行自我进化和成长，但是对于to B的用户业务来讲，和互联网to C的用户场景有很大的不同。To B的企业级用户在进行选型和判断的时候，更加理性，通常是公司内部多个相关角色集体参与和决策的过程，越是大的B类客户，这个决策的链条更长，参与的角色更多，对于不同规模的公司，具体使用产品的用户身份（Persona）而言也各有不同，有DBA，架构师，研发工程师，甚至是技术总监以及CTO等都会参与到重大的产品和技术选型当中。也就是说，自研数据库本身在根据某些场景的问题提供解决能力的同时，背后还有一个很大的诉求就是，在产品的通用能力（安全、可靠、易管理、多功能、精细度）方面要体现整体能力的成熟度。也就是说一个自研数据库从诞生的那一天开始，需要有一个非常高的标准达到同类产品的成熟度，立足这个成熟度的基础之上，通过提供解决某些场景问题的特定能力，并以此获得客户进行选择的价值认同感和优越感。 结语 在描述了云计算产业的融合创新和边界拓展之后，我们分享了POLARDB的融合创新以及云原生数据库的关键特征。通过实现这些技术创新点并形成完整的产品服务体系之后，在自主研发的道路上我们快速成长。 我们深刻的领会到，连接现实和浪漫情怀以及远大理想的，从来不是诗和远方的田野，而是雪山、草地、沙漠和荆棘。选择自主研发之路，并不是一蹴而就的事情，这是一条“比难更难”的漫长之旅。我们知道，最难的路，才是自我升华最快的路。  “信仰是去相信我们所从未看见的，而这种信仰的回报，是看见我们相信的。”但丁700多年前的这句名言，和今天“因为相信而看见”描述的是同样的价值追求。如果一个企业要活102年，那么这种价值追求将会书写它的传奇，这就是我理解的卓越公司和优秀公司的区别之一。