在Redshift FAQ下为什么Redshift不需要物化视图或索引？
问：如何亚马逊红移的效果进行比较，数据仓库和分析最传统的数据库？
它说以下内容：
高级压缩：柱状数据存储可以比基于行的数据存储，因为类似的数据存储在磁盘上依次被压缩得多。 Amazon Redshift采用多种压缩技术，通常可以实现相对于传统关系数据存储的显着压缩。此外，Amazon Redshift不需要索引或物化视图，因此比传统关系数据库系统使用更少的空间。将数据加载到空表时，Amazon Redshift会自动对您的数据进行采样并选择最合适的压缩方案。
为什么会出现这种情况？
诚实（在我看来）这有点不合适。虽然RedShift既没有这些，我也不确定这是否说它不会从中受益。
物化视图
我没有真正知道他们为什么让这个要求。可能是因为他们认为引擎非常高效，使得它们的收益最小。
我会质疑这一点，我所从事的产品维护着自己的物化视图，并且可以显示出这样做会带来显着的性能提升。也许AWS相信我一定是在做错什么呢？
指标
红移没有索引。
它确实有SORT ORDER这与聚簇索引非常相似。它只是数据排序的字段列表（如复合聚集索引）。
它甚至最近推出了INTERLEAVED SORT KEYS。这是直接尝试拥有多个独立的排序顺序。而不是通过a THEN b THEN c订购它有效其中每个订单同时。
由于RedShift如何实现其列存储，这成为可能。
- 每一列彼此柱分开存储
- 每一列被存储在块大小为1MB
- 每个1MB块具有汇总统计
除了作为存储图案这个有效地变成一组伪索引。
- 如果数据被a then b then x
分类 - 但是你要z = 1234
- 红移着眼于块统计（列z）的第一
- 这些统计数据会说由块存储的最小值和最大值
- 这允许红移跳过许多那些块中的某些条件下
- 此实习生允许红移来识别从其他列
这太长了评论。
简单的答案是：因为它可以真正地读取所需的数据，非常快速并行。
索引的主要用途之一是“针尖干草堆”查询。这些查询只需要相对少量的行，并且这些查询与WHERE子句匹配。列式数据存储处理这些不同。整列被读入内存 - 但只有列，而不是行的其余数据。这与每列有一个索引类似，只是需要扫描匹配值（即并行性派上用场）。
索引的其他用途是匹配用于加入或聚合的密钥对。这些可以通过替代的基于散列的算法来处理。
至于物化视图，RedShift的优势不是更新数据。许多这样的查询速度够快而没有实现。而且，物化对于在高事务环境中维护数据会产生很大的开销。如果您没有很高的事务环境，那么可以在批量加载后增加临时表。
啊确定这是有道理的。你能否澄清一下：如果你没有很高的交易环境，那么你可以在批量加载后递增临时表。我不太确定我是否遵守。 – m0meni
据我所知，从我的经验来看，RedShift并没有使用“将整列读入内存”的范例。相反，它比这更细粒度。列被碎片化成1MB块，并带有汇总统计信息，这些统计信息允许某些块根本不被读取。实际上，如果该字段是唯一的，则汇总统计信息允许引擎识别要读取的单个1MB块，其余部分将被忽略。 – MatBailie
@MatBailie。 。 。我的理解是，“页面”标题包含页面上列的最小值和最大值。这对“排序”列（例如，自动递增的ID或插入时间）有很大的好处。对其他色谱柱可能有好处，但事实并非如此。当然，这些事情可能会随着时间而改变，所以我的理解可能会过时。 –
索引是基本上在OLTP系统用于检索特定的或一小群读取哪些块值。相反，OLAP系统检索大量值并对大量值执行聚合。索引不适合OLAP系统。相反，它使用带分类键的称为区域映射的二级结构。
索引在B树上运行。下面博客中的“没有btree的生活”部分用示例解释了基于btree的索引如何影响OLAP工作负载。
https://blog.chartio.com/blog/understanding-interleaved-sort-keys-in-amazon-redshift-part-1
柱状存储，压缩编码，数据分配，压缩，查询编译，优化等的组合提供的电源红移要快。
实施上述因素，减少了Redshift上的IO操作，并最终提供了更好的性能。要实施高效的解决方案，需要对上述部分以及您在Amazon Redshift上运行的查询有大量的了解。
例如。 Redshift支持Sort键，Compound Sort键和Interleaved Sort键。 如果您的表格结构是lineitem（orderid，linenumber，supplier，quantity，price，discount，tax，returnflat，shipdate）。 如果您选择orderid作为排序关键字，但如果您的查询基于shipdate，则Redshift将会高效运行。 如果您在（orderid，shipdate）上有复合sortkey，并且只有您的查询仅在发货日期，Redshift将无法高效运行。 如果您在（orderid，shipdate）上有交错软键，并且您的查询不支持实体化视图，但它很容易允许您通过在现有表上运行选择查询来创建（临时/ permant）表。它最终复制了数据，但是以所需的格式执行查询（类似于物化视图）下面的博客提供了关于上述方法的一些信息。
红移确实我们最近的基准测试之一期间与其他系统，如蜂房，黑斑羚，星火，BQ等以及票价构架
如果我手动在redshift中创建实例化视图，我应该只是在一段时间内创建和删除表？ – m0meni
@ AR7 - 这取决于你。我们处理多TB数据集。重建整张桌子至少可以说是惩罚性的。 RedShift的UPDATE行为是软删除记录（直到VACUUM）并将新数据插入表的未分类部分。因此，我们只需删除任何已更改或已删除的内容，然后插入已更改或新增的内容。然后在维护阶段处理VACUUM和ANALYZE。重新构建会避免未排序的块，并且本身比VACUUM更快。这是一种折衷。 – MatBailie
您是否有推荐使用红移的资源？我对使用它很新，而且目前这里没有那么多的数据，但它肯定会增长，我宁愿不准备。我不太了解真空吸尘器或红移的最佳做法，除了亚马逊在他们的文档中有更多的信息，了解更多信息会更好。 – m0meni