问题标签 [columnstore]

有人可以用一个非常基本的 SQL 示例解释理论上的冗余如何影响数据压缩吗？在网上阅读，在我看来，更多的重复项会更好地压缩。但我不知道怎么做。

我试图查看列存储索引可以在表上提供的那种性能提升。该表大约有 370 万行、11 列，并存储为堆（即没有主键）。我在表上创建一个列存储索引并运行以下查询：

创建表语句如下：

在这种情况下，我从列存储索引获得的性能提升可以忽略不计。使用列存储索引的查询几乎与没有索引的原始查询一样慢，在某些情况下甚至更慢，即使也使用了批处理模式。

令人惊讶的是，当我在现有表上创建一个不断增加的主键 ID 并重建列存储索引时，CPU 时间提高了 15 倍，运行时间提高了 3 倍。

我不明白添加主键如何影响列存储索引的查询性能，列存储索引无论如何都以压缩格式存储数据。此外，主键只会改变页面的顺序，在这种情况下，不会改变。

下面是执行计划

以下是解释我的表格和情况的链接：

为什么表上存在主键会显着提高列存储索引的性能？

在比较这两种情况时，一种是使用列存储索引运行查询，另一种是在简单堆上运行查询。当我比较这两个结果时，我观察到即使使用列存储的查询比另一种情况执行得更好，但只是在堆上运行。但是，使用列存储索引的查询涉及物理读取（1），而原始的不涉及。

这两个查询具有相同的执行计划。此外，我在暖缓冲区和冷缓冲区中都运行查询。在冷缓冲区中，原始查询需要 4 次物理读取，而在警告缓冲区中，它需要 0 次物理读取。然而，使用列存储索引的查询行为保持不变。这背后有什么特别的原因吗？

在加入列存储索引表时，有什么方法可以说服 SQL Server 2014 进行联接消除？

我们有一个标准的维度模型，带有事实表和维度，并且为了方便用户，还有一些视图将事实与它们的多个维度结合起来。

当使用传统的行存储表时，我们可以利用 SQL 的能力来消除那些方便视图中的连接，如果它们对于给定的查询不是必需的，因为事实和事实之间定义了 FK/PK 关系。允许查询计划器确定连接不会添加或删除行的维度。

但是，我们希望将事实表转换为列存储，因为它们对于通常在数据集市上完成的聚合查询类型具有巨大的性能改进。但是如果这样做，我们将失去定义外键的能力，因为列存储不支持它们。反过来，这会阻止规划器进行联接消除，从而使便利视图在许多情况下进行大量不必要的联接。

有没有办法说服计划者在不使用外键的情况下进行加入消除？

我有兴趣研究 memsql 中的列式存储。我正在尝试创建柱状表。我使用的查询是，

但是查询在clustered columnstore. 我不知道是什么导致了这个错误。

数据库中索引的工作方式：参考 Xenph Yan 的答案

在表中的字段上创建索引会创建另一个数据结构，该结构包含字段值和指向与其相关的记录的指针。然后对该索引结构进行排序，允许对其执行二进制搜索。

我理解 ORC 索引的方式是，ORC 每 10'000 行（默认情况下）保留有关行的统计信息（最小值、最大值、总和），如果我查询数据，它会查看统计信息以确定是否需要读取行块与否。

那么ORC索引不对数据进行排序是否正确？

我有一个 69 列的大表，其中包含非常非结构化的数据，我希望能够对每一列执行临时查询。为此，我希望能够通过索引（或至少其中大多数）对每一列进行排序。快速查询的数据中没有“关键”列。

我们目前正在运行一个 4 节点集群（3 台 8GB 机器和一台 4GB RAM），同时尝试在其自身上运行表的左外连接（约 7.5GB）。表中很少有字段存储为列存储。查询的结构有点像：

有任何想法吗？

我真的明白现在问这个问题还为时过早，但我有一个类似于我想在此基础上创建的POC要求。

如何实施运营分析SQL Server 2016？我知道我已经columnstore index在 In-Memory 表上创建了。但我不确定报告包。如何实施实时报告([demo][1])？我可以实施SSRS吗？还是我需要任何其他报告包（可能与天蓝色有关）

参考

我已经在 AWS 的 Ubuntu 服务器上运行的 CitusDB 安装上成功配置了 cstore_fdw。

我尝试在我们的一台运行 CentOS 6.5 的客户端服务器上安装它。我可以安装它但不能执行COPY命令。

是否有任何关于在 Citus 中使用COPY基于 cstore_fdw 的表的文档？

我有一些表，其中两个有大约 100 万条记录。在一个过程中，我使用了这些表，大约需要 5-10 分钟来获取大约 25,000 行。

我创建了一些聚集索引和非聚集索引，执行计划显示都是聚集索引查找或非聚集索引查找。但是该过程仍然需要超过5分钟才能执行。

所以我尝试创建列存储索引但仍然没有改进。

各位大佬，有没有大神给点建议啊。我需要如何创建索引以及哪个更好列存储或普通聚集/非聚集索引