【问题标题】:Pros & cons of BigQuery vs. Amazon Redshift [closed]BigQuery 与 Amazon Redshift 的优缺点 [关闭]
【发布时间】:2014-12-08 01:16:42
【问题描述】:

比较 Google BigQuery 与 Amazon Redshift 表明,两者都可以满足相同的要求,主要是成本计划不同。与可能存在连接表问题的 Google BigQuery 相比,Redshift 的配置(定义键和优化工作)似乎更复杂。

是否有 Google BigQuery 与 Amazon Redshift 的优缺点列表?

【问题讨论】:

标签: google-bigquery amazon-redshift


【解决方案1】:

我在 reddit 上发布了这个比较。一位长期的 RedShift 实践者很快就对我的陈述发表了评论。完整对话请见https://www.reddit.com/r/bigdata/comments/3jnam1/whats_your_preference_for_running_jobs_in_the_aws/cur518e

调整集群规模:

  • Redshift 会要求您选择多个 CPU、RAM、HD 等并打开它们。
  • BigQuery 不在乎。随时使用,无需配置。

什么都不做时的每小时成本:

  • Redshift 会要求您按每小时运行的每台服务器付费,即使您什么都不做。
  • 闲置时,BigQuery 每月存储的每 GB 费用仅为 0.02 美元。每月每 GB 2 美分,仅此而已。

查询速度:

  • Redshift 性能受您购买的 CPU 数量的限制
  • BigQuery 以透明的方式引入所需的资源,以便在几秒钟内运行您的查询。

索引:

  • Redshift 会要求您根据特定条件索引(更正:分发)您的数据,并且您将只能基于此索引运行快速查询。
  • BigQuery 没有索引。每个操作都很快。

抽真空:

  • Redshift 需要持续数小时的定期维护和“真空”操作。您需要为每个服务器小时付费。
  • BigQuery 没有。忘掉“吸尘”吧。

数据分区和分发:

  • Redshift 要求您考虑如何在服务器内分配数据以保持性能 - 优化仅适用于某些查询。
  • BigQuery 没有。只需运行您想要的任何查询。

流式传输实时数据:

  • Redshift 不可能(?)。
  • BigQuery 可以轻松处理每张表每秒最多提取 100,000 行。

发展你的集群:

  • 如果您有更多的数据,或者更多的并发用户使用 Redshift 进行扩展会很痛苦。
  • BigQuery 可以正常工作。

多区:

  • 您想要一个多区域 Redshift 以确保可用性和数据完整性?很痛苦。
  • BigQuery 默认是多区域的。

要试用 BigQuery,您不需要信用卡或任何设置时间。试试看 (quick instructions to try BigQuery)。

当您准备好将自己的数据放入 BigQuery 时,只需将 JSON 换行符分隔的日志从 Google Cloud Storage 复制并导入即可。

请参阅此云上数据仓库定价的深入指南: Understanding Cloud Pricing Part 3.2 - More Data Warehouses

【讨论】:

【解决方案2】:

Amazon Redshift 是一个标准 SQL 数据库(基于 Postgres),具有允许其扩展的 MPP 功能。这些功能还要求您在一定程度上符合您的数据模型以获得最佳性能。它支持大量的 SQL 标准,大多数可以与 Postgres 对话的工具都可以原封不动地使用它。

BigQuery 不是数据库,in the sense that there it doesn't use standard SQL and doesn't provide JDBC/ODBC connectivity。这是一项具有自己的 API 和接口的独特服务。它为 SQL 查询提供有限的支持,但大多数用户通过自定义代码(Java、Python 等)进行交互。一些第 3 方工具添加了对 BigQuery 的支持,但现有工具如果不进行修改将无法运行。

tl;dr - Redshift 更适合与现有工具交互和使用复杂的 SQL。 BigQuery 更适合自定义编码交互和不喜欢 SQL 的团队。

2017-04-17 更新 - 这是成本和速度差异的最新摘要(包含在销售宣传中,因此 YMMV)。 TL;DR - 如果您定期查询数据,Redshift 通常会更快并且更便宜。 http://blog.panoply.io/a-full-comparison-of-redshift-and-bigquery


更新 - 由于我一直对此(?‍♂️)投反对票,因此这里是对另一个答案中项目的最新回复:

调整集群规模:

  • Redshift 允许您根据使用情况调整成本。如果您想要尽可能快的查询,请选择 SSD 节点,如果您想要尽可能低的每 GB 成本,请选择 HDD 节点。从小处着手,随时添加节点。

什么都不做时的每小时成本:

  • Redshift 让您的集群为查询做好准备,可以在几毫秒内做出响应(结果缓存),并提供简单、可预测的月度账单。
  • 例如,即使某个脚本在周末意外运行了 10,000 个巨型查询您的 Redshift 账单也不会增加

查询速度:

  • Redshift 的性能绝对在同类产品中是最好的,并且一直在变得更快。在过去 6 个月内速度提高了 3-5 倍。

索引:

  • Redshift 没有索引。它允许您定义排序键以将性能从快速优化到超快。

抽真空:

  • Redshift 现在会在您的集群有可用资源时自动运行例行维护,例如 ANALYZE 和 VACUUM DELETE。

数据分区和分发:

  • Redshift 从不需要分发。它允许您定义分发键,即使是巨大的连接也可以非常快速。
  • {向竞争对手询问加入绩效...}

流式传输实时数据:

  • Redshift 有 2 个选择
    • 使用 Amazon Kinesis Firehose 将实时数据流式传输到 Redshift。
    • 完全跳过摄取,使用 Redshift Spectrum 外部表在 S3 着陆(并且高速)后立即在 S3 上查询您的实时时间。

发展你的集群:

  • Redshift 可以在几分钟内弹性调整大多数集群的大小。

多区:

  • Redshift 可以无缝替换任何出现故障的硬件并持续备份您的数据,包括跨区域(如果需要)。

【讨论】:

  • BQ 是一个柱状分布式数据库。可以使用它自己的 SQL 口音轻松查询。主要区别在于易于与标准 db、etl、ui 工具集成,这里 redshift 具有较小的优势。并且管理所需的工作量,这里 bq 有一些优势。
  • 好吧,公平点,BQ技术上是一个“列式数据库”,实际上不是支持 JDBC/意义上的“数据库”/来自无数现有工具的 ODBC 连接。
  • 它已经存在了三年,并且建立在与 Google 自己使用的完全相同的技术之上。为什么你会认为它会被放弃? Google 是否放弃了其他云技术?
  • BigQuery 使用非常类似于 SQL 的语法,因此您的陈述“BigQuery 更适合自定义编码交互和不喜欢 SQL 的团队”。不准确。
  • 它现在也具有 ODBC 连接性。不确定它是否在此讨论期间之前存在。 cloud.google.com/bigquery/partners/simba-drivers
猜你喜欢
  • 1970-01-01
  • 1970-01-01
  • 1970-01-01
  • 2010-09-14
  • 2011-10-24
  • 2012-11-06
  • 2010-10-06
  • 1970-01-01
  • 1970-01-01
相关资源
最近更新 更多