「时序数据库」时序数据库和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的服务器的内存量时，考虑横向扩展，将索引和负载分散到多个服务器上。

• 肯定数据在何时过时，以及采起什么操做，好比归档或删除。

架构师亨哥韩

资产的生命周期 #资产管理#，#资产生命周期#，#ALM#，#物联网#，#IoT#

视频号