我正在构建一个应用程序(使用 Django 的 ORM)，它将摄取大量事件，比如说 50/s(每条消息 1-2k)。最初，事件的一些“实时”处理和监视在范围内，因此我将使用 redis 来保留一些数据以做出决策，并在有意义时删除它们。我打算保留所有实体，包括 Postgres 中的事件，暂时用于“静态”存储。
将来我需要仪表板和其他功能的“分析”功能。我想为此使用 Amazon Redshift。我考虑过直接使用 Redshift 并跳过 Postgres。但我也看到有人说它应该更多地扮演一个被动的角色。也许我可以在 SQL 后端保留一个数据窗口并定期存档到 Redshift。
我的问题是:
使用像 Redshift 这样的东西作为网络应用程序的后端是正常的还是它通常扮演更被动的角色？如果不是，那么认为我可以将 Postgres 扩展到足以让事件数据仅以此为起点是否现实？另外，如果没有，“数据和归档窗口”方法是否有意义？
编辑以下是我在写这篇文章之前看到的一些东西:
- 有人说 "yes go for it"关于这个问题我应该使用 Redshift。
- 有人说 "eh not performant enough for most web apps"并支持使用 postgres 数据库阵营。
最佳答案
Redshift (ParAccel) 是一个 OLAP 优化的数据库，基于非常旧版本的 PostgreSQL 的一个分支。
它擅长跨大量数据并行化以读取为主的查询。它不适合许多小事务，尤其是在典型的 OLTP 工作负载中看到的许多小写事务。
你介于两者之间。如果您不介意数据丢失窗口，那么您可以合理地积累数据点，并在适当大小的事务中使用一个或两个写入线程将它们写入 Redshift。
如果您无法承受任何数据丢失窗口并期望处理 50+ TPS，则不要考虑直接使用 Redshift。光是往返费用就已经很恐怖了。使用本地数据库 - 甚至是您定期轮换的基于文件的仅附加日志。然后定期将新数据上传到 Redshift 进行分析。
您可能不应该直接使用 Redshift 的其他一些充分理由:
具有列存储设计的 OLAP 数据库通常最适合星型模式或类似结构。此类模式对于 OLTP 工作负载来说速度慢且效率低下，因为插入和更新会触及许多表，但它们使得沿各个轴查询数据以进行分析更加高效。
使用 ORM 与 OLAP 数据库对话是自找麻烦。 ORM 在 OLTP 优化的 DB 上已经够糟糕了，它们不幸倾向于 n+1
SELECT和/或浪费链式左连接，倾向于做很多小插入而不是一些大插入，等等. 这在大多数 OLAP 优化的数据库上会更糟。Redshift 基于令人痛苦的旧 PostgreSQL，具有许多限制和不兼容性。为普通 PostgreSQL 编写的代码可能不适用于它。
就我个人而言，我会为此完全避免使用 ORM - 我只是在本地 SQLite 或本地 PostgreSQL 或其他东西中累积数据，发送多值 INSERT 或使用 PostgreSQL 的 COPY 以加载我从内存缓冲区接收到的数据 block 。然后，我会使用适当的 ETL 工具定期转换本地数据库中的数据，并将其与分析服务器上已有的数据合并。
现在忘记我刚才说的一切，并通过模拟应用的工作负载来做一些基准测试。这是唯一真正有用的判断方式。
关于django - Redshift 作为 Web 应用后端？，我们在Stack Overflow上找到一个类似的问题： https://stackoverflow.com/questions/26979927/