oro*_*aki 6 python optimization reporting star-schema amazon-redshift
我们有一个Python应用程序UserS IN TransactionS作CommissionS,FeeS,等,具有Contact接收小号EmailMessageS,和Activitys充分的(地方Document小号上传,Status修改等).
我们为客户生成电子表格报告,详细说明上传到交易的文档数量,各种佣金类型,收费,活动等.这些报告在某些情况下提供客户帐户的统计信息,给定年份中的每个月(电子表格中每个月都在其自己的行中).
我们已经通过我们的网络应用程序达到了一个目的,我们生成的某些电子表格报告需要花费几分钟才能生成(所有等待Postgres),尽管我们努力优化查询,添加索引,尽管我们只使用SSD并且有足够的RAM来使数据库适合内存.从本质上讲,我们已经达到了一个规模,在这个规模中,一些基本报告变得过于昂贵而无法对我们的生产数据库进
我已经在一定程度上使用上面的选项1-4,但我想探索更多选项.另外,如果可能的话,我想完全停止使用选项4,而且我不太热衷于实现选项5(仅仅使用像Redshift这样的东西).在某些情况下,选项6是一个很好的选择,但这不是我们现在准备采取的措施.
我开始真正开始研究Redshift,但今天早上让我感到厌倦的是阅读(这里) " 它不是一个实时分析引擎. "这是否也意味着" 它对于在一个单一内生成报告没有用网页请求 ",或者这个博客更有可能说它对实时应用程序(在线游戏等)没用？
我也看过Quicksight,但它似乎更适合为我们自己构建业务仪表板,而不是为我们的用户生成报告.
鉴于上述信息,您将如何解决这个问题？Redshift是一个明显的答案,我上面关于实时不利的担忧是没有意义的吗？在这样的情况下,是否有其他服务或工具或方法对您更有意义？
这绝对意味着 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 数据。
如果您的用户需要真正的“实时”报告，这可能会破坏交易。但如果它们的工作时间为数天或数周，那么为了获得快速加载的报告，一个小时左右的延迟是值得的。