SQL Server 2008在数据仓库方面的价值

最新推荐文章于 2025-01-16 11:31:37 发布

cqpj28160

最新推荐文章于 2025-01-16 11:31:37 发布

阅读量170

点赞数

文章标签：数据库移动开发

今天我和一家为移动开发系统的公司进行交流的过程中讨论到了SQL Server 2008。随着SQL Server 2008 RC0的发布，越来越多的开发人员和企业开始关注这个产品，尽管大家沿用着微软产品的第一个版本不能生产部署的判断，但是SQL Server 2008对大容量数据库的支持确实是很多以SQL Server为数据平台的应用系统带来了不小的福音。

因为我关注SQL Server 2008已经有了一段时间，所以对SQL Server 2008的各项新特性也有了一定的认识，这里和大家分享一些SQL Server 2008在数据仓库方面的商业价值。

Resource Governor

最重要的也是最吸引眼球的应该是SQL Server 2008的Resource Governor，但个人对这项功能的评判为适中。

对于众多中小型企业来说，这项功能确实不错。因为在中小型企业中，通常由于硬件投入的限制，数据仓库并不是常规意义的数据仓库，因为在这些环境中数据仓库通常承担集中数据存储、报表处理分析多项功能，甚至有些企业还在数据仓库服务器上运行交易型数据库，或者将交易型数据和分析性数据存储在一个数据库内。

对于这种环境，Resource Governor无疑是一项非常重要的功能，因为Resource Governor可以有效地隔离不同应用目的的访问载荷。通过为交易型数据操作、分析性数据访问、数据仓库的ETL分配不同的资源槽，可以确保各种应用都可以获得一定的资源而不至于导致一种应用消耗完所有的资源。

数据压缩

这项功能个人认为实用性较强，因为所有数据仓库中最头疼的问题之一就是海量数据对于存储空间和IO带宽的消耗。

通过数据压缩，首先我们可以减少可观的存储空间消耗，同时由于数据压缩带来的IO效率提高也可以有效解决传统存储设备IO带宽的限制。

虽然这项功能需要以处理器资源作为代价，但是毕竟现在主流的PC服务器在CPU和内存方面的成本要远低于存储的成本。想想现在4核处理器的普及以及内存价格的不断走低就可以说明这一点了。

不过传统PC服务器在本地磁盘方面的限制却使得磁盘IO的限制越来越明显，如果要获得更高的IO带宽我们一般都要依赖于相对还是比较昂贵的SAN技术或者外部存储技术，而这些技术和设备代价一般都不菲。

因此通过数据压缩来解决IO带宽确实是那些还没有计划和预算实施SAN的企业的一个解决方案，至少是中短期内一个解决方案。

不过还不止如此，SQL Server 2008中数据压缩功能是可以针对表甚至分区的。因此对于那些混合交易型数据和历史数据的数据库，我们完全可以对不同类型的数据采用不同的压缩方式，例如对于交易型数据不进行压缩以确保这些数据在修改时的性能；对于中期数据采用行压缩来提高数据访问效率和减少存储空间，行压缩也不至于在中期数据由于某些原因需要修改的时候会造成非常昂贵的IO代价；而对于远期数据，由于几乎不需要修改，则可以采用更为高效的页面压缩技术来进一步减少数据存储空间消耗，并最大化IO效率。

因此数据压缩对于数据仓库来说，或者对于混合型数据库来说，应该算的上是一项非常实用的技术。

数据更新跟踪

SQL Server 2008中对数据更新的跟踪其实应该算有两种，一种叫CDR（Change Data Capture），而另外一种叫CT（Change Tracking）。

CDR

CDR技术我觉得还有一些问题，虽然这项技术可以通过日志来析取被更新的数据，这样就可以减少ETL在进行数据版本比较时的代价。

数据仓库中对数据更新的跟踪主要是为了满足ETL的需求，因此CDR要发挥作用就需要配置在数据仓库的数据源，也就是那些交易数据库中。这个限制就使得这项技术的商业实用性有所降低，因为要将交易型数据库升级到SQL Server 2008比将数据仓库升级到SQL Server 2008要困难的多。

不过如果客户的环境中有用到数据集市，那么数据仓库与数据集市间的同步就可以使用到这项技术。毕竟，将这些分析型数据库升级到SQL Server 2008要相对简单一些。

还有一点，CDR技术虽然可以提供交易的完整信息，而且其通过日志析取操作历史可以减少源数据访问争抢，但是这个方案需要在交易型数据库上实施。如果有人想在数据仓库上实施这个CDR，那么就完全没有必要了，因为数据仓库的更新通常都是批量的，没有必要考虑其数据更新操作的原始性，我们只要知道哪些数据被更新了以及这些数据的当前状态，而不需要知道数据更新的完整过程。

CT

CT技术在SQL Server 2008中的定位其实不是用于ETL，而是用于数据同步的，这也使得其记录的信息不如CDR记录的完备。CT技术之通过数据行的唯一主键来告知我们那些数据行被修改了。

不过这项技术如果用于多维数据库以及数据集市与数据仓库之间的同步确实是一个相对廉价的技术方案。在多维数据库以及数据集市中如果实施了分区，那么配合CT技术我们就是非常简单地判断出那些分区需要刷新数据，这样就可以减少对多维数据库和数据集市进行全量刷新的需要。

另外一点需要申明的是，CT技术与原来很多系统中利用触发器跟踪数据更新这种方案最大的区别就在于，CT是异步的，因此它对交易并发能力的影响要减少很多。

因此，如果有需要在数据仓库、数据集市以及多维数据库之间同步数据的，CT技术可以列入被选方案中。

稀疏列及筛选索引

这两项新特性在数据仓库中也是非常有价值的。

数据仓库中存储的许多维度表都有列数众多但是值非常稀疏的情况存在。我见过物流应用和零售应用中的商品信息、CRM应用中的客户信息都需要在数据仓库中存储成百上千的属性列，而这些信息中的大多数的数据实例都不会拥有完整的信息，例如在零售的数据仓库中，衣服会有颜色、款式、尺寸这样的信息，而食品则为有包装规格、口味、生产日期等信息，电子类商品则会有型号、能耗等信息，软件类产品则由版本、硬件要求等信息。

稀疏列对于在一张表中维护一个维度所有属性的要求可以很方便的满足，数据仓库的设计人员再也不需要精心设计各种附加属性表了。因为稀疏列最多可以在一张表中支持上万列，对于几乎所有的商业应用来说，一个维度上万的属性应该是足够了。

如果客户使用了稀疏列，那么筛选索引就必不可少了。因为稀疏列一旦应用，就会出现表中大多数字段在大多数数据行上NULL的，比如说食品、电器、软件在口味这一列上就都是NULL的。那么如果客户需要在口味列上创建索引，将这么多的NULL值编入索引是毫无意义的，筛选索引就可以帮我们避免这种无意义的行为。

不过，这项技术也只是对新数据仓库会有非常大的意义。如果客户的数据仓库已经投入生产环境，那么这两技术的应用代价还是比较昂贵的，因为这就意味着我们修改表结构，要修改ETL、报表、多维数据库的设计。

其他技术

SQL Server 2008中对于数据仓库的改进还有其他一些功能，但是这些功能相对革新不大，因此就放在一起说。

日期时间

SQL Server 2008中对日期数据的改变是支持仅日期和仅时间的数据类型，还有将日期时间的精度扩大到了100纳秒。仅日期和时间的新数据类型可以帮助我们减少日期时间在数据仓库中存储的歧异性，不过想到这些数据类型需要使用特殊的.Net类来访问，相比很多开发人员就会有些犹豫了。对于100纳秒的精度，大多数商业应用是不需要的，对于一些自动化控制的应用来说，这个精度倒是会让人为之一振。

Minimal Logging

这项技术对数据仓库来说有些...，因为大多数数据仓库的数据载入确实都是BULK LOAD，如果将数据仓库的还原级别设置为简单，这项技术就没有多大意义了。

分区并行度

这项技术不错，对于现在主流的多内核处理器，对分区表访问执行计划并行度的改进可以明显提高访问效率，而且这项技术是产品的内置特性，对现有应用不会产生任何影响。

MERGE

这个新的DML语句可以减少ETL代码的复杂度，而且在某些情况下也可以提高执行效率。

SSIS中的Data Profiling

这个新的任务流作业模块可以减少我们对数据质量校验的设计复杂度，不过个人觉得这个模块还有些粗糙，因为它要配合脚本代码对校验结果进行分析。幸好微软已经提供了范例脚本。

LOOKUP转换

SSIS中支持LOOKUP模块缓存数据的持久化可以说也是一项值得期待的特性，因为对于大多数数据仓库来说，执行查找操作的引用数据集一般都比较大，PC服务器那点可怜的内存非常容易被轻易耗尽。持久化后的缓存数据无疑可以提高LOOKUP抓换的效率。

EDM和LINQ

呃~~~这两项就不多说了，虽然这两项技术都可以减少关系型数据在应用开发中进行表达和访问的复杂度，但是对于数据仓库来说没有这个必要。因为数据仓库的设计应该本来就已经相当偏向于业务描述了，至少数据集市和多维数据库一定是，所以没有必要用这两项技术来访问，而且这两项技术对于大量密集的数据访问载荷来说，性能还是堪忧的。