Redshift 作为 Web 应用后端？

Question

我正在构建一个应用程序（使用 Django 的 ORM），它将接收很多事件，比如说 50/s（每个 msg 1-2k）。最初，对事件的一些“实时”处理和监控在范围内，因此我将使用 redis 保留一些数据以做出决策，并在有意义时将其删除。我打算暂时保留所有实体，包括 Postgres 中的事件以用于“静态”存储。

将来我将需要仪表板和其他功能的“分析”功能。我想为此使用 Amazon Redshift。我考虑直接使用 Redshift 并跳过 Postgres。但我也看到人们说它应该扮演更多的被动角色。也许我可以在 SQL 后端保留一个数据窗口并定期归档到 Redshift。

我的问题是：

使用 Redshift 之类的东西作为 Web 应用程序的后端是否正常，或者它通常更多地扮演被动角色？如果不是，那么认为我可以扩展 Postgres 足以让事件数据仅从它开始是否现实？如果不是，“数据和档案窗口”方法是否有意义？

编辑以下是我在写这篇文章之前看到的一些事情：

• 有人说"yes go for it" 我应该使用 Redshift 来回答这个问题。
• 有人说"eh not performant enough for most web apps" 并支持前面有一个postgres 数据库 阵营。

Answer 1

Redshift (ParAccel) 是一个 OLAP 优化的数据库，基于一个非常旧的 PostgreSQL 版本的分支。

它擅长跨大量数据并行化以读取为主的查询。它不适合许多小型事务，尤其是在典型 OLTP 工作负载中看到的许多小型写入事务。

您介于两者之间。如果您不介意数据丢失窗口，那么您可以合理地累积数据点，并在相当大的事务中使用一个或两个写入器线程将它们写入 Redshift。

如果您无法承受任何数据丢失窗口并期望处理 50+ TPS，则不要考虑直接使用 Redshift。单是往返费用就太可怕了。使用本地数据库 - 甚至是您定期轮换的基于文件的仅附加日志。然后定期将新数据上传到 Redshift 进行分析。

您可能不应该直接使用 Redshift 的其他几个充分理由：

• 具有列存储设计的 OLAP DB 通常最适合星型模式或类似结构。对于 OLTP 工作负载，此类模式缓慢且效率低下，因为插入和更新涉及许多表，但它们使沿各个轴查询数据以进行分析的效率更高。

• 使用 ORM 与 OLAP DB 对话是自找麻烦。 ORM 在 OLTP 优化的 DB 上已经够糟糕了，不幸的是，它们倾向于 n+1 SELECTs 和/或浪费的链式左连接，倾向于执行许多小插入而不是几个大插入等。这将是均匀的在大多数 OLAP 优化的数据库上更糟糕。

• Redshift 基于一个令人痛苦的旧 PostgreSQL，具有许多限制和不兼容性。为普通 PostgreSQL 编写的代码可能无法使用它。

我个人会完全避免使用 ORM - 我只是在 SQLite 或本地 PostgreSQL 或其他东西中本地累积数据，发送多值 INSERTs 或使用 PostgreSQL 的 COPY 加载数据块当我从内存缓冲区中收到它时。然后我会使用适当的 ETL 工具定期转换本地数据库中的数据，并将其与分析服务器上已有的数据合并。

---

现在忘记我刚才所说的一切，去做一些基准测试，模拟您的应用工作负载。这是唯一真正有用的判断方式。

Answer 2

除了 Redshift 缓慢的事务处理（按照现代数据库标准）之外，还有另一个大挑战：

Redshift 仅支持serializable 事务隔离，很可能是作为支持 ACID 事务同时还针对并行 OLAP 主要读取工作负载进行优化的折衷方案。

这可能会导致各种与并发相关的故障，而这些故障在默认情况下支持读提交隔离的典型数据库上不会出现故障。