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

Question

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

两个事实表，每个表约有8000万行

三个维度表，每个表的行数介于300,000至500,000之间

两个事实表都有3个外键用于连接维度表

一个安全表也有3个外键用于连接维度表

开发人员正在使用我的数据创建一个利用列式数据库的应用程序。他们在性能方面遇到了问题，当我建议在他们的表中添加索引/键时，他们说在列式数据库中索引并不能提高性能。因此，他们要求我将事实表与维度表合并。

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

我需要高层次的信息，但为了完整起见，关系型数据库是Teradata，列式数据库是SAP HANA。

- Nick Morgan

---

请阅读这篇文章。 - krokodilko

我不熟悉SAP HANA，但我可以告诉你另一个列式数据库（MariaDB Columnstore），它根本不允许你显式定义索引。存储是以这样一种方式构建的，以消除对索引的需求。理论上，列式数据库在读取方面表现出色（适用于大型表），但在写入方面表现较差。至少MariaDB Columnstore完美地符合这个描述。 - Ciprian Stoica

“关系型”是关于用户对数据的视图——作为表格——并不意味着任何实现方面的内容。 - philipxy

Answer 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更适合事务性数据。因此，如果该应用程序利用列式数据库，则更适合在大量数据中高效地搜索特定数据——因为只需要加载受影响的列，而不是整个记录。

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

- Lena Weber

Answer 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, ...]

此外，如果系统分布在几个节点上，则需要考虑分发密钥以确保每个节点处理的数据份额相似。

如果您遇到性能问题，我首先要检查的是您对表格发起的查询。接下来，请检查它们所连接的列，并查看事实表是否按照这些列的顺序填充。

从那里开始，您可以进一步进行故障排除。

- Cristian Varela

Answer 3

一般说来，在SAP HANA中，索引并不能提供更好性能的选项这种说法是不正确的。在某些情况下，索引可以将数据访问的效率提高数倍。

与数据库性能一样，要找到缓慢性能的原因，需要比“存在问题”更多的信息。SAP HANA提供了一些特定的开发工具（带有星型连接的分析视图和计算视图），以支持FACT-DIMENSION模型查询。如果已经使用了这些工具，则下一步应该是审查缓慢查询的执行计划。

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

这就是高层次语句所能带给您的全部内容。除此之外，需要查看所提到的信息和相关查询。

- Lars Br.