虽然这是一个老问题,但我最近一直在研究这个问题并遇到了以下问题(其中至少有两个是在提出这个问题之后写的)。我不确定这些中的任何一个如何处理非常大的对象 - 在 10GB 时,您可能需要进行一些认真的测试,因为我认为很少有数据库开发人员会为他们的产品考虑这种大小的对象(只是猜测)。我肯定会考虑将它们直接存储到磁盘,只需参考数据库中的文件位置。
(顺便说一下,下面的观点都很肤浅,因为我还没有认真使用它们)。
OrientDB看起来是我发现的三个中最成熟的。它似乎是一个文档和/或图形数据库,并声称非常快(利用“RB+Tree”数据结构——B+ 和红黑树的组合)。它声称超级快速和轻便,没有外部依赖。似乎有一个活跃的社区正在开发它,例如,在过去的几天里有很多提交。它还符合TinkerPop图数据库标准,增加了另一层功能(例如 Gremlin 图查询语言)。它符合ACID,具有 REST 和其他外部 API,甚至还有一个基于 Web 的管理应用程序(大概可以与您的嵌入式数据库一起部署,但我不确定)。
接下来的两个更多地属于 N(ot)O(nly)SQL 世界的简单键值存储阵营。
JDBM3是一个极小的数据存储:它有一个哈希映射、树映射、树集和链表,它们通过内存映射文件写入磁盘。它声称非常轻量和快速,是完全事务性的,并且正在积极开发中。
HawtDB看起来非常简单和快速——基于 BTree 或 Hash 的索引通过内存映射文件持久保存到磁盘。它(可选)是完全事务性的。过去 7 个月(到 2012 年 3 月结束)没有提交,邮件列表上也没有太多活动。这并不是说它不是一个好的库,但值得一提。
JDBM3 和 HawtDB 非常小,所以你不会得到任何花哨的 GUI。但我认为它们的速度和简单性都非常吸引人。
这些都是我发现的符合您要求的所有内容。此外,Neo4J 很棒——一个图形数据库,现在已经相当成熟并且在嵌入式模式下工作得很好。不过,它是 GPL/AGPL 许可的,因此可能需要付费许可,除非您也可以开源代码:http:
//neotechnology.com/products/price-list/
当然,你也可以使用一张大表没有索引的H2 SQL 数据库!