大规模 ETL 字符串查找性能问题答案

【问题标题】：Large scale ETL string lookups performance issues大规模 ETL 字符串查找性能问题
【发布时间】：2009-09-14 14:36:13
【问题描述】：

我遇到了 ETL 流程性能问题。我有一张表，里面有 4+ 十亿行。结构是：

id 上的聚集唯一索引和 md5hash 上的非聚集唯一索引

SQL Server 2008 企业版页面级压缩已开启

我们必须将来自网络服务器日志的原始 URL 存储为一个维度。由于原始字符串 > 900 个字符，我们不能在该列上放置唯一索引。我们使用 md5 散列函数来创建唯一的 32 个字符的字符串以用于索引目的。我们不能在表中允许重复的 raw_url 字符串。

问题是性能不佳。 md5hash 本质上当然是随机的，因此索引碎片驱动到 50%，这导致 IO 效率低下。

寻求有关如何构建它以实现更好的插入和查找性能以及更少的索引碎片的建议。

【问题讨论】：

【解决方案1】：

我会将表分解为物理文件，将较旧的不变数据放在只读文件组中。确保非聚集索引也在文件组中。

编辑（来自评论）：在我考虑的时候，如果你关闭页面级压缩，那也会改善 I/O。

【讨论】：

顺便说一下，非聚集索引中的 MD5 散列不应该对页面拆分造成那么大的问题。
我们在处理机器上有 24 个 CPU，因此在这种情况下，页面级压缩实际上减少了 IO 开销，并且我们只会稍微增加 CPU 利用率。值得权衡。此外，作为随机字符串的 md5hash 会将索引碎片率提高到 50%，因此如果我们在索引上使用 50% 的填充因子，我们没有太多的分页方式，但我们确实有 1/2 为空增加 IO 开销的页面
第一次构建索引时，会有 I/O 开销，但我不明白从长远来看这是个问题吗？我宁愿拥有空白页面，也不愿在 INSERT 上进行页面拆分。你看过文件组吗？
建立MD5哈希索引需要多长时间？
我们正在使用一个文件组，其中有许多数据文件分布在 Complellent SAN 上的控制器上。我不记得创建原始索引需要多长时间，但需要几个小时。我们确实保留了索引，而不是因为重建它的时间而删除和重新创建它。

【解决方案2】：

我认为它应该是事实表中的退化维度。

并想办法对数据进行分区。也许取前 xxx 个字符并将它们存储为一个单独的字段，并以此进行分区。然后，当您进行查找时，您将传递短列和长列，因此它首先在分区中查找。

【讨论】：

对于分区功能，我认为你只能使用md5的前2个字符。使用更多将导致超过 1000 种可能的组合。即便如此，您仍会将 1 个未分区索引拆分为 256 个较小的索引，从而允许在重建和插入时进一步并行