用於數據記錄的數據庫設置
我們目前正在開始建構我們系統的第 2 版，我們注意到第 1 版的一件事是我們將擁有相當多的數據，因此我們開始重新思考我們如何儲存數據的方法。
基本上我們有數據記錄器，每 5 分鐘將數據發送回伺服器。使用目前的系統，我們只有很少的感測器，因為我們剛剛開始，所以我們只有大約 250 個記錄器，它們以每年 2.5gb 或每年大約 2100 萬行的速度生成數據。數據主要是光照水平、溫度、濕度等數字。我們預計這些記錄器的數量會增長得相當快，到明年年底我們應該有數千個記錄器。
然而，有了這個下一代平台，我們將擁有多個可以使用的感測器，並且多個類似的感測器可以連接到一個系統。系統將有大約 8 個用於感測器板的埠，但每個感測器板可以有多個感測器。作為一個粗略的例子，一個系統可以有 5 到 100 個不同類型的感測器輸入。（是我們目前的2-10倍）
數據只寫入一次，然後只讀取。99% 的讀取是針對最長兩個月的數據。
到目前為止，我提出了幾個不同的選擇，我很想听聽是否有人有很好的見解，哪一個可能是最具可擴展性的。
- 有一個主 Ping 表，其中包含每個報告的一些基本數據，然後為每個感測器板類型提供單獨的表。如果需要顯示所有數據，則選擇最多為 8 個表連接。
- 擁有一張包含所有 ping 數據的非常寬的表
- 全部或部分使用 NoSQL 思想，並以 JSON 或類似格式插入大部分 ping 數據。
其次，聽聽哪種數據庫設置最具可擴展性會很有趣：
- 擁有一個最多有 2 個月數據的生產伺服器，這樣更容易完全保存在記憶體中。將所有歷史數據解除安裝到輔助伺服器。
- 將所有東西都放在一台伺服器上。
- 分片？
- 複製？
我們正在我的地方做一些非常相似的事情，幾週前這個問題一直在我腦海中浮現。
在註意到日誌消耗了 SQL Server 中 98% 的數據庫後，我對應該如何處理這個問題進行了一些研究。
這完全取決於您的日誌的結構，但我們的日誌並不是真正的關係型，因此將它們儲存在 RDBMS 中並消耗為 RDBMS 建構的所有資源是沒有意義的。
我開始研究 NoSQL 儲存，發現DB Engines Ranking對於比較每個 DB 引擎的特性集非常有用。
就我個人而言，我發現最終的一致性解決方案對我有用，因為它具有良好的分片、可用性和對大型數據集的快速讀取。
查看CAP Theorem wiki 條目以了解不同類型的 NoSQL 解決方案的權衡。
我們目前正在使用 MapReduce 作業為我們的日誌測試 Cassandra 部署。
RDMS 非常適合此類時間序列數據，因為它提供了 NoSQL 解決方案中不可用的極其強大的功能集。
由於您的工作量很大，因此有一些非常重要的注意事項可以避免性能問題。
具有插入和索引以及縮放的大表性能。
將感測器數據直接寫入您將要查詢的表中是很有誘惑力的。我發現隨著插入率的上升以及擴大或擴大規模的必要性，這會導致問題。
接收感測器資訊，然後將其排隊以插入主表，讓您執行此操作。還可以讓您根據自己的需要索引主表，而不需要那些減慢的插入，並且如果沒有從感測器接收到時間數據，則可能會破壞您的時間數據。
因此，您可以擴展您的邊緣以接收感測器數據，然後排隊批量插入到單獨的數據庫/伺服器。
在執行中維護數據集是一個不同的問題，這將歸結為頁面數量，儘管感測器很小，但這些頁面的數量可能很大。
一種簡單的方法是在聚集索引上創建一個非聚集索引，這將為您提供數據的副本。但是使用過濾的非聚集索引可能會得到更好的結果。因此，基礎表可能會變得很大，但讀取性能不會受到影響，因為您可以直接從索引中提取過去幾個月的數據。
不用多說，RDMS 完全沒問題。請務必確定自己的位置以橫向擴展數據輸入並減少大表讀取問題。
儲存問題應該可以通過存檔和多個伺服器解決。