DMS 的 JCR 与 JPA：性能、优点和缺点
JCR vs JPA for a DMS: performance, benefits, drawbacks
在做了一些关于 JCR or RDBMS, and reading other posts 的研究之后，我仍然不确定是否将 JCR 而不是 JPA 用于文档管理系统，它必须处理不同的文档类型，非常大的文件 和 大量 来自许多用户的并发访问。
我考虑 JCR 的主要原因是因为文档对我来说看起来像 content，并且该规范已经处理了一些随之而来的问题——主要是我对存储和版本控制。此外，我想将文档内容封装在 JCR 实现中，并将 JPA 用于特定于应用程序的所有其他内容。
也许有人可以帮我解决剩下的问题：
- JCR 的 read/query 性能与 JPA 有什么关系（我知道它在实现上会有很大差异，但可能有一些经验法则）？
- 是否有人在具有某些特定 JCR 实现的类似用例中具有真实世界经验？如果是这样，您是否将其与关系数据库 (JPA) 混合使用？
- 考虑到文件存储和版本控制的好处，引入 JCR 是否值得？ （我可能会使用我自己的自定义使用访问控制 (JPA)，我不需要额外的灵活性来在运行时引入新的节点属性）
- 有人对数据完整性和备份解决方案有任何经验吗？
UPDATE：虽然这个问题已经得到了详细的回答，但从更实际的角度来看，有人可能会对它的使用有更挑剔的眼光。我个人越来越关注以下与技术无关的问题：
- 文档：Jackrabbit 的文档很差，它是 OCM contains a dead link in the first paragraph, some example search queries throw exceptions for unknown reasons, there is a TODO 的非常基本的教程指南，它的独立服务器在 JDK8 中无法正常工作，根本没有文档。
- 成熟度：Jackrabbit Oak 似乎仍在开发中，其他解决方案看起来要么被放弃要么处于前沿。
- 社区：与 JPA 相反，对 JCR 的研究导致更少 hits。当一个刚接触该技术的项目团队陷入（琐碎的）问题中时，这可能是一个真正的问题。
简短版本：文档是结构化或半结构化的内容。这就是分层组织的数据存储的用例。如果您不想自己实现所有基本的 dms/cms 东西，您应该选择 JCR（考虑一下，您可能是第一次这样做，而他们一直都在这样做）。
长版本：JCR 按规范涵盖了文档或内容管理系统的大部分基本用例，例如版本控制、锁定、生命周期管理或参照完整性。此外，它允许您在不更改模式的情况下扩展数据（当然您可以在模型中定义节点类型，但您不必这样做）。大多数 JCR 实现（如 Jackrabbit）在后端使用数据库，使它们 "little more" 而不是关系后端上的抽象层。处理大数据时，可以使用文件系统存储（这比将每个二进制数据都存储到数据库中要快得多），同时将结构化数据（节点和属性）存储在数据库中。
使用 JPA 时，您必须自己处理所有这些 dms/cms 问题。您当然可以这样做，但它已经在 JCR 实现中完成了更多的低级编程。每个模型更改都需要更改架构，并且 table 布局并不是那么微不足道（您想为文档设置一个大的 table，每个 属性 都是一列吗？想要为每个文档单独 table class？如何对生命周期建模，如何对版本控制建模？）
对于 JCR 的第一跳，我建议 David's Model，将应用程序的所有内容都视为内容。我曾在一个项目中工作过，我们决定不混合使用 JCR 和 JPA，这样我们就不必处理不同的 API 存储。
并且至少有一些 JCR 实现
- Jackrabbit 2（参考实现，针对读取操作进行了优化，目前处于维护模式）
- Jackrabbit OAK（旨在高度可扩展的内容存储库，平衡 read/write 性能。它与 Jackrabbit 来自同一个核心团队）
- Jackrabbit FileVault（后端纯粹基于文件系统）
- Modeshape（替代实现，快速且可扩展，使用 REST API，相当不错的文档）
顺便说一句。 JCR API 和实现在很大程度上考虑了 RESTful 架构。因此，如果您考虑 REST API，映射也相当简单。此外，它允许消费者直接通过 JCR API 浏览内容，从而可以轻松地将内容集成到其他应用程序中（即只读），而您必须使用 JPA 来制定消费者合同来揭示数据库的内部设计更有可能因更改而中断。
关于您剩下的问题：
- 我没有比较图表，和往常一样，它取决于数据结构和索引以及您的查询设计。 JCR 实现具有内置缓存，您通常会迭代结果集。所以没有关于faster/slower的一般性陈述，这完全取决于用例。
- 我做过类似的事情，我们对 Jackrabbit 的实现很满意，但我们使用的是 JDK7。我们在存储库中拥有所有数据（包括用户设置、应用程序设置等），根本没有 JPA 持久性。如果您需要，还有一个 Object Content Mapping 可用。
- 不错，值得介绍。 Jackrabbit 有自己的用户管理可用——您不必自己实施。访问控制可通过 JCR API 和 JAAS 获得。尽管我建议不要使用 JCA ResourceAdapter 来管理用户管理和访问控制，因为它不会公开 Jackrabbit API。
- 关于数据完整性和备份的问题对 JCR 或 JPA 来说并不特殊，它们都在某种程度上确保完整性（数据库完整性，JCR 做参照完整性）并且都可以备份（db 备份，fs 备份）。两者都是访问数据的标准化方式，因此您甚至可以执行自己的备份逻辑。
在做了一些关于 JCR or RDBMS, and reading other posts 的研究之后，我仍然不确定是否将 JCR 而不是 JPA 用于文档管理系统，它必须处理不同的文档类型，非常大的文件 和 大量 来自许多用户的并发访问。
我考虑 JCR 的主要原因是因为文档对我来说看起来像 content，并且该规范已经处理了一些随之而来的问题——主要是我对存储和版本控制。此外，我想将文档内容封装在 JCR 实现中，并将 JPA 用于特定于应用程序的所有其他内容。
也许有人可以帮我解决剩下的问题：
- JCR 的 read/query 性能与 JPA 有什么关系（我知道它在实现上会有很大差异，但可能有一些经验法则）？
- 是否有人在具有某些特定 JCR 实现的类似用例中具有真实世界经验？如果是这样，您是否将其与关系数据库 (JPA) 混合使用？
- 考虑到文件存储和版本控制的好处，引入 JCR 是否值得？ （我可能会使用我自己的自定义使用访问控制 (JPA)，我不需要额外的灵活性来在运行时引入新的节点属性）
- 有人对数据完整性和备份解决方案有任何经验吗？
UPDATE：虽然这个问题已经得到了详细的回答，但从更实际的角度来看，有人可能会对它的使用有更挑剔的眼光。我个人越来越关注以下与技术无关的问题：
- 文档：Jackrabbit 的文档很差，它是 OCM contains a dead link in the first paragraph, some example search queries throw exceptions for unknown reasons, there is a TODO 的非常基本的教程指南，它的独立服务器在 JDK8 中无法正常工作，根本没有文档。
- 成熟度：Jackrabbit Oak 似乎仍在开发中，其他解决方案看起来要么被放弃要么处于前沿。
- 社区：与 JPA 相反，对 JCR 的研究导致更少 hits。当一个刚接触该技术的项目团队陷入（琐碎的）问题中时，这可能是一个真正的问题。
简短版本：文档是结构化或半结构化的内容。这就是分层组织的数据存储的用例。如果您不想自己实现所有基本的 dms/cms 东西，您应该选择 JCR（考虑一下，您可能是第一次这样做，而他们一直都在这样做）。
长版本：JCR 按规范涵盖了文档或内容管理系统的大部分基本用例，例如版本控制、锁定、生命周期管理或参照完整性。此外，它允许您在不更改模式的情况下扩展数据（当然您可以在模型中定义节点类型，但您不必这样做）。大多数 JCR 实现（如 Jackrabbit）在后端使用数据库，使它们 "little more" 而不是关系后端上的抽象层。处理大数据时，可以使用文件系统存储（这比将每个二进制数据都存储到数据库中要快得多），同时将结构化数据（节点和属性）存储在数据库中。
使用 JPA 时，您必须自己处理所有这些 dms/cms 问题。您当然可以这样做，但它已经在 JCR 实现中完成了更多的低级编程。每个模型更改都需要更改架构，并且 table 布局并不是那么微不足道（您想为文档设置一个大的 table，每个 属性 都是一列吗？想要为每个文档单独 table class？如何对生命周期建模，如何对版本控制建模？）
对于 JCR 的第一跳，我建议 David's Model，将应用程序的所有内容都视为内容。我曾在一个项目中工作过，我们决定不混合使用 JCR 和 JPA，这样我们就不必处理不同的 API 存储。
并且至少有一些 JCR 实现
- Jackrabbit 2（参考实现，针对读取操作进行了优化，目前处于维护模式）
- Jackrabbit OAK（旨在高度可扩展的内容存储库，平衡 read/write 性能。它与 Jackrabbit 来自同一个核心团队）
- Jackrabbit FileVault（后端纯粹基于文件系统）
- Modeshape（替代实现，快速且可扩展，使用 REST API，相当不错的文档）
顺便说一句。 JCR API 和实现在很大程度上考虑了 RESTful 架构。因此，如果您考虑 REST API，映射也相当简单。此外，它允许消费者直接通过 JCR API 浏览内容，从而可以轻松地将内容集成到其他应用程序中（即只读），而您必须使用 JPA 来制定消费者合同来揭示数据库的内部设计更有可能因更改而中断。
关于您剩下的问题：
- 我没有比较图表，和往常一样，它取决于数据结构和索引以及您的查询设计。 JCR 实现具有内置缓存，您通常会迭代结果集。所以没有关于faster/slower的一般性陈述，这完全取决于用例。
- 我做过类似的事情，我们对 Jackrabbit 的实现很满意，但我们使用的是 JDK7。我们在存储库中拥有所有数据（包括用户设置、应用程序设置等），根本没有 JPA 持久性。如果您需要，还有一个 Object Content Mapping 可用。
- 不错，值得介绍。 Jackrabbit 有自己的用户管理可用——您不必自己实施。访问控制可通过 JCR API 和 JAAS 获得。尽管我建议不要使用 JCA ResourceAdapter 来管理用户管理和访问控制，因为它不会公开 Jackrabbit API。
- 关于数据完整性和备份的问题对 JCR 或 JPA 来说并不特殊，它们都在某种程度上确保完整性（数据库完整性，JCR 做参照完整性）并且都可以备份（db 备份，fs 备份）。两者都是访问数据的标准化方式，因此您甚至可以执行自己的备份逻辑。