【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系统的各个方面进行全面管理，但数据本身的实际存储位置却处于云环境之内。它还帮助我们在无需费神管理的前提下获得了出色的高可用性表现。遗憾的是，它同时也让我们的数据库暴露在互联网的薄弱环节乃至安全漏洞之下。对数据库性能进行故障排查将变得更加困难，因为我们根本不知道问题是出在本地服务器、索引机制、查询还是互联网连接身上。多年以来，我们一直可以通过本地网络实现附加数据库文件，而阻碍这类方案推广的正是性能因素。有一段时间，我甚至开始以为将开放互联网加入基础设施体系会是个好主意，现在看来自己还是图样图森破。
