存储
时间序列数据存储的存储优化策略
存储时间序列数据应该取决于数据的使用方式及其年代。发现保存数据用于比较分析、机器学习和其他目的的技巧。
我们使用数据的方式会随着时间和场景的变化而变化。以时间序列数据为例。这类数据包括性能监控信息、物联网传感器的测量、移动设备的流位置数据和其他数据，这些数据将时间作为其独特识别特征的一部分。
最近产生的时间序列数据尤其如此在分析数据流时非常有用对于异常情况或向靠近企业的移动设备发送优惠券。这样的数据可能非常有价值，至少在短时间内是如此。只有当消息在即将发生的事件之前到达时，才会向工程师发送关于磁盘即将耗尽空间的警告。同样，如果优惠券是在顾客回家后才寄到，那么它就没有那么有价值了。
在创建用于检测异常的统计和机器学习模型时，时间序列数据存储是必不可少的。有了足够的数据，算法可以检测出典型的重大事件之前的模式。磁盘空间不足很容易预测；从因总体趋势或季节变化而变化的数据中进行推断需要更细致的建模方法。建模方法越复杂，就越有可能从附加数据中获益。
甚至在机器学习成为企业IT工具箱的常规部分之前，较旧的时间序列数据就可用于分析。例如，比较一家商店当月的销售额与上一年同月的销售额是评估业绩的常用方法。如果你看看整体趋势，比如说过去六个月，那么显示数据的可视化一天的聚合水平可能无法与使用一分钟测量水平的聚合水平区分开来。
管理者可以利用使用时间序列数据的不同方式来优化存储成本和使用数据的应用程序的性能。
最近生成的时间序列数据
最近的时间序列数据是最有可能被使用的信息，并且应该能够以低延迟访问它。在某些情况下，例如流处理，这可能需要在将数据写入持久存储之前使用内存缓存来存储数据。在异常检测应用程序和其他需要在一个狭窄的时间窗口内检测和响应的应用程序中可能会出现这种情况。
当时间序列数据被持久化时，您需要考虑如何查询它。例如，您是否通常根据其他值（如客户、传感器或位置标识符）查询时间序列数据存储？理想情况下，可能同时访问的数据存储在一起，例如在同一分区或数据库碎片中。
同时，您希望避免将太多数据写入单个分区或碎片。这可能会导致将串行I/O操作热点定位或隔离到少量存储组件，而不是并行化操作跨越许多不同的组件。
对于宽列NoSQL数据库，如谷歌Cloud Bigtable和Apache Cassandra，这是一个常见的问题。但这种情况可能发生在任何分布式数据存储中，甚至是水平可伸缩的关系数据库谷歌Cloud Spanner。
年长的时间序列数据
当您不再可能在细粒度级别访问旧数据时，您应该这样做考虑聚合并将其储存起来。
我们使用数据的方式随着时间和用例的变化而变化。这给我们提供了一个机会，可以调整我们的存储产品，以降低成本，同时优化数据的使用方式。
例如，考虑如何使用前一时期的时间序列数据。你可能会将一年前的日交易量或费率与最近的数据进行比较，但你很少(如果有的话)将一年前的数据与一分钟的数据进行比较。在这种情况下，可以计算时间序列数据存储中的每日聚合，并将其存储在低延迟存储中，以便进行查询。
简单的总数和计数往往就足够了。但是，如果您需要更多关于您正在聚合的数据的信息，您可以使用描述性统计，例如均值和标准偏差，来描述原始数据的分布。
机器学习
聚合对于满足不需要细粒度细节，但训练机器学习模型取决于大量的详细数据。对于这个用例，在模型训练需要细粒度数据之前，将其存储在低成本的存储上是有意义的。因为模型训练可以利用GPU和其他加速器，所以一个挑战是保持这些设备以其可以处理的速率提供数据。
例如，谷歌在谷歌Cloud中为数据设计了近线存储(Nearline Storage)，这些数据不太可能每个月被读取一次以上，这使其成为大容量、长期存储的理想选择。当机器学习任务需要数据时，您可以将其复制到低延迟的持久磁盘，以便通过培训程序直接访问。
我们使用数据的方式随着时间和用例的变化而变化。这给我们提供了一个机会，可以调整我们的存储产品，以降低成本，同时优化数据的使用方式。这同样适用于时间序列数据存储，也适用于其他业务数据。
