我目前正在为 SaaS 近实时分析应用程序测试 Redshift。 查询性能在 100M 行数据集上很好。
但是，当更多用户同时使用该应用程序时，每个集群 15 个查询的并发限制将成为一个问题。
我无法缓存所有聚合结果，因为我们授权自定义每个查询的过滤器（即席查询）
申请的要求是：
Redshift 不适合这个用例吗？对于这些要求，您还会考虑哪些其他技术？
【问题讨论】：
标签： amazon-redshift
这个问题也发布在 Redshift 论坛上。 https://forums.aws.amazon.com/thread.jspa?messageID=498430񹫾
我将我的答案交叉发布给通过 Google 找到此问题的其他人。 :)
在过去，我们会为此使用 OLAP 产品，例如 Essbase 或 Analysis Services。如果您想研究 OLAP，有一个非常好的开源实现，称为 Mondrian，它可以在各种数据库（包括 Redshift AFAIK）上运行。另请查看 Saiku，了解基于 OSS 浏览器的 OLAP 查询工具。
我认为您应该使用超过 15 个并发查询来测试 Redshift 的行为。我怀疑它不会引起用户注意，因为查询只会排队一两秒。
如果您证明 Redshift 不起作用，您可以测试 Vertica 的免费 3 节点版本。它比 Redshift 更成熟一些（即它将处理更多并发用户）并且在数据加载方面更加灵活。
在我看来，Hadoop/Impala 对于您这种规模的数据集来说过于复杂。它也不是为大量并发查询或短期查询而设计的。
Shark/Spark 专为您的数据快速到达并且您可以预先计算的指标集有限的情况而设计。同样，这似乎不符合您的要求。
祝你好运。
【讨论】：
Redshift 对 join 和 group by/order by 中使用的键非常敏感。没有动态索引，因此通常您可以定义适合任务的结构。
您需要确保您的连接与结构 100% 匹配。看看解释计划——你不应该有任何重新分配或广播，也没有领导节点活动（例如排序）。考虑到您将要进行的查询数量，这听起来像是最关键的要求。
能够过滤/聚合任意 100 列的要求也可能是个问题。如果结构（dist 键、排序键）在大多数情况下与列不匹配，您将无法利用 Redshift 优化。然而，这些都是可扩展性问题——你可以增加节点的数量来匹配你的性能，你可能会对最优解决方案的成本感到惊讶。
如果投影列的数量很少，这可能不是一个严重的问题，否则 Redshift 将不得不在排序或聚合（即使以分布式方式）时将大量数据保存在内存中（并最终溢出），并且可以再次影响性能。
除了扩展之外，您始终可以实施分片或镜像，以克服一些队列/连接限制，或联系 AWS 支持以解除一些限制
您应该考虑预聚合。只要 Redshift 不需要进行重新排序等转换，它就可以在几秒钟内扫描数十亿行。而且它可以存储 PB 级的数据——所以如果你存储过多的数据也没关系
因此，总而言之，仅根据您提供的定义，我认为您的用例并不适合。它可能需要工作，具体取决于具体的使用模式。
【讨论】：