是否应该使用AWS Redshift进行在线查询？

我有一个使用案例，其中一个相当大的（大于1 TB）的SQL数据库必须转移到云，我想使用Redshift而不是一些RDS解决方案，因为它便宜一些，而且我处理延迟我的查询少于10秒。应用程序将很少查询数据库 - 大约每天100次。是否应该使用AWS Redshift进行在线查询？

与RDS相比，使用Redshift会是一个合理的选择，可以节省成本吗？

更新：系统将每天更新一次或两次数据库。

来源

2017-04-03 emotionull

你刚才提到，你很少会查询系统。但是请提一下使用更新还是插入语句来修改系统？答案将很大程度上取决于你是否要插入/更新。 –

@YusufHassan对不起。我应该包括这一点。我已经更新了该问题，以指定该数据库每天更新一次或两次。 – emotionull

请接受我的答案，如果它帮助你实现你正在寻找的东西。这样，它不会在线程中丢失，并会帮助其他有类似问题的人:) –

关于什么最适合您业务的争论将永远存在，您考虑到所有成本和性能权衡会更好地采取最佳决策，但凭借我以上提供的所有经验和信息，我可以理直气壮地让你知道影响下面的行动将有：

谁来写红移表？

如果数据不是实时的，您可以继续使用Redshift。但是，如果您需要实时数据或您的其他指标依赖于它，例如显示余额或忠诚信用点，则Redshift不是理想的选择。理想情况下，在CPU使用率最低时加载数据。

写操作是十分缓慢的红移

作为柱状，因此预计散装写入将是极为缓慢。因此，如果您插入数据，请确保在午夜发生，以便CPU不会在ETL任务中使用。

什么数据集将被查询？

如果数据集是OLAP，那么Redshift是理想的。如果数据是OLTP，那么切换到时不会有性能优点，但它可以节省一些成本。当您的业务增长时，这将是一个痛点

我们需要了解的是，Amazon Redshift与任何基于行的数据仓库都不相似。它用于分析目的。如果您要生成批量数据（每天以百万为单位）并且需要查询它，那么它就是您的工具。公司使用Amazon Redshift进行队列，用户行为和趋势分析，因为这涉及到查询大型数据集。列式数据库用于查询数百万条记录，因为列式定位已针对查询庞大数据集进行了优化。

如果您正在存储OLTP数据集，例如创建的用户，订单放置，订单属性，首选项，余额等等，那么亚马逊Redshift不是您的工具。写入速度会很慢，您在查询这样的小型OLTP数据集时不会看到任何性能改进。此外，如果您的架构配置为Master - Slave，则无法承受任何延迟，并且使用RS会导致向从属设备的数据迁移延迟，因为它不针对写入操作进行优化。预计Slave将成为master的复制品，其中包含几乎实时的数据，并且使用RS来实现此架构将导致无用的延迟。

鉴于如果您捕获用户行为，点击和手势，移动角度，他/她的访问经纬度...任何生成批量数据，您将查询巨大的数据集的分析目的，然后红移是为你的工具。这些数据点不需要实时，可以每天加载一次或两次。

我建议去红移只有当你看到性能的改进。如果你只为切换成本节约措施，并在未来的业务升级，这将是一项艰巨的任务，为您再次迁移到适当的架构。

来源

2017-04-04 06:59:49

AWS已经定位红移清楚：它是平均数据库入库。

总之，AWS期望的管理员：根据数据库仓库

按摩数据库需要
知道如何分片/分割数据库
知道如何优化数据库，例如如果需要去归一化（即转换或从OLTP（联机事务处理）友好的OLAP（联机分析处理）友好。迁移表
移动到红移时，可能需要更多的磁盘空间，因为它会创建内部优化额外的索引。

总之，移动红移也许或许不是给你带来任何的成本和/或性能优势，它不是灵丹妙药。

来源

2017-04-06 15:37:41 mootmoot

这听起来像根据你的使用情况红移可能是一个Redshift更像是一个OLAP而不是OLTP数据库，在非数据库语言中，它是mor e意味着实时插入或读取（实时分秒）。红移也比类似RDS低得多的并发性，但也听起来并不像这对你的强烈需求。如果你需要

RDS将使意义：

实时单个记录插入
子第二查询
高达每秒数千执行查询。

因为你可以处理超过1秒的查询时间，但是在10以下，而且你的查询工作量不算太大，Redshift应该可以正常工作。

来源

2017-04-09 04:58:27 CraigKerstiens

是否应该使用AWS Redshift进行在线查询？

回答

相关问题