1

所以快速更新我为什么创建这个问题。

目前,我们将设备的遥测数据存储在 Azure SQL Server 的现场。这很好用(在 EF、LINQ 和关系数据库方面有大量经验)但我知道这很可能不是最好的解决方案,尤其是对于存储“大”数据(数据现在仍然很小,但会在一年内增长) )。

我选择 DocumentDB 作为我们可能的解决方案来存储我们的事件历史。其余的将留在 SQL 中——用户、配置文件、设备信息、SIM、车辆等,因为我不想完全停止开发,因为我们将 100% 转移到 docdb,而只是做最好的短期 - 成本 + 性能。

通过这个视频,我终于想出了一个关于如何存储遥测数据的可能解决方案 - https://www.youtube.com/watch?v=-o_VGpJP-Q0 他们推荐每个时间段一个文档(示例使用 1 个小时)。这仍然是推荐的方法吗?

在此处输入图像描述

    [Index]
    public DateTime TimestampUtc { get; set; }
    public DateTime ReceivedTimestampUtc { get; set; }
    [Index]
    public EventType EventType { get; set; }
    public Guid ConnectionId { get; set; }
    public string RawEventMessage { get; set; }
    [Index]
    public Sender Sender { get; set; }
    [Index]
    public Channel Channel { get; set; }
    public DbGeography Location { get; set; }
    public double? Speed { get; set; }
    public double? Altitude { get; set; }
    public Int16? Heading { get; set; }
    public Byte? HDOP { get; set; }
    public Byte? GPSFixStatus { get; set; }
    public Byte? GPSFixType { get; set; }
    public string Serial { get; set; }
    public string HardwareVersion { get; set; }
    public string FirmwareVersion { get; set; }
    public string Relay1 { get; set; }
    public string Relay2 { get; set; }
    public string Relay3 { get; set; }
    public string Ign { get; set; }
    public string Doors { get; set; }
    public string Input1 { get; set; }
    public string Input2 { get; set; }
    public string Out1 { get; set; }
    public string Out2 { get; set; }
    public int V12 { get; set; }
    public int VBat { get; set; }
4

2 回答 2

2

这是几种可能的选择之一。哪个最好取决于您的数据是什么样的。例如,如果您的事件的开始日期/时间和持续时间(或结束日期/时间)有所不同,或者如果您跟踪实体的所有状态变化,那么像Richard Snodgrass的时态数据模型是理想的。有趣的是,Microsoft SQL Server 2016 最近添加了对临时表的直接支持,但它们在 SQL 规范中作为 TSQL2 已经有一段时间了。注意,TSQL2 规范包括有效时间事务时间支持,但我相信最近添加的 MS SQL 2016 仅支持有效时间……但这没关系,因为这是最有价值的。我只是指出这一点,因为如果不增加事务时间的复杂性,了解有效时间表的工作方式就足够困难了。

这种方法的美妙之处在于,您不必在收集数据时决定所需的时间粒度,只要/当您聚合它时。

但是,正如您所说,SQL 对于如此大的数据集并不理想。因此,我在我的Lumenize库中的 DocumentDB 之上实现了有效时间 Richard Snodgrass 样式的时间模型,特别是TimeSeriesCalculator及其其他时间序列功能。在此处阅读第 10-19 页,了解有关 Lumenize 时间序列分析中的数据模型和常见操作的背景知识。该套牌是我在 Rally 时所做的一个实现,称为基于 MongoDB 的 Lookback API,但概念是相同的,我现在已经切换到 DocumentDB(但 Rally 没有)。

对您提出的模型的另一条评论,您可能需要为每次阅读考虑单独的文档。如果每分钟有一个文档或每个设备有一个文档,那么这个例子有点令人困惑。如果是每台设备每小时一个,那么您可以放心,您永远不会超过 60 分钟,这没关系,但在我能想到的几乎所有其他方式中,看起来您有单次的风险文档无限增长,这在 DocumentDB(以及所有 NoSQL 数据建模)中是一个很大的禁忌。此外,正如您所说,即使它不是无限的,它也会涉及大量的就地更新。由于您的系统可能会写得很重,我建议您最好每次阅读一个文档。如果您以后必须存储非规范化聚合以提高速度,那么您仍然可以选择这样做。你甚至可能不需要它。让生产系统的性能告知该决定。

我建议您阅读星型模式的时间维度。它看起来很像您的计划,但它也是我描述的非规范化聚合存储的理想选择。我还没有看到任何关于 NoSQL 的星型模式概念的文章,但这里有一篇来自传统 SQL 世界的文章,它将帮助您了解这些概念。

正如我所说,有很多选择,如果不了解您的情况,我不知道哪个是最好的。

于 2016-06-06T18:00:49.103 回答
0

好的,所以我想我要为每个事件创建 1 个文档(现在每 5 分钟 1 个,但可以更改为每个设备每秒 1 个)。附加到文档的原因肯定会很昂贵,因为您需要对该文档进行“替换”?(docdb 现在是否支持追加/部分更新?)当然,这涉及读取,然后是不断增长的替换,这比仅为每个事件添加新文档更昂贵和及时。唯一需要担心的是当我们有数百万/数十亿的文件时……这样可以吗?

于 2016-06-07T08:22:35.940 回答