我正在构建一个应用程序（使用Django的ORM）来摄取很多事件，比方说50 / s（每个消息1-2k）。最初对事件的一些“实时”处理和监视是在范围内的，所以我将使用redis来保留一些数据来做出决定，在有意义时将它们删除。我现在要坚持所有实体，包括Postgres中用于“静止”存储的事件。
将来我需要仪表板和其他功能的“分析”功能。我想使用Amazon Redshift。我考虑过直奔Redshift并跳过Postgres。但我也看到人们说它应该扮演更多的被动角色。也许我可以在SQL后端保留一个数据窗口并定期存档到Redshift。
我的问题是：
使用像Redshift这样的东西作为Web应用程序的后端是否正常，或者它通常扮演更多的被动角色？如果不是这样认为我可以扩展Postgres足以让事件数据只从那开始？如果没有，“数据和档案窗口”方法是否有意义？
编辑以下是我在撰写帖子之前看过的一些内容：
答案 0 :(得分：3)
Redshift（ParAccel）是一个经过OLAP优化的数据库，它基于一个非常旧版本的PostgreSQL的分支。
擅长并行化读取大多数数据的查询。它在许多小事务中都很糟糕，特别是在典型的OLTP工作负载中看到的许多小写事务。
你介于两者之间。如果您不介意数据丢失窗口，那么您可以合理地累积数据点，并在正常大小的事务中为Redshift创建一个或两个写入线程。
如果您无法承担任何数据丢失窗口，并且期望处理50+ TPS，那么请不要考虑直接使用Redshift。仅往返费用就是可怕的。使用本地数据库 - 甚至是您定期轮换的基于文件的附加日志。然后定期将新数据上传到Redshift进行分析。
您可能不应该直接使用Redshift的其他一些好理由：
具有列存储设计的OLAP DB通常最适合使用星型模式或类似结构。这样的模式对于OLTP工作负载来说速度慢且效率低，因为插入和更新会触及许多表，但它们会使各种轴上的数据查询更加高效。
使用ORM与OLAP DB通信是一个问题。 ORM在OLTP优化的DB上非常糟糕，他们不幸倾向于n + 1 SELECT s和/或浪费的链式左连接，倾向于做许多小插入而不是几个大插件等。这将是在大多数OLAP优化的数据库上更糟糕。
Redshift基于一个痛苦的旧PostgreSQL，具有一系列限制和不兼容性。为普通PostgreSQL编写的代码可能无法使用它。
我个人完全避免使用ORM - 我只是在SQLite或本地PostgreSQL中本地累积数据，发送多值INSERT或使用PostgreSQL＆＃39 ; s COPY在我从内存缓冲区收到数据时加载数据块。然后，我使用适当的ETL工具定期转换来自本地数据库的数据，并将其与分析服务器上已有的数据合并。
现在忘记我刚刚说过的所有内容，然后通过模拟应用程序的工作量来做一些基准测试。这是唯一真正有用的方法。
答案 1 :(得分：0)
除了Redshift缓慢的事务处理（按照现代数据库标准）之外，还有另一个巨大的挑战：
Redshift仅支持serializable事务隔离，这很可能是折衷方案，以支持ACID事务，同时还优化了并行OLAP读取次数最多的工作负载。
这可能导致各种与并发相关的故障，而这些故障在默认情况下不是支持读取提交隔离的典型数据库上的故障。