柱状数据库优化与关系数据库优化有何不同?

时间:2017-07-31 20:47:01

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

我有以下数据库结构,存储在关系数据库中:

  • 两个事实表,每个行数约为80万行
  • 三维表格,其中包含300,000 - 500,000行
  • 两个事实表都有3个用于连接维度表的外键
  • 一个安全表还有3个用于连接维度表的外键

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

这似乎与我对数据库管理基本原理的了解相矛盾。柱状数据库是否无法使用索引来提高性能?应该采取哪些步骤来优化柱状性能?

我正在寻找高级信息,但为了完整起见,关系数据库是Teradata,柱状数据库是SAP HANA。

3 个答案:

答案 0 :(得分:2)

在较高级别,关系数据库和列式数据库之间的区别在于数据的存储方式。关系数据库的存储记录按行,列为列。

例如: 记录: 名称ID号邮政编码 史密斯4444 98210 琼斯1234 10125

一个RDBMS存储这是按记录块:smith,4444,98210和jones,1234,10125 柱状DB按列逐列存储:smith,jones和4444,1234和98210,10125

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

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

由于DB结构不同,此应用程序可能无法正常运行。

答案 1 :(得分:0)

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

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

如果将行插入由此列(以及其他)排序的事实表中,则可以在表中实现极佳的压缩级别,因此从磁盘读取表所需的I / O要少得多。

ie: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,...]

此外,如果系统分布在少数节点上,则需要考虑分发密钥,以确保每个节点都有相似的数据共享来处理。

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

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

答案 2 :(得分:0)

索引不提供在SAP HANA中获得更好性能的选项的一般说法是不正确的。有一个明显的例子,指数何时可以通过数量级来改善数据访问。

与数据库性能一样,需要更多信息,而不仅仅是“有问题”才能找到性能低下的原因。 SAP HANA提供了一些特定的开发工件(具有星形连接的分析视图和计算视图)以支持FACT-DIMENSION模型查询。 如果已经使用了这些,那么下一步就是查看慢速查询的执行计划

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

就高级陈述而言,这可以带你到这里。除此之外的任何内容都需要查看上述信息和相关查询。

相关问题