0

这是我之前的一个问题的后续，在明确决定将分区切换作为快速将数据放入需要保持对读者可用的大量索引的事实类型表中的最佳方式之后。

虽然这似乎是最好的方法，但它还不足以真正满足允许多个（< 5）用户同时批量插入、索引新数据并出现在索引视图中的要求（不是必须是真正的索引视图，只是选择依赖于索引的视图）。

分区的想法是每个分区和以分区为根的索引子树可以并行锁定为只读，复制到工作表中，插入/更新新数据并重建索引，然后切换回主表所以读者不受影响。

问题是单个工作台。每个并行批量插入都需要自己的副本，具有与主表相同的约束以允许切换。

到目前为止，我已经遇到了几堵墙，试图绕过这个瓶颈：

  1. 我尝试使用相同的分区函数对工作表进行分区。这不起作用，因为您不能在分区基础上禁用索引以插入其中，同时在另一个上重建索引。
  2. 创建一个临时表作为工作表。这不起作用，因为虽然您可以使用相同的索引名称，但您不能轻松地动态创建约束并且无论如何都不能切换它。
  3. 有一组固定的命名工作表吗？如何选择一个并在别名下使用它，以便我只有一个存储的过程？
  4. 动态SQL？我已经非常努力地避免走那条路。这很复杂。

挑战很大，但在我接受瓶颈之前有人有什么想法吗？Sql 2012 会有帮助吗？适当的数据仓库如何应对这个问题？

4

1 回答 1

3

适当的数据仓库如何应对这个问题？妥协并为 EDW 设定切合实际的目标。数据仓库不可能是所有人的一切。确保您正在实施的是最适合业务的解决方案（不仅仅是技术人员/分析师）。如果您无法从经验丰富的同行和专家那里找到解决方案，您的目标是否现实？

将成本与您跳过的所有环节联系起来。数据真的需要最新吗？如果我告诉您，我们需要在存储上再花费 200,000 美元，因为我们不断地复制分区和重建索引，而当前的解决方案无法满足 IOPS 需求，该怎么办？在某个时候，他们会发现它不是免费的。虽然您不需要只是说不，但您确实需要对相关成本保持现实和坦率。此外，您的存储管理员会感谢您。

至于 2012 年，有一个新的列存储索引可以减少或替换您当前用于覆盖所有分析师搜索请求的所有非聚集索引。它是高度压缩的，涵盖了非常广泛的搜索参数，并利用了新的批处理执行模式。它在低选择性查询（例如经常在事实表上执行的查询）上表现最佳。一个问题是您不能直接进行更新。您必须将分区切换到临时表，将列存储放到临时表上，更新临时表，重新添加列存储，然后将分区切换回事实表。这听起来很多，但可能比维护所有这些非集群要快得多，并且需要更少的 IO。

我的问题一直是“如果它不断变化，它真的是一个事实表吗？”。这不是OLTP吗？尝试抵消交易或至少将所有更新推送到预定的非高峰时间。更新事实表已成为过去。所有的大男孩都在朝着“不赞成更新”的面向列的数据仓库架构发展。PowerPivot 和 Analysis Services 表格模型基于列存储技术构建。

最后，查看 Kimballs 的 DW Toolkit 书籍。他有几个列出最佳实践并涵盖边缘情况的案例。我从他们那里学到的是，数据仓库开发不仅仅是兴奋的数据库开发。它还涉及政治和将资源集中在对企业最有利的事情上。

于 2012-10-20T05:33:14.370 回答