可扩展，低开销，高性能的Java持久性框架

Posted 2021-03-28

我期待建立一个网站/应用程序。类模型大约有100个对象，并不是特别复杂。

需要构建网站以处理大约30 000个并发用户，但它应该能够处理更多。

我想使用现成的持久性框架，而不是编写我自己的jdbc来访问数据库。

我别无选择，只能使用关系数据库。

我希望它有一些形式的缓存，并且还希望能够自定义sql，因为这通常是性能调优所必需的。

我应该使用什么持久性框架的任何建议？

更新：谢谢大家。在这种情况下，我认为手动编写sql代码的能力胜过。如果您有权访问它，可以进行一些并发调整。虽然我同意，你也可以在hibernate / jpa中访问它，但它不是规则的例外。 myBatis也是一种更轻量级，更少“神奇”的持久性框架。此外，出于性能和扩展的原因，我不认为使用太多的外键来处理集合由持久性框架管理是明智的，所以我可能不会在hibernate中使用该功能。这将允许我在必要时对数据库进行分片。我也认为myBatis可能是一个更容易实现的持久性框架。 AFAIK，例如它没有透明的持久性。您的答案已经确认没有另一个更符合这些要求的持久性框架。

答案

如果手动优化的SQL是你想要的东西，那么我建议使用myBatis（以前称为iBatis）。它使用您提供的手写SQL为您处理JDBC机制以及对象列映射。

它不会为你做的是对象关系映射（即关联和集合的自动处理）。如果这对您来说更重要，那么像EclipseLink或Hibernate这样的JPA实现是显而易见的选择。这些也可以处理自定义SQL，但它比myBatis更加繁琐。

两者都应该能够毫无问题地处理您的负载需求 - 问题是您的数据库可以处理它。

另一答案

担心您的基础架构并避免设计瓶颈，而不是框架。

如果您想处理大量并发用户，那么设计可以使用硬件进行扩展。不要过分担心在应用程序中缓存数据，大多数像样的数据库都能为你做好工作，只要你在那里留下足够的内存。

另一答案

我的决定可能有点迟，但我认为这可能是未来考虑的选择。我同意Qwerky的观点，即数据抽象层（即ORM或其他框架）的缓存被高估了。大多数现代RDBMS都有自己的内部缓存，因此通常性能调优更像是DBA工作，而不是开发人员。此外，配置不当的缓存很快就变成了性能噩梦。

我创建了jOOQ作为一个数据库抽象框架，它试图保持与SQL本身非常接近，除了从流畅的API构建的面向对象的类型安全查询之外，不需要在JDBC之上放置更多抽象。 jOOQ不会隐藏Java代码中的任何关系事实，因此您可以完全控制所使用的SQL。

http://www.jooq.org

另一答案

第一个也是显而易见的选择是JPA，或Hibernate，它来自它。

另一答案

那些不需要rdbms的持久性，Collections类模型上的专用高速，高可靠性和高并发持久性存储呢？甲骨文（sleepycat）Berkeley DB非常接近，但遗憾的是它遇到了高并发性的显示阻塞问题。

另一答案

如果您阅读此Hibernate tutorial（超过140篇文章），您会发现Hibernate可以用作高性能数据访问库，原因如下，this sample chapter of High-Performance Java Persistence中也对此进行了解释：

• 扩展标识符生成器（hi / lo，pooled，pooled-lo）
• 透明的预备语句批处理
• 实体级缓存高度一致的并发策略
• 无版本乐观锁定（例如，OptimisticLockType.ALL，OptimisticLockType.DIRTY）
• 支持多租户