用于星型架构的OLAP或OLTP?

进行星型模式设计需要考虑的不仅仅是存储数据的数据库。

选择星型模式设计的一个直接原因是它的简单性和表达能力:根据经验,业务事务是使用事实表建模的,而业务实体(或业务“上下文”)是作为维度表建模的。这种设计的一个实际结果是,无论您使用的是SQL还是Tableau或PowerBI等BI/可视化工具,您的数据都将更容易被业务用户理解和使用。

实际上,任何RDBMS都将完全支持星型模式,在某些情况下,如Oracle,它可以使用特殊(位图)索引来优化星型模式上的典型查询模式。过去15年(至少)一直如此,几乎在任何主要的RBDM中都实现了各种规模的数据仓库。

在红移中也可以这样做:定义数据模型(星形模式),构建数据结构(表),相应地将数据加载到其中,并像往常一样进行查询。星型模式将比不相关或复杂的表结构更具表现力(因此更易于使用);在这种情况下,它实际上主要是一种元数据层,用于抽象数据的复杂性。这篇文章详细介绍了一个基准,该基准使用行业标准TPC-DS基准来衡量Redshift的性能和对星型模式查询的支持: https://blog.fivetran.com/warehouse-benchmark-dce9f4c529c1

您甚至不需要一个“合适的”数据库来启用星型架构设计,例如,您实际上可以在HDF上转储文件,并且仍然可以使用配置单元在这些文件上设计星型架构,只是为了使其更易于使用,因为配置单元将为您提供HDFS上的SQL接口,而星型架构将使SQL更简单、更容易理解。

两者都支持星型模式。由于您的数据已经处于红移状态,因此通过使用该平台,您可以消除将数据移动到SQL数据库中的额外工作和数据丢失/损坏的风险。

当前数据的红移组织方式、数据量和要运行的查询类型可能会影响查询性能。由于您并不是从星型架构开始的,因此您的红移实例可能不会针对星型架构进行优化。亚马逊对此发表了一篇博文 here . 您可以实现哪些提示取决于您当前的环境,但至少您应该能够使用数据压缩和工作负载管理建议。这 guide 红移架构和功能也可以帮助您实现亚马逊优化建议。