存儲可穿戴數據（Fitbit）的理想數據庫選擇

我最近在Fitbit上開發應用程序。我正在考慮MongoDB或HBase，因爲它支持聚合並支持以Key值格式處理數據。示例數據集：存儲可穿戴數據（Fitbit）的理想數據庫選擇

{ 
    "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" 
    } 
}

什麼是數據庫的理想選擇存儲傳感器數據，我希望做分析這個數據在我的應用程序？謝謝！

來源

2015-09-20 Nicole

當您的數據中沒有結構時，NoSQL DB是一個不錯的選擇。您也可以在RDBMS中模擬（鍵值）功能。您顯示的樣本數據看起來可以很容易地標準化並存儲在MySQL或SQL Server中。你爲什麼不先去那個？它也很容易管理。最重要的是，你的數據有的結構。

如果性能成爲問題，您可以使用索引。即使是非正常化。你可以在這個關於Normalization in databases的回答中找到正確處理數據的步驟。您可以像在任何NoSQL解決方案中一樣執行聚合並在RDBMS中處理數據。你有其他原因嗎？

來源

2015-09-20 22:47:55 displayName

來自傳感器的數據會很大，並會定期收集。因此，我正在考慮一個NoSQL db。 – Nicole

@Nielet：Large無法量化來幫助任何人告訴你是否應該使用RDBMS或NoSQL。我知道RDBMS表可以毫無問題地處理數百萬行的順序。我不知道幾十億，因爲我還沒有遇到這種情況。不要擔心來自傳感器的數據。除非你對RDBMS有一些特定的失敗，只和他們一起去吧。 – displayName

您可以嘗試亞馬遜紅移因爲，

它使用複製命令直接JSON負載能力。
它支持完整的ANSI SQL（因爲它基於PostgreSQL）。
它具有分析函數buit裏面。
它支持Python和R，如果你想更多的「分析」。
它與最流行的報告解決方案（Microstrategy，Tableau等）直接連接
它完全在AWS雲上。

來源

2015-09-21 09:28:57 Paladin

Mongo有一點需要擔心：存儲數據的開銷很大。在典型的RDBMS或時間序列數據庫中，它只存儲數據，而不是每行的元數據（字段名稱和類型）。

您應該查看Time Series數據庫，如Graphite和InfluxDB。即使Cassandra也有這方面的一些功能。

另一方面，正如另一位海報人員指出的那樣，從常規的SQL數據庫開始可能會更簡單，只有在需要時才能遷移。通過推遲選擇，您將更好地瞭解所需的具體權衡。

一個簡單的數據庫就是Graphite。它做了一個非常具體的權衡：每個圖的數據存儲要求是恆定的（即，即使您記錄了多年的數據，也不會隨着時間的推移而變得更大）。它還可以每秒處理數百萬個指標。唯一的缺點是分辨率「老化」，所以你可以告訴它存儲幾分鐘的1米分辨率，然後降低到一個月的10米分辨率，然後降低到1年的1小時分辨率和10年的1分辨率。您可以告訴它爲每個時間間隔保留統計信息（最大值，最小值，平均值，第90百分位數）。獲取任意時間跨度的圖形基本上是單個磁盤尋道。有很棒的儀表板可以查看你的數據（我推薦graphana）。

來源

2016-01-18 19:55:48 BraveNewCurrency

存儲可穿戴數據（Fitbit）的理想數據庫選擇

回答

相關問題