存储可穿戴数据的理想数据库选择 (Fitbit)

Posted 2023-04-18

【中文标题】存储可穿戴数据的理想数据库选择 (Fitbit)

【英文标题】：Ideal database choice for storing Wearable data (Fitbit)

【发布时间】：2015-09-20 21:55:47

【问题描述】：

我最近在 Fitbit 上开发一个应用程序。 我正在考虑使用 MongoDB 或 HBase，因为它支持聚合并支持以键值格式处理数据。 示例数据集：

    "activities-heart": [
        
            "customHeartRateZones": [],
            "dateTime": "today",
            "heartRateZones": [
                
                    "caloriesOut": 2.3246,
                    "max": 94,
                    "min": 30,
                    "minutes": 2,
                    "name": "Out of Range"
                ,
                
                    "caloriesOut": 0,
                    "max": 132,
                    "min": 94,
                    "minutes": 0,
                    "name": "Fat Burn"
                ,
                
                    "caloriesOut": 0,
                    "max": 160,
                    "min": 132,
                    "minutes": 0,
                    "name": "Cardio"
                ,
                
                    "caloriesOut": 0,
                    "max": 220,
                    "min": 160,
                    "minutes": 0,
                    "name": "Peak"
                
            ],
            "value": "64.2"
        
    ],
    "activities-heart-intraday": 
        "dataset": [
            
                "time": "00:00:00",
                "value": 64
            ,
            
                "time": "00:00:10",
                "value": 63
            ,
            
                "time": "00:00:20",
                "value": 64
            ,
            
                "time": "00:00:30",
                "value": 65
            ,
            
                "time": "00:00:45",
                "value": 65
            
        ],
        "datasetInterval": 1,
        "datasetType": "second"
    

当我希望在我的应用程序中对这些数据进行分析时，存储传感器数据的数据库的理想选择是什么？ 谢谢！

【参考方案1】：

Mongo 需要担心的一件事：存储数据的开销很大。在典型的 RDBMS 或时间序列数据库中，它只存储您的数据，而不是每一行的元数据（字段名称和类型）。

您应该研究 Graphite 和 InfluxDB 等时间序列数据库。甚至 Cassandra 也为此提供了一些功能。

另一方面，正如另一位发帖人所指出的，从常规 SQL 数据库开始可能更简单，并且仅在需要时迁移。通过推迟选择，您将更好地了解您想要的具体权衡。

Graphite 是一个易于上手的数据库。它做出了一个非常具体的权衡：每个图表的数据存储需求是恒定的（即不会随着时间的推移而变大，即使您记录多年的数据。）它还可以每秒处理数百万个指标。唯一的缺点是分辨率“过时”，因此您可以告诉它存储 1m 分辨率几天，然后降低到 10m 分辨率一个月，然后 1h 分辨率 1 年，1d 分辨率 10 年。您可以告诉它保留每个间隔的统计信息（最大值、最小值、平均值、第 90 个百分位）。获取任意时间跨度的图表基本上是一次磁盘寻道。有很棒的仪表板可以查看您的数据（我推荐Grafana）。

【参考方案2】：

当您的数据中没有结构时，NoSQL DB 是一个不错的选择。您也可以在 RDBMS 中模拟（键、值）功能。您显示的示例数据看起来可以很容易地标准化并存储在 mysql 或 SQL Server 中。你为什么不先去呢？它也将非常容易管理。最重要的是，您的数据具有结构。

如果性能成为问题，您可以使用索引。甚至去规范化。您可以在此关于Normalization in databases 的 SO 答案中找到标准化数据的步骤。您可以像在任何 NoSQL 解决方案中一样在 RDBMS 中执行聚合和处理数据。你还有其他原因吗？

【讨论】：

来自传感器的数据会很大，并且会定期收集。因此，我正在考虑使用 NoSQL 数据库。

@Nielet：Large 无法量化，无法帮助任何人告诉您应该选择 RDBMS 还是 NoSQL。我知道 RDBMS 表可以毫无问题地处理数百万行的顺序。我不知道数十亿，因为我还没有遇到这种情况。不要担心来自传感器的数据。除非您对 RDBMS 有一些特定的失败，否则只能使用它们。

【参考方案3】：

您可以试用 Amazon Redshift，因为，

它具有使用复制命令直接加载 json 的能力。 它支持完整的 ANSI SQL（因为它基于 PostgreSQL）。 内置分析功能。 如果您想要更多“分析”，它支持 Python 和 R。 它与最流行的报告解决方案（Microstrategy、Tableau 等）直接连接 它完全在 AWS 云上。