我目前正致力於一個家庭自動化項目，該項目爲用戶提供在一段時間內查看其能源使用情況的可能性。目前我們每15分鐘要求一次數據，我們預計第一個大型飛行員將有2000名左右的用戶。將大量數據存儲在數據庫中
我的老闆正在要求我們存儲至少半年的數據。快速彙總可以估計出約3500萬條記錄。雖然這些記錄很小（每個大約500bytes），但我仍然想知道將這些記錄存儲在我們的數據庫（Postgres）中是否是一個正確的決定。
有沒有人有一些很好的參考資料和/或建議如何處理這一數量的信息？
現在，35K記錄0.5K每個意味着37.5G的數據。這適合於你的飛行員的數據庫，但你也應該考慮飛行員之後的下一步。當飛行員取得巨大成功時，你的老闆會不高興，並且你會告訴他，在未來幾個月裏，如果不重新設計所有的東西，你就不能再爲系統添加100.000個用戶。此外，有關新功能什麼VIP用戶可以在每個分鐘請求數據...
這是一個複雜的問題，你做出的選擇會限制你的軟件的發展。
爲先導，保持儘可能簡單，以獲得產品出盡可能便宜 - >確定爲數據庫。但告訴你的老闆，你不能像這樣開放服務，你必須改變的東西，每週得到10.000新用戶。
一件事下一個版本：有許多數據倉庫：一個經常更新的用戶數據，一個爲你查詢/統計系統，...
你可以看看RRD你的下一個版本。
還要記住更新頻率：2000個用戶更新數據每次15分鐘是指每秒2.2更新 - >確定; 100。000名用戶每5分鐘更新數據意味着每秒更新333.3次。我不確定一個簡單的數據庫可以跟上這一點，而單一的Web服務服務器肯定不能。
通過適當的索引來避免查詢速度慢，我不希望任何像樣的RDBMS與那種數據集的鬥爭。很多人都在使用PostgreSQL來處理比這更多的數據。
這是什麼數據庫:)
我們經常打這個看起來像這樣的表。很顯然，根據用途構建索引（你是讀或寫很多，等等），從一開始就考慮基於數據的高級別分組的表分區。
此外，您可以實施存檔的想法來保持活動表的精簡。歷史記錄要麼從未被觸動過，要麼被報道過，在我看來，這兩種記錄都不適合用來表格。
值得一提的是，我們有100m左右記錄的表，我們不認爲那裏是一個性能問題。很多這些性能改進都可以在事後很少產生痛苦的情況下完成，因此您可以始終從常識解決方案入手，並且只有在性能被證明很差時才能進行調整。
你沒有更好的保持整個時期的個別樣本？您可以實施某種合併機制，將每週/每月樣本連接成一條記錄。並按計劃運行合併。
您的決定必須取決於您需要能夠在數據庫上運行的查詢類型。
首先，我建議你做一個性能測試 - 編寫一個程序，生成測試條目，對應於你將在半年內看到的條目數量，插入它們並檢查結果以查看是否查詢時間令人滿意。如果沒有，請按照其他答案的建議嘗試編制索引。這也是值得一試的寫性能，以確保你可以在15分鐘內實際插入15分鐘內生成的數據量。
製作一個測試將避免所有問題的母親 - 假設:-)
想想也生產性能 - 您的飛行員將有2000個用戶 - 將您的生產環境中有4000個用戶或一年20萬個用戶或二？
如果我們談論的是一個非常大的環境，您需要考慮一個解決方案，通過添加更多的節點來擴展，而不是依賴於始終能夠將更多的CPU，磁盤和內存添加到單臺機器。您可以在應用程序中執行此操作，方法是跟蹤多個數據庫機器中的哪一臺正在託管特定用戶的詳細信息，或者您可以使用Postgresql集羣方法之一，或者您可以採用完全不同的路徑 - 方法NoSQL，在那裏你完全從RDBMS走開，並使用水平擴展的系統。
有很多這樣的系統。我只有個人經驗Cassandra。你必須認爲完全不同於你從RDBMS世界中習慣的東西，這是一個挑戰 - 想想更多關於你想如何訪問數據而不是如何存儲數據。舉例來說，我認爲以user-id爲關鍵字存儲數據，然後添加一個列名稱爲時間戳記的列，並且列值是該時間戳記的數據是有意義的。然後，您可以詢問這些列的切片，以便在Web UI中繪製結果 - Cassandra對UI應用程序具有足夠好的響應時間。
投入時間學習和使用nosql系統的好處是，當您需要更多空間時 - 您只需添加一個新節點即可。同樣的事情，如果你需要更多的寫性能，或更多的閱讀性能。
有很多技術來解決這個問題。如果您觸及最少數量的記錄，則只會獲得效果。在你的情況下，你可以使用以下技術。
任何進一步的查詢，你可以寄給我的[email protected]
速度也是一個硬件問題，尤其是存儲。 –