為研究目的儲存每小時/每日期權數據的最佳方式
這裡有很多關於儲存的討論，但我找不到我正在尋找的東西。
我需要設計一個數據庫來儲存（主要）期權數據（罷工、溢價出價/要價等）。我在 RDBMS 中看到的問題是，給定大量的罷工表將非常長，因此會導致處理緩慢。雖然我不願意使用 MongoDB 或類似的 NoSQL 解決方案，但目前它似乎是一個非常好的替代方案（快速、靈活、可擴展）。
- 不需要分時數據，它將是每小時和每天的收盤價以及我想添加的任何其他參數。所以，不需要經常更新，寫入速度也不是那麼重要。
- 主要的性能要求是將其用於數據探勘、統計和研究，因此應該盡可能快（最好是容易）從中提取和聚合數據。即，考慮 10 年回溯測試，它每週對各種類型的期權執行約 100 次交易，或者在一段時間內計算波動率掉期。所以越快越好。
- 有大量現有的歷史數據將被傳輸到數據庫中，並且每天都會更新。我不確定它到底需要多少記憶體，但 AFAIK 記憶體根本不應該是一個限制。
- 流行的程式語言和包（C++、Java、Python、R）的支持是非常可取的，但不會破壞交易。
有什麼建議麼？
列式數據庫或 No-SQL 解決方案可能是您的最佳選擇。
這取決於您的目標作業系統、您的吞吐量和延遲要求是什麼、您是否希望保留所有數據以及最終預期的數據大小有多大。顯然，如果您只希望儲存每小時/每日數據，那麼即使是包含 SPX500 底層證券一年所有期權數據的數據庫也可能適合記憶體，如果是這種情況，您絕對應該查看 RedisDB。它可以持久化/快照數據，但通常將它們載入回記憶體。
如果您的數據大小限制了將其裝入記憶體，那麼另一種解決方案，如 RavenDB（編寫良好的 .Net 庫）或其他非 .net 解決方案，取決於要求，如 Mongo 或 Couch db 可能適合很多更好的。請添加更多要求，我很樂意編輯我的文章並添加資訊，因為我相信我可以增加價值。
編輯：
根據您更新的資訊，我建議更仔細地查看 Redis：不僅有幾乎任何可以想像的程式語言和作業系統的庫（我在帶有 BookSleeve API 的 .Net 框架中使用它）。您還可以在 R 中獲得強大的支持。您可以將包含數百萬個元素的時間序列轉儲到其中，將其保留在記憶體中（您也可以將其持久化），但您可以非常快速地從 R 中訪問數據。我不知道老實說，從 R 中訪問時間序列數據的更快方法加上額外的索引包將為您提供一個很棒的訪問器庫。如果您尋找快速、高效的東西並查看提示 R 使用的想法/數據，那麼 RedisDB 就是您想要的。當然，這不應該是滿足大量數據需求的解決方案，但您特別提到您處理每小時/每天的數據，為此目的，即使是執行 64 位程式碼的 16gb 核心記憶體的機器也足夠了，因此某些建議 redis 將強迫你投資離譜的硬體是沒有根據的。如果您希望用 R 或 python 或其他語言對這些數據進行大量分析，並希望快速訪問，那麼 redis 是您的解決方案。如果您更關注長期儲存並且樂於接受磁碟訪問延遲，則無需基於記憶體的數據庫，而是查看文件或其他鍵/值或列式數據儲存。如果您希望在 R 或 python 或其他語言中大量分析這些數據並希望快速訪問，那麼 redis 是您的解決方案。如果您更關注長期儲存並且樂於接受磁碟訪問延遲，則無需基於記憶體的數據庫，而是查看文件或其他鍵/值或列數據儲存。如果您希望在 R 或 python 或其他語言中大量分析這些數據並希望快速訪問，那麼 redis 是您的解決方案。如果您更關注長期儲存並且樂於接受磁碟訪問延遲，則無需基於記憶體的數據庫，而是查看文件或其他鍵/值或列數據儲存。
其他解決方案也可能有效，但如果您希望解決所有要求，而不是強迫您坐下來幾天只是為了讓 SQL 解決方案執行而考慮架構和表關係，那麼我建議您研究Redis 或類似方法，而不是 SQL。列式數據庫也可以工作，儘管開源解決方案使用起來相當笨拙，而且我想說在可用性和可擴展性方面沒有經過深思熟慮。（例如：HDM5，雖然它更像是一種文件格式而不是數據庫，但直到 2013 年，這些傢伙仍然無法在 hdf5 文件中啟用動態調整數據大小。您可以刪除內容，但不會返回分配的空間。不管人們怎麼說我關於 NASA 或其他使用它的組織，我以這些大型組織的方式解決了這個故事，這些組織有大量的政府參與，在許多非優先領域的資金和資源可能會變得極其稀缺。如果有足夠的資金來開發更好的數據庫，我認為任何大型組織都不會繼續使用 1990 年代類型的數據庫。這就是某些組織仍在使用它們的原因，但我認為這不是支持使用 Berkeley DB 或 HDF5 的理由；我使用了它們，發現它們在很多方面都非常有限，而且性能甚至沒有那麼好。如果有足夠的資金來開發更好的數據庫，我認為任何大型組織都不會繼續使用 1990 年代類型的數據庫。這就是某些組織仍在使用它們的原因，但我認為這不是支持使用 Berkeley DB 或 HDF5 的理由；我使用了它們，發現它們在很多方面都非常有限，而且性能甚至沒有那麼好。如果有足夠的資金來開發更好的數據庫，我認為任何大型組織都不會繼續使用 1990 年代類型的數據庫。這就是某些組織仍在使用它們的原因，但我認為這不是支持使用 Berkeley DB 或 HDF5 的理由；我使用了它們，發現它們在很多方面都非常有限，而且性能甚至沒有那麼好。
總結：選擇你選擇的武器，如果你願意解決 api 或核心資料結構中有時奇怪的限制，但列式數據庫可能是解決方案，但它們是用來處理時間序列數據的。或者不選擇 SQL 解決方案，無論是基於記憶體/記憶體的解決方案還是純粹的持久化解決方案。但我強烈建議您不要使用 SQL。當被問及他們使用哪個數據庫進行時間序列儲存時，通常是初學者或初級人員的贈品，答案是他們使用 MySQL、MySQL 或嵌入式 SQL 解決方案。這些只是不是為了很好地處理時間序列數據而設計的。