「时序数据库」时序数据库和MongoDB第二部分-模式设计最佳实践

「时序数据库」时序数据库和MongoDB第二部分-模式设计最佳实践

在上一篇博客文章​​时间序列数据与MongoDB：第一部分-简介​​中，我们介绍了时间序列数据的概念，然后介绍了一些可以用于帮助收集时间序列应用程序需求的发现问题。对这些问题的回答有助于指导支持大容量生产应用程序部署所需的模式和MongoDB数据库配置。在这篇博客文章中，我们将重点讨论在读、写、更新和删除操作下，两种不同的模式设计如何影响内存和磁盘利用率。

在分析结束时，您可能会发现应用程序的最佳模式设计可能是利用模式设计的组合。通过遵循我们下面列出的建议，您将有一个良好的起点来为您的应用程序开发最佳模式设计，并适当调整您的环境大小。

设计一个时间序列模式

让我们首先说明，没有一种规范模式设计可以适用于所有应用程序场景。无论您开发的模式是什么，都要考虑权衡。理想情况下，您希望获得最佳的内存和磁盘利用率平衡，以产生最佳的读写性能，从而满足应用程序的需求，并支持数据摄取和时间序列数据流的分析。

在这篇博客文章中，我们将讨论各种模式设计配置。首先，为每个数据样本存储一个文档，然后使用每个时间序列时间范围的一个文档和每个固定大小的文档对数据进行封装。为每个文档存储一个以上的数据样本称为bucketing。这将在应用程序级别实现，不需要在MongoDB中进行任何配置。有了MongoDB灵活的数据模型，你可以优化存储你的数据，为你的应用程序的需求提供最好的性能和粒度。

这种灵活性还允许数据模型随着时间的推移适应新的需求——比如从不属于原始应用程序设计的新硬件传感器捕获数据。这些新的传感器提供了与原始设计中使用的传感器不同的元数据和属性。有了这些灵活性，您可能会认为MongoDB数据库是蛮荒的西部，任何东西都可以，您很快就会得到一个充满无序数据的数据库。MongoDB通过模式验证提供了您所需要的尽可能多的控制，允许您完全控制执行强制字段的存在和可接受值的范围等等。

为了帮助演示模式设计和bucketing如何影响性能，请考虑我们想要存储和分析历史股票价格数据的场景。我们的示例股票价格生成器应用程序每秒钟为它跟踪的给定数量的股票创建示例数据。1秒是本例中为每个股票行情收集的数据的最小时间间隔。如果您想在自己的环境中生成示例数据，可以在GitHub上使用StockGen工具。需要注意的是，尽管本文中的示例数据使用股票刻度作为示例，但您可以将这些相同的设计概念应用于任何时间序列场景，比如物联网传感器的温度和湿度读数。

用于生成示例数据的StockGen工具将生成相同的数据，并将其存储在两个不同的集合中:StockDocPerSecond和StockDocPerMinute，它们各自包含以下模式:

场景1:每个数据点一个文档

{"_id" : ObjectId("5b4690e047f49a04be523cbd"),"p" : 56.56,"symbol" : "MDB","d" : ISODate("2018-06-30T00:00:01Z")},{"_id" : ObjectId("5b4690e047f49a04be523cbe"),"p" : 56.58,"symbol" : "MDB","d" : ISODate("2018-06-30T00:00:02Z")},...

场景2:每分钟一个文档的基于时间的bucketing

{"_id" : ObjectId("5b5279d1e303d394db6ea0f8"),"p" : {"0" : 56.56,"1" : 56.56,"2" : 56.58,…"59" : 57.02},"symbol" : "MDB","d" : ISODate("2018-06-30T00:00:00Z")},{"_id" : ObjectId("5b5279d1e303d394db6ea134"),"p" : {"0" : 69.47,"1" : 69.47,"2" : 68.46,..."59" : 69.45},"symbol" : "TSLA","d" : ISODate("2018-06-30T00:01:00Z")},...

请注意，字段“p”包含一个子文档，其中包含每分钟每秒的值。

模式设计的比较

让我们根据StockGen工具生成的4周的数据来比较和对比存储大小和内存影响的数据库指标。在评估数据库性能时，度量这些指标非常有用。

对数据存储的影响

在我们的应用程序中，时间粒度的最小级别是秒。场景1中描述的每秒存储一个文档对于那些来自关系数据库背景的人来说是最合适的模型概念。这是因为我们为每个数据点使用一个文档，这类似于表格模式中为每个数据点使用一行。这种设计将在单位时间内产生最大数量的文档和集合大小，如图3和图4所示。

图4显示了每个集合的两种大小。这个系列中的第一个值是存储在磁盘上的集合的大小，而第二个值是数据库中数据的大小。这些数字是不同的，因为MongoDB的WiredTiger存储引擎支持静态数据压缩。逻辑上每秒的收集是605MB，但是在磁盘上，它消耗了大约190 MB的存储空间。

对内存利用率的影响

大量的文档不仅会增加数据存储的消耗，还会增加索引的大小。在每个集合上创建索引，覆盖符号和日期字段。与一些将自己定位为时间序列数据库的键值数据库不同，MongoDB提供了二级索引，使您能够灵活地访问数据，并允许您优化应用程序的查询性能。

图5:每秒和每分钟的索引大小(MB)比较

这两个集合中定义的索引的大小如图5所示。MongoDB的最佳性能发生在索引和最近使用的文档适合由WiredTiger缓存分配的内存时(我们称之为“工作集”)。在我们的示例中，我们在4周的时间内只生成了5只股票的数据。对于这个小测试用例，我们的数据已经为PerSecond场景生成了一个大小为103MB的索引。请记住，有一些优化(如索引前缀压缩)可以帮助减少索引的内存占用。然而，即使有了这些优化，正确的模式设计对于防止失控的索引大小也是很重要的。考虑到增长轨迹，对应用程序需求的任何更改，比如在我们的样例场景中跟踪超过5只股票或超过4周的价格，都将给内存带来更大的压力，最终需要将索引页出到磁盘。当这种情况发生时，您的性能将会下降。要缓解这种情况，可以考虑水平伸缩。

水平扩展

随着数据大小的增长，当MongoDB副本集中托管主mongod的服务器达到物理限制时，可能最终会水平伸缩。

通过MongoDB Sharding水平扩展，性能可以得到提高，因为索引和数据将分布在多个MongoDB节点上。查询不再针对特定的主节点。相反，它们是由一种称为查询路由器(mongos)的中间服务处理的，该服务将查询发送到包含满足查询的数据的特定节点。注意，这对应用程序是完全透明的——MongoDB为你处理所有的路由

场景3:基于大小的封装

在比较前面的场景时，最重要的一点是使用数据包具有显著的优势。场景2中描述的基于时间的bucketing将一分钟的数据存储到一个单一的文档中。在物联网等基于时间的应用中，传感器数据可能以不规则的间隔生成，一些传感器可能比其他传感器提供更多的数据。在这些场景中，基于时间的bucketing可能不是方案设计的最佳方法。另一种策略是基于大小的bucketing。使用基于大小的bucketing，我们将围绕每个发出的传感器事件的特定数目的一个文档来设计模式，或围绕一整天(以先发出的为准)来设计模式。

要了解基于大小的bucketing的实际运作，请考虑这样一个场景:您正在存储传感器数据，并将bucket大小限制为每个文档200个事件，或一天(以先到的方式)。注意:200的限制是一个任意的数字，可以根据需要进行更改，而不需要更改应用程序或模式迁移。

{_id: ObjectId(),deviceid: 1234,sensorid: 3,nsamples: 5,day: ISODate("2018-08-29"),first:1535530412,last: 1535530432,samples : [{ val: 50, time: 1535530412},{ val: 55, time : 1535530415},{ val: 56, time: 1535530420},{ val: 55, time : 1535530430},{ val: 56, time: 1535530432}]}

图6显示了一个基于大小的桶示例。在这种设计中，试图将每个文档的插入限制为任意数量或特定的时间段可能会很困难;但是，使用upsert很容易做到，如下面的代码示例所示:

sample = {val: 59, time: 1535530450}day = ISODate("2018-08-29")db.iot.updateOne({deviceid: 1234, sensorid: 3, nsamples: {$lt: 200}, day: day},{$push: { samples: sample},$min: { first: sample.time},$max: { last: sample.time},$inc: { nsamples: 1}},{ upsert: true })

当新的传感器数据进来时，它被简单地附加到文档中，直到样本数量达到200，然后由于我们的upsert:true子句创建一个新文档。

这个场景中的最佳索引是{deviceid:1,sensorid:1,day:1,nsamples:1}。当我们更新数据时，日期是精确匹配的，这是超级高效的。在查询时，我们可以在单个字段上指定日期或日期范围，这也很有效，还可以使用UNIX时间戳按第一个和最后一个进行过滤。注意，我们使用整数值来表示时间。这些时间实际上是作为UNIX时间戳存储的，只占用32位存储空间，而ISODate占用64位存储空间。虽然与ISODate相比查询性能差别不大，但如果您计划最终摄入tb级的数据，并且不需要存储小于1秒的粒度，那么将数据存储为UNIX时间戳可能很重要。

固定大小的Bucketing数据将产生非常相似的数据库存储和索引的改善，就像场景2中每次Bucketing所看到的那样。这是在MongoDB中存储稀疏物联网数据的最有效方法之一。

如何处理旧数据

我们应该永久存储所有数据吗?超过一定时间的数据对您的组织有用吗?旧数据的可访问性如何?当您需要它时，它是否可以简单地从备份中恢复，或者它是否需要在线并作为活动存档供用户实时访问，以便进行历史分析?正如我们在本博客系列的第1部分中所述，这些是在上线之前应该问的一些问题。

有多种处理旧数据的方法，根据您的特定需求，有些方法可能比其他方法更适用。选择一个最适合您的需求。

Pre-aggregation

对于几年前生成的每个事件，您的应用程序真的需要一个数据点吗?在大多数情况下，保持这种数据粒度的资源成本超过了能够随时查询到这个级别的好处。在大多数情况下，可以预先聚合和存储数据，以便进行快速查询。在我们的股票示例中，我们可能希望仅将每天的收盘价存储为一个值。在大多数架构中，预先聚合的值存储在一个单独的集合中，因为对历史数据的查询通常与实时查询不同。通常对于历史数据，查询查找的是一段时间内的趋势，而不是单个实时事件。通过将这些数据存储在不同的集合中，您可以通过创建更高效的索引(而不是在实时数据上创建更多索引)来提高性能。

离线归档策略

在对数据进行归档时，与数据检索相关的SLA是什么?恢复数据备份是可以接受的吗?还是需要数据处于在线状态并随时准备进行查询?回答这些问题将有助于推动您的档案设计。如果不需要对归档数据进行实时访问，那么可以考虑备份数据并将其从活动数据库中删除。生产数据库可以使用MongoDB Ops Manager进行备份，如果使用MongoDB Atlas服务，则可以使用完全托管的备份解决方案。

使用remove语句删除文档

一旦数据通过数据库备份或ETL过程复制到存档库，数据可以通过remove语句从MongoDB集合中删除，如下所示:

db.StockDocPerSecond.remove ( { "d" : { $lt: ISODate( "2018-03-01" ) } } )

在本例中，“d”字段上定义的日期在2018年3月1日之前的所有文档都将从StockDocPerSecond集合中删除。

您可能需要设置一个自动化脚本，以便经常运行以清除这些记录。或者，您可以通过定义一个生存时间(TTL)索引来避免在这个场景中创建自动化脚本。

使用TTL索引删除文档

TTL索引与常规索引类似，只是定义了从集合中自动删除文档的时间间隔。在我们的示例中，我们可以创建一个自动删除超过一周的数据的TTL索引。

db.StockDocPerSecond.createIndex( { "d": 1 }, { expireAfterSeconds: 604800 } )

尽管TTL索引很方便，但请记住，检查大约每分钟发生一次，不能配置间隔。如果您需要更多的控制以使删除不会在一天的特定时间发生，那么您可能希望调度一个执行删除操作的批处理作业，而不是使用TTL索引。

通过删除集合来删除文档

需要注意的是，使用remove命令或TTL索引将导致磁盘I/O偏高。对于已经处于高负载的数据库，这可能是不可取的。从活动数据库中删除记录的最有效和最快的方法是删除集合。如果可以将应用程序设计为每个集合代表一段时间，那么当需要归档或删除数据时，只需删除集合。这可能需要在您的应用程序代码中使用一些智能来知道应该查询哪些集合，但其好处可能大于此更改。当你发出一个删除命令时，MongoDB也必须从所有受影响的索引中删除数据，这可能需要一段时间，这取决于数据和索引的大小。

在线归档策略

如果仍然需要实时访问归档数据，请考虑这些查询发生的频率，以及只存储预先聚合的结果是否足够。

分片归档数据

归档数据并保持数据可实时访问的一种策略是使用分区分片对数据进行分区。切分不仅有助于跨多个节点横向扩展数据，还可以标记切分范围，以便将数据分区固定到特定的切分上。一种节省成本的措施是让归档数据驻留在运行低成本磁盘的碎片上，并定期调整碎片本身中定义的时间范围。这些范围将导致平衡器自动在这些存储层之间移动数据，为您提供分层的、多温度的存储。查看使用分区分片创建分层存储模式的教程，了解更多信息。

通过可查询的备份访问归档数据

如果您的存档数据不经常被访问，并且查询性能不需要满足任何严格的延迟sla，考虑备份数据并使用MongoDB Atlas或MongoDB OpsManager的可查询备份特性。可查询备份允许您连接到备份并向备份本身发出只读命令，而无需首先还原备份。

从数据湖查询数据

MongoDB是一种廉价的解决方案，不仅适用于长期归档，也适用于您的数据湖。投资Apache Spark等技术的公司可以利用MongoDB Spark连接器。这个连接器将MongoDB数据物化为与Spark和机器学习、图形、流和SQL api一起使用的数据数据库和数据集。

关键的要点

一旦应用程序在生产环境中运行并具有多个tb的大小，从资源的角度来看，任何重大更改都可能非常昂贵。考虑这样一个场景:您有6 TB的物联网传感器数据，并且以每秒50,000次插入的速度积累新数据。读取的性能开始成为一个问题，您意识到没有正确地扩展数据库。除非你愿意让应用程序宕机，否则这种配置模式的改变——例如从原始数据存储转移到bucket存储——可能需要构建垫片、临时暂存区域和各种临时解决方案来将应用程序转移到新的模式。这个故事的寓意是为增长做计划，并适当设计适合应用程序sla和需求的最佳时间序列模式。

本文分析了股票价格时序数据存储的两种不同模式设计。在您的场景中，最终获胜的股票价格数据库模式是最好的模式吗?也许吧。由于时间序列数据的性质和典型的数据快速摄入，答案实际上可能是利用以读或写重用例为目标的集合组合。好消息是，MongoDB灵活的模式很容易进行更改。实际上，您可以运行两个不同版本的应用程序，为同一个集合编写两个不同的模式。但是，不要等到查询性能开始下降时才去寻找最佳设计，因为将现有文档的TBs迁移到一个新的模式会花费时间和资源，并且会延迟应用程序的未来版本。在进行最终设计之前，您应该进行真实世界的测试。引用一句著名的谚语:“量两次，切一次。”

在下一篇博客文章“用MongoDB查询、分析和显示时间序列数据”中，我们将研究如何有效地从存储在MongoDB中的时间序列数据中获取价值。

关键提示:

MMAPV1存储引擎不赞成使用，因此使用默认的WiredTiger存储引擎。请注意，如果您阅读几年前的模式设计最佳实践，那么它们通常是在旧的MMAPV1技术上构建的。了解时间序列应用程序的数据访问需求。模式设计影响资源。关于模式设计和索引，“测量两次，削减一次”。如果可能的话，用真实的数据和真实的应用程序测试模式。Bucketing数据减少了索引大小，因此大大减少了硬件需求。时间序列应用程序通常会捕获大量数据，因此只在对应用程序的查询模式有用的地方创建索引。考虑多个集合:一个集中在写重插入和最近的数据查询上，另一个集中在预聚合数据的历史查询上的bucket数据集合。当索引的大小超过托管MongoDB的服务器的内存量时，考虑横向扩展，将索引和负载分散到多个服务器上。确定数据在什么时候过期，以及采取什么操作，比如归档或删除。

谢谢大家关注，转发，点赞。

版权声明：本文内容由网络用户投稿，版权归原作者所有，本站不拥有其著作权，亦不承担相应法律责任。如果您发现本站中有涉嫌抄袭或描述失实的内容，请联系我们jiasou666@gmail.com 处理，核实后本网站将在24小时内删除侵权内容。