1

我目前正在为 SaaS 近实时分析应用程序测试 Redshift。查询性能在 100M 行数据集上很好。

但是，当更多用户同时使用该应用程序时，每个集群 15 个查询的并发限制将成为一个问题。

我无法缓存所有聚合结果，因为我们授权在每个查询上自定义过滤器（临时查询）

申请的要求是：

  • 查询必须在 10 秒内返回结果
  • 在超过 100 列上使用过滤器的即席查询
  • 在应用程序上同时连接 1 到 50 个客户端
  • 数据集以 1000 万行/天的速度增长
  • 典型的查询是带有聚合函数 COUNT 的 SELECT，带有 1 或 2 个连接的 AVG

Redshift 不适合这个用例吗？对于这些要求，您还会考虑哪些其他技术？

4

2 回答 2

1

这个问题也发布在 Redshift 论坛上。https://forums.aws.amazon.com/thread.jspa?messageID=498430髾

我将我的答案交叉发布给通过谷歌找到这个问题的其他人。:)

在过去，我们会为此使用 OLAP 产品，例如 Essbase 或 Analysis Services。如果您想研究 OLAP，有一个非常好的开源实现，称为 Mondrian，它可以在各种数据库（包括 Redshift AFAIK）上运行。另请查看 Saiku，了解基于 OSS 浏览器的 OLAP 查询工具。

我认为您应该使用超过 15 个并发查询来测试 Redshift 的行为。我怀疑它不会引起用户注意，因为查询只会排队一两秒。

如果您证明 Redshift 不起作用，您可以测试 Vertica 的免费 3 节点版本。它比 Redshift 更成熟一些（即它将处理更多并发用户）并且在数据加载方面更加灵活。

在我看来，Hadoop/Impala 对于您这种规模的数据集来说过于复杂。它也不是为大量并发查询或短期查询而设计的。

Shark/Spark 专为您的数据快速到达并且您可以预先计算的一组有限指标的情况而设计。同样，这似乎不符合您的要求。

祝你好运。

于 2013-11-08T14:43:54.160 回答
0

Redshift 对 join 和 group by/order by 中使用的键非常敏感。没有动态索引，所以通常你定义你的结构来适应任务。

  1. 您需要确保您的连接与结构 100% 匹配。看看解释计划——你不应该有任何重新分配或广播，也没有领导节点活动（例如排序）。考虑到您将要进行的查询数量，这听起来像是最关键的要求。

  2. 能够过滤/聚合任意 100 列的要求也可能是一个问题。如果结构（dist 键、排序键）大部分时间与列不匹配，您将无法利用 Redshift 优化。然而，这些都是可扩展性问题——你可以增加节点的数量来匹配你的性能，你可能会对最优解决方案的成本感到惊讶。

如果投影列的数量很少，这可能不是一个严重的问题，否则 Redshift 将不得不在排序或聚合（即使以分布式方式）时将大量数据保存在内存中（并最终溢出），这会再次影响性能.

  1. 除了扩展之外，您始终可以实施分片或镜像，以克服一些队列/连接限制，或联系 AWS 支持以解除一些限制

  2. 您应该考虑预聚合。只要 Redshift 不需要进行重新排序等转换，它就可以在几秒钟内扫描数十亿行。它可以存储 PB 级的数据——所以如果你存储过多的数据也没关系

因此，总而言之，仅根据您提供的定义，我认为您的用例并不适合。它可能需要工作，细节取决于确切的使用模式。

于 2016-03-14T04:17:01.953 回答