在不使用关系数据库的情况下在 Java 中存储和检索对象的简单方法？ [关闭]

Posted 2023-03-31

【中文标题】在不使用关系数据库的情况下在 Java 中存储和检索对象的简单方法？ [关闭]

【英文标题】：Easy way to store and retrieve objects in Java without using a relational DB? [closed]

【发布时间】：2009-01-14 16:10:25

【问题描述】：

您是否知道在 Java 中存储和检索对象的“简单”方法不使用像 Hibernate 这样的关系 DB/ORM？

[请注意，我并没有为此考虑按原样进行序列化，因为它不允许检索对象图中间的任意对象。我也不考虑 DB4O，因为它有限制性许可。谢谢。]

“简单”的意思是：不必处理诸如键/值对之类的低级细节来重建对象图（与 BerkeleyDB 或传统缓存一样）。这同样适用于从面向文档或面向列的数据库（CouchDB、HBase、...，甚至 Lucene）重建对象。

也许有一些有趣的项目在上述存储系统和我不知道的对象模型（例如用于 RDBMS 的 ORM）之间提供了一层集成。

任何人成功地在生产中使用这些，或者尝试使用关系数据库以外的持久性策略？ RDF 商店怎么样？

更新：我看到一篇非常有趣的文章：A list of distributed key-value stores

【问题讨论】：

也许您应该将您的问题重新表述为“在不使用关系数据库、对象序列化或任何 GPL 许可产品的情况下在 Java 中存储和检索对象的简单方法？”。顺便说一句，我也很想知道这样的解决方案。

谢谢，但我认为这个标题太长了！

我同意。我在这里看到 2 个选项：直接写入文件系统（序列化）或使用数据库。这两个你都不想要？还是您想要 DB40 之类的东西，但许可限制较少？

我不同意你对序列化的反对。您可以序列化地图，拥有序列化对象的地图等。

@Tom：也许我在那里不够清楚。我的意思是，如果我序列化，即一个包含 5 只动物的动物园对象，我怎么可能独立地检索/反序列化任何给定的动物？你看到了吗？

【参考方案1】：

Object Serialization（也就是将内容存储到文件中） Hibernate（使用关系数据库，但对开发者来说相当透明）

我建议使用 Hibernate，因为它可以处理在使用数据库时使开发人员陷入困境的大部分丑陋细节，同时仍然允许多年来对数据库软件进行的优化。

【讨论】：

感谢您的回答，但我只是说我不想想使用数据库！这意味着不使用 ORM 我猜...我正在寻找替代的东西。也正如我在帖子中所说，没有序列化！！！

【参考方案2】：

NeoDatis 看起来很有趣。它是根据 LGPL 获得许可的，因此不像 GLP 那样严格。

查看他们的1 minute tutorial，看看它是否能满足您的需求。

【讨论】：

谢谢史蒂夫。我实际上非常了解neodatis（我什至编写了warp-persist-neodatis 集成）——我刚刚停止使用它，因为它确实有问题，但我应该再试一次。该死的，我想我在这里要求太高了...... :)

您参与过 NeoDatis 项目吗？我接触过的大多数开源项目都对错误报告/补丁非常敏感。我没有参与 NeoDatis - 所以他们可能是例外:)

是的，这家伙反应灵敏。但他一个人，问题是我一直都有问题——所以我不确定稳定性。我现在要再次检查 :) 并查看源代码

【参考方案3】：

我想推荐XStream，它只是简单地获取您的 POJO 并从中创建 XML，以便您可以将其存储在磁盘上。它非常易于使用，并且是开源的。

【参考方案4】：

我会推荐像 Matt 这样的 Hibernate（或者更一般地说，OR-mapping），但后端也有一个 RDBMS，我不太清楚你的意思是什么

...不使用关系数据库？...

了解更多有关应用程序的信息也会很有趣，因为 OR 映射并不总是一个好主意（开发性能与运行时性能）。

编辑：我很快了解了兵马俑，并且有一个很好的 *** 讨论 here 关于用该工具替换数据库。仍处于试验阶段，但值得一读。

【讨论】：

谢谢。我的意思是“去掉 RDBMS 和 ORM”

【参考方案5】：

我仍然认为你应该考虑为db4o付费。

如果您想要其他内容，请在标题中添加“with an MIT-style license”。

【讨论】：

我不这么认为。感谢您的评论

【参考方案6】：

在this question 上查看 Prevayler 上的 cmets。 Prevayler 是一个围绕对象序列化的事务性包装器——粗略地说，使用纯 java 中的对象并通过没有 sql 的 java API 持久化到磁盘，比编写自己的序列化更简洁。

注意事项 - 将序列化作为一种​​持久性机制，当您更新类时，您将面临使保存的数据无效的风险。即使使用包装库，您也可能希望自定义序列化/反序列化处理。它还有助于在类中包含 serialVersionUID，这样您就可以覆盖 JVM 关于何时更新类的想法（因此无法重新加载您保存的序列化数据）。

【参考方案7】：

嗯...如果没有序列化，也没有 ORM 解决方案，我会退回到某种基于 XML 的实现吗？如果您只想从对象图中提取一些对象，您仍然需要仔细设计它 - 可能每个对象都有一个不同的文件，其中对象关系通过 URI 引用到另一个文件？

我会说这并不“容易”，因为我一直发现设计 XML 到对象的映射有点费时，但我真的受到了 Apache Betwixt 上的一次谈话的启发，这让我感到充满希望我只是过时了，现在有更简单的解决方案。

【讨论】：

这不就是序列化吗？

【参考方案8】：

Terracotta 提供了一个高度可用、高度可扩展的持久性磁盘对象存储。您可以仅将它用于此功能 - 或者您可以使用它的广泛功能来实现完全集群的应用程序 - 您可以选择。

兵马俑：

不会破坏对象标识，为您提供最自然的编程界面 不需要序列化 集群（并持久化）几乎所有 Java 类（Maps、Locks、Queues、FutureTask、CyclicBarrier 等） 以内存速度将对象保存到磁盘 仅移动对象增量，提供非常高的性能

Here's a case study about how gnip 使用 Terracotta 进行内存持久性 - 没有数据库。 Gnip 接收 Facebook、Twitter 等网站上的所有事件，并以标准化的方式为消费者制作它们。他们目前的解决方案是每秒处理超过 50,000 条消息。

它是 OSS，与许多其他 3rd 方框架高度集成，包括 Spring 和 Hibernate。

【参考方案9】：

我想我已经找到了问题的答案。

当您一直从关系、规范化和连接的角度考虑数据时，要获得面向文档的范式思维方式并非易事。

CouchDB 似乎符合要求。它仍然可以充当键值存储，但其强大的查询功能（map/reduce、查看排序规则）、并发准备和与语言无关的 HTTP 访问使其成为我的选择。

只有错误是必须正确定义 JSON 结构并将其映射到对象，但我相信我会想出一个简单的解决方案来使用 Java 和 Scala 的关系模型（并担心以后的缓存，因为争用是远离数据库）。 Terracotta 仍然很有用，但肯定不像 RDBMS 场景那样有用。

感谢大家的意见。