我希望建立一个网站/应用程序。类模型大约有100个对象，并不是特别复杂。
需要构建网站以处理大约30 000个并发用户，但它应该能够处理更多用户。
我想使用现成的持久性框架，而不是编写自己的jdbc来访问数据库。
我别无选择，只能使用关系数据库。
我希望它具有某种形式的缓存，并且还希望能够自定义sql，因为这通常是性能调整所必需的。
我应该使用什么持久性框架的任何建议？
更新：谢谢大家。在这种情况下，我认为手动编写sql代码的能力胜过。如果您有权访问它，可以进行一些并发调整。虽然我同意，你也可以在hibernate / jpa中访问它，但它不是规则的例外。 myBatis也是一种更轻量级，更少“神奇”的持久性框架。此外，出于性能和扩展的原因，我不认为使用太多的外键来处理集合由持久性框架管理是明智的，所以我可能不会在hibernate中使用该功能。这将允许我在必要时对数据库进行分片。我也认为myBatis可能是一个更容易实现的持久性框架。 AFAIK，例如它没有透明的持久性。你的答案已经证实，没有另一个更符合这些要求的持久性框架。
答案 0 :(得分：3)
如果手动优化的SQL是您想要的，那么我建议myBatis（以前称为iBatis）。它使用您提供的手写SQL为您处理JDBC机制以及对象列映射。
不会为你做的是对象关系映射（即关联和集合的自动处理）。如果这对您来说更重要，那么像EclipseLink或Hibernate这样的JPA实现是显而易见的选择。这些也可以处理自定义SQL，但它比myBatis更加繁琐。
两者都应该能够毫无问题地处理您的负载需求 - 问题是您的数据库可以处理它。
答案 1 :(得分：2)
担心您的基础架构，避免设计瓶颈，而不是框架。
如果您想处理大量并发用户，那么设计可以使用硬件进行扩展。不要过分担心在应用程序中缓存数据，只要你在那里留下足够的内存，大多数体面的数据库都会为你做好工作。
答案 2 :(得分：2)
我的决定可能有点迟，但我认为这可能是未来考虑的选择。我同意Qwerky的观点，即数据抽象层（即ORM或其他框架）的缓存被高估了。大多数现代RDBMS都有自己的内部缓存，因此通常性能调优更像是DBA工作，而不是开发人员。此外，配置不当的缓存很快就会变成性能噩梦。
我创建了jOOQ作为数据库抽象框架，它试图与SQL本身保持非常接近，除了从流畅的API构建的面向对象的类型安全查询之外，不需要在JDBC之上添加更多抽象。 jOOQ不会隐藏Java代码中的任何关系事实，因此您可以完全控制所使用的SQL。
答案 3 :(得分：0)
答案 4 :(得分：0)
如果不需要rdbms的持久性，Collections类模型上的专用高速，高可靠性和高并发持久性存储怎么办？ Oracle（sleepycat）Berkeley数据库非常接近，但很遗憾地遇到了高并发性的显示锁定问题。
答案 5 :(得分：0)
如果您阅读此Hibernate tutorial（超过140篇文章），您会发现Hibernate可用作高性能数据访问库，原因如下，{{{ 3}}：