Comments 16
Не понял аналогию Hibernate vs. MyBatis -> BMW vs. Mercedes. Что вы имеете ввиду?
у Оба framework Hibernate и MyBatis есть свой достойнства и недостатки. Выбор очень сильно зависит от системного требования проекта. Очень хотел избежать от дебаты типа "Hibernate лучшее чем MyBatis" или "MyBatis лучшее Hibernate".
получим следующее время отклика:

Эка вы как классно профилируете запросы! Я так тоже умею — можно несколько раз позапускать запрос в SQL Developer и он закешируется в самой оракл и никакой MyBatis 2 Level Cache не нужен :)
Если серьезно, MyBatis кеш конечно помогает и выручает, но профит посчитан неверно.
Спасибо за замечания, следующий раз будем постараться улучшить статью
В принципе можно было бы поставить логирование времени на входе выполнения в MyBatis и на выходе с учетом кеша.
Вход понятен где — это вызов метода маппера.
В методе по выборке из кеша это второе время.
После вызова маппера это третье время.
Работу самого MyBatis'a в данном случае можно пренебречь. Уже тремя этими параметрами можно как то манипулировать и делать выводы.
Кстати, у Вас все виртуальные машины расположены локально? Если да, то имеет смысл их разнести на разные машины в рамках локальной сети, это будет еще ближе к "боевым" измерениям (потери на сетевом транспорте).
а также нам было интересно использовать его как единую платформу для spark и Hadoop.

Вопрос немного не по теме. Вы alluxio не пробовали для этих целей?
А как происходит инвалидация кэша? что если по ключу "SELECT * FROM all_objects t where t.OBJECT_TYPE='TABLE' and t.object_name=?" в базе есть новые данные?
Существуют несколько способ:
  • В настройках кэш apache ignite: политика Expire — по подробнее можно читать здесь
  • На уровне MyBatis mapper: В операциях CRUD в XML можно указать flushCache=«true»
  • А если в таблице изменился данные мимо DAO, то есть кто не будут или 3ая система изменил данные в БД прямую: В этом случае необходимо сбросит или обновить кэш ignite, для реализации таких случае у Oracle есть возможности так называемое «Oracle database change notification», более подробнее можно узнать здесь
или 3ая система изменил данные в БД прямую

Кто такая эта "Зая"? Я бы не советовал пускать Зай и Мась в продакшн :)
Прирост производительности = Время отклика без кэширования/Время отклика с кэшированием = 1589/6 что приблизительно в 265 раз быстрее или прирост производительности = ((Время отклика без кэширования- Время отклика с кэшированием)/ Время отклика с кэшированием * 100) приблизительно на 26 383% быстрее.

Выглядит круто, но статья про L2 кэш, а вычисления для случая, когда L1 также пуст. В реальности же увеличение производительности не будет больше, чем число нод. А если еще и sticky-session использовать, то того меньше.
Only those users with full accounts are able to leave comments. Log in, please.
Information
Founded

21 September 2001

Location

Россия

Employees

1,001–5,000 employees

Registered

23 April 2015