我在电子健康记录领域工作，如果尝试使用关系数据库，我使用的标准(http://www.openehr.org)在许多用例中会造成严重的不匹配。
我已经设法开发了一些相当成功的方法，使用关系数据库来处理大多数树结构，但如果我使用键值类型的存储，我可以做得更好。
问题是，RDMS概念已经在市场上占据了主导地位，以至于成熟度几乎完全与关系数据库相关。每当有人考虑离开关系空间时，特别是最近，NOSQL之歌就开始响起。大多数NOSQL选项都太年轻了，我很难投资它们来处理敏感的医疗保健数据。
所以我正在寻找成熟的，开源的，高性能的选项在非关系空间，特别是那些方便的键值类型的操作。例如，BerkeleyDB就是一个这样的选择，但是Oracle目前的许可条款对我不起作用。
我不需要SQL，我将不得不实现一种自定义查询语言(它已经定义为openEHR规范的一部分)。我不需要表格，因为我的数据都是树结构。我需要成熟、稳定和性能，我需要ACID遵从性、可伸缩性，我需要开源。我甚至考虑过将各种成熟的Java框架结合在一起来实现这些目标，并在这里提出了一个问题，但似乎这不是一个现实的方法。
有什么隐藏的或明显的宝石我错过了吗?
成熟度、稳定性、性能、ACID遵从性、可扩展性、开源、树状结构数据-使用OpenLDAP。
如果您真的想使用自己的数据模型和查询语言，您可以使用LMDB，这是为OpenLDAP开发的键值存储。
如果您的应用程序是用Java编写的，那么Chronicle Map是解决您的问题的成熟且非常有效的解决方案。它比伯克利db快多了。不过，Chronicle Map不是ACID，它只通过操作系统级别的文件内存映射提供最终的一致性。你可以在这里找到关于Chronicle Map的耐久性保证的确切信息