Comments 16
Не понял аналогию Hibernate vs. MyBatis -> BMW vs. Mercedes. Что вы имеете ввиду?
получим следующее время отклика:
Эка вы как классно профилируете запросы! Я так тоже умею — можно несколько раз позапускать запрос в SQL Developer и он закешируется в самой оракл и никакой MyBatis 2 Level Cache не нужен :)
Если серьезно, MyBatis кеш конечно помогает и выручает, но профит посчитан неверно.
Спасибо за замечания, следующий раз будем постараться улучшить статью
В принципе можно было бы поставить логирование времени на входе выполнения в MyBatis и на выходе с учетом кеша.
Вход понятен где — это вызов метода маппера.
В методе по выборке из кеша это второе время.
После вызова маппера это третье время.
Работу самого MyBatis'a в данном случае можно пренебречь. Уже тремя этими параметрами можно как то манипулировать и делать выводы.
Кстати, у Вас все виртуальные машины расположены локально? Если да, то имеет смысл их разнести на разные машины в рамках локальной сети, это будет еще ближе к "боевым" измерениям (потери на сетевом транспорте).
Вход понятен где — это вызов метода маппера.
В методе по выборке из кеша это второе время.
После вызова маппера это третье время.
Работу самого 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», более подробнее можно узнать здесь
Прирост производительности = Время отклика без кэширования/Время отклика с кэшированием = 1589/6 что приблизительно в 265 раз быстрее или прирост производительности = ((Время отклика без кэширования- Время отклика с кэшированием)/ Время отклика с кэшированием * 100) приблизительно на 26 383% быстрее.
Выглядит круто, но статья про L2 кэш, а вычисления для случая, когда L1 также пуст. В реальности же увеличение производительности не будет больше, чем число нод. А если еще и sticky-session использовать, то того меньше.
L1 cache Mybatis всегда включен по умолчанию. L1 cache кэширует данные в течение одной SQL сессии, поэтому эффект от L1 cache не очень велико.
https://gyazo.com/768e87434ac49e371e6c324c393840bd
https://gyazo.com/768e87434ac49e371e6c324c393840bd
Sign up to leave a comment.
Настройка и использование Apache Ignite в качестве MyBatis кэш второго уровня (L2 cache)