我正在使用 SQL Server 2014 设置一个 OLAP 数据库。核心事实表有大约 40,000,000 行、225 列，平均行大小为 181 字节。我一直在玩聚簇列存储索引，但运气不佳。一般来说，我发现使用新技术时查询性能要慢 4 倍以上。
一个特殊的例子 - 使用 int32 主键选择单行现在需要 12 秒......这是对行存储表的亚秒操作（当然它在 PK 上有一个唯一索引，这不允许与聚集列存储索引）。
我试图找出我做错了什么 - 从 MS 文档中听起来这是完成这项任务的理想技术；也许我错过了一些东西。
我正在 Windows 8.1 64 位上运行 SQL 2014 Enterprise，具有 128GB RAM 和 SSD 用于数据存储。此应用程序的数据是只读的。
创建聚集索引时，表本身成为按索引键排序的索引结构。
想象一下，现在我们在表 XPTO (a,b,c,d,e) 中有 5 列，“a”是主键，我们在表 XPTO 上创建一个列存储索引，其中包含列 (b,c)。
这个索引的结构是什么？与聚簇表相比有不同的结构吗？或者列存储是否有指向聚集表的指针（如其他非聚集索引）。
最后，同样的场景但是创建了所有属性的列索引，结构是什么？
sql-server clustered-index sql-server-2012 columnstore sql-server-2014
我想在一些非常大的宽表上实现（SQL Server 2014）聚集列存储索引。我需要更多内存来支持这个吗？如果是这样，我如何确定多少？
我刚刚阅读了位于此处的 SQL 2016 列存储索引指南。我们将在 SQL 2016 数据库中有一些相当大的表（数亿到数十亿行），用于 OLTP 和分析。
这些表将主要通过以下两种方式之一进行查询： 1) 用户将根据 Where 子句中的特定离散值检索相当小的结果集（例如，Where SubId = 'ABC'）；2) 用户将根据日期/时间值范围检索更大的结果集（例如，其中 ReadTime 介于 '2/1/2017' 和 '2/5/2017' 之间）。
由于列存储索引更适合场景 #2（我认为），我正在考虑为场景 #1 制作非列存储（例如，在 SubId 上）并创建非聚集列存储索引（例如，在 ReadTime 上） ) 用于场景 #2。
但是，我不确定这是否真的比在 ReadTime 上创建列存储聚集索引和在 SubId 上创建非列存储索引更好。
我不确定如何做出这个决定。
我需要我所能获得的所有帮助才能成功重建索引。特别是有关事务日志管理的专家建议。
背景
目标数据库是在聚集列存储索引 (CCIX) 中托管 3 个大表的 DW 数据库。最大的表叫做模拟。它拥有约 370 亿行和约 600 GB 的高压缩数据。根据我们使用较小表的初步估计，150 GB CCIX 表可以扩展到 5 TB，因此我们为这次重建提供了额外的 29 TB。
为什么我们必须这样做？
在我们的 ETL 服务的第一个版本中，数据在加载到 CCIX 之前没有先合并和排序。这导致 CCIX 的非最佳使用，因为许多行段在压缩之前没有完全填充。最佳段必须压缩 1,0485,76 行，并且必须按时间排序，以便基于时间的查询可以在 sql server 中获得最多的行组消除，并减少要处理的段。随着更多的文档可用，我们将学习更多的 CCIX。
我的对齐摘录在这里 https://drive.google.com/file/d/0BzGLNskaj70UQUtZYW9CZF9iUUk/view?usp=sharing
新的 ETL 保证数据在加载到 CCIX 之前及时整合和排序。所以未来的加载将被排序，我们在这里关注的是在首次加载期间加载的现有数据。
有关完整的案例描述，请阅读此处。 https://drive.google.com/open?id=0BzGLNskaj70URmZURlVDWVNYd2M
这是我们的第二次尝试，尽管新脚本具有基于分区的索引重建，但我可以看到日志文件仍在堆积。我们需要控制这一点。
我的问题是：
我已经执行了第二次尝试（正在进行），是否可以检查哪些分区已经被处理和排序？我在重建脚本中有 OFFLINE = ON 。
当基于分区的索引重建正在进行时，我们如何管理事务日志的大小？我们需要对此进行检查，并在可能的情况下定期截断每个分区。
由于日志文件中的空间不足，索引重建最初失败。我们添加了一个新的日志文件并使用单独的磁盘。但是我们如何确保这不会在第二次运行中再次发生？基于分区的重建是否足以保证我们能够成功重建？
感谢你的帮助。
按分区重建脚本（第二次尝试）——进行中
已用时间：17 小时 34 分钟
--create a new clustered row index (CRI)
CREATE CLUSTERED INDEX [Analog_ColumnStoreIndex]
ON [dbo].[Analog]
( …sql-server transaction-log columnstore sql-server-2016 bulk-insert
我在我的报告数据库中使用 MS SQL Server 2016 聚集列存储索引（我们称之为 CCI）。
在最初的设计中，我考虑的是星型模式，但后来我开始使用 CCI。现在我放弃了许多维度表，转而将字符串直接展平到“事实”表中。我保留维度表的唯一地方是当该维度具有频繁更改的属性并且要求使更改的属性适用于所有历史记录时。我做了这么多让一位拥有更多 DW 经验但没有空闲时间探索 CCI 的同事感到沮丧。
似乎作为单独列存储在磁盘上的平面表（以及提供的大规模压缩）根本不需要很窄。使用 CCI 时，何时还需要维度表？
data-warehouse database-design sql-server columnstore star-schema
我需要建立一个数据库来存储评估。
每个评估可以有无限数量的问题和无限数量的回答。
每个评估的响应可以增长到 500k。
每个评估的问题可以是 10 到 200。
虽然评估和评估响应表将使用“正常”关系表设计，但问题和答案应存储为键/值对。
Assessments
|AssessmentID|Name|JsonSchema|
Questions
|QuestionID|AssessmentID|QuestionValue|QuestionType|
AssessmentResponses
|ResponseID|AssessmentID|RespondentName|Date|JsonResponse|
Answers
|ResponseID|QuestionID|AnswerValueText|AnswerValueDecimal|
如您所见，我还以 JSON 格式存储了评估模式和响应，因为我发现在 Web UI 上快速可视化非常有用。特别是 JsonResponse 包含相关响应中给出的所有答案，如下所示：
{
"interviewDate":"2001/12/28",
"city":"Mombasa",
"phone":"123456789",
"name":"Marco",
"age":16
}
典型的查询可以是：
请注意，对于查询 2，年龄值将存储在AnswerValueDecimal列中，我将在其中存储所有数值。
我想知道列存储索引是否会提高这种结构的性能？
请注意，我知道 ElasticSearch 实例对我有很大帮助，但由于预算问题，我们现阶段无法实施。
关于数据的更多细节
评估中问题的答案通常是从有限数量的选项中选出的。例如：
最终用户可以根据他们从特定评估中需要的信息来构建查询。举上面的例子，他们想知道城市的北部和西部地区有多少永恒的建筑，到底有多少。
但是比如还有一个问题“你多大了？”，他们想过滤之前的查询，知道北区和西区有多少Eternite建筑，那里有一个年龄低于25岁的人……
使用 JSON 字段存储数据
我尝试使用 SQL Server …
聚集列存储索引表通常对大型表很有用。理想情况下有数百万行。并且对于查询也很有用，它仅选择此类表中可用列的子集。
如果我们打破这两个“规则”/最佳实践会发生什么？
与行存储的聚集索引表相比，我的测试没有显示任何性能下降。这在我们的案例中很棒。
是否有违反这两条规则的“长期”影响？或者任何尚未出现的隐藏陷阱？
上下文为什么需要它：我设计了一个数据库模型，它将用于不同供应商数据库的许多实例。每个数据库中的模式保持不变，但不同的供应商具有不同的数据量。因此，很少有小供应商可能会在他们的表中得到少量数据（<1 000 000）。我不能让自己为行存储和列存储模型保留两个不同的数据库。
我在用于日志记录的表上有一个聚集的列存储索引 - 仅插入（但不是批量插入）。当前的表统计是：
我今天早上通过以下操作看到以下操作sp_whoisactive：
ALTER INDEX [...] ON [...].[...]
REBUILD PARTITION = ALL WITH (DATA_COMPRESSION = COLUMNSTORE_ARCHIVE);
我使用以下查询来检查row_group_id我们有多少行：
SELECT
tables.name AS table_name,
indexes.name AS index_name,
partitions.partition_number,
dm_db_column_store_row_group_physical_stats.row_group_id,
dm_db_column_store_row_group_physical_stats.total_rows,
dm_db_column_store_row_group_physical_stats.deleted_rows,
dm_db_column_store_row_group_physical_stats.state_desc,
dm_db_column_store_row_group_physical_stats.trim_reason_desc
FROM sys.dm_db_column_store_row_group_physical_stats
INNER JOIN sys.indexes
ON indexes.index_id =
dm_db_column_store_row_group_physical_stats.index_id
AND indexes.object_id =
dm_db_column_store_row_group_physical_stats.object_id
INNER JOIN sys.tables
ON tables.object_id = indexes.object_id
INNER JOIN sys.partitions
ON partitions.partition_number =
dm_db_column_store_row_group_physical_stats.partition_number
AND partitions.index_id = indexes.index_id
AND partitions.object_id = tables.object_id
我们3383用1048576行和很少的行来排列组，如下所示： …
columnstore ×10
sql-server ×8
bulk-insert ×1
index ×1
json ×1
olap ×1
performance ×1
postgresql ×1
star-schema ×1
t-sql ×1