переводить спящий режим на noSQL?

Question

Передо мной стоит задача сделать наш программный стек масштабируемым.В настоящее время он не масштабируется, потому что все сосредоточено в огромной центральной базе данных Oracle.Все обращаются к нему, поэтому он всегда очень занят, более того, из-за опасений потери данных файл базы данных напрямую записывается в netapp, поэтому доступ к диску медленный.

Мы успешно работали с решениями noSQLс другими задачами, поэтому мы их рассматриваем.Но одна проблема заключается в том, что текущий код в значительной степени опирается на Hibernate из-за его простоты, поскольку вы можете легко обходить граф бизнес-объектов, не беспокоясь о загрузке ссылочных объектов.

Для noSQL в настоящее время нет такого доступного драйвера Hibernate;ДАЖЕ, если бы было, проблема с noSQL заключается в том, что ни один из них не поддерживает JOIN, так что эффективная JOIN FETCH невозможна, и вам пришлось бы потратить несколько поездок в магазин, чтобы получить связанные объекты.В результате я склонен думать, что noSQL хорош только для проектов с независимыми объектами, а не для сложных графов объектов.

Есть идеи?

Answer 1

Еще одна новая вещь, которую стоит попробовать - это playOrm, в котором есть JQL / HQL, НО с некоторыми изменениями, чтобы сделать его совместимым с noSql (т. Е. Вам нужно разбить 1 триллион таблиц строк, чтобы вы могли объединить 1 раздел с чем-то еще).Он выполняет все функции ManyToOne, OneToMany и т. Д. И т. Д.

Существуют и другие отличия, такие как метод findAll, типичный для noSql для захвата 100 строк за один раз, как это делается параллельно многим серверам.

Примером масштабируемого JQL-запроса может быть (обратите внимание на идентификатор раздела, так как вы могли бы разделить свои сделки, возможно, по счету или чему-то значимому для вашего домена).

@ NoSqlQuery (name = "findJoinOnNullPartition", query = "PARTITIONS t (: partId) выберите t FROM TABLE в качестве t INNER JOIN t.security как s где s.securityType =: type и t.numShares =: shares")

Answer 2

Я бы порекомендовал попробовать Infinispan в качестве распределенного кэша второго уровня. Это позволит вам кластеризовать серверы приложений и по-прежнему кэшировать данные в приложении с интенсивным чтением.

Это руководство очень полезно для шагов, чтобы начать с этим. Вам также необходимо убедиться, что вы используете управление транзакциями JTA.