时间序列存储设计

Question

我查看了google cloud Bootstrapper.cs的时间序列文件以及opentsdb的方案设计，它基于与bigtable非常相似的hbase。

opentsdb的方案设计使用大量技巧将数据点和行键编码为宽行，以使每个数据点的大小更小。但在谷歌的文章中建议使用窄行。

我的问题是，我可以从openntsdb方案设计中获得一些真正的好处，用于使用bigtable进行时间序列存储。并且，bigtable的压缩是否可以帮助我删除冗余，以便opentsdb模式产生很小的差异？

Answer 1

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

StumbleUpon平台和MapR的视频（下面）中的许多建议都是时间序列文件中未包含的优秀设计理念。回答你的问题：

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

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

1. 对bigtable的压缩是否可以帮助我删除冗余，以便opentsdb架构产生很小的差异？

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

架构设计

Google Time Series paper拥有工程团队的建议，并且拥有多年使用Bigtable设计经验的好处。

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

时间序列设计

Cloudera有一个很好的chapter on Schema case studies谈论时间序列。

OpenTSDB设计

MapR＆＃39; HBase Key Design with OpenTSDB视频很短，值得一看。 查看OpenTSDB，StumbleUpon有一个interesting deck。

Answer 2

在白皮书中Cloud Bigtable Schema Design for Time Series Data - 出于三个原因，我们建议使用窄行。

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

第二个视角特定于Cloud Bigtable。我们建议使用窄行，因为如果您使用宽行，尤其是包含可能无限数量事件的行，您可能会轻易地或意外地遇到导致性能问题的maximum recommended row size for Cloud Bigtable of 100MB。

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

很好的问题，深刻而且相关，谢谢你提出来。