【问题标题】:Best way to store high frequency, periodic time-series data?存储高频、周期性时间序列数据的最佳方式?
【发布时间】:2018-11-01 13:06:56
【问题描述】:

我已经为 nodejs 项目创建了一个 MVP,以下是与我要问的问题相关的一些功能:

1-应用程序有一个带有 CRUD 操作的 IP 地址列表。 2-应用程序将在每 5 秒后 ping 每个 IP 地址。 3- 并针对每个 IP 地址显示其状态,即存活或死亡以及正常运行时间(如果存活)

我在 net-ping、express、mongo 和 angular 库的帮助下在 nodejs 上创建了一个有效的 MVP。现在我有一个新的功能要求是:

"计算为每个 IP 地址生成的每个 ping 的往返时间(延迟),并填充条形图或任何类型的图表,以显示 RTT(延迟)历史(1 个月至 1 年)每个连接”

我需要将每个 ping 的响应存储在数据库中,假设最好的情况是,如果我要存储的每个文档的大小为 0.5 kb,那么每天将存储 9.5MB 数据,每个存储 285MB一个月和一年 3.4GB 的单个 IP 地址,我的应用程序中将有 100-200 个 IP 地址。

考虑到应用程序可以扩展更多,最适合我的要求的最佳解决方案(包括付费解决方案)是什么?

【问题讨论】:

    标签: node.js database mongodb architecture storage


    【解决方案1】:

    时间序列数据需要从数据库的角度进行特殊处理,因为它们从容量、查询性能、读/写优化目标等方面给传统数据库管理带来了挑战。

    我不建议您将这些数据存储在传统的 RDBMS 或对象/文档数据库中。

    最好的选择是使用专门的时间序列数据库引擎,例如 InfluxDB,它可以支持下采样(聚合)和原始数据保留规则

    【讨论】:

      【解决方案2】:

      所以我在阅读this 后更改了时间序列数据的架构设计,这大大减少了我计算大小的数字

      之前的架构是这样的:

      {
        timestamp: ISODate("2013-10-10T23:06:37.000Z"),
        type: "Latency",
        value: 1000000
      },
      {
        timestamp: ISODate("2013-10-10T23:06:38.000Z"),
        type: "Latency",
        value: 15000000
      }
      Size of each document: 0.22kb
      number of document created in an hour= 720
      size of data generated in an hour=0.22*720 = 158.4kb
      size of data generated by one IP address in a day= 158 *24 = 3.7MB
      

      由于每次下一次time_Stamp 只是从上一次增加5 秒,因此可以优化架构以减少冗余数据。 新架构如下所示:

      {
        timestamp_hour: ISODate("2013-10-10T23:06:00.000Z"),// will contain hours
        type: “Latency”,
        values: {//will contain data for all pings in the specific hour
          0: 999999,
          …
          37: 1000000,
          38: 1500000,
          … 
          720: 2000000
        }
      }
      Size of each document: 0.5kb
      number of document created in an hour= 1
      size of data generated in an hour= 0.5kb
      size of data generated by one IP address in a day= 0.5 *24 = 12kb
      

      所以我假设数据的大小将不再是一个问题,虽然对于在这种情况下应该使用哪种类型的存储以确保最佳性能存在争议,但我会相信 mongoDB 在我的案例。

      【讨论】:

        猜你喜欢
        • 1970-01-01
        • 1970-01-01
        • 2018-12-01
        • 2015-05-11
        • 1970-01-01
        • 1970-01-01
        • 1970-01-01
        • 2019-05-04
        • 2011-04-17
        相关资源
        最近更新 更多