红移或平面设计中的尺寸建模-成本与时间
我已经开始学习AWS红移&我遇到了许多我认为不支持数据仓库、星型/雪花模式的东西。
基于使用响应，所有建议只有Redshift插入方法才能获得最佳性能，因为它是为read设计的。但是它不是增加了储存的成本吗？我目前正在研究MSBI，我的事实和维度有着复杂的结构。例句:一个事实表是跨各种业务共享的(数据集市)，很少有维度是类型2(我必须跟踪历史)&很少有不需要雪花设计的复杂场景。
考虑到云存储和计算的成本，我希望在云上保留最小的数据(就像我在我的前提系统中所做的那样，这有助于4TB的存储)。
现在，如果我做的方法与我在前提下所做的相同，那么我将不得不运行我的ETL，将关键列与暂存进行比较&然后执行CRUD，这使得将我现有的系统移动到云是毫无意义的。如果我使用平坦的表结构，那么我的表中的数据将增加4-6倍，这将增加云端存储的成本，而在此基础上的计算可能会增加额外的成本。
How to handle Slowly Changing Dimension Type 2 in Redshift? Redshift Performance of Flat Tables Vs Dimension and Facts
对上述问题的回答将讨论如何使平面表更容易与Redshift相关联。
但在Redshift博客上，讨论了如何优化星型模式。
星型和雪花模式在Amazon上运行良好，添加交错排序键进一步提高了性能，在需要时减少了表上更多筛选器谓词的I/O。
现在，如果我选择只用于insert (这是称赞Redshift体系结构)的方法，那么我将以支付更多的存储费用结束。如果我选择采用传统的数据仓库设计，那么我最终会为计算成本支付额外的费用。
有什么真实的例子可以帮助我理解你在Redshift中所遵循的方法吗？
回答 1
Stack Overflow用户
发布于 2020-08-17 17:06:30
根据我的经验，Redshift很好地处理平面表，压缩消除了许多存储开销。但是，对于我的用例来说，最主要的关注是保持ETL尽可能简单。
Redshift几乎总是建议ZSTD压缩，但是对于某些维度，当您知道很少有不同的值时，您可以使用BYTEDICT获得更好的压缩。
有了一个好的排序键和一个支持聚合模式的分发密钥，您可以在查询平面表时充分利用集群的功能，而不受带宽的限制。当然，对于具有分布式维度表的星型模式也是如此，但是总有这样的维度，它不够小，无法分发，而且FK并不适合作为分发键。
在你深入红移之前，也要考虑雅典娜是否是你的解决方案。使用S3进行存储要比Redshift磁盘便宜得多，而且在许多用例中性能是相当的。还有红移频谱中的混合模式，您可以将旧分区卸载到S3，并且只将最近的分区保存在较小的集群中。
https://stackoverflow.com/questions/63453336
复制相似问题
腾讯云开发者
