以下是我能够发现的关于在 SSAS 中存储此类字符串的影响,尤其是在 SSAS 2008 中。在我考虑数据结构的地方,它完全专注于 MOLAP 存储,这是我一直在试验的。
首先,像 Business Intelligence Development Studio 这样的标准 MS ETL(提取/转换/加载,即数据导入)工具可能会尝试阻止您导入大型文本字段,尤其是 varchar(max) 字段,但有一种解决方法,并且已被证明对我。(对于 BIDS,它涉及手动设置 XML 文件中的 DataSize 元素,可能设置为 163315555 字节的神奇大小。感谢Matija Lah解决这个问题。)
其次,据我所知,存储大量长而独特的字符串不应该对 SSAS 使用的磁盘数据结构造成严重破坏。此外,磁盘上的字符串数据的大小应该与数据源中的字符串数据的数量级相同。以下是有关 SSAS 处理字符串的一些粗略信息:
- 核心 OLAP 数据结构(例如,对于维度的属性,或对于度量组的事实)不直接包含字符串;而是包含“字符串存储”文件(扩展名为 .ksstore、.asstore、.bsstore 或 .string.data)的偏移量,这些文件包含实际的字符串数据。
- 在给定的字符串存储中,每个字符串仅表示一次。如果源数据表中的几行包含重复的字符串,那么在 SSAS/MOLAP 级别,这将转换为重复的文件偏移量,而不是重复的字符串值
- 如果您的源字符串长度为 n,则字符串存储中的相应数据结构具有 8 个字节的开销,加上每个字符 2*n 个字节。(字符串在 SSAS 中固有地以 2 字节 Unicode 格式存储。)
- 对于这些东西的一些奇妙的细节,我推荐这本书Microsoft SQL Server 2008 Analysis Services Unleashed,特别是第 20 章,“物理数据模型”。
- 至少在我的实验中,字符串存储文件似乎没有被压缩——至少它们并不比未压缩的字符串存储小得多。
我已经通过实验验证,无论是存储在 SSAS MOLAP 还是 sql 表中,文本数据都采用相同数量级的字节。特别是,我从我的一个维度表中执行了“从 mytable 中选择 sum(len(myfield))”,然后与我的 SSAS 数据目录中相应属性文件的大小进行比较。SQL 中的大小为 172MB,SQL 服务器中的大小为 304MB。(如果我将所有唯一值相加,则 Sql 大小为 147MB字符串,而不是所有字符串。)在我的情况下,大小差异主要由字符编码来解释;我的源 sql 数据以每个字符一个字节存储,而 SSAS 以每个字符两个字节存储所有字符串。我发现 .kssstore 文件在大小上完全支配了与此属性关联的所有其他文件,无论我是否通过 AttributeHierarchyOptimizedState=FullyOptimized 优化了该属性。
第三,字符串存储文件的大小上限为 4GB,这限制了可以与特定维度/属性相关联的唯一文本的数量。就我而言,我还不到极限的 10%,但这可能会影响某些人。(原始帖子的快速数量级计算:1M 事实 * 10,000 字节/每个事实 = 10GB 左右的文本。)如果你确实达到了这个限制,你显然会在立方体“处理”时间达到它。显然它甚至适用于 ROLAP 维度。可能有一些技巧可以解决这个问题。见这里。请注意,Sql Server 2012可能会取消此 4GB 限制。
第四,如果长唯一字符串在 SSAS 中产生问题,它们似乎是在内存表示级别上这样做的。一个潜在的问题(我没有详细研究过)是,将这些额外的字符串缓存在内存中会使 SSAS 无法将其他重要的数据结构保存在内存中,从而降低性能。The Microsoft Data Warehouse Toolkit一书提出的另一个问题(尽管我还没有在其他地方找到这个说法)是 SSAS 在其内存数据结构上做了一些扩展的字符串填充:
“关系数据库存储可变长度的字符串列......但是,SQL Server 工具集的其他部分会将这些列填充到它们的全宽。值得注意的是,Integration Services 和 Analysis Services 在将字符串列加载到内存时用空格填充它们。集成服务和分析服务都喜欢物理内存,因此声明比所需宽得多的字符串列是有代价的。”
总而言之,到目前为止,将我的长字符串数据存储在多维数据集中似乎很方便,而且我还没有发现任何预期灾难的原因,所以我正在尝试一下。如果事情没有解决,我会尝试提供更新。