列式数据库优化与关系型数据库优化有何不同？答案

【问题标题】：How does columnar database optimization differ from relational database optimization?列式数据库优化与关系型数据库优化有何不同？
【发布时间】：2018-01-07 13:32:59
【问题描述】：

我有以下数据库结构，存储在关系数据库中：

两个事实表，每个表大约有 8000 万行
具有 300,000 - 500,000 行的三个维度表
两个事实表都有 3 个外键用于连接维度表
一个安全表还有 3 个外键用于连接维度表

一位开发人员正在使用我的数据创建一个使用列式数据库的应用程序。他们一直遇到性能问题，当我建议向他们的表中添加索引/键时，他们说索引列式数据库不会提高性能。结果，他们要求我将事实表与维度表结合起来。

这似乎与我对数据库管理基本原则的了解相矛盾。列式数据库真的不能使用索引来提高性能吗？应采取哪些步骤来优化柱状性能？

我在求高阶资料，不过为了完整起见，关系型数据库是Teradata，列型数据库是SAP HANA。

【问题讨论】：

请阅读this article
我不熟悉 SAP HANA，但我可以告诉您另一个列式数据库 (MariaDB Columnstore)，它根本不允许您显式定义索引。存储的构建方式消除了对索引的需求。理论上，列式数据库擅长阅读（适用于大表）但不擅长写作。至少 MariaDB Columnstore 非常适合这个描述。
“关系”是关于用户对数据的看法——作为表格——&并不暗示任何关于实施的事情。

标签： sql database-design relational-database query-optimization columnstore

【解决方案1】：

在高层次上，关系数据库和列式数据库之间的区别在于数据的存储方式。关系型数据库按行存储记录，按列存储。

例如：记录：

Name          ID number        zip code
smith         4444             98210
jones         1234             10125

RDBMS 按记录存储这是块：smith, 4444, 98210 和 jones, 1234, 10125 柱状数据库按列将其存储在块中：smith, jones 和 4444, 1234 和 98210, 10125

您可以创建索引。在 HANA 中有 UNIQUE、BTREE、CPBTREE 索引。唯一值的唯一索引 - 就像 RDBMS 中的主键一样，BTree 是二叉搜索树索引，CPBTREE 是压缩前缀 B+ 树索引。

但是，在创建索引以寻求修复之前评估性能问题很重要。查看日志，分析数据库并找出导致性能缓慢的原因。评论“开发人员正在使用我的数据创建使用列式数据库的应用程序”可能是问题的症结所在。每种数据库类型中存储和检索数据的方式完全不同。 RDBMS 更适合事务数据。因此，如果此应用程序利用了列式数据库，那么它更适合在大量数据中有效地搜索特定数据——因为只需要加载受影响的列，而不是整个记录。

由于数据库结构不同，此应用程序可能无法正确运行。

【讨论】：

【解决方案2】：

我对 SAP HANA 不太熟悉，但一般来说，列存储数据库没有传统关系意义上的索引。相反，每一列都像是一个单独的索引。

这种类型的数据库通常适用于分析查询，因为它们通常会读取大量数据。以任何事实表为例，其中一个维度的外键通常会有很多重复值（假设该维度的行数比事实表小得多）。

如果将行插入到按（以及其他）此列排序的事实表中，您可能会在表中实现出色的压缩级别，因此读取表所需的磁盘 I/O 将大大减少。

即：col_fk_to_dim = [1,1,1,1,1,2,2,2,3,3,3,3,3,3,4,5,5,5,5,5 ... ]

可以压缩为 [1x5, 2x3, 3x6, 4x1,5x5, ...]

此外，如果系统分布在少数几个节点上，您需要考虑分布键，以确保每个节点都有相似的数据份额来处理。

如果您遇到性能问题，我首先要检查的是您针对表启动的查询。接下来检查它们正在连接的列，并查看事实表是否按这些列的排序顺序填充。

您可以从那里进一步排除故障。

【讨论】：

【解决方案3】：

关于索引无法在 SAP HANA 中提供更好性能的一般说法是不正确的。很明显，索引可以将数据访问提高几个数量级。

与数据库性能一样，除了“存在问题”之外，还需要更多信息来找出性能下降的原因。 SAP HANA 提供了一些特定的开发工件（分析视图和带有星形连接的计算视图）来支持 FACT-DIMENSION 模型查询。如果已经使用了这些，那么下一步就是检查慢查询的执行计划。

如果这不会导致改进性能的方法，那么使用 PlanViz 执行跟踪将是下一个最佳选择。这允许查看查询执行的哪一部分实际花费了多少时间。

这就是高级语句可以带您到这里的程度。除此之外的任何事情都需要查看上述信息和相关查询。

【讨论】：