Вопрос по – Масштабирование и кластеризация JPA

9

Я собираю обычное приложение Java EE на jboss7, которое будет использовать JPA на уровне данных. Я хотел бы сделать это приложение таким, чтобы оно масштабировалось с нагрузкой. Хотя совершенно очевидно, как масштабировать веб-уровень: создавать больше машин и отбрасывать их за балансировщиком нагрузки, масштабирование уровня данных происходит меньше.

Я, вероятно, могу кластеризовать свою базу данных (MySQL). Стил, который оставляет слой JPA некластеризованным. В идеале JPA будет расширяться за счет использования (кластеризованного) кэширования памяти при поддержке MySQL.

Когда я смотрю вокруг, вся информация о масштабировании JPA кажется 3-4 годами. Люди говорят об ehcache, memcached и бесконечности. Я не уверен, что это все еще актуально.

Может кто-нибудь сказать мне состояние дел в кластеризации и масштабирования Java EE, особенно на уровне данных.

Я получил удивительные ответы от Петра и Джеймса. К сожалению, SOF позволит мне отметить только один правильный ответ. Спасибо обоим. Далее мне нужно выяснить, что является лучшим в кешировании: зачем мне использовать что-то кроме memcached. Raj

Ваш Ответ

2   ответа
6

Различные стратегии кэширования по-прежнему являются способом масштабирования JPA / Hibernate (вы в основном назвали самые популярные варианты в своем вопросе). Насколько я знаю, ничего необычного не произошло с 4-5 лет в этой области. Еще один вариант, который вы не упомянули, - это JBoss Cache. Таким образом, кэш второго уровня для JPA / Hibernate по-прежнему правит в этой области.

Почему нет прогресса здесь? Мое предположение состоит в том, что в первую очередь люди, которым нужны масштабируемые приложения, обычно игнорируют JPA и Hibernate в областях, где требуется высокая производительность. Обычно люди идут с SQL, одетым в помощники Spring Framework JDBCTemplate и управление транзакциями. Тогда масштабируемость - это вопрос возможностей базы данных в этой области.

Другая тенденция заключается в использовании баз данных No-SQL. Существует множество решений: MongoDB, CouchoDB, Cassandra, Redis и многие другие. Обычно это Google BigTable, подобные хранилищам значений ключей (это упрощение, но это более или менее идея, лежащая в основе такого подхода), и они масштабируются как ад, если вы принимаете их ограничения (отношения более не легко управляются и т. Д.).

Error: User Rate Limit Exceeded
Error: User Rate Limit Exceeded Raj
Error: User Rate Limit Exceeded Raj
static.springsource.org/spring/docs/3.1.x/…Error: User Rate Limit Exceeded
6

Есть много решений, две основные категории решений:

  • scaling the database
  • using a clustered cache to reduce database load

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

Error: User Rate Limit Exceeded Raj

Похожие вопросы