python - 一旦我们的数据库变得太慢，我该如何创建按需报告？

Question

我们的应用/数据

我们有一个 Python 应用程序，在 Transaction 中包含 User，其中包含 Commission、Fee，等等，Contacts 接收 EmailMessages，以及哪些 Activitys 发生在(Document uploaded , Status 变化等)。

我们的报告

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

我们的问题

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

我正在考虑的解决方案

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

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

我应该看哪里？

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

我也看过 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 数据。

如果您的用户需要真正的“实时”报告，这可能会破坏交易。但是，如果它们以数天或数周为单位工作，那么为了获得快速加载报告，延迟一个小时左右是值得的。