【问题标题】:Availability of single-node Bigtables单节点 Bigtables 的可用性
【发布时间】:2018-07-13 08:40:15
【问题描述】:

我在一家公司工作,目前该公司拥有一个小型物联网网络。但是,预计该网络将在未来几年显着增长。在为未来做准备时,我们希望使用 Bigtables 来存储我们的数据,但我们的预算还没有考虑到运行 Bigtable 生产实例的成本。

鉴于此,我的问题是:即使文档说没有保证 wrt。开发实例的正常运行时间或性能,是否有可能在单个节点上运行数据库,直到需要生产实例?单节点Bigtable至少相对可靠,还是建立一个临时SQL数据库更好?

【问题讨论】:

  • 根据我的经验,单节点 Bigtable 对于指南中明确规定的工作负载(在 QPS/等方面)甚至超出此范围的工作负载非常健壮。尽管我从未运行过开发人员。请注意长时间,因此无法评论正常运行时间/等。如果您想节省成本,那么考虑构建一个 HBase 集群而不是临时 SQL,这将比最小的生产 Bigtable 集群便宜得多,但是您的代码和应用程​​序逻辑将在 if/when you are准备搬到 Bigtable。否则,使用 SQL 您必须更改所有内容。

标签: google-cloud-bigtable


【解决方案1】:

披露:我是 Google Cloud Bigtable 的产品经理。

鉴于此,我的问题是:即使文档说没有保证 wrt。开发实例的正常运行时间或性能,是否有可能在单个节点上运行数据库,直到需要生产实例?单节点Bigtable至少相对可靠,还是建立一个临时SQL数据库更好?

是否可以运行 Cloud Bigtable 开发实例?是的,我已经与与您处于同一位置的客户交谈过:他们喜欢数据模型和 API,并且知道他们可以在需要时进行扩展,但他们目前的情况并不需要3+ 节点生产集群,所以他们使用的是开发集群。

如果您这样做,您可能会出现更高的不可用情况,但这并不比使用另一个数据库(无论是 SQL 还是 NoSQL)运行单个 VM 更糟糕:任何事物中只有一个意味着可用性严重依赖于该数据库事情正在上升和可达。

事实上,Cloud Bigtable 的无状态特性实际上使这一点变得更好——因为数据实际上并没有存储在服务器节点本身,而是存储在我们的分布式复制文件系统 Colossus 上,我们可以(并且做)如果您的节点不可用,替换另一个 Bigtable 节点来为您的数据提供服务,而不会丢失任何数据。

也就是说,我们无法为开发集群提供 SLA 或任何保证正常运行时间或可用性,因此请记住这一点。

希望这会有所帮助。

【讨论】:

  • 谢谢,很有帮助!
猜你喜欢
  • 1970-01-01
  • 2018-06-12
  • 1970-01-01
  • 1970-01-01
  • 1970-01-01
  • 1970-01-01
  • 1970-01-01
  • 2012-09-01
  • 1970-01-01
相关资源
最近更新 更多