哪個NoSQL實現最合適？

我是NoSQL的新手，我很努力想要找出最適合我正在嘗試構建的應用程序的NoSQL實現。哪個NoSQL實現最合適？

我的Java應用程序需要有一個包含數百萬到數十億條條目的內存哈希映射，因爲它模擬了單層神經網絡。現在我們使用Trove以便能夠使用基元作爲鍵和值來減小地圖的大小並提高訪問速度。該地圖是地圖的地圖，其中外部地圖的鍵是長的，而內部地圖具有長/浮點鍵/值。

當應用程序啓動時，我們需要能夠將保存的狀態從磁盤讀取到映射圖。對地圖貼圖的更改也需要連續或按照某個預定時間間隔保存到磁盤。

因爲他們的文檔和對象數據庫，我最初被拉向OrientDB，雖然我現在還不確定什麼會更好。然後我碰到了Redis，這是一個關鍵的價值存儲，並與可轉儲到磁盤的內存數據集一起工作，包括主從複製。但是，它看起來不像地圖的值可以是除了字符串以外的任何東西。

我在正確的地方尋找解決方案以滿足我的需求嗎？現在，我喜歡Redis的內存和主從方面，但我喜歡OrientDB的對象/文檔功能，因爲我的數據結構比簡單的字符串更復雜，並且能夠使用帶有原始鍵/值類型的Trove非常有利。如果閱讀便宜並且寫作比其他方式更昂貴，那將會更好。

想法？

來源

2013-02-20 herrtim

爲什麼不直接將Trove數據結構序列化到磁盤？文檔（http://trove4j.sourceforge.net/javadocs/serialized-form.html）的判斷看起來似乎有某種支持，但很難說，因爲它都是自動生成的，而不是精心製作的教程。儘管如此，對於你的用例來說，爲什麼你需要一個合適的數據庫並不是很明顯，所以KISS可能適用。

來源

2013-02-20 14:13:21

謝謝，我喜歡這個答案。我忽略了在文檔中，我會寫一些測試代碼現在就試用它。這可能最終成爲最佳解決方案。缺點是，我必須編寫自己的持久代碼，但最終我的應用程序將得到優化。如果我試圖將它發展到NoSQL框架，我可能不得不做出醜陋的妥協。 – herrtim 2013-02-20 15:00:08

OrientDB具有最靈活的引擎，其索引，圖形，事務和複雜文檔爲JSON。爲什麼不？

來源

2013-02-20 18:35:28 Lvca

如果您希望使用Redis進行此操作，則可能最適合使用ZSET或HASH作爲基礎結構（Redis支持結構，而不僅僅是字符串值）。除非您需要根據值的值/排序順序來獲取地圖的各個部分，否則HASH可能是最好的（就內存和速度而言）。

所以你可能會想要使用一個long - > {long：float，...}。也就是說，longs映射到long/float映射。然後，您可以使用HGET，HMGET的多個條目或HGETALL的完整地圖獲取地圖中的單個條目。您可以看到命令參考http://redis.io/commands

在節省空間的一面，根據您希望的HASH的大小，您可能可以調整它們以使用較少的空間，而對性能的影響有限/無負面影響。

在事物的持久性方面，可以使用快照運行Redis，也可以使用只帶追加文件的增量保存方式運行。你可以看到持續性的文檔在這裏：http://redis.io/topics/persistence

如果你想問更尖銳的問題，您應該頭部到郵件列表https://groups.google.com/forum/?fromgroups=#!topic/redis-db/33ZYReULius

來源

2013-02-20 19:20:52 Josiah

感謝您的詳細解答。我開始看到Redis如何爲此工作。爲了使它適用於我當前的Java應用程序，我可以使用Jedis項目。看起來Jedis會通過一個端口與Redis進行通信。我不得不做一些基準測試來比較純Java Trove實現和Jedis/Redis實現，看看哪些更好。 – herrtim 2013-02-21 15:18:00

退房Java-Chronicle。這是一個低延遲持久性庫。我認爲您可能會發現它爲這類數據提供了出色的性能。

來源

2013-02-21 11:59:03 Nicholas

這看起來相當不錯，尤其是寫入磁盤速度。哇。文檔和示例雖然很少，但我不確定如何使用它實現我的地圖貼圖。 – herrtim 2013-02-21 15:50:37

Redis的支持比簡單的字符串（如列表），（分類）設置或哈希可能來方便您的域模型更加複雜data structures。另一方面，您的神經網絡可以利用OrientDB豐富的圖形功能，具體取決於它的結構。

來源

2013-02-25 08:07:58 yojimbo87

哪個NoSQL實現最合適？

回答

相關問題