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