我们在User中有一个Transaction的Python应用，其中包含Commission s，Fee等，Contact s EmailMessage，以及Activity上传的Document，Status更改等。）
我们为客户生成电子表格报告，详细说明上传到交易的文件数量，各种佣金的数额，收费，活动等。这些报告在某些情况下提供了客户的统计数据。帐户，在给定年份中的每个月（电子表格中每个月在其自己的行中）。
我们已经通过我们的网络应用程序达到了一定程度，我们生成的某些电子表格报告需要几分钟才能生成（所有等待Postgres），尽管我们努力优化查询，添加索引，尽管我们只使用SSD并且足够的RAM以使数据库适合内存。从本质上讲，我们已经达到了一个规模，其中一些基本报告变得过于昂贵而无法对我们的生产数据库进行简单的聚合查询。
我已经在一定程度上使用上面的选项1-4，但我想探索更多选项。另外，如果可能的话，我想完全停止使用选项4，而且我不太热衷于实现选项5（仅仅使用像Redshift这样的东西）。在某些情况下，选项6是一个很好的选择，但这不是我们现在准备采取的措施。
我开始真正开始研究Redshift，但今天早上让我感到厌倦的是阅读(here)“它不是一个实时分析引擎。”这也是意味着“它对于在单个Web请求中生成报告没有用”，或者该博客是否更有可能声称它对实时应用程序（在线游戏等）没用？
我也看过Quicksight，但它似乎更适合为自己构建业务仪表板，而不是为我们的用户生成报告。
鉴于上述信息，您将如何解决这个问题？ Redshift是明显的答案吗？我上面关于不适合实时的担忧是没有意义的？在这样的情况下，是否有其他服务或工具或方法对您更有意义？
答案 0 :(得分：1)
这绝对意味着Redshift不适合实时加载和报告。 Redshift是一个基于列的数据库，因此对它的写入（相对）昂贵，而与基于行的数据库（如MySQL）相比，读取速度非常快。
这意味着Redshift非常适合需要读取大量数据的查询，但您应该批量加载到Redshift。
我已经多次使用Redshift来处理你的用例。生产数据每天多次克隆到Redshift中（比如每30分钟一次，逐步增加。有许多供应商可以为您完成此操作）。每当需要报告时，查询都会命中Redshift而不是生产数据库。查询不仅运行得更快，而且不会锁定生产数据库。
此外，如果查询返回时间仍然不够快，您不喜欢。您可以设置数据管道以创建汇总表。您可以点击这些汇总表
，而不是查询每个报表的原始交易数据例如
SELECT date(transaction_date) as day, count(1) as transactions
FROM transactions
GROUP BY day
ORDER BY day
可能会变成
SELECT day, transactions
FROM transactions_summary_by_day
权衡是延迟。由于您不是经常写入Redshift，因此从Redshift中提取的任何报告都只会将数据作为最新的批处理批处理。也许这是30分钟，也许是1天，这取决于你的设置。数据管道会增加这种延迟，因为它们构建的报告仅使用自上次运行以来的数据，这依赖于当时加载的Redshift数据。
如果您的用户需要真正的“实时”报告，这可能是一个破坏者。但是如果他们按天或者几周工作，那么有一个小时左右的延迟对于快速加载报告是值得的。