哪個嵌入式數據庫用Java編寫的簡單鍵/值存儲？

我最近問了一個關於Neo4j的問題，我開始工作了，而且看起來不錯。它是可嵌入的，它是用Java編寫的，並沒有太多的依賴關係。哪個嵌入式數據庫用Java編寫的簡單鍵/值存儲？

但是，它是一個圖形數據庫，我不知道這是個好主意還是不要將它用作簡單的鍵/值存儲。

基本上我已經有了一個大的地圖，這在Java中是這樣的：

Map<Integer,Map<String,String>>

我在主地圖有幾十上百萬個條目，每個條目都包含自身的地圖的財產/價值。「內部」地圖相對較小：大約20個條目。

我需要一種方法來保持從web應用運行到另一個地圖。

使用Neo4j，我所做的是爲每個ID（整數）創建一個節點，然後將每個條目的一個屬性放入內部映射中。從我的早期測試看來，這似乎有效，但我不確定這是繼續進行的好方法。

哪種嵌入式數據庫，用Java編寫，你會用到嗎？

的要求是：

用Java編寫的
嵌入（所以沒有什麼太大）
不 SQL（*）
開源
輕鬆備份（我需要能夠做「活」備份，服務器運行時）

我的術語可能有點錯誤太多，所以隨便幫我/指正。對於我的「地圖地圖」，最合適的是一個關鍵/值對數據庫對嗎？

我有點失去了作爲鍵/值對數據庫，文件數據塊，大表，圖形數據塊等之間的差異

我也會喜歡，如果是使用圖形DB是個好主意像我的需要Neo4J（我認爲性能真的不會是一個問題，因爲我會有相對較少的參賽作品）。

當然我可能只是堅持我自己的地圖的地圖，但我真的不想在這裏重新發明任何車輪。我想重用一個久經考驗的數據庫...

（*）我不想SQL的原因是我總是會有這個「地圖映射」，內部映射會不斷演變，所以我不想要太結構化的東西。

來源

2012-03-19 Cedric Martin

是內在的地圖很可能是在每個條目不同主地圖的內部地圖之間是否存在大量的重疊？您可以採取多種不同的路線，但這取決於結構中參照複製的數量。 – cdeszaq 2012-03-19 14:41:34

@cdeszaq：感謝您的評論和幫助......內部地圖大多具有相同數量的屬性和相同的屬性，但是每個屬性的值會有所不同。我會說有一些重疊，但我不認爲表演會成爲一個很大的擔憂：我更喜歡方便/小/易於備份的東西。你認爲Neo4j會在這裏工作嗎？我知道有幾個選擇：太多，我有點失落：） – 2012-03-19 14:47:11

@cdeszaq：我忘了提及：內部地圖的屬性應該在應用程序的生命週期中「發展」：新屬性將被添加（舊的條目不具有這些新的屬性時，在查詢不確定的屬性時應默認爲默認值）。所以存在重疊，但它沒有「結構化」，因爲沒有任何固定的模式（如果我的術語是正確的）。 – 2012-03-19 14:53:18

你可以看看Berkeley DB的

http://docs.oracle.com/cd/E17277_02/html/GettingStartedGuide/index.html

這是在處理大數據量非常有效，它的鍵/值。我真的不能告訴更多地瞭解它，因爲我發現了自己，但如果你有時間去看看進去......

來源

2012-03-19 14:41:31

我要回答你的問題*「是的，伯克利總是很好，但它是用C編寫的*」，然後我意識到現在有一個*「Berkeley DB Java版本」*完全用Java和開源編寫......它可能是有趣。 – 2012-03-19 14:50:23

是純粹的Java ...問題是許可對（小）軟件事業不友好。 – 2015-09-20 15:33:13

似乎有一對夫婦谷歌的LevelDB的端口到Java：

再有就是嵌入式Java的整個列表數據庫這裏：

來源

2012-03-19 14:57:41 Kiril

這些都是很好的鏈接......在我的具體情況下，你會推薦他們中的任何一個嗎？ – 2012-03-19 15:43:07

@CedricMartin如果你想要一個輕量級且速度極快的嵌入式數據庫，我肯定會推薦LevelDB。要從LevelDB獲得最大性能，請嘗試使用迭代器按順序訪問您的密鑰，而不是獲取（Iterator.Seek vs DB.Get）。 LevelDB對於隨機讀取/寫入非常快速，但對於順序讀取/寫入而言，它是高度優化的。此外，LevelDB對故障具有很強的適應性，並且它內置了修復數據庫的功能，如果無法打開它的話。 – Kiril 2012-03-19 16:36:19

您可以只是堅持使用XML或JSON文件。這兩個都不需要架構，並且在磁盤和內存之間來回切換相當容易，尤其是在性能確實無關緊要的情況下。（例如，你只是偶爾加載配置）

好處是，XML和JSON都非常簡單，處理地圖相當不錯。

您的應用程序還具有更輕的依賴性負載。如果您只是在需要時堅持/取消保留大數據結構，而不使用大多數嵌入式解決方案將添加的任何查詢或類似功能，則整個嵌入式數據庫類型系統非常繁重。

爲了滿足您的需求，它大部分內置於Java，易於備份，因爲它只是一個文件，高度可嵌入，非常開源，而不是SQL。有時候XML可能有點冗長而笨拙，但它是一個衆所周知的領域，並且具有非常豐富的工具，以便您可以根據需要在應用程序外部處理它。

來源

2012-03-19 15:16:28 cdeszaq

好吧，我確實考慮過XStream，我相信還有其他方法可以做到這一點，但它似乎有點「低級」。我必須處理失敗的「事務」，如果在編寫XML文件時電源線被移除，可能會出現不一致的狀態，等等。另外，我將有幾千萬條記錄（正如我在我的問題中所寫的那樣），所以在這種情況下，我不確定XML或JSON會是「輕量級的」（我要麼需要很多XML文件，要麼將多個條目放在同一個文件中）。 XML或JSON是一個選項，但我現在有Neo4j正在運行，它看起來相對較輕。 – 2012-03-19 15:46:36

是的，它有點低級，但不需要任何其他的依賴關係。如果你擔心電力中斷和交易等問題，我會質疑使用幾乎所有的嵌入式解決方案。最後，如果你有一些可行的東西，那就直接使用它，直到你能證明你需要別的東西。如果Neo4j能正常工作並滿足您的需求，請使用它並繼續處理更重要的問題。先把它出門，然後一旦你有真正的反饋就重複。在此之前，你只是在猜測。 – cdeszaq 2012-03-19 15:50:19

*「如果您擔心中斷寫入和交易等電源故障，我會質疑幾乎所有嵌入式解決方案的使用」* ...有點兒。但肯定其中一些人必須比其他人更好地保護這種事件。事情是：我知道我在猜測。我花了幾個小時讓Neo4j運行起來，我想知道我可以嘗試與之比較。哦，我會遵循你的建議，並保持與Neo4j截至目前，即使我不需要「圖形」功能。接下來我會嘗試如果遇到問題，應該是「Berkeley DB Java版本」：） – 2012-03-19 15:54:53

爲您的使用情況下，我會建議創建mapdb（http://www.mapdb.org）

它符合您的要求：

用Java編寫的
嵌入 - 單罐子沒有依賴
沒有SQL - 給你地圖，堅持到磁盤
開源（Apache 2許可證）
輕鬆備份（幾個文件）

，但有其他不錯的功能，如交易，併發性和性能。

來源

2014-07-01 10:39:38 Andrejs

Chronicle-Map是這個領域新的好球員。

它是離堆居住（有能力通過內存映射文件的方式被保存在磁盤上）Map實施
超高速 - 每秒維持數以百萬計的查詢/更新，我。即每個查詢有平均
亞微秒的延遲，支持併發更新（假設爲一個簡易替換的ConcurrentHashMap）
特別支持的你提到的，如果組屬性集合內固定屬性映射 - 允許更新該值的特定屬性，而不需要對整個值進行任何序列化/反序列化（20個字段）。此項功能稱爲數據值生成在編年史/ Lang項目。

還有更多...

來源

2014-12-06 08:18:08 leventov

末到一部分，但你可以使用Tayzgrid。它的開源代碼和它的進程內緩存可以嵌入到你的應用程序中。它基本上是一個內存數據網格或In Memory Key value store，但它也有你想要的能力，即成爲一個簡單的過程嵌入式密鑰值存儲。

來源

2015-09-08 12:38:34

結帳www.jsondb.io

這是一個純Java，存儲其數據作爲文件嵌入輕量級的數據庫，這使得它很容易備份

來源

2016-12-25 10:43:14

非常酷！感謝您的支持！加上支持XPath o耶!!!!!!!!!!!! – GOXR3PLUS 2017-01-28 03:39:51

哪個嵌入式數據庫用Java編寫的簡單鍵/值存儲？

回答

相關問題