虽然这是一个老问题,我一直在寻找到这家最近和所遇到以下(至少两个,这一问题被提出之后的写)。我不确定其中的任何一个如何处理非常大的对象 - 并且在10GB时,您可能不得不进行一些严重的测试,因为我认为很少有数据库开发人员会为他们的产品考虑这种大小的对象(只是猜测)。我一定会考虑直接将它们存储到磁盘,只需引用数据库中的文件位置即可。
(下面的观点都很肤浅,顺便说一下,因为我还没有认真地使用它们)。
OrientDB看起来最成熟的三,我发现的。它似乎是一个文档和/或图形数据库,并声称速度非常快(使用和“RB +树”数据结构 - B +和红黑树的组合)。它声称是超快速和轻量级的,没有外部依赖性。例如,似乎有一个积极的社区正在开发它,在过去的几天中有很多提交。它还符合TinkerPop图形数据库标准,它增加了另一层功能(如Gremlin图形查询语言)。它符合ACID,具有REST和其他外部API,甚至是基于Web的管理应用程序(大概可以与嵌入式数据库一起部署,但我不确定)。
接下来的两个更多的陷入了N(OT)O(nly)SQL世界的简单键值存储阵营。
JDBM3是一个非常小的数据存储:它具有通过内存映射文件写入磁盘的哈希映射,树映射,树集和链表。它声称非常轻巧,速度非常快,完全交易并且正在积极开发中。
HawtDB看起来相似非常简单和快速 - 基于BTree或哈希的索引持久化到磁盘与内存映射文件。它(可选)完全交易。在过去的七个月中(截至2012年3月底)没有任何承诺,邮件列表上的活动也不多。这并不是说它不是一个好的图书馆,但值得一提。
JDBM3和HawtDB是非常小的,所以你不会得到任何花哨的图形用户界面。但我认为他们对于速度和简单性都非常有吸引力。
这些都是我发现符合您的要求。另外,Neo4J非常棒 - 图形数据库,现在已经相当成熟,并且在嵌入式模式下效果很好。这是GPL/AGPL许可的,虽然如此,可能需要支付牌照,除非你能过开源代码: http://neotechnology.com/products/price-list/
当然,你也可以使用H2 SQL database一个大表,没有索引!
一直试图使用OrientDB作为文档数据库。文档已过时,几乎所有示例都使用已弃用的类...阅读最新版本的javadocs几乎没有任何帮助......我期待着尝试一下,但在开始令人沮丧的开始之后,我不是当然,这是一个不错的选择。 – Renato 2015-08-17 17:21:30