哪个嵌入式数据库用 Java 编写用于简单的键/值存储？ [关闭]答案

【问题标题】：Which embedded DB written in Java for a simple key/value store? [closed]哪个嵌入式数据库用 Java 编写用于简单的键/值存储？ [关闭]
【发布时间】：2012-04-04 01:11:44
【问题描述】：

我最近问了一个关于 Neo4j 的问题，我开始使用它并且看起来不错。它是可嵌入的，并且是用 Java 编写的，并且没有（太多）依赖项。

但它是一个图形数据库，我不知道将其用作简单的键/值存储是否是个好主意。

基本上我有一张大地图，在 Java 中它看起来像这样：

Map<Integer,Map<String,String>>

我在主映射中有几千万个条目，每个条目都包含一个属性/值映射。 “内部”映射相对较小：大约 20 个条目。

我需要一种方法来将该地图从 web 应用程序的运行中持久保存到另一个。

使用 Neo4j，我所做的是为每个 ID（整数）创建一个节点，然后为内部映射中的每个条目放置一个属性。从我早期的测试来看，它似乎有效，但我不确定这是一个好方法。

您会使用哪个用 Java 编写的可嵌入数据库？

要求是：

用 Java 编写
可嵌入（所以没什么大不了的）
不是 SQL (*)
开源
易于备份（我需要能够在服务器运行时进行“实时”备份）

我的术语也可能有点错误，所以请随时帮助/纠正我。对于我的“地图地图”，最合适的应该是键/值对数据库吧？

我有点迷失键/值对数据库、文档数据库、大表、图形数据库等之间的区别。

我也想使用像 Neo4J 这样的图形数据库来满足我的需要是否是个好主意（我认为性能真的不会成为问题，因为我将拥有相对少量的条目）。

当然，我可以简单地保留我自己的地图地图，但我真的不想在这里重新发明任何轮子。我想重用一个久经考验的数据库...

(*) 我不想要 SQL 的原因是我将始终拥有这个“地图的地图”，并且内部地图会不断发展，所以我不想要过于结构化的东西。

【问题讨论】：

主图的每个条目中的内图是否极有可能不同，或者主图的内图之间是否存在大量重叠？您可以采取许多不同的路线，但这实际上取决于您的结构中的引用复制量。
@cdeszaq：感谢您的评论和帮助...内部地图应该具有相同数量的属性和相同的属性，但是每个属性的值会有所不同。我会说很多重叠，但是我认为性能不会引起那么大的关注：我更喜欢方便/小/易于备份的东西。你认为 Neo4j 会在这里工作吗？我知道有几种选择：太多了，我有点迷路了:)
@cdeszaq：我忘了提：内部地图的属性应在应用程序的生命周期内“进化”：将添加新属性（以及没有这些新属性的旧条目, 在查询不存在的属性时应默认为默认值）。所以有重叠，但它不是“结构化的”，因为实际上没有任何固定的模式（如果我的术语正确的话）。

标签： java database web-applications nosql embedded-database

【解决方案1】：

结帐 www.jsondb.io

这是一个纯Java，可嵌入的轻量级数据库，将其数据存储为文件，便于备份

【讨论】：

非常酷！谢谢你！加上支持 XPath 哦耶！！！！！！！！！！！！

【解决方案2】：

晚了，但您可以使用 Tayzgrid。它的开源及其进程内缓存可以嵌入到您的应用程序中。它基本上是一个内存数据网格或In Memory Key value store，但它也具有您想要的功能，即成为一个简单的进程内嵌入式键值存储。

【讨论】：

【解决方案3】：

对于您的用例，我会推荐 MapDB (http://www.mapdb.org)

它符合您的要求：

用 Java 编写
可嵌入 - 没有依赖关系的单个 jar
不是 SQL - 为您提供持久化到磁盘的映射
开源（Apache 2 许可证）
易于备份（文件少）

并具有其他不错的功能，例如事务、并发性和性能。

【讨论】：

【解决方案4】：

Chronicle-Map 是该领域的新好球员。

它是堆外驻留的（能够通过内存映射文件持久化到磁盘）Map 实现
超快 - 每秒可支持数百万次查询/更新，即。 e.每个查询平均有亚微秒级的延迟
支持并发更新（假设是 ConcurrentHashMap 的直接替换）
您提到的属性映射的特殊支持，如果属性集在集合中是固定的，则允许更新值的特定属性，而无需对整个值进行任何序列化/反序列化（20 个字段）。此功能在 Chronicle/Lang 项目中称为数据值生成。
还有更多...

【讨论】：

【解决方案5】：

您可以只使用 XML 或 JSON 文件。这些 都不需要 架构，并且在磁盘和内存之间来回切换相当容易，尤其是在性能真的不太重要的情况下。（例如，你只偶尔加载配置）

优点是 XML 和 JSON 都非常简单，并且可以很好地处理 Maps。

您的应用程序的依赖负载也轻得多。如果您只是在需要时持久化/取消持久化大数据结构，而不使用大多数嵌入式解决方案将添加的任何查询或类似功能，那么整个嵌入式 DB 类型的系统将非常繁重。

为了满足您的要求，它大部分都内置在 Java 中，易于备份，因为它只是一个文件，高度可嵌入，非常开源，而不是 SQL。 XML 有时可能有点冗长和笨拙，但它是一个众所周知的领域，并且围绕它有非常丰富的工具，因此您可以在需要时在应用程序外部处理它。

【讨论】：

好吧，我确实考虑过 XStream，我确信还有其他方法可以做到这一点，但它似乎有点“低级”。我必须处理失败的“事务”，如果在编写 XML 文件时拔掉电源线等可能出现不一致的状态。此外，我将有几千万个条目（正如我在问题中所写的那样），所以在这种情况下，我不确定 XML 或 JSON 是否会那么“轻量级”（我要么需要大量 XML 文件，要么将多个条目放在同一个文件中）。 XML 或 JSON 是一种选择，但我现在确实在运行 Neo4j，它看起来相对轻量级。
是的，它有点低级，但它不需要任何其他依赖项。如果您担心在写入和事务处理过程中出现电源故障等问题，我会质疑使用几乎 any 嵌入式解决方案。最后，如果你有一些有用的东西，那么就使用它，直到你可以证明你需要别的东西。如果 Neo4j 工作并满足您的需求，请使用它并继续处理更重要的问题。先把它拿出来，然后在你得到真正的反馈后进行迭代。在那之前，你只是在猜测。
“如果您担心写入过程中的电源故障和交易等问题，我会质疑使用任何嵌入式解决方案”...有点。但可以肯定的是，他们中的一些人必须比其他人更好地防范此类事件。事情是：我知道我在猜测。我花了几个小时让 Neo4j 启动并运行，我想知道我可以尝试与之比较。哦，好吧，我会听从你的建议，从现在开始继续使用 Neo4j，即使我不需要“图形”功能。如果遇到问题，我会尝试下一个是“Berkeley DB Java 版”：）
作为使用小型（一个 .jar）可嵌入数据库可能导致失败的示例，以下是 Oracle 网站对“Berkeley DB Java”的评价：“Berkeley DB Java 版可靠地存储数据并确保数据完整性。在系统发生故障时，Berkeley DB Java 版将恢复事务数据并根据日志和数据库信息将系统重置为功能一致的状态。 “这是我想从中受益而不必重新发明轮子的事情:)
@cdeszaq 大多数优秀的嵌入式数据库在发生故障时都具有某种恢复功能。例如，LevelDB 被设计为对故障具有极强的弹性，它在发生故障时具有非常好的恢复功能，并且可以以最小的数据丢失进行恢复。

【解决方案6】：

Google 的 LevelDB 似乎有几个移植到 Java 中：

那么这里有一个完整的嵌入式 Java 数据库列表：

【讨论】：

这些是很棒的链接...在我的具体情况下，您会推荐其中的任何一个吗？
@CedricMartin 如果您想要一个轻量级且速度极快的嵌入式数据库，我绝对会推荐 LevelDB。要从 LevelDB 获得最大性能，请尝试使用迭代器而不是获取（Iterator.Seek vs DB.Get）按顺序访问您的密钥。 LevelDB 对于随机读/写非常快，但它针对顺序读/写进行了高度优化。此外，LevelDB 具有很强的故障恢复能力，并且它内置了在您无法打开数据库时修复数据库的功能。

【解决方案7】：

你可以看看 berkeley DB

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

它在处理大量数据方面非常有效，而且它是键/值。因为我自己发现了它，所以我无法真正告诉它更多信息，但如果你有时间看看它......

【讨论】：

我正准备回答你“是的，Berkeley 总是很好，但它是用 C 编写的” 然后我意识到现在有一个 “Berkeley DB Java 版” 完全用 Java 和开源编写......这可能很有趣。
它是纯 Java ......问题是许可证对（小型）软件业务不友好。