问题标签 [columnstore]

我们目前在 Azure 上运行，我们有一个包含数亿行的表。此表是静态的，每周都会刷新。我们查看了 ColumnStore 索引，但不幸的是它还不是 Azure 所以下面是我的问题，

• ColumnStore 索引在 Azure 中是否可用？
• 如果不是，我们可以使用什么其他技术来获得与 ColumnStore 索引相同的性能优势？
• 我们可以使用 Azure 表存储获得相同的查询性能吗？

我是 Azure 和 Columnar 数据库的新手，所以如果我问这些问题，请多多包涵.. :)

假设我们有下表：

和一个查询：

如果 T 由列存储索引索引，则此分组查询通常由非聚集列存储索引扫描驱动。

如果列存储索引以逐列格式存储行，并且每列单独排序，那么它如何一次为每行提供多个列？这似乎是不可能的，因为各个列以不同的排序顺序排序。我想不出任何方法可以将各个列合并回包含两列（本例中为 String1、String2）的整行。

这在内部如何运作？

列存储索引的好处之一是单个列的数据“在磁盘上彼此相邻”存储。这代表更好的压缩和更快的读取时间。

然而; 当使用 B 树（常规的非聚集索引）时，该树的叶子不是数据本身吗？因此，当我在 A 列上创建索引时，A 列的所有字段不会出现在磁盘上与表并行排序吗？这意味着数据可以被压缩并且可以被快速读取。

简而言之：列存储索引何时比单个列上的 B 树更高效？

提前致谢！

我有一个大约 2 亿行和大约 15 列的表。我打算在我的表上创建列存储索引。根据我在列存储索引中使用的列的顺序，性能是否会有任何变化？如果是，其背后的逻辑是什么？

我在测试 sql server 2012 的列存储索引功能时很开心。因为您无法使用此类索引更新/插入表，所以我阅读了一些选项：保留一个单独的表并为每个批量插入使用新分区或禁用索引，执行更新/插入，然后重建索引。

对于我的测试，我选择了后一个选项并最终得到了这个存储过程：

如果我手动执行这些行，一切正常。但是，如果我运行该过程，则会收到无法在具有列存储索引的表上执行更新/插入的错误。

为什么是这样？

更新：

我遵循了我之前接受的答案中的建议，但我仍然得到同样的结果。

甚至尝试在 sproc 调用周围放置“begin tran”和“commit tran”。

使用动态 sql，如：

有效，但实际上，我想在没有动态 sql 的情况下过日子。在这种情况下不可能吗？

我有一个关于数据仓库和面向列的数据库的问题。在我的项目中，该公司在 Visual Studio SQL Server 中使用仓库解决方案，他们在查询大量数据的复杂问题时遇到性能问题。我想尝试用基于列的数据库替换数据库。我知道您可以将面向行的数据库“转换”为更多基于列的数据库，或者使用开源数据库，例如 Vertica 或 Sybase IQ，我只是想知道它如何适合仓库？您是否必须在仓库中有星型连接模式，或者您可以使用列式方法，我意识到这是一个愚蠢的问题，但我只是在开始探索不同的数据库和解决方案之前试图理解它。

提前致谢！

当我们在一个巨大的表上创建列存储索引时，它是使用磁盘上的单独物理存储来存储列存储索引还是将基表的存储结构从行存储更改为列存储。

这里我的问题是，当我们在任何表上创建普通索引时，它使用单独的存储将索引列数据存储到 b-tree 中而不影响基表，就像列存储索引一样？

• （要求）
• 我们需要一个快速且可扩展的解决方案。
• 我们需要更快的方式进行即席查询；

我正在考虑将我的 10 列表分成 10 个表。该表有 100 亿行。

原表ID,VALUE1,VALUE2,VALUE3,VALUE4,VALUE5,VALUE6,VALUE7,VALUE8,VALUE9,VALUE10

10张桌子

• ID,VALUE1（索引在 value1 上）
• ID,VALUE2（索引在 value2 上）
• ID,VALUE3（索引在 value3 上）
• ID,VALUE4（索引在 value4 上）
• ID,VALUE5（索引在 value5 上）
• ID,VALUE6（索引在 value6 上）
• ID,VALUE7（索引在 value7 上）
• ID,VALUE8（索引在 value8 上）
• ID,VALUE9（索引在 value9 上）
• ID,VALUE10（索引在 value10 上）

我的计划是，如果我在 WHERE 条件中有 5 个子句，则转到 5 个表并询问它们，而不是使用哈希集来设置 ID 的子集。

我的问题是我正在重新发明轮子？这是 “列存储 DB By RDBMS ”还是其他什么？

我们（团队）正在为一个大型在线交易网站提供审计报告解决方案。

我们的审计解决方案是在源表上启用 CDC 并跟踪对象上发生的每一次更改，抓取它们并将它们推送到目标表中进行报告。

到目前为止，我们在源 - 目标中得到了一对一的表。

目标中只有插入，没有更新或删除。

因此，最终审计表将比实际源表大，因为这些表会保留更改历史记录。

我的计划是根据主题/模块将目标表展平为更少，启用列存储索引，然后将其用于报告。

对上述方法是否有任何建议或有任何替代方法。

我们的 SQL Server 2012 Enterprise 设置存在性能问题，我无法解释，希望大家有所了解。

我们有一个事实表，其中包含我们聚合的一堆 int 列以及一个区域维度表。

这是我们的事实表的结构：

• regionId (int)
• 收入（十进制 10,2）
• orderIntake (十进制 10,2)

这是我们维度表的结构：

• 世界区域（varchar（100）9
• 集群（varchar（100））
• 国家 (varchar(100))
• regionId (int)

事实表和维度表通过 regionId 列上的 INNER JOIN 连接。只要我们不限制国家，这方面的表现是相当不错的。

例如

SELECT SUM(revenue) FROM factTable f INNER JOIN regionDim r ON f.regionId=r.regionId

速度很快（<1 秒）。

然而

SELECT SUM(revenue) FROM factTable f INNER JOIN regionDim r ON f.regionId=r.regionId WHERE r.country IN ('France','Germany')

对于大约 50 万条记录，速度非常慢（> 8 秒）。

我们确实有以下 indizes：

• regionId 列上事实表上的 ColumnStore 索引
• 维度表上的聚集索引 (regionId,country,cluster,worldRegion)

从索引或整体结构的角度来看，我们有什么可以改变的吗？