大规模、基于时间序列的聚合操作的架构和模式答案

【问题标题】：Architecture and pattern for large scale, time series based, aggregation operation大规模、基于时间序列的聚合操作的架构和模式
【发布时间】：2011-08-11 13:23:44
【问题描述】：

我将尝试描述我的挑战和操作：我需要计算历史时期的股票价格指数。例如，我将选取 100 只股票并计算它们去年每秒（甚至更少）的总平均价格。我需要像这样创建许多不同的指数，其中股票是从 30,000~ 种不同的工具中动态挑选出来的。

主要考虑的是速度。我需要尽快输出几个月的这种索引。

出于这个原因，我认为传统的 RDBMS 太慢了，因此我正在寻找一种复杂且原始的解决方案。

这是我想到的，使用 NoSql 或面向列的方法：将所有股票分配到某种时间键值对中：价格与所有它们匹配的时间行。然后使用某种地图缩减模式来仅选择所需的股票并汇总它们的价格，同时逐行读取它们。

我想要一些关于我的方法的反馈、对工具和用例的建议，或者对完全不同的设计模式的建议。我对解决方案的指导方针是价格（希望使用开源）、处理大量数据的能力以及快速查找（我不关心插入，因为它只进行一次并且永远不会改变）

更新：快速查找并不是指实时，而是相当快速的操作。目前我需要几分钟来处理每天的数据，这相当于每年计算几个小时。我想在几分钟内完成。

【问题讨论】：

数据只是历史数据，还是更新非常频繁，您总是需要最新数据进行计算？
每种仪器和每年的价格是多少？您的系统是否有足够的内存来保存内存中的所有内容，或者是否需要磁盘访问？
@nitin 仅历史记录。对于实时，我使用 CEP 引擎。
@codo 我认为将引号减少到基于秒或毫秒的行。所以只需计算一年中有多少秒（8 小时工作日）
对不起，我的评论中有错字。我想知道在特定时间段内必须处理每种工具的多少价格（而不是会产生多少价格）。处理的每个时间序列的典型时间段是多少？（你提到了处理一天的数据……）

标签： database design-patterns architecture nosql

【解决方案1】：

过去，我参与过多个项目，这些项目涉及使用不同存储技术（文件、RDBMS、NoSQL 数据库）对时间序列进行存储和处理。在所有这些项目中，关键是确保时间序列样本按顺序存储在磁盘上。这样可以确保快速读取数千个连续样本。

由于您似乎有中等数量的时间序列（大约 30,000），每个都有大量样本（每秒 1 个价格），一个简单而有效的方法可能是将每个时间序列写入一个单独的文件。在文件中，价格按时间排序。

然后您需要为每个文件建立一个索引，以便您可以快速找到文件中的某些时间点，而无需在您只需要某个时间段时从头开始读取文件。

通过这种方法，您可以充分利用当今的操作系统，这些操作系统具有大型文件缓存并针对顺序读取进行了优化（通常在检测到顺序模式时提前读取文件）。

聚合多个时间序列涉及将每个文件中的某个时间段读取到内存中，计算聚合后的数字并将它们写入某处。要充分利用操作系统，请一一读取每个时间序列的全部所需时间段，不要尝试并行读取它们。如果您需要计算较长的周期，请不要将其分解为更小的周期。

您提到当您将价格减少到每秒一个时，您每天有 25,000 个价格。在我看来，在这样的时间序列中，许多连续价格将与很少有工具每秒交易（甚至定价）一次以上（除非您只处理标准普尔 500 股票及其衍生品）相同。因此，额外的优化可能是通过仅在价格确实发生变化时存储新样本来进一步压缩您的时间序列。

在较低级别上，时间序列文件可以组织为由样本运行组成的二进制文件。每次运行都以第一个价格的时间戳和运行长度开始。之后，连续几秒钟的价格随之而来。每次运行的文件偏移量可以存储在索引中，这可以通过关系 DBMS（如 MySQL）来实现。该数据库还将包含每个时间序列的所有元数据。

（远离内存映射文件。它们速度较慢，因为它们没有针对顺序访问进行优化。）

【讨论】：

您建议使用基于文件的数据的相当低级的方法。为什么不利用像 hadoop 这样的现代系统的力量？
是的，这是一种低级方法，专为具有廉价存储的单个系统而设计。我对 Hadoop 了解不多，但它的主要目的是集群中的计算和存储。你没有提到你有一个计算机集群。我对时间序列处理的经验是，限制因素是 IO，而高性能的关键是对数据的物理布局进行大量控制。
如果速度是您最关心的问题，我认为这里列出的建议会继续下去。试图变得太花哨可能只会增加开销。

【解决方案2】：

如果您描述的场景是唯一要求，那么有一些“低技术”简单的解决方案，它们更便宜且更易于实施。首先想到的是LogParser。如果您还没有听说过，它是一个在简单 CSV 文件上运行 SQL 查询的工具。它的速度令人难以置信快 - 通常约为 500K 行/秒，具体取决于行大小和 HD 的 IO 吞吐量。

将原始数据转储到 CSV，通过命令行运行一个简单的聚合 SQL 查询，就大功告成了。很难相信它可以这么简单，但它确实如此。

关于 logparser 的更多信息：

【讨论】：

我喜欢你描述的那种简单直接的方法。但是您的描述中缺少的是如何选择要处理的时间段。 AltControl 的描述似乎表明时间序列很长，但一次只处理一小段时间。因此，有效地选择要处理的范围可能是必不可少的。 LogParser - 如果我理解正确的话 - 将从头到尾读取整个文件。
按日期/时间对输入文件进行分区（和名称）并仅对相关文件运行查询...任何日志文件处理的标准做法
二进制数据存储不是更高效吗？对于数值处理，字符串处理会增加很多开销。

【解决方案3】：

您真正需要的是一个内置时间序列功能的关系数据库，IBM 最近发布了一个 Informix 11.7（注意必须是 11.7 才能获得此功能）。更好的消息是，对于您正在做的免费版本，Informix Innovator-C 将绰绰有余。 http://www.freeinformix.com/time-series-presentation-technical.html

【讨论】：