0

我查看了谷歌云https://cloud.google.com/bigtable/docs/schema-design-time-series的时间序列论文以及基于 hbase 的 opentsdb 的方案设计，与 bigtable 非常相似。

opentsdb 的方案设计使用了很多技巧，将数据点和行键编码为宽行，从而使每个数据点的大小更小。但在谷歌的论文中只是建议使用窄行。

我的问题是，我能否从 opentsdb 方案设计中获得一些真正的好处，用于使用 bigtable 进行时间序列存储。而且，bigtable 的压缩真的可以帮助我消除冗余，从而使 opentsdb 模式几乎没有什么区别吗？

4

2 回答 2

3

为您的应用程序设计模式通常非常适合您的需求。您可以提出一般性建议，但对于您的特定应用，采用完全不同的设计可能会更好。

StumbleUpon 甲板和 MapR 的视频（如下）中的许多建议都是出色的设计理念，并未包含在时间序列论文中。要回答您的问题：

  1. 我可以从使用 bigtable 的时间序列存储的 opentsdb 方案设计中获得一些真正的好处吗？

是的 - OpenTSDB 的设计理念是好的理念，并且与 Cloud Bigtable 论文兼容。

  1. bigtable 的压缩真的可以帮助我消除冗余，从而使 opentsdb 架构几乎没有什么区别吗？

Cloud Bigtable 的压缩带来了很大的不同。（即使有冗余，较小的东西通常会比较大的东西压缩得更小。）

架构设计

Google时间序列论文中包含工程团队的建议，并且受益于多年使用 Bigtable 设计的经验。

当然，您应该从HBase 和 Schema Design和Designing your Schema for Cloud Bigtable开始。Ian Varley 的硕士论文No Relation: The Mixed Blessings of Non-Relational Databases也值得一读。

时间序列设计

Cloudera 有一个关于 Schema 案例研究的好章节，其中讨论了时间序列。

OpenTSDB 设计

MapR 的HBase Key Design with OpenTSDB视频很短，值得一看。研究 OpenTSDB 有一个来自 StumbleUpon的有趣的套牌。

于 2015-12-02T04:32:21.423 回答
0

在白皮书 -时间序列数据的 Cloud Bigtable 架构设计- 我们出于三个原因推荐窄行。

第一个原因并非特定于 Cloud Bigtable。默认情况下，我们建议使用窄行，每行一个事件，因为这使您的查询易于实现，因此您的应用程序更易于开发、测试和维护。我们建议仅将宽行作为一种优化，它不会混淆您的查询并改进应用程序的某些可衡量方面。

第二种观点特定于 Cloud Bigtable。我们建议使用窄行，因为如果您使用宽行，尤其是包含可能无限数量的事件的行，您很容易或意外地遇到Cloud Bigtable 的最大建议行大小 100MB，这可能会导致性能问题。

第三个观点是观察到 Apache HBase 和 Cloud Bigtable 是 HBase 接口的不同实现。对 Apache HBase 表现良好的优化可能不适用于 Cloud Bigtable，反之亦然。白皮书总结了多年来在 Google 内部运行 Bigtable 的经验教训，通常发现窄行优于宽行。

很好的问题，深刻而中肯，谢谢你的提问。

于 2015-12-02T02:41:08.823 回答