我有以下数据库结构，存储在关系数据库中：
- 两个事实数据表，每个表有 ~8000 万行
- 包含 300,000 - 500,000 行的三维表
- 两个事实数据表都有 3 个外键，用于联接到维度表
- 一个安全表还具有 3 个用于联接到维度表的外键
开发人员正在使用我的数据创建利用列式数据库的应用程序。他们一直遇到性能问题，当我建议在他们的表中添加索引/键时，他们说索引列式数据库不会提高性能。因此，他们要求我将事实数据表与维度表合并。
这似乎与我对数据库管理基本原则的了解相矛盾。列式数据库真的不能使用索引来提高性能吗？应采取哪些步骤来优化列式性能？
我正在寻找高级信息，但为了完整起见，关系数据库是 Teradata，列式数据库是 SAP HANA。
在高级别上，关系数据库和列式数据库之间的区别在于数据的存储方式。 关系数据库按行存储记录，按列存储记录。
例如： 记录：
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更适合事务数据。因此，如果此应用程序利用列式数据库，那么它更适合在大量数据中有效地搜索特定数据 - 因为只需要加载受影响的列，而不是整个记录。
此应用程序可能无法正常运行，原因可能只是由于数据库结构不同。
我对 SAP HANA 不是很熟悉，但一般来说，列存储数据库没有传统关系意义上的索引。相反，每一列都像一个单独的索引。
这种类型的数据库通常适用于分析查询，因为它们通常会读取大量数据。以任何事实数据表为例，其中维度的外键之一传统上具有大量重复值(假设维度在行方面比事实数据表小得多)。
如果将行插入到按此列(以及其他列)排序的事实数据表中，则可能会在表中实现出色的压缩级别，因此读取表所需的磁盘 I/O 要少得多。
即：col_fk_to_dim = [1,1,1,1,2,2,2,3,3,3,3,3,3,4,5,5,5,5,5,5,5 ...]
可以压缩为 [1x5， 2x3， 3x6， 4x1,5x5， ...]
此外，如果系统分布在几个节点上，则需要考虑分布键，以确保每个节点都有相似的数据共享要处理。
如果您遇到性能问题，我要检查的第一件事是您针对表启动的查询。接下来，检查它们要联接的列，并查看事实数据表是否按这些列的排序顺序填充。
从那里您可以进一步排除故障。
索引不提供在 SAP HANA 中提高性能的选项的一般声明不正确。对于索引可以将数据访问改善几个数量级，有一些明显的情况。
与数据库性能一样，除了"存在问题"之外，还需要更多信息来查找性能缓慢的原因。SAP HANA 提供了一些特定的开发工件(分析视图和带星形联接的计算视图)来支持事实维度模型查询。 如果已使用这些方法，则下一步将是查看慢查询的执行计划。
如果这不能带来提高性能的方法，那么使用PlanViz执行跟踪将是下一个最佳选择。这允许查看查询执行的哪个部分实际花费了多少时间。
这就是高级陈述可以带你到这里为止。除此之外的任何内容都需要查看提到的信息和有问题的查询。