Hibernate (uses a relational database but it is fairly transparent to the developer)
I would suggest Hibernate because it will deal with most of the ugly details that bog developers down when using a database while still allowing for the optimizations that have been made to database software over the years.
I would like to recommend XStream which simply takes your POJOs and creates XML out of them so you can store it on disk. It is very easy to use and is also open source.
I'd recommend Hibernate (or, more general, OR-mapping) like Matt, but there is also a RDBMS at the backend and I'm not so sure about what you mean by
...without using a relational DB?...
It also would be interesting to know more about the application, because OR-mapping is not always a good idea (development performance vs. runtime performance).
Edit: I shortly learned about terracotta and there is a good stackoverflow discussion here about replacing DBs with that tool. Still experimental, but worth reading.
Check out comments on Prevayler on this question. Prevayler is a transactional wrapper around object serialization - roughly, use objects in plain java and persist to disk through java API w/o sql, a bit neater than writing your own serialization.
Caveats- with serialization as a persistance mechanism, you run the risk of invalidating your saved data when you update the class. Even with a wrapper library you'll probably want to customize the serialization/deserialization handling. It also helps to include the serialVersionUID in the class so you override the JVM's idea of when the class is updated (and therefore can't reload your saved serialized data).
嗯...如果没有序列化，也没有 ORM 解决方案，我会退回到某种基于 XML 的实现吗？ 如果您只想从对象图中提取某些对象，那么您仍然需要仔细设计它 - 也许每个对象都有一个不同的文件，其中对象关系由 URI 引用到另一个文件？
我会说这并不“容易”，因为我总是发现设计 XML 到对象的映射有点耗时，但 Apache Betwixt 上的一次对话确实给了我很大的启发，这让我感到希望我能够已经过时了，现在有更简单的解决方案。
Hmm... without serialization, and without an ORM solution, I would fall back to some sort of XML based implementation? You'd still have to design it carefully if you want to pull out only some of the objects from the object graph - perhaps a different file for each object, where object relationships are referenced by a URI to another file?
I would have said that wasn't "easy" because I've always found designing the mapping of XML to objects to be somewhat time consuming, but I was really inspired by a conversation on Apache Betwixt that has me feeling hopeful that I'm just out of date, and easier solutions are now available.
Terracotta provides a highly available, highly scalable persistent to disk object store. You can use it for just this feature alone - or you can use it's breadth of features to implement a fully clustered application - your choice.
Terracotta:
does not break object identity giving you the most natural programming interface
does not require Serialization
clusters (and persists) nearly all Java classes (Maps, Locks, Queues, FutureTask, CyclicBarrier, and more)
persists objects to disk at memory speeds
moves only object deltas, giving very high performance
Here's a case study about how gnip uses Terracotta for in-memory persistence - no database. Gnip takes in all of the events on Facebook, Twitter, and the like and produces them for consumers in a normalized fashion. Their current solution is processing in excess of 50,000 messages / second.
It's OSS and has a high degree of integration with many other 3rd party frameworks including Spring and Hibernate.
I guess I have found a sort of answer to my question.
Getting the document-oriented paradigm mindset is no easy task when you have always thought your data in terms of relationships, normalization and joins.
CouchDB seems to fit the bill. It still could act as a key-value store but its great querying capabilities (map/reduce, view collations), concurrency readiness and language-agnostic HTTP access makes it my choice.
Only glitch is having to correclty define and map JSON structures to objects, but I'm confident I will come up with a simple solution for usage with relational models from Java and Scala (and worry about caching later on, as contention is moved away from the database). Terracotta could still be useful but certainly not as with an RDBMS scenario.
发布评论
评论（9）
我建议 Hibernate 因为它将处理开发人员在使用数据库时陷入困境的大部分丑陋细节，同时仍然允许多年来对数据库软件进行的优化。
I would suggest Hibernate because it will deal with most of the ugly details that bog developers down when using a database while still allowing for the optimizations that have been made to database software over the years.
NeoDatis 看起来很有趣。 它是根据 LGPL 获得许可的，因此不像 GLP 那样严格。
查看他们的1 分钟教程，看看它是否能满足您的需求。
NeoDatis looks interesting. It is licensed under the LGPL, so not quite as restrictive as the GLP proper.
Check out their 1 minute tutorial to see if it will work for your needs.
我想推荐 XStream 它只需获取您的 POJO 并从中创建 XML，以便您可以将其存储在磁盘。 它非常易于使用，而且是开源的。
I would like to recommend XStream which simply takes your POJOs and creates XML out of them so you can store it on disk. It is very easy to use and is also open source.
我会像 Matt 一样推荐 Hibernate（或者更一般的 OR 映射），但后端还有一个 RDBMS，我不太确定你的意思
了解有关应用程序的更多信息也很有趣，因为 OR 映射并不总是一个好主意（开发性能与运行时性能）。
编辑：我很快就了解了 terracotta，这里有一个很好的 stackoverflow 讨论 关于用该工具替换数据库。 仍处于实验阶段，但值得一读。
I'd recommend Hibernate (or, more general, OR-mapping) like Matt, but there is also a RDBMS at the backend and I'm not so sure about what you mean by
It also would be interesting to know more about the application, because OR-mapping is not always a good idea (development performance vs. runtime performance).
Edit: I shortly learned about terracotta and there is a good stackoverflow discussion here about replacing DBs with that tool. Still experimental, but worth reading.
我仍然认为你应该考虑支付 db4o 的费用。
如果您想要其他内容，请在标题中添加“具有 MIT 风格的许可证”。
I still think you should consider paying for db4o.
If you want something else, add "with an MIT-style license" to the title.
查看 Prevayler 对此问题的评论。 Prevayler 是对象序列化的事务包装器 - 粗略地说，使用纯 java 中的对象并通过 java API（无需 sql）持久保存到磁盘，比编写自己的序列化更简洁。
注意事项 - 使用序列化作为持久性机制，您在更新类时面临着使保存的数据无效的风险。 即使使用包装器库，您也可能需要自定义序列化/反序列化处理。 它还有助于在类中包含serialVersionUID，这样您就可以覆盖 JVM 关于类何时更新的想法（因此无法重新加载保存的序列化数据）。
Check out comments on Prevayler on this question. Prevayler is a transactional wrapper around object serialization - roughly, use objects in plain java and persist to disk through java API w/o sql, a bit neater than writing your own serialization.
Caveats- with serialization as a persistance mechanism, you run the risk of invalidating your saved data when you update the class. Even with a wrapper library you'll probably want to customize the serialization/deserialization handling. It also helps to include the serialVersionUID in the class so you override the JVM's idea of when the class is updated (and therefore can't reload your saved serialized data).
嗯...如果没有序列化，也没有 ORM 解决方案，我会退回到某种基于 XML 的实现吗？ 如果您只想从对象图中提取某些对象，那么您仍然需要仔细设计它 - 也许每个对象都有一个不同的文件，其中对象关系由 URI 引用到另一个文件？
我会说这并不“容易”，因为我总是发现设计 XML 到对象的映射有点耗时，但 Apache Betwixt 上的一次对话确实给了我很大的启发，这让我感到希望我能够已经过时了，现在有更简单的解决方案。
Hmm... without serialization, and without an ORM solution, I would fall back to some sort of XML based implementation? You'd still have to design it carefully if you want to pull out only some of the objects from the object graph - perhaps a different file for each object, where object relationships are referenced by a URI to another file?
I would have said that wasn't "easy" because I've always found designing the mapping of XML to objects to be somewhat time consuming, but I was really inspired by a conversation on Apache Betwixt that has me feeling hopeful that I'm just out of date, and easier solutions are now available.
Terracotta 提供了一个高度可用、高度可扩展的持久性磁盘对象存储。 您可以仅将它用于此功能 - 或者您可以使用它的广泛功能来实现完全集群的应用程序 - 您可以选择。
Terracotta：
这里有一个关于 gnip 的案例研究使用 Terracotta 进行内存持久化 - 无数据库。 Gnip 接收 Facebook、Twitter 等上的所有事件，并以标准化方式为消费者生成它们。 他们当前的解决方案每秒处理超过 50,000 条消息。
它是 OSS，与许多其他第 3 方框架（包括 Spring 和 Hibernate）具有高度集成。
Terracotta provides a highly available, highly scalable persistent to disk object store. You can use it for just this feature alone - or you can use it's breadth of features to implement a fully clustered application - your choice.
Terracotta:
Here's a case study about how gnip uses Terracotta for in-memory persistence - no database. Gnip takes in all of the events on Facebook, Twitter, and the like and produces them for consumers in a normalized fashion. Their current solution is processing in excess of 50,000 messages / second.
It's OSS and has a high degree of integration with many other 3rd party frameworks including Spring and Hibernate.
我想我已经找到了我的问题的某种答案。
当您始终根据关系、规范化和连接来思考数据时，获得面向文档的范式思维方式并不是一件容易的事。
CouchDB 似乎符合要求。 它仍然可以充当键值存储，但其强大的查询功能（map/reduce、视图排序规则）、并发就绪性和与语言无关的 HTTP 访问使其成为我的选择。
唯一的问题是必须正确定义 JSON 结构并将其映射到对象，但我相信我会想出一个简单的解决方案，用于 Java 和 Scala 的关系模型（稍后会担心缓存，因为争用已从数据库）。 Terracotta 仍然有用，但肯定不如 RDBMS 场景。
谢谢大家的意见。
I guess I have found a sort of answer to my question.
Getting the document-oriented paradigm mindset is no easy task when you have always thought your data in terms of relationships, normalization and joins.
CouchDB seems to fit the bill. It still could act as a key-value store but its great querying capabilities (map/reduce, view collations), concurrency readiness and language-agnostic HTTP access makes it my choice.
Only glitch is having to correclty define and map JSON structures to objects, but I'm confident I will come up with a simple solution for usage with relational models from Java and Scala (and worry about caching later on, as contention is moved away from the database). Terracotta could still be useful but certainly not as with an RDBMS scenario.
Thank you all for your input.