0

我有动力将一些长文本字符串存储在 OLAP 多维数据集中，长约 1,000 或 10,000 个字符 - 但我想知道这是否会让我误入歧途。（我也很想了解更多关于 OLAP 引擎如何处理字符串的信息。）我想到的特定用例是，我的每个 OLAP 事实都有一个独特的、预先存在的“记录描述”，而且我想将这些描述放在多维数据集中，以便在执行 DRILLTHROUGH 操作时可以选择将它们取回。相反，在进行普通数据透视表/聚合类型操作时，我不需要出现记录描述。（描述太长而无法在数据透视表中合理显示，而且每个事实都有一个独特的描述，这意味着对描述进行聚合是没有意义的。）我当前的数据集大约有 700 个，

我希望如果我将这些长字符串放在一个多维数据集中，OLAP 服务器可以做一些明智的事情。特别是在 Sql Server / SSAS 案例中，我想也许我会将它们放在标记为 ROLAP 的维度中，以节省内存使用，并使用退化维度（在 SSAS 术语中也称为“事实维度”），以避免不必要的 ETL 复杂性。但我很好奇这是否会因某种原因被视为一种可怕的做法，或者是否有任何隐藏的陷阱。

更新：我的示例用例是您有一个与每个 OLAP 事实相关联的字符串。但是考虑一下字符串与特定维度的每个特定值相关联的情况也可能是有益的。（例如，假设您有一个公司维度，并且每个公司都有一个有点长的公司描述字符串。）

4

4 回答 4

3

以下是我能够发现的关于在 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 在将字符串列加载到内存时用空格填充它们。集成服务和分析服务都喜欢物理内存，因此声明比所需宽得多的字符串列是有代价的。”

总而言之，到目前为止，将我的长字符串数据存储在多维数据集中似乎很方便，而且我还没有发现任何预期灾难的原因，所以我正在尝试一下。如果事情没有解决，我会尝试提供更新。

于 2011-12-23T20:31:25.373 回答
1

您可以将值存储在表中，然后创建一个整数代理键。

将整数代理添加到您的 UDM 并创建 SSRS 钻取操作

http://msdn.microsoft.com/en-US/library/ms174526(v=SQL.90).aspx

通过键值查找文本字段。

于 2011-12-31T07:48:17.947 回答
0

还没有完成所有描述的可能性并链接到它，但是 2007 年的这个线程是关于同一主题的，并且似乎非常相关：

http://www.sqldev.org/sql-server-analysis-services/discussion-about-how-to-create-a-fact-drillthrough-dimension-the-best-way-34857.shtml

这里提出的一种新可能性是，与其将存储在事实表中的文本视为退化维度，不如将其视为文本值（相对于数值）度量。最初的谷歌搜索表明 SSAS 可能支持这一点，但有一些技巧可以做到这一点，例如，您可能想要禁用该度量的聚合，您可能需要做一些非标准的事情以使该字段出现在钻取中，并且它可能需要 SSAS 企业版。

于 2011-12-31T23:16:41.213 回答
0

我会使用退化维度，但通过 SSAS 隐藏它，直到通过钻取操作请求。

我无法指导您在 AS 引擎的内部存储字符串，但至于将它们存储在 SQL 中，我会确保您的 varchar(MAX) 列位于列的末尾，以加快 SQL 引擎对这些列的扫描行。

在 700,000 行，有足够的内存和磁盘 I/O 时，您不会对 SQL 产生太多负担。

于 2011-12-23T20:33:33.950 回答