Redshift作为Web App后端吗？

Question

我正在构建一个应用程序（使用Django的ORM），该应用程序将吸收很多事件，比如说50 / s（每msg 1-2k）。最初是对事件进行一些“实时”处理和监视，因此我将使用Redis保留一些数据来制定决策，并在有意义的时候删除它们。我打算保留所有实体，包括Postgres中用于“静止”存储的事件。

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

我的问题是：

使用Redshift之类的东西作为Web应用程序的后端甚至是正常的，还是通常起着被动的作用？如果不是这样，认为我可以对Postgres进行足够的缩放以使事件数据仅以此为起点是不现实的？如果没有，“数据和归档窗口”方法是否有意义？

编辑这是我写这篇文章之前见过的一些东西：

• 有人对我应该使用Redshift回答这个问题说“是的”。
• 有人说“对于大多数Web应用程序来说性能不足”，并通过postgres数据库阵营支持它的前端。

Answer 1

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

它擅长对大量数据进行并行读取查询。它不适合许多小型事务，尤其是典型 OLTP 工作负载中的许多小型写入事务。

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

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

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

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

• 使用 ORM 与 OLAP DB 对话是自找麻烦。ORM 在 OLTP 优化的数据库上已经很糟糕了，它们不幸倾向于 n+1SELECT和/或浪费链式左连接，倾向于进行许多小插入而不是一些大插入，等等。这在大多数情况下会更糟OLAP 优化的数据库。

• Redshift 基于非常旧的 PostgreSQL，有很多限制和不兼容性。为普通 PostgreSQL 编写的代码可能不适用于它。

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

现在忘记我刚才所说的一切，通过模拟应用程序的工作负载来进行一些基准测试。这是唯一真正有用的讲述方式。