标签: columnstore

首先，我不是在问什么。我不是问我的设置应该是什么。

许多人建议将值提高到超过默认值，我当然理解为什么基于 B 树的查询会出现这种情况。但我一直在阅读有关内存中聚集列存储索引的（几乎）线性可扩展性，我想知道将成本阈值设置得太高是否会导致 SQL Server 使基于列存储的 CPU 内核查询饿死。

所以问题是：当涉及到“并行成本阈值”时，​​SQL Server 是否会以不同的方式对待列存储索引，这是否会导致我改变关于初始设置应该是什么的决定？

我想搭建一个类似Google Analytics的系统（仅供内部使用，流量少，功能少），主要关注

1. 通过不同维度的用户人口统计信息，例如用户代理、操作系统、国家等，实时统计唯一的 URI 访问/PV

2. 实时计算平均用户会话长度（如果来自同一IP的两个请求之间的差异小于1分钟）

有没有好的数据库存储可以实时启用这种查询？

ps 我目前正在测试 InfiDB。

BIT列在聚集列存储索引中使用时是否提供任何性能优势？例如，我对在 CCI 中定义列BIT而不是 所获得的任何性能优势感兴趣BIGINT。我正在使用 SQL Server 2016。

我对 CCI 压缩的工作原理知之甚少，但根据我所阅读的内容和一些测试，似乎数据类型（仅限于存储整数的精确数字）在列存储压缩方面确实无关紧要. 例如，如果我将 10 个完整的行组插入到带有BIGINT列而不是BIT列的表中，我看不到压缩行组之间的大小差异。以下是一项测试的源数据：

DROP TABLE IF EXISTS dbo.CCI_BIT_TEST_SOURCE;

CREATE TABLE dbo.CCI_BIT_TEST_SOURCE (
    ID1 BIGINT NOT NULL,
    ID2 BIGINT NOT NULL,
    ID_BIT BIT NOT NULL,
    ID_BIGINT BIGINT NOT NULL,
    INDEX CCI__CCI_BIT_TEST_SOURCE CLUSTERED COLUMNSTORE
);

INSERT INTO dbo.CCI_BIT_TEST_SOURCE WITH (TABLOCK)
SELECT
  t.RN
, t.RN
, t.RN % 2
, t.RN % 2
FROM
(
    SELECT TOP (10485760) ROW_NUMBER() OVER (ORDER BY (SELECT NULL)) …

问题与this one类似，但答案似乎没有回答这个问题。

我对聚集列存储表的理解（如果我错了，请纠正我）是每列都以某种物理排序的方式存储，这意味着每列已经有相当于聚集索引的内容。如果是这种情况，那么在表上添加更多索引就没有多大意义了……或者是吗？也许是一个综合指数？

我的想法是否正确？

我已经将几个大型表（每个都有 >10^9 行和几十列）从 SQL Server 2014 实例上的聚集行存储移动到聚集列存储索引，并注意到这些表上的统计信息更新（默认采样，在我们的 ETL 中触发）或来自 Hallengren 脚本）现在需要更长的时间。

一个更具理论性的问题是为什么会这样？我的疯狂猜测是，统计信息更新会产生大量随机读取，这与列存储索引不能很好地配合，因为它们更适合大量数据的顺序读取。我很高兴知道更“深入”的解释。

更重要的问题是我是否可以做点什么来反对它。我已经在 SQL Server 2017 实例上尝试了针对具有单个 bigint 列（见下文）的表的测试用例，得到了相同的结果。增量统计在纸面上似乎是一个很好的解决方案。我需要重新创建所有统计对象（目前不是增量的，可能是由于历史原因），扩展 ETL 逻辑并更新我们的 Hallengren 脚本版本（我们目前使用旧版本）。如果有人能在我进入这个兔子洞之前分享他/她的经验，我将不胜感激。

重现步骤：

/*Create a rowstore and a columnstore table with a single bigint column*/
CREATE TABLE dbo.rowstore (col1 BIGINT);
GO

CREATE TABLE dbo.columnstore (col1 BIGINT);
GO

CREATE CLUSTERED COLUMNSTORE INDEX CCI_columnstore ON dbo.columnstore;
GO

/*Fill both tables with 400 * 10^6 rows. This results in a 15GB large rowstore and a 3,1GB large columnstore tables*/
;WITH e1(n) AS …

我有一个几乎有 1T 行的表。

create table bigtable (
  K1 int, K2 date, -- PK columns
  C1 ..., C8 ...., -- columns with various data types like float, date, varchar, ...
  B1 bit, B2 bit, ......, B10 bit -- 10 or so bit columns
  primary key (K1, K2)
)

我想使用列存储来提高查询性能。有以下选项。

1. 创建集群列存储索引
2. 为所有列创建一个非聚集列存储索引
3. 为除这些位列和其他低选择性列之外的所有列创建一个较小的非聚集列存储索引？

用户将自己编写查询。许多查询将是聚合查询。选项 3 的运行速度是否与其他两个尺寸较小的选项一样快？

我正在使用 SQL Server 2014。在我的情况下，我可以定期删除/重新创建非聚集列存储索引，因为数据不经常更新。

我正在为新的数据仓库设计 ERD。

• SQL Server 2016
• “事实”表的聚集列存储索引
• 松散星型模式

我将“事实”放在引号中并说“松散星型模式”，因为使用聚集列存储，我可以将许多维度直接放入“事实”表中，而无需担心行宽的典型问题。我的许多维度都进入了“事实”表。我正在创建一些维度表和代理键，但前提是除了暗淡描述本身之外，暗淡还具有属性。

这给我带来了一些非常广泛、高基数的领域，即nvarchar(max). 不必太深入，将这些字段视为非规范化列表。我需要针对我的一个数据源的粒度对列表进行非规范化。我确实在另一个事实表中对其进行了规范化，但不是我在此数据源中出现的事实表。

用户需要这些字段来搜索我正在显示的数据集市中的关键字。在我当前的设计中，它们位于聚集列存储“事实”表中。用户将经常查询事实表而不触及nvarchar(max)字段。

有没有比聚集列存储表更正确的将宽维度放入我的数据仓库的地方？

Joe Obbish告诉我，我们目前无法放入nvarchar(max)CCI。创建一个 LOB 表作为我的“事实”表的扩展对我来说是最佳实践吗？

我们将来可能会添加其他语言。目前和在可预见的期限内，该nvarchar栏仅包含英语。

我对float/real数据类型的聚合下推有问题。根据文档，“任何数据类型 <= 64 位”或 8 字节 () 支持聚合下推：

• 支持的聚合运算符有 MIN、MAX、SUM、COUNT、AVG
• 支持任何 <= 64 位的数据类型。例如，支持 bigint 是因为它的大小是 8 个字节，但不支持十进制 (38,6)，因为它的大小是 17 个字节。此外，不支持字符串类型
• 聚合运算符必须位于 SCAN 节点或带有 group by 的 SCAN 节点之上

无论我做什么，它都不起作用。我尝试使列可以为空而不为空。分组和无分组。

我们在最新版本的 SQL Server 2016 (SP1-CU3) 上运行。我想知道有人经历过吗？这对我来说似乎是一个错误。我错过了什么吗？

如果您遇到同样的问题，请为我的 SQL Server 反馈请求点赞。现在我面临着将float列转换为numeric. 但是numeric类型的操作通常比较慢。所以我可能在一个地方赢了，在另一个地方输了。我已成功测试numeric(15,12)。

这是说明问题的脚本（请启用实际执行计划以查看问题）：

DROP TABLE IF EXISTS dbo.TestTable;

CREATE TABLE dbo.TestTable 
(
     cKey             INT               NOT NULL
   , cGroup           INT               NOT NULL
   , cNumeric36_3     NUMERIC(36, 3)    NULL
   , …

我有一个带有聚集列存储索引的简单表：

ID INT NOT NULL,
Hash BINARY(20) NOT NULL

此表有一些十亿行和根据sp_spaceused，sys.allocation_units并SSMS报告，其大小约为25GB。

我的问题是我无法解释所有这些空间。查询sys.column_store_row_groups并且sys.column_store_segments只给我大约 7,8GB。索引不使用字典：primary_dictionary_id并且secondary_dictionary_id对于所有段都是 -1。查询sys.column_store_dictionaries根本不返回任何行。

元组移动器已完成其工作，所有行组都处于压缩状态。我已经试过了ALTER INDEX REORGANIZE以防万一。

我对大小差异的唯一想法是一些我没有考虑的类似字典的东西。关于我可能缺少什么的任何想法？

我正在运行 SQL Server 2017 (RTM-CU4)。

编辑 1：

这是 sp_spaceused 用于相关表的输出：

+--------+------------+-------------+-------------+------------+----------+
|  name  |    rows    |  reserved   |    data     | index_size |  unused  |
+--------+------------+-------------+-------------+------------+----------+
| IdsBin | 1073741824 | 25028112 KB | 25007432 KB | 16 KB      | 20664 KB |
+--------+------------+-------------+-------------+------------+----------+

编辑2：

这是一个包含 100 万行的复制脚本。它在我的机器上运行大约 …

我有一个包含约 100 亿条记录的行存储表。该表在一个 INT 字段上进行分区，并且有大约 1,400 个活动分区。我还有一个基于相同分区方案/功能构建的聚集列存储表。我可以将活动分区从 Rowstore 表切换到 Columnstore 表吗？

ALTER TABLE [dbo].[RowstoreTable] SWITCH PARTITION 741 TO [dbo].[ColumnstoreTable] PARTITION 741

此数据库驻留在 SQL Server 2014 企业版上。