Stretch数据库（简称StretchDB）是即将发布的SQLServer 2016中的新特性，它支持数据库一部分存在于内部环境，另一部分存在于Azure SQL数据库云服务中。企业使用StretchDB可以“延伸”其内部部署数据库到云端，比如“热”数据可以存储在本地部署的SQL Server实例中，而“冷”数据很显然可以存储到Azure中。

是什么原因导致我们需要把一部分数据存储在本地，而另一部分存储到云端呢？企业级存储代价是非常昂贵的，所以我们把经常使用的数据放到本地高性能存储阵列中是有意义的，而可以把很少访问的数据放到不太昂贵的存储中（如图1）。或许，组织迈向云端的第一步就是把备份数据放到云环境中，或者使用云服务作为灾备策略的一部分（有AlwaysOnAvailability Group Replica支持）。

图1：热数据和冷数据被分别存储在本地SQL Server和Azure数据库中。

StretchDB正是解决是否要删除数据这种困境的利器

一些组织喜欢删除那些很少使用的旧数据（如果有的话），但是可能会有一些法规或者业务需求不允许这么做。一些组织把旧数据以不同的格式或应用归档，但是访问这种过时的冷门数据就很困难了。通常，业务负责人不想归档，因为业务需要或者法规需要希望一定量的历史数据保留。这种组织的默认行为是把这些数据永久保留。SAN管理员总是在想办法增加存储容量和性能。他们的默认做法似乎鼓励删除或者把数据归档。数据库团队通常总是处于这两者之间的激战之中。

StretchDB正是解决这种困境的利器。目前，组织可以在表一级别进行选择，或者启用“远程数据归档”选项；该设置是针对表一级别的，分区级别区分还不行。目前两种方案都是针对StretchDB的第一次迭代（如图2）。第一个场景是数据库中已经有归档表，你可以延伸它。第二种情况是单个表混合存在热数据和冷数据，数据的区分是组织基于制定日期或者某一列定义的（比如“归档”字段标识）。

图2：查询如何处理。

这么做不只是把数据放到云端纯粹存储那么简单。如果是这样的话，数据不能查询返回，那么远端存储数据就不会带来太多价值了。有了StretchDB，通过Azure SQL数据库的计算资源就可以过滤数据，处理向云端的请求。

使用StretchDB不需要修改应用

在本文发布的时候，单个Azure数据库的容量限制为500GB。这个容量限制在未来基本上是肯定要增长的，尽管未来也仍然会有一个上限。但是StretchDB可以利用分片绕过容量限制。微软公司指出，这样可以扩展Azure后端，显式提供给用户使用，支持他们延伸尽可能多的数据，满足需要。如果一个表做了延伸，资源管理器还可以部署实现最小化数据迁移，节约流量消耗。这一点对于网络成本已经达到峰值或者非峰值速率的情况很有用。

StretchDB功能特性

StretchDB包括以下功能：

• 冷数据永远在线可用
• 显著降低存储总拥有成本TCO
• 低成本计算
• 可以利用现有应用访问冷数据
• 更容易维护性能和索引
• 更快的备份和恢复
• 自动管理和保护冷数据

在新版本SQL Server发布的时候，通常会有一些新特性会相对容易实施，而且不需要应用做修改。这本身就是一种特性。SQL Server会判断数据是本地访问还是远程访问，从而采取合适的处理。正如其他任何功能一样，这些新特性也需要有一些设置，但是操作的步骤已经最小化了。在备份和恢复方案已经最小化了数据传输和备份存储的工作。DBA使用的维护脚本都不需要修改。查询也不需要修改，因为优化器足够智能，可以对访问云端的冷数据相应做不同的执行计划。

此时此刻，StretchDB仍然在开发中。目标是将局限性最小化，但是通常新特性的第一轮迭代将会有一些基本的限制，比如延伸表中会有一些数据类型可能不支持。

公司可以更有效地管理存储成本

要注意的是，远端数据我们称为冷数据。一旦数据延伸到Azure后，如果数据需要删除或者修改，这就需要有管理功能了。数据的修改会影响备份和索引。很明显，因为数据在远端，所有在访问冷数据时会有延时。查询处理器是足够智能的，他可以理解数据是在本地，还是远端，或者是两者兼而有之。

StretchDB使组织可以更有效地管理存储成本，把热数据放在本地，而把冷数据放到云端。客户可以定义哪些表包含有冷数据，可以整个表处理，也可以按条件过滤（比如按指定日期数据项或者按注入“归档”列之类的标识字段过滤）。StretchDB功能对用户和开发者都是透明的，不需要修改代码就可以利用到改功能。即使脚本和维护任务也不需要修改，因为SQL Server足够智能，它自己可以知道哪些数据在本地，哪些数据在远端。StretchDB是在单个数据库内利用本地和远端资源混合策略的一个最好的例子。