sql - 为什么 Redshift 不需要物化 View 或索引？

Question

在 Redshift FAQ在下面

Q: How does the performance of Amazon Redshift compare to most traditional databases for data warehousing and analytics?

它说如下:

Advanced Compression: Columnar data stores can be compressed much more than row-based data stores because similar data is stored sequentially on disk. Amazon Redshift employs multiple compression techniques and can often achieve significant compression relative to traditional relational data stores. In addition, Amazon Redshift doesn't require indexes or materialized views and so uses less space than traditional relational database systems. When loading data into an empty table, Amazon Redshift automatically samples your data and selects the most appropriate compression scheme.

为什么会这样？

Answer 1

说实话(在我看来)有点虚伪。尽管 RedShift 没有这些，但我不确定这是否等于说它不会从它们中受益。

物化 View

我不知道他们为什么提出这个要求。可能是因为他们认为引擎的性能如此之好，以至于拥有它们的 yield 微乎其微。

我会对此提出异议，我从事的产品维护自己的物化 View ，并且可以通过这样做显示出显着的性能提升。也许 AWS 认为我一定是做错了什么？

索引

RedShift 没有索引。

它确实有 SORT ORDER这与聚集索引异常相似。它只是数据排序所依据的字段列表(如复合聚集索引)。

它甚至最近推出了INTERLEAVED SORT KEYS .这是对多个独立排序顺序的直接尝试。而不是通过 a THEN b THEN c 订购它同时有效地由每个人订购。

由于 RedShift 实现其列存储的方式，这成为可能。
- 每列与其他列分开存储
- 每列存储在 1MB 块中
- 每个 1MB 块都有汇总统计

除了作为存储模式之外，这还有效地成为了一组伪索引。
- 如果数据按 a then b then x 排序
- 但你想要z = 1234- RedShift 首先查看块统计信息(对于列 z)
- 这些统计数据将说明该块存储的最小值和最大值
- 这允许 Redshift 在某些条件下跳过其中的许多块
- 这个实习生允许 RedShift 识别从其他列读取哪些块