【问题标题】:Tableau Reading Data: Which table type is better?Tableau 读取数据:哪种表类型更好?
【发布时间】:2017-03-05 05:24:14
【问题描述】:

当 Tableau 通过 SQL Server 连接到数据表时,使用 Tableau(只读程序)有什么表现更好(什么返回查询更快)?连接多个又高又瘦的桌子还是一张又短又宽的桌子?

又高又瘦的桌子有很多行但很少有列并且是连接的。短而宽的表行数较少,但列数较多。

我相信 tall 和 thin 选项返回查询更快,因为冗余数据更少、列更少(创建更快的索引)、更少的 NULLS 和更少的索引(因为列更少),但我至少需要第二个意见,所以请告诉我你的。

我对这个问题感兴趣的原因是为了提高我们的客户在向我们的服务器查询数据以呈现其可视化效果时的查询性能。

【问题讨论】:

  • @Mihai 已编辑问题。希望它更容易理解。让我知道是否需要进一步解释。另外,我知道桌子不分为薄和宽。我的例子是询问我是否应该有 1 个宽和短的桌子(士气低落)或者我应该有多个规范化的桌子(又高又瘦)。让我知道是否需要进一步解释。

标签: sql-server indexing tableau-api tabular


【解决方案1】:

这在很大程度上取决于您要达到的目标。对于某些应用程序,最好使用较少的条目和许多字段,而对于其他应用程序,最好有许多条目和较少的字段。

请记住,Tableau 与 Excel 或 SQL 不同,这意味着您应该将数据操作保持在最低限度,因为某些计算在 Tableau 中不容易/不可能完成(有些是可能的,但涉及导出数据并重新连接到它)。 Tableau 应该主要用于数据可视化目的

另外,在同一张图表中比较不同的度量是非常麻烦的。这意味着,如果您想比较 sum(A) 和 sum(B),您必须绘制 2 个不同的图表(并且不要将两者放在同一个图表中)。我发现拥有少量度量字段和大量维度会更容易。这样我就可以轻松地对度量进行切片/比较。在最后一个示例中,我将有 2 个条目,而不是具有 A 和 B 度量的 1 个条目,一个具有 A 度量和一个维度(说正在测量的是 A),另一个具有 B 度量和一个维度(在同一分别是字段)

但这并不意味着您应该始终使用“高瘦桌子”。您需要了解您想要实现的目标以及哪种格式更适合您的需求(以及 Tableau 设计)。除非您正在处理非常大的表,并且您的分析每天(或实时)进行多次并且性能是一个非常大的问题,否则您应该专注于让您的生活更轻松的事情(特别是当您必须改变和稍后调整分析)。

为了提高性能,我在 Tableau 中遵循 3 条规则:

1) 始终提取(数据到 tde) - 它比大多数其他数据库格式快得多(我没有全部测试,但直接连接的 csv、mdb、xls 或 SQL 更快)

2) 永远不要使用 Tableau 链接 - 除非它不影响性能(例如,低范围字段的命名法),否则最好将所有信息都放在同一个数据库中

3) 删除 thrash - 将所有可能的信息都保存在数据库中非常吸引人,但它也以性能为代价。我尽量只保留分析所需的信息,以保持我需要的灵活性限制。过滤数据是可以的,将过滤器放在上下文中更好,但在数据提取或数据源本身进行过滤是最好的解决方案

【讨论】:

  • 感谢您的帖子。我同意你所说的。另外,我不是在处理来自 Tableau 的数据。我只是在用 Tableau 读取数据。此外,当客户在我们的数据库中查询数据以进行 Tableau 可视化时,性能是我试图解决的问题。最后我同意你的建议。数据提取帮助和删除数据提取中所有未使用的字段大有帮助。
【解决方案2】:

经过大量研究,我找到了一个普遍的答案。通常,特别是对于 SQL Server 和 Tableau,您希望引导对表进行规范化,这样可以避免冗余数据,因此,您的表需要扫描的数据更少,从而可以更快地执行查询。但是,您不希望将表规范化到表之间的连接实际上导致查询比仅将查询发送到一个又短又宽的表时花费更长的时间。最终,您只需要进行测试,看看多少规范化/非规范化最适合最快的查询返回。

【讨论】:

    猜你喜欢
    • 1970-01-01
    • 2010-12-29
    • 2016-11-24
    • 2011-12-17
    • 1970-01-01
    • 1970-01-01
    • 2012-02-16
    • 1970-01-01
    • 2014-10-22
    相关资源
    最近更新 更多