缩放和集群 JPA答案

【问题标题】：Scaling and Clustering JPA缩放和集群 JPA
【发布时间】：2012-05-06 21:36:11
【问题描述】：

我正在 jboss7 上组装一个常规的 Java EE 应用程序，它将在数据层中使用 JPA。我想让这个应用程序随着负载的增加而扩展。虽然很清楚如何扩展 Web 层：创建更多机器并将它们放在负载均衡器后面，但扩展数据层的情况就不那么简单了。

我可能可以集群我的数据库（MySQL）。仍然，这使 JPA 层不聚集。理想情况下，JPA 将通过使用由 MySQL 支持的（集群）内存缓存来扩展。

当我环顾四周时，所有关于 JPA 缩放的信息似乎都是 3-4 年的历史。人们谈论 ehcache、memcached 和 infinispan。我不确定这是否仍然是最新的。

谁能告诉我 Java EE 集群和扩展的最新技术，尤其是在数据层。

【问题讨论】：

我从 Piotr 和 James 那里得到了惊人的答案。不幸的是，SOF 只会让我将一个标记为正确答案。感谢双方。接下来，我需要找出缓存中最好的品种：为什么我会使用除了 memcached 之外的任何东西。

标签： caching jakarta-ee jpa memcached ehcache

【解决方案1】：

各种缓存策略仍然是扩展 JPA/Hibernate 的方式（您基本上命名了您的问题中最流行的选项）。据我所知，在这个领域 4 到 5 年以来没有发生什么特别的事情。您还没有提到的另一个选项是 JBoss Cache。所以 JPA/Hibernate 的二级缓存仍然在这方面占主导地位。

为什么这里没有进展？我的疯狂猜测是，首先，需要可扩展应用程序的人往往会在需要高性能的领域忽略 JPA 和 Hibernate。通常人们使用穿着 Spring Framework JDBCTemplate 助手和事务管理的 SQL。那么可扩展性就是这个领域的数据库能力问题。

另一个趋势是使用 No-SQL 数据库。有很多解决方案：MongoDB、CouchoDB、Cassandra、Redis 等等。这些通常是 Google BigTable 之类的键值存储（这过于简单化，但或多或少是该方法背后的想法），如果您接受它们的限制（关系不再容易管理等），它们的扩展性就如地狱一般。

【讨论】：

您好 Piotr，感谢您的回复。我有兴趣了解有关 JDBC 模板助手的更多信息。有什么好的指点吗？
static.springsource.org/spring/docs/3.1.x/… 是一本好书。还有书，《Spring in Action》还可以
承担性能问题的人极不可能完全忽略或避免 JPA - 这没有多大意义，因为 JPA 本身对性能几乎没有影响......它可以很容易地与任何优化良好的 SQL 语句......神奇之处在于 JPA 的标准/标准 API，一个糟糕的标准会很慢，但也会有一个糟糕的 SQL 语句，事实上，使用 JPQL 可以将 JPA 开销降低到“几乎不存在” ...但那是另一个故事。每个自动忽略/避免 JPA 的人都没有做好自己的工作。对不起。

【解决方案2】：

解决方案有很多，解决方案主要分为两大类：

扩展数据库
使用集群缓存减少数据库负载

EclipseLink 支持数据分区，以便跨一组数据库实例分片数据，

见： http://java-persistence-performance.blogspot.com/2011/05/data-partitioning-scaling-database.html

你也可以使用 MySQL Cluster，

见： http://www.mysql.com/products/cluster/

Oracle TopLink Grid 提供 EclipseLink JPA 支持，以作为分布式缓存与 Oracle Coherence 集成，

见： http://www.oracle.com/technetwork/middleware/ias/tl-grid-097210.html

EclipseLink 的缓存通过缓存协调支持集群，

见： http://wiki.eclipse.org/EclipseLink/Examples/JPA/CacheCoordination

【讨论】：

嗨，詹姆斯，感谢您的回复。我们希望同时进行扩展并避免任何单点故障。在我所有的调查中，memcached 似乎是“同类中最好的”：它得到了广泛的支持，并且似乎能够做任何其他缓存会做的事情。你怎么看？