Question

SQL Server DBA如何应对海量数据挑战

Answer 1

如今许多公司都在构建数据仓库，从各种数据来源整合数据，使他们更便于展示。每个数据仓库规模、复杂度和实施都各有不同，但是有一点是不变的：管理和处理数据仓库表比联机事务处理(OLTP)系统需要更多规划和提前思考。让我们来看看，在处理越来越大的数据集市时数据库管理员(DBA)面临的几个挑战。在使用数据仓库时，你会发现那些在小表上执行很快的操作如果没有规划和停顿基本不可能执行了。表锁定操作(比如，重建索引或者增加列)可能会花数小时时间，而不是几秒种。在一些数据仓库中，你可能有比OLTP系统中更长的窗口要维护，但是一旦你习惯了几十亿行级的数据，你就知道这里是完全不一样的玩法。SQL Server中提供了一些功能，让管理非常巨大的表更容易了一些，尽管许多功能只在微软的某些企业版中才可用。例如，重建索引功能支持你在联机模式重建索引，也就是说该表不必锁定，在重建索引时仍然可用。另一个值得了解的企业版功能是表分区。给带有许多索引的巨大表加载数据执行会很慢，因为插入每一行以后索引需要更新。如果你先删除索引再做，你的加载数据过程会更快，但是之后你仍然需要重建索引。当表非常巨大时，你可能每天都在添加数据，重建索引意味着你本质上是在一遍一遍做同样的事情。表分区解决了这个问题，它支持你创建合适的分区(比如，按月，按天，按年和月，按年和周)，可以运行你的分区加载到空的临时表。一旦你的加载完成了，就可以创建与你在主表上相同的索引，并把分区“切换”到主表。在系统后台，SQL Server只修改元数据，临时表变成了主表的一部分。如果你有大于30GB到40GB的表，那你必须严肃处理分区问题。正如你可以切入分区一样，你也可以切出分区，在几毫秒内从一个表中删除数百万行数据。如果你曾经做过以小增量批量删除数百万行数据，你就知道它会花数小时时间，而且会增加你事务日志和日志备份文件的大小。切出分区只是修改一下表的元数据和内部指针。页压缩也可以带来显著的数据查询性能改善。它尤其对那些包含多次出现相同值的数据仓库表有益处。如果你压缩了你的数据页，你会获得两方面好处：你的数据会占用更少的空间，查询将运行更快。你付出的代价是更高性能的CPU，所以要确保测试是否可用并监视CPU的使用量。大部分数据库服务器都有空闲的CPU备用，因为磁盘I/O很容易变成第一个瓶颈。给大表增加非空列可能会需要很长时间。那是因为SQL Server需要扩展每一行，追加一列并给其填充值。表将保持锁定，在大表上操作会花数小时之久。更好的做法是先添加一列允许为空，然后运行处理给该列添加需要的值。做完这些以后，再修改列类型，使其不允许为空。既然数据仓库服务器需要能源，而且通常会有多个处理器，企业授权成本那是相当可观。在一些情况下，你可以使用SQL Server客户端访问授权(CAL)作为你数据仓库的授权。这使得一小部分用户可以直接访问数据。但是一旦你完成了数据加载和CAL服务器授权处理，就可以把聚合数据和报表用表转移到更廉价的SQL Server实例上——比如，标准版或者工作组版——那些是按每处理器授权的。那样的话，你就可以从Web应用程序访问数据了。在构建数据仓库时，DBA会面临几个挑战，但是管理大表肯定是可行的。例如，像联机索引重建，索引分区或者页压缩都是有帮助的策略，通过提升速度并增加这类表的数据库可用性。请记住，这些都是非常巨大的数据量，所以要提前考虑和谨慎规划你的数据加载策略。你的组织可是指望你保证那些数据仓库表可用呢。