问题标签 [columnstore]

我有大型表的大型数据库，而从多个表中检索数据（查询大约包含 10 个内部连接）从数据库中获取数据需要很长时间（在某些情况下需要 10-20 秒或分钟）。该查询需要大多数表中的几乎所有列和其余表中的近一半列。

我的问题是在我的案例中使用 SQL Server 2012 列存储架构有多大帮助。目前我正在使用 SQL Server 2008。欢迎任何其他时间优化建议，因为我非常需要优化此类查询

此查询在 Intel (i5 3.00GHz) 8GB RAM 上需要 50 秒（大约），结果为 5676 行。

Sequence 176232行38列，Sequence$Document 132776行8列，ClassMapping 6行10列，ObjectClass 6行11列，Sequence_Flow 4847730行22列，OrgPeople 4656行11列，TemplateProposals 90889行64列，Sequence_Flow_Target 521621行9列，人 4655 行 67 列。

所有属性数据类型都在（数字、字符串、日期）

我在与 MonetDB 相关的各种白皮书中偶然发现了这两个概念。似乎既要瞄准又要实现类似的目标——加快范围查询的选择。这两个概念是否在 MonetDB 中同时实现？

我已经在 OS X 上的 PostgreSQL 9.3.5 中安装了 cstore_fdw 扩展，它看起来好像在这个过程中没有错误（/usr/local/pgsql/bin/路径不正确，但是文件被复制到它们应该在的位置，就像pg_config在 symlinked 中一样$PATH）：

但是，当我尝试启动 Postgres 时，无法加载扩展：

有谁知道可能出了什么问题？

我决定在一个项目中使用 Cassandra，在阅读了大量文档之后，我仍然无法想象出一种对关联数据进行建模的好方法。

系统应该将数据存储为这些类型的类型和实例。同时，类型可以通过自定义关联来关联，自定义关联定义了如何关联实例。

对于更具体的示例，请考虑以下数据：

• 关联：a1，a2，a3
• 类型：t1，t2，t3
• 实例：t1-i1，t1-i2，t2-i3，t3-i4，t3-i5，t3-i6

然后，用户可以定义类型如何关联：

• t1 - a1 - t2
• t2 - a2 - t3
• t3 - a3 - t3

上面将稍后定义实例如何关联：

• t1-i1 - t2-i3（基于t1 - a1 - t2）
• t2-i3 - t3-i5（基于t2 - a2 - t3）
• t3-i5 - t3-i6（基于t3 - a3 - t3）
• t3-i6 - t3-i6（基于t3 - a3 - t3）

以上几点注意事项：

1. 2种类型之间可以有n个关联
2. 同一类型/实例之间可以存在关联（上面的示例）
3. 类型之间的关联定义了如何关联 实例

查询是什么：

1. 系统应该能够对单个关联、类型和实例类型进行 CRUD。
2. 类型的关系。（例如：GET /t-assoc/t1-> [ t1 - a1 - t2 ]）
3. 关联类型的关系。（例如：GET /t-assoc/t2/a1-> [ t1 - a1 - t2 ]）
4. 与上述相同，但具有完整的关系
5. 例如关系（例如：GET /i-assoc/t1/t1-i1-> [< t1 , t1-i1 >- a1 -< t2 , t2-i3 >]）
6. 关联实例的关系（例如：GET /i-assoc/t1/t1-i1/a1-> [< t1 , t1-i1 >- a1 -< t2 , t2-i3 >]）
7. 关联实例与类型的关系（例如：GET /i-assoc/t1/t1-i1/a1/t3-> []）
8. 同上，关系完整
9. 类似于3.只是它应该返回实际的相关类型，而不是返回关系（例如：GET /types/t1/a1-> [ t2 ]）
10. 类似于7.，同时返回实例（例如：GET /instance/t1/t1-i1/a1/t2-> [< t2 , t2-i3 ]>）

我在实现上述结构时进行了一些迭代，但我未能将其表示为允许在单个查询中执行上述所有操作的结构。这是 CQL 版本：

反向字段是一种能够从两个方向发现关系的技巧。这意味着我将插入t1 - a1 - t2为：

1. t1-a1-t2-真
2. t2-a1-t1-假

此实现不支持查询号：9 和 10。对于 9，我需要执行 2 个查询，其中第二个是IN查询。这不是最优的，因为这些将是最常见的查询。

关于允许在 1 个查询中执行上述内容的不同设计的任何建议？

编辑：作为图形结构，这将非常适合图形数据库。我正在尝试在 Cassandra 中解决这个问题。

我在我的 SQL Server 2014 数据库系统上使用 TPC-H (SF 10)。为了提高查询性能，我决定按日期列对两个最大的表（Lineitem 和 Orders）进行分区（同一磁盘），因为其中许多查询都使用日期范围。首先我决定使用每周分区方案，然后我使用每月方案。我在每个表上都使用了一个聚集列存储索引。我执行了第一个 TPC-H 查询：

对于上面的查询，我得到了以下结果。

• 每周分区
• 访问的分区数 348 (1..348)（总共 361 个分区）
• （862194 行未读取，因为它们位于最后一个分区中）
• 逻辑读取：1381
• Lob 逻辑读取：109005
• Lob 物理读取：1371
• Lob 预读读取：200554
• 执行时间：2807 毫秒
• 编译CPU：43
• 编译时间：43

• 编译内存：1408

• 每月分区

• 访问的分区数 80 (1..80)（共 84 个分区）
• （881.087 行未读取，因为它们位于最后一个分区中）
• 逻辑读取：2902
• Lob 逻辑读取：617554
• Lob 物理读取：388
• Lob 预读读数：260486
• 执行时间：2680 毫秒
• 编译CPU：12
• 编译时间：12
• 编译内存：872

它们之间最大的区别是使用的批次数量。在每周分区下大约有 333.201 批用于执行索引扫描，而在每月分区下只有 191.275 批。

我对这个结果有点困惑。我预计第一次执行（每周分区）会比第二次更快，因为读取操作更少。每月分区表上的 lob 逻辑读取明显更高，但执行时间、编译 CPU、时间和内存更低。所以我认为每月分区更有效。其他查询的结果看起来几乎相同:(。有人能帮我理解这里发生了什么吗？

所以，我只是用 maxdop 1 再次进行了测试。这是我的结果：

每周分区

• 逻辑读取：1381
• lob 逻辑读取：108619
• lob 物理读取：1362
• lob 预读读取：200664

每月分区

• 逻辑读取：739
• lob 逻辑读取：94901
• lob 物理读取：402
• lob 预读读取：262598

这是执行计划，这两个执行看起来完全一样，这里有一些更详细的信息：

http://i.stack.imgur.com/293oN.png

读操作数的差异没有以前那么大，并且在每周分区下有更多的物理读取。此外，每周分区下还有更多的逻辑读取。这与我的预期完全相反：/。

执行计划，（每月分区）我首先创建了一个 CI，然后创建了一个聚集列存储索引（使用 drop existing = on 和 maxdop 1）

http://i.stack.imgur.com/Euo8m.png

我有一个 SQL Server 2014 的评估版。它过期了，我购买了 SQL Server 2014 的标准版。不幸的是，在评估期间，我至少创建了一个列存储索引。应该是多个吧。我的数据库处于可疑模式并告诉我必须删除列存储索引。但是，它不会让我放弃它，因为它处于可疑模式。

我可以运行 sys.indexes 但它没有显示相关数据库的任何索引。我无法运行 DBCC CHECKDB。我真的不想为 SQL Server 的下一个级别付费。

我有一个关于在 SQL Azure 上将 Top 与具有聚簇索引的表一起使用的问题。

这两个表都有聚集列存储索引，表 HeaderTable 有 300K 行，表 ValuesTable 有 650 万行。

如您所见，第二个查询中的顶部操作非常慢。也许有人对这个问题有一些提示？

嗨，我有一个设计问题：

您如何设计一个系统，在同一数据库管理系统中有效地将 XML 数据库隐藏在列存储和行存储中？

谢谢。

我需要一个存储过程，它将接受表名作为参数，然后在每列上创建非聚集列存储索引。

有人可以帮我解决这个问题吗？

我使用数据集浏览了 Citus 快速入门指南中的示例customer_reviews。它工作得很好，但是在常规 PostgreSQL 表中的相同数据集上的性能也相当不错。我怀疑这是因为数据集可能适合 RAM：我有一个 4 CPU Linux VM 和 8 GB RAM。

有人可以指出一个更好的数据集/查询示例来突出 cstore_fdw 的实用程序，传统的行存储在哪里遇到性能问题？