時間序列數據存儲：RDBMS 與 NoSQL

Question

這些天來，我面臨着存儲一些時間序列數據的問題。

該數據取自工業機器：對於每個作業（大約每小時 3 個，24/24 小時），軟件記錄：

• 油壓;
• 油溫；
• 一些振動數據。

振動數據以非常高的頻率（> 10 kHz）采集，並導致非常龐大的內存需求。 這個問題使我的公司評估了一些有效存儲這些數據的可能性。

插入不會很頻繁（當機器不工作時，可能每天 1 或 2 次）。 讀取可能會非常頻繁（另一個軟件將檢索數據以進行繪圖和分析）。

目前，將使用單個節點來存儲數據，所以我不想（暫時）考慮分區和並行化問題。

我應該更喜歡什么解決方案？ 一個關系 DBMS（如 MySQL 或 PostgreSQL），還是一個通用的 NoSQL DB（如一個面向列的數據庫 - 考慮到所有時間序列都是單變量的 - 如 Cassandra，或面向文檔的數據庫，如 MongoDB）？

除了我的特定用例之外，什么時候通常更喜歡 RDMBS 而不是 NoSQL 用於時間序列存儲？ 何時更喜歡 NoSQL 而不是 RDBMS？

Answer 1

tl;博士：

通常對於時間序列，我會使用像 InfluxDb 這樣的時間序列數據庫。

將 NoSQL 用於非結構化的大量數據，例如：記錄結果、網站搜索數據等。非常適合針對特定查詢進行優化，但也適用於處理包含小數據層次結構（如表或最多 3 個表）的微服務。

使用關系數據庫：當您有一個大而強大的層次結構時，例如：銷售流程的工作流程的進出。 如果必須在大量數據上保持數據結構的完整性，則關系會更好。

這是關於如何處理各種關系關系與文檔存儲的很好的總結： https ://completedeveloperpodcast.com/document-vs-relational-databases/

---

好吧，總的來說，網上有很多關於這個主題的文章。 通常，在關系數據庫中，原理圖是“預先”知道的——盡管它會隨着時間的推移而改變，但它是相當靜態的。

大多數 Not-only-SQL 的最大“好處”是它們：

• 不需要固定的原理圖和固定的關系來保持數據的一致性。 這意味着 - 例如圖形數據庫 - 您可以更輕松、更靈活地與其他對象相關聯，或者您必須擁有幾個獨立的表。
• 通過設計能夠（更好）水平擴展，這在更大的系統中是解決性能相關問題的一大好處。 （考慮成為幾個獨立的表來看看為什么）
• 數據不需要（非常）結構化。 如果您需要在數據庫中包含外部數據源或典型的非結構化數據，這又是一個好處。
• 在小型實體中運行良好，查詢優化存儲。
• 一些雲提供商提供無服務器解決方案，從而降低成本

注意：有多種 NoSQL 數據庫類型，都有不同的方法和各自的優缺點。

---

所以：

除了我的特定用例之外，什么時候通常更喜歡 RDMBS 而不是 NoSQL 用於時間序列存儲？

使用 RDMBS 時，您至少需要預先了解您的原理圖，並且它們不會經常更改。

在以下情況下，您更喜歡 RDMBS：

• 這種結構化數據和一致性檢查是您存儲的數據的內在屬性。 例如：維護倉庫庫存清單，跟蹤工作時間等。
• 您的數據存儲可以被視為一個獨立的權限。 例如：文件系統索引器或產品測試結果存儲。

何時更喜歡 NoSQL 而不是 RDBMS？

在以下情況下，您更喜歡 NoSQL：

• 您無法預先確定所有關系並期望經常添加數據、源和關系。 典型的用例是大數據存儲、關系存儲； 更具體的：社交網絡、高級統計相關性或經常變化的外部數據提供者。
• 您需要高可擴展性，這在大多數 NoSQL 系統中更為自然。
• 您只想以或多或少的結構化方式將一些數據轉儲到雲中的某個位置。 例如，創建一個簡單的表來保存設置記錄。
• 有簡單的實體和查詢，不需要復雜的連接和分層數據

---

至於你的用例：

您的數據結構似乎是眾所周知且固定的。 這要求關系數據庫。

數據量和它的簡單性是選擇 NoSQL 的一個論據。

至於高負載：數據結構也是預先知道的。 然而，處理高負載時涉及到一些問題。 可以將關系數據庫配置為應付這個數量並且性能非常好，但 NoSQL 通常對此進行了更好的優化。

---

我覺得這有點平衡，而過去是關系型的； 在這種情況下，我現在會去文件存儲。

---

但是，它確實提出了另一個問題：由於您正在 24/7 監控； 您多久需要一次去年或前一年的數據？ 上個月還是上周？

我只是問，因為有更多選項可以處理這些數據量。 歷史數據通常被視為日志，僅“不時”請求。 在這種情況下，您可以將數據卡盤存儲在不同的服務器上，甚至以不同的形式存儲。 例如，10kHz 振動數據也可以以 blob 或存儲數據流的形式存儲在專用服務器上。