【IT168 评测】微软的最新SQL Server版本不仅利用内存表实现了OLTP性能强化，同时对备份以及高可用性选项进行扩展、从而使二者与Windows Azure紧密对接。

　　SQL Server 2014作为该系列的重要升级版本，核心要素分为两点：云与速度——换言之，更具体地讲在于Azure集成与内存内OLTP(即联机事务处理)。实事求是地讲，相较于云、我个人对于速度方面的提升更感兴趣，不过我也理解目前有越来越多的客户开始尝试以云为基础的运营方式、而云功能对于这部分使用者而言可谓至关重要。

　　纵观整个SQL Server家族，我认为SQL Server 2014可以算是自SQL Server 2008 RTM以来最为重要的一个版本。回顾过去，大家可能还记得SQL Server 2008带来的变更数据捕捉、数据压缩以及最为重要的PowerShell等功能特性。接下来的SQl Server 2008 R2则提供用于自助式商务智能的PowerPivot插件、StreamInsight以及主数据服务。SQL Server 2012带给我们的新组件包括Availability Groups、列式存储索引以及数项T-SQL强化。大家可以将SQL Server 2008视为一套数据仓库版本，SQL Server 2008 R2作为商务智能版本，而SQL Server 2012则作为高可用性版本。

　　SQL Server 2014对部分上述功能作出了进一步增强，其中包括Availability Groups、列式存储索引以及安全性(加密备份机制)等等。在今天的文章中，我们将主要关注新版本在云以及性能表现方面的特色。

　　将数据库交由Azure打理

　　SQL Server 2014允许用户通过两种方式使用Azure存储资源。第一，大家可以将数据库备份至Azure BLOB存储体系当中。尽管这项功能(官方将其称为SQL Server Backup to URL)早在2012年就已经出现，但SQL Server 2014利用SQL Server Managed Backup to Windows Azure对其进行了强化——大家也可以简称其为Manged Backup，毕竟在我们的探讨范围中它只会与Azure协作。Managed Backup这个名字取得很贴切，因为它的功能与字面意思一样、确实负责帮助我们管理自己的备份数据。SQL Server会检查我们的保存期限以及事务型工作负载，借此找出哪个时间段最适合进行备份工作——这一切都由系统自行完成，完全无需人为介入。大家也可以在实例层面或者数据库层面对其进行设置，从而切实控制这套指向云端的数据库备份方案。

　　虽然Managed Backup能够帮助我们简化备份策略，特别是帮助那些没有设置全职数据库管理员岗位的小型企业用户，但它仍然存在着一些问题。首先，我们必须认真审查需要通过网络加以传输的数据库数据量。传输能否成功在很大程度上取决于大家的网络连接状况以及外部线路的稳定性表现。在传输过程中，大家可能会间歇性遭遇一些网络性能问题。

　　其次，大家还需要认真考量该功能所带来的资源用量。如果各位的数据库规模太大，或者有人把一套大型数据库存放在服务器上并由系统备份至云端，我们需要的实际用量可能会超出服务协议的规定范围，并因此带来意料之外的大笔存储资源使用成本。换句话来说，对于小型数据库而言，Managed Backup确实是一套足以取代外部磁带存储的理想方案。

　　在与SQL Server的协作关系中，Azure所扮演的绝不仅仅是备份机制这一角色。大家还可以将一套Windows Azure虚拟机定义为Availability Group的辅助副本。对于那些需要可靠的高可用解决方案、但却无力承担用于故障转移的第二座数据中心的小型企业来说，这样的处理方式无疑相当贴心。SQL Server甚至还提供一套向导机制来帮助我们完成安装。不过这项功能存在一些较为严苛的前提，例如需要在内部子网与Azure之间使用站点到站点VPN，因此请大家确保自己的基础设施技术团队在启动整体方案之前把准备工作完成好。

　　另一项值得关注的特性要数Windows Azure当中的SQL Server Data Files。这个名称是不是有点长?我对于这项特性实在没啥兴趣，它的作用是允许用户创建一套内部数据库并将其文件保存在Azure BLOB存储资源当中。这套方案非常开放、因此极易被滥用(某些企业用户可能会将规模庞大且事务型工作负载比例较高的数据库交给云端打理)，不过在特定条件下它也确实能够发挥相当程度的积极作用。

　　举例来说，当我们要在本地服务器上创建一套数据库，我们通常会将数据库文件保存在本地存储体系或者SAN当中。Windows Azure中的Data Files允许大家另辟蹊径，将文件存放在可经URL加以访问的Azure存储位置中。如果各位不愿把数据库文件在不同的服务器之间挪来挪去，那么这套方案的意义还是相当重要的。毕竟数据的迁移常常带来问题，这种不会产生数据往来的作法显然更受欢迎。也就是说，我们不必再为数据库遭遇故障后的恢复工作而担忧，也无需通过网络进行文件复制或者花费数个小时坐等保存在外部的磁带运送至基础设施现场。BLOB存储始终在线，帮助我们免去一切后顾之忧。

　　对于一部分企业用户而言，Windows Azure中的Data Files能够在灾难恢复策略当中发挥重要作用。这是一套真正的混合型解决方案，大家可以对内部SQL Server系统的各个方面进行全面管理，但数据本身的实际存储位置却处于云环境之内。它还帮助我们在无需费神管理的前提下获得了出色的高可用性表现。遗憾的是，它同时也让我们的数据库暴露在互联网的薄弱环节乃至安全漏洞之下。对数据库性能进行故障排查将变得更加困难，因为我们根本不知道问题是出在本地服务器、索引机制、查询还是互联网连接身上。多年以来，我们一直可以通过本地网络实现附加数据库文件，而阻碍这类方案推广的正是性能因素。有一段时间，我甚至开始以为将开放互联网加入基础设施体系会是个好主意，现在看来自己还是图样图森破。

　　满足速度需求

　　时至今日，即使是规模最小的网络业务新兴企业都开始将着眼点放在全球市场，但他们很快发现自己的服务器已经被无数请求所淹没。在性能表现方面，微软在这套最新SQL Server版本中提供了一些不错的特性以应对此类挑战。

　　我们先从SQl Server 2014中的Hekaton开始——我个人认为这可算是新版本当中的旗舰级特性。Hekaton是微软打造的优化内存表：我们要做的就是定义一套经过内存优化的表，Hekaton引擎会自行完成余下的工作。而且与其它内存内数据库解决方案不同，Hekaton允许我们向内存中添加单一表而非强制要求整套数据库。这显然更符合实际业务场景，毕竟我们通常只需要对少数表进行性能强化，而把整套数据库都添加到内存中却只为了强化其中几个表根本不符合资源的优化配置原则。

　　Hekaton之所以能够带来如此显著的性能提升效果，依靠的是对优化算法、乐观并发、消除物理锁定与闭锁以及内存内表存储等机制的结合。如果大家设定了只将面向优化内存表的存储规程，则可以将其转换成Hekaton规程以获得更理想的运行速度。转换过程会将其编译成原生C代码，从而实现执行效率提升。

　　这种转换对于对象类型有所限制，因此大家需要在全面采用这套解决方案之前先对代码进行检查与测试。举例来说，优化存储规程当中不能包含指针、子查询甚至是CTE(即公用表表达式)。这只是这份长长的不支持清单当中的一部分条目，剩下的部分请大家自己做好功课——包括数据库与表的各种要求。鉴于这还是一项全新功能，我相信这些限制将随时间的推移而逐渐解除。

　　强调了这么多关于速度的内容，它的执行速度到底有多快?其效果到底值不值得我们用代码转换来换取?我已经见识过一些令人印象深刻的演示，而且微软的站点实现了10倍到30倍的显著性能增强。具体提速效果取决于多方面因素，但根据我所看到的演示案例以及自己亲手进行的测试，微软方面公布的数据还是靠谱的。实际情况就是，如果大家需要打理高强度事务型OLTP环境并能够满足Hekaton的起效要求，那么各位肯定会它赞不绝口。

　　SQL Server 2012引入的列式存储索引给数据仓库的性能表现带来大幅提升。我个人曾经实际体验过，原本在传统索引中需要耗时数分钟的查询操作在列式存储索引中不到一秒即可完成。列式存储索引的弊端在于其无法进行更新。为了将数据载入到表中，大家必须首先清除这些索引，并在载入完成后另行创建。SQL Server 2014很好地解决了这个问题，如今列式存储索引已经支持更新功能了——干得好，微软。

　　我总是提醒自己团队中的数据库管理新手们用两种方式来解决性能瓶颈：要么降低工作负载强度，要么增加数据吞吐能力。这两种方法显然是从数据吞吐量角度入手，但下面的两项新功能则直接针对工作负载。

　　Resource Governor最终获得了对物理I/O的控制权。对于任何一套给定系统来说，磁盘都是最可能成为性能瓶颈的对象——这是由磁盘天然的机械部件属性所造成。通常来讲，磁盘传输能力之所以跟不上需求，是因为一些流氓查询占据了大量额外的I/O资源。事实上，我就经历过数据仓库的IOPS被查询拉升至数十亿乃至上百亿、最终陷入崩溃的情况。现在大家终于可以把查询的对象指定为资源池，同时限定每个分卷所要面对的I/O上限了。这意味着不会再出现错误查询占用全部磁盘资源的荒谬状况。降低磁盘系统上的I/O总量对于提升整体性能有着极大帮助。

　　专走捷径

　　下面这项功能被称为Delayed Durability，它实际并不会对数据库产生加速作用、但却能让终端用户从使用体验上感受到提速效果。让我们通过典型的事务型负载来进行说明。

　　我们假设终端用户现在需要更新一条记录。更新内容首先被写入到内存中的日志里，而这份日志随后被写入磁盘。在日志记录被写入到磁盘中后，应用程序会识别出事务处理已经完成，这样用户就能继续进行其它工作了。针对数据库的实际更新操作会在之后的时段内进行。现在有了Delayed Durability，应用程序将在日志被写入到磁盘之前就获得事务完成提醒。这意味着终端用户用不着等待日志向低速磁盘介质写入这一相对缓慢的处理过程，即可快速处理其它工作。我发现很多系统中的瓶颈都源自日志处理过程，而Delayed Durability能够很好地解决这个问题。

　　不过正如我之前所说，Delayed Durability本身并不能真正减少工作负载。过去需要完成的任务现在仍然需要被完成。这套数据库引擎只不过以更快的速度将控制权返还给客户端，这样终端用户就能在感受上获得更好的操作体验。这项功能同样可以进行配置——大家可以在数据库层、事务层甚至是原子块层(面向整个存储规程)对其加以控制。不过在使用这项功能之前，请大家务必小心谨慎。如果我们的系统在事务被写入磁盘之前发生故障，那么这部分信息将彻底丢失。这也就是Durability(耐用性)一词的含义：事务是可以恢复的。如果我们降低了耐用性操作的执行优先级以换取更理想的客户端响应时间，就必须作好部分数据可能丢失的准备。

　　最后，SQL Server 2014还带来了一系列安全强化机制。当然，我们现在已经拥有备份加密方案，不过其它新功能的出现直接宣判了第三方备份产品的死刑。这压死骆驼的最后一根稻草正是对象级恢复。此外新版本还提供多种新的服务器级权限——CONNECT ANY USER DATABASE与SELECT ALL USER SECURABLES——它们允许大家以前所未有的简便方式进行安全事务管理。具体来讲，我们现在可以将这些权限一次性指派给全部现有以及未来将要创建的数据库系统。大家不必再随着新数据库的不断加入而重复权限分配流程。

　　SQL Server 2014是个极为强大的版本，其中集合了大量出色的新功能以及对现有特性的强化方案。尽管我个人对于云功能不太感冒，但我仍然对微软在OLTP方面投入的改善努力给予好评，而且相信未来其效果还会进一步提升。Hekaton是这个版本中引入的全新机制，因此大家可以期待其中的部分限制会在未来的子版本中逐一解除。

　　说了这么多，我们仍然没有见识到SQL Server 2014中的全部新功能。哪些项目最值得关注?我个人建议大家了解缓冲池扩展、增量统计以及在线操作优先级锁定管理。这些新功能都会给我们的系统性能带来巨大影响。不过值得注意的是，集成服务、报告服务以及复制功能在新版本中没有得到任何强化;而且尽管T-SQL迎来了小幅改进，但数据库管理员或者开发者的实际工作方式并未发生任何变化。

　　总而言之，SQL Server 2014为我们提供了多种提升性能表现的途径，并允许大家利用Azure云实现备份与高可用性保障。目前面对此类难题的SQL Server用户们，请认真关注这款刚刚面世的新版本。