【文档数据库】时间序列数据与MongoDB:第一部分-简介

Chinese, Simplified

时间序列数据正日益成为现代应用的核心——比如物联网、股票交易、点击流、社交媒体等等。随着批量系统向实时系统的转变,对时间序列数据的有效捕获和分析可以使组织能够更好地检测和响应事件,领先于竞争对手,或提高操作效率,以降低成本和风险。使用时间序列数据通常不同于常规应用程序数据,您应该观察一些最佳实践。这个博客系列试图提供这些最佳实践,当你在MongoDB上构建你的时间序列应用程序:

  • 介绍时间序列数据的概念,并描述与这类数据相关的一些挑战
  • 如何查询、分析和呈现时序数据
  • 提供发现问题,帮助您收集成功交付时间序列应用程序所需的技术需求。

什么是时间序列数据?

虽然并非所有的数据在本质上都是时间序列,但越来越多的数据可以被归类为时间序列——这是由允许我们实时而不是批量利用数据流的技术所推动的。每个行业、每个公司都需要对时间序列数据进行查询、分析和报告。假设一个股票日内交易员不断地查看股票价格的feed,并运行算法来分析趋势和确定机会。他们在一段时间内查看数据,例如每小时或每天。联网的汽车公司可以获得发动机性能和能源消耗等遥测数据,以改进零部件设计,并监测磨损率,以便在问题发生前安排车辆维修。他们也会在一段时间内查看数据。

为什么时间序列数据具有挑战性?

时间序列数据可以包括以固定时间间隔捕获的数据(如每秒的设备测量),也可以包括以不规则时间间隔捕获的数据(如从警报和审计事件用例生成的时间间隔)。时间序列数据通常还带有诸如设备类型和事件位置之类的属性,并且每个设备可能提供数量可变的附加元数据。数据模型能够灵活地满足各种快速变化的数据摄入和存储需求,这使得具有严格模式的传统关系(表格)数据库系统难以有效地处理时间序列数据。此外,还有可伸缩性的问题。由于多个传感器或事件产生的高频率读数,时间序列应用程序可以产生大量的数据流,需要消化和分析。因此,允许数据向外扩展并跨许多节点分布的平台比扩展的单块表格数据库更适合这种用例。

时间序列数据可以来自不同的来源,每个来源生成需要存储和分析的不同属性。数据生命周期的每个阶段都对数据库提出了不同的要求——从摄入到使用和归档。

  • 在数据摄取期间,数据库主要执行写密集操作,主要包括偶尔更新的插入操作。当数据流在摄入期间检测到异常(例如超过某个阈值)时,数据使用者可能希望得到实时警报。
  • 随着越来越多的数据被摄入,消费者可能想要查询这些数据以获得具体的见解,并发现趋势。在数据生命周期的这个阶段,工作负载是读的,而不是写的,但是数据库仍然需要保持较高的写率,因为数据是并发地摄取然后查询的。
  • 消费者可能希望查询历史数据,并利用机器学习算法进行预测分析,以预测未来行为或识别趋势。这将对数据库施加额外的读取负载。
  • 最后,根据应用程序的需求,捕获的数据可能有一个保质期,需要在一段时间后进行归档或删除。

正如您所看到的,处理时间序列数据不仅仅是简单地存储数据,还需要广泛的数据平台功能,包括处理同时的读和写需求、高级查询功能和归档等等。

谁在使用MongoDB处理时间序列数据?

  • MongoDB提供了满足高性能时间序列应用程序需求所需的所有功能。定量投资管理公司Man AHL利用了MongoDB的时间序列能力。
  • Man AHL的Arctic应用利用MongoDB存储高频金融服务市场数据(大约每秒250M嘀嗒)。这家对冲基金经理的定量研究人员(“quants”)利用Arctic和MongoDB研究、构建和部署新的交易模型,以了解市场的行为。与现有的私有数据库相比,使用MongoDB, Man AHL节省了40倍的成本。除了节省成本之外,它们还能将处理性能比以前的解决方案提高25倍。Man AHL在GitHub上开源了他们的北极项目。
  • 博世集团是一家跨国工程集团,拥有近30万名员工,是全球最大的汽车零部件制造商。物联网是博世的一项战略举措,因此公司选择MongoDB作为物联网套件的数据平台层。该套件不仅为博世集团内部的物联网应用提供了动力,也为其在工业互联网应用领域的许多客户提供了动力,如汽车、制造业、智慧城市、精准农业等。如果您想了解更多关于管理由物联网平台生成的多样化、快速变化和高容量时间序列数据集所面临的主要挑战,请下载Bosch和MongoDB白皮书。
  • 西门子是一家专注于电气化、自动化和数字化领域的全球性公司。西门子开发了MongoDB支持的“Monet”平台,提供先进的能源管理服务。Monet使用MongoDB进行实时原始数据存储、查询和分析。

关注应用程序需求

在处理时间序列数据时,您必须投入足够的时间来理解如何创建、查询和过期数据。有了这些信息,您可以优化模式设计和部署架构,以最佳地满足应用程序的需求。

在没有捕获应用程序的需求的情况下,您不应该同意性能指标或sla。

当你开始你的时间序列项目与MongoDB,你应该得到以下问题的答案:

写工作负载

  • 摄入的速率是多少?每秒有多少次插入和更新?

随着插入速度的增加,您的设计可能会受益于通过MongoDB自动分片的水平扩展,允许您跨多个节点分区和扩展数据

  • 同时有多少客户端连接?

虽然单个MongoDB节点可以处理来自数以万计的物联网设备的同时连接,但您需要考虑通过分片将其扩展,以满足预期的客户机负载。

  • 需要存储所有原始数据点吗?还是可以预先聚合数据?如果是预聚合的,可以存储什么粒度或间隔的摘要级别?每分钟?每15分钟吗?

如果你的应用需要证明这一点,MongoDB可以存储你所有的原始数据。但是,请记住,通过预聚合减少数据大小将产生更低的数据集和索引存储,并提高查询性能。

  • 每个事件中存储的数据大小是多少?

MongoDB的单个文档大小限制为16 MB,如果你的应用程序需要在一个文档中存储更大的数据,比如二进制文件,你可能想要利用MongoDB GridFS。理想情况下,在存储大量时间序列数据时,最好保持文档大小较小,大约一个磁盘块大小。

阅读工作负载:

  • 每秒有多少读取查询?

更高的读取查询负载可能得益于额外的索引或通过MongoDB自动分片进行的水平伸缩。

与写卷一样,读卷可以通过自动分片进行缩放。还可以跨副本集中的辅助副本分布读取负载。

  • 客户是地理分散还是位于同一地区?

通过部署地理上更接近数据使用者的只读辅助副本,可以减少网络读取延迟。

  • 您需要支持哪些常见的数据访问模式?例如,您是按单个值(如时间)检索数据,还是需要更复杂的查询,即按属性组合(如事件类、按区域、按时间)查找数据?

当创建了适当的索引时,查询性能是最佳的。了解如何查询数据并定义适当的索引对数据库性能至关重要。同时,能够在不干扰系统的情况下实时修改索引策略,是时间序列平台的一个重要属性。

  • 您的用户将使用哪些分析库或工具?

如果您的数据消费者正在使用像Hadoop或Spark这样的工具,MongoDB有一个MongoDB Spark连接器,它集成了这些技术。MongoDB也有Python、R、Matlab和其他用于分析和数据科学的平台的驱动程序。

  • 您的组织是否使用BI可视化工具来创建报告或分析数据?

MongoDB通过MongoDB BI连接器集成了大多数主要BI报告工具,包括Tableau、QlikView、Microstrategy、TIBCO等。MongoDB还有一个叫做MongoDB Charts的本地BI报告工具,它提供了在MongoDB中可视化数据的最快方法,而不需要任何第三方产品。

数据保存和归档:

  • 什么是数据保留策略?数据可以被删除或存档吗?如果有,在什么年龄?
  • 如果存档,存档需要多长时间以及可访问性如何?存档数据需要是活动的,还是可以从备份中恢复?

在MongoDB中有不同的删除和归档数据的策略。其中一些策略包括使用TTL索引、可查询备份、分区分片(允许您创建分层存储模式),或者简单地创建一个体系结构,在该体系结构中,您只需在不再需要时删除数据集合。

安全:

  • 需要定义哪些用户和角色,每个实体所需的最低特权权限是什么?
  • 加密要求是什么?您是否需要同时支持时间序列数据的空中(网络)加密和静止(存储)加密?
  • 是否所有针对数据的活动都需要记录在审计日志中?
  • 应用程序是否需要符合GDPR、HIPAA、PCI或任何其他监管框架?

监管框架可能需要启用加密、审计和其他安全措施。MongoDB支持这些遵从性所需的安全配置,包括静态和动态加密、审计和基于角色的粒度访问控制。

虽然不是所有可能考虑的事情的详尽列表,但它将帮助您思考应用程序需求及其对MongoDB模式设计和数据库配置的影响。在下一篇博客文章“第2部分:MongoDB中时间序列数据的模式设计”中,我们将探索为不同需求集构建模式的各种方法,以及它们对应用程序性能和规模的相应影响。在第3部分“时间序列数据和MongoDB:第3部分—查询、分析和呈现时间序列数据”中,我们将展示如何查询、分析和呈现时间序列数据。

原文:https://www.mongodb.com/blog/post/time-series-data-and-mongodb-part-1-introduction

本文:http://jiagoushi.pro/node/1334

讨论:请加入知识星球【首席架构师圈】或者小号【jiagoushi_pro】或者QQ群【11107777】

SEO Title
Time Series Data and MongoDB: Part 1 – An Introduction