一旦对我们的数据库来说太慢了，我该如何创建按需报告？

Question

我们的应用/数据

我们有一个 Python 应用程序，其中 Transactions 中的 Users 具有 Commissions、Fees 等，其中 Contacts 接收 EmailMessages 和 Activity s 发生在（Documents 上传，Status 更改等）。

我们的报告

我们为客户生成电子表格报告，详细说明上传到交易的文件数量、赚取的各种佣金总额、收取的费用、活动等信息。在某些情况下，这些报告提供客户的统计数据帐户，用于给定年份中的每个月（每个月在电子表格中的单独行中）。

我们的问题

尽管我们努力优化查询、添加索引并且尽管我们只使用 SSD 并且有足够的 RAM 以将数据库装入内存。从本质上讲，我们已经达到了一些基本报告变得过于昂贵而无法针对我们的生产数据库作为简单聚合查询运行的规模。

我正在考虑的解决方案

1. 将统计信息非规范化到 Postgres 中的现有表中
2. Memcached 中的缓存统计信息
3. 通过将一些处理转移到 Python 中来减少/简化查询
4. 在队列中运行昂贵的报告并在准备好时通知管理员
5. 将统计信息存储在单独的报告表中（星型模式等）
6. 分片

我已经在一定程度上使用了上面的选项 1-4，但我想探索更多选项。另外，如果可能的话，我想完全停止使用选项 4，而且我不太热衷于实施选项 5（而不是简单地使用 Redshift 之类的东西）。在某些情况下，选项 6 是一个不错的选择，但我们目前还没有准备好采用。

我应该去哪里看？

我实际上开始研究 Redshift，但今天早上让我陷入困境的是阅读 (here) 说“它不是实时分析引擎。”这是否也意味着“ 它对于在单个 Web 请求中生成报告没有用”，或者这个博客更有可能声明它对实时应用程序（在线游戏等）没有用处？ p>

我也看过 Quicksight，但它似乎更适合为我们自己构建业务仪表板，而不是为我们的用户生成报告。

根据以上信息，您将如何解决这个问题？ Redshift 是显而易见的答案吗？我对不适合实时的上述担忧没有实际意义？在这种情况下，是否有其他一些对您更有意义的服务、工具或方法？

Answer 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 数据。

如果您的用户需要真正的“实时”报告，这可能是个大问题。但是，如果他们以数天或数周为单位工作，那么有一个小时左右的延迟是值得的，以获取快速加载的报告。