NoSQL、JSON 和时间序列数据管理: Anuj Sahni 访谈

时间序列数据是以固定的时间间隔按顺序排列的变量值。时间序列数据正从四面八方向我们涌来：传感器、移动设备、Web 追踪、财经事件、工厂自动化以及各种工具—只列举这几个吧。

时间序列数据管理最近比较受关注，InfoQ 采访了 Oracle NoSQL 数据库的高级产品经理 Anuj Sahni，请他介绍时间序列数据，以及如何对这种类型的数据建模。

InfoQ: 什么是时间序列数据，它跟结构化数据有什么区别？

Sahni: 时间序列是按统一的时间间隔采集的数据点序列。比如来自全球证券交易所的股票行情信息，定期采集的贵金属价格，按周期间隔采集的特定经 / 纬度的天气详情，从制造机械或石油钻井平台的传感器上源源不断输出的数据。时间序列信息不一定会跟结构化数据有什么不同，但它是 a) 数量和速度出众 b) 信息的稀疏性使得很难用传统的数据存储方式保存它，因为那种方式是为定义良好的结构化数据设计的。

InfoQ: 将一个数据集建模为时间序列数据有什么好处？

Sahni: 并不是所有的数据都需要用时间序列表示，但如果你有持续的信息项进来（比如说来自于传感器），并且你想要基于时间维度分析那些数据，那么比较稳健的做法是保留每条信息项的到达时间，并为之建立索引以便提高查询速度。

InfoQ: 为了把时间序列类型的数据保存在我们的数据库中，设计时要考虑哪些问题？

Sahni: 时间序列数据，一般来说，都是大量生产的，所以需要特别考虑如何保存在数据库中，以及如何很好地访问它们。所以你应该尽量事先明确数据的访问方式，比如在证券交易的演示中，我们知道每只股票的行情信息都是每秒生成一次的，即每只股票每天有 86K 的行情信息。如果我们把那么多条记录都各自存在不同的行中，那访问这些信息的时间复杂度将会非常巨大，所以我们可以按 5 分钟，1 小时，或者一天将这些记录分组为一条向量记录。把信息存在更大数据块里的好处显而易见，因为你要从 NoSQL 存储中获取特定时间段的数据时，所做的查询次数更少。还有一点需要记住，如果你开的窗口太小，那你就要做很多的读写操作；如果太大，那耐久力就是个问题，如果出现系统故障，你就要有信息丢失了。所以你得掌握好两者的平衡。

InfoQ: 在使用时间序列数据时，开发人员应该遵循什么样的设计或架构模式呢？

Sahni: 在设计任何一个时间序列应用时，最重要的就是要了解客户端应用的访问模式，以及它所要求的信息粒度。尽管我们可能需要持久化所有的时间序列数据，但一般我们不需要把每个数据点都存成数据库里的单独记录。如果我们可以定义一个时间窗口，然后把那个时间段的所有读取都存为一个数组，那么我们可以极大削减存储在数据库中的实际记录数量，提升系统的性能。继续前面那个例子，如果每支股票每天生成 84K 的数据点，那么你在访问这些信息时就需要在硬盘上做很多的随机 I/O，简直太多了，但如果你可以把同样的信息存为一个数组，每个数组放一个小时的信息，那么取一天的数据只需要查询 24 次就行了。

另外一个需要平衡的是数组对象的大小 (不管是 JSON, XML 还是其他什么东西)。你应该不想让数组的窗口大小大到最终返回的数据超出你的需要太多，那样就浪费了宝贵的带宽。但如果你把窗口定的太精细，那很可能会降低吞吐量，并增加系统的延迟。所以要处理好两边的平衡，得出合适的时间窗口大小，从 / 往数据库中读 / 写时间序列数据集合。

InfoQ: 把数据集存为时间序列数据有什么限制吗？

Sahni: 我得说处理时间序列数据所面临的真正挑战是基于需求和访问模式微调系统。如果将来访问模式变了，那你可能必须重建索引，重新计算数组的大小来优化查询。所以每个时间序列应用的定制性都非常强，你可以采用最佳实践，但却不能指望只通过引入数据建模模板来解决不同的时间序列问题。

Anuj 还在去年的 JavaOne 大会上讲了如何在应用中管理时间序列数据。

关于受访者

Anuj Sahni是 Oracle 的高级产品经理 **，他负责管理公司在NoSQL数据库和大数据产品上的领导地位。**Anuj 在世界 500 强公司里有超过 12 年的产品管理 / 开发经验。他领导过高度成功的、分布在全球的跨职能团队开发新软件和基于云的服务。Anuj 在佛罗里达大学取得了计算机工程硕士学位，还在生物信息学领域发表过学术论文。在闲暇时，他喜欢骑行、追踪，还有跟他的两个女儿玩。

查看原文链接： NoSQL, JSON, and Time Series Data Management: Interview with Anuj Sahni