我的大多数平台都位于Google Cloud上，我们对此感到非常满意。但就目前而言，在我看来，尽管BigQuery (BQ)可以处理不可思议的数据量，但它仅在价格和性能方面能在狭窄的场景中正常运行。在考虑更改为Redshift时，我想分享一下我的结论（可能是错误的），以免引起误解。
以下是部分内容以及我们的结论：
stream数据到BQ。尺寸内容可能会更改，并且更改必须流式传输到BQ。record X更改为“ steve”，而不是“ John”，然后更改为“ Robert”。由于这些limitations，流到BQ的挑战在于，您必须至少等待30分钟才能再次DML记录X（尽管DML在42分钟后出现了缓存错误）。因此，我们需要建立的不仅仅是队列，因为第三个DML不需要等待30分钟，而第二个DML必须被忽略。insert/*个操作（不允许delete/delete, delete/update, update/update），因此所有非insert DML流操作都必须为serialized。DML latency是一个巨大的问题。可以流insert，也很容易bulk insert，但是流delete或update每次操作将花费您半秒的时间，并且在表的基础上必须为serialized。因此，如果系统中发生了许多updates，则queue可能永远不会结束。BQ能够处理“对查询延迟极为敏感的工作量”，但在我看来，这在很大程度上取决于您的用例。对于我的用例（较小的resultset），SQL的等待时间太长，对于一个小的查询，只有两秒的延迟。resultset上运行数百个小型datasets查询的情况。您需要为在scan上访问的数据列付费（但请记住，没有索引）。如果您在60KB resultset上有120GB dataset，则无论filter condition is的精确度如何，您都需要为120GB付费（您可以尝试使用sharding来避免， partition，rollup temporary tables和其他技术，但是当一组非常基本的索引可以完成工作时，它将增加您的复杂性。当然，光明的一面是BQ是完整的serverless，没有基础架构复杂性，没有调优，没有索引，没有对高可用性的担心，而且存储价格合理。
据我所知，如果您想要低延迟，如果您的数据更改（甚至很少更改），如果用例不要求您扫描大量数据，则应避免使用{{1} }。
欢迎任何考虑。
[edit]：小BQ但大Resultset。因此，postgree可能不是我们想要去的地方的选择。
答案 0 :(得分：0)
作为后续，我已经了解了我在原始帖子中提到的问题的一些观点。
尽管我认为我写的是正确的，但我提到的大多数问题的解决方案都不是Redshift。您将解决几个问题，创建两个其他问题，并且仍然会面对其中大多数问题。
因此，关于我对Redshift的理解，并最终决定继续使用BQ（公开：我在BQ上做了很多工作）
Redshift DML延迟与BQ一样糟糕。原因不同，症状几乎相同。如this文档所述，您可以为已更新的每一列存储1 MB。BQ相比，基础架构方面的细节太多Oracle在十年前已经solved解决了这个问题。 Google BQ以完全不同的方式面对问题，separating来自处理层的存储层。随着postgre的发展，Redshift保留了一些DDL约束语言（例如主键），它们不仅无害，而且在使用select distinct时会产生错误的输出。arrays之类的复杂结构。看来spectrum的Redshift可以访问S3中的外部数据，但这不是我们想要的。Redshift中流数据似乎比BQ复杂得多。从好的方面来说，如果您超过20％的时间使用DW，这将是cheaper，这是我的情况，您将发现更多的BI工具覆盖率。
如果流数据和DML延迟非常重要，或者您需要较小结果集上的SQL延迟，那么使用Oracle或其他非列式DW可能会更好。
答案 1 :(得分：-1)
免责声明 ：我从事GCP支持工作，所以我对Redshift不太熟悉，这也值得研究。
BigQuery主要是为分析而设计的，对于任何没有流式传输或附加的内容，您都会遇到更大的延迟。 如果您担心延迟，您还可以考虑使用BigTable，它提供的延迟比BigQuery低得多，并且可能更适合您的use-case。
而且，正如@AlexYes所说，如果您的数据不是那么大，那么最好的选择就是PostgreSQL。
编辑：如果您需要一个关系数据库，则在GCP中还有Cloud Spanner，它共享BigTable的许多构想但是关系数据库。即使没有这样宣传，它也具有一些分析功能。但是，它比BigQuery贵很多。