Добрый день!
Помогите пожалуйста решить такую задачу:

Есть отностилельно длительная операция чтения из БД. Читаются "все данные" за определенный промежуток времени (последние 3 месяца, последние полгода, прошлый год и т.п.).
Чтобы ускорить это узкое место (запись происходит очень редко - почти всегда чтение) я решил написать некий аналог кэша - это лист с полученными записями и две "даты" (с ... по ...), указывающие какие значения в нашем листе уже есть. Соответственно при получении запроса данные выбираются из имеющегося листа или если диапазон шире в него данные "довыбираются" из базы и опять же это хозяйство возвращается.
И тут внезапно я открыл для себя что спринг как всегда про все уже "подумал" и все уже написано, т.е. прочел про @Cacheable. Попробовал с небольшой entity - остался очень доволен результатом.
Однако @Cacheable вытягивает данные из кэша если запрос "повторяется", что совсем не то что мне нужно. Нужно чтобы если в кэше есть данные за последний месяц а зпрос пришел "за последние 2 месяца", то он "возвращал" имеющийся у него месяц и довыбирал данные за еще один (и оставлял "у себя" данные уже за 2 месяца). Решения такой задачи не нашел, но учитывая что я в Spring новичек думаю может и оно таки есть? Подскажите пожалуйста, люди добрые.

Blazkowicz,

Спасибо! Вы мне не первый раз отвечаете, причем молниеносно:)
Теперь знаю куда копать - буду разбираться. Спасибо еще раз.

BlazkowiczПаша01Вы действительно так быстро ответили. Как это у вас получилось? Вы быстро нагуглили или работали с этим?
Ну, по опыту, такие абстракции должны были существовать. Хорошие фреймверки позволяют написать свою реализацию на любом уровне.
Поэтому я открыл мануал на нужном разделе
http://docs.spring.io/spring/docs/current/spring-framework-reference/html/cache.html
и быстро просмотрел, что такое возможно в принципе, а так же полистал классы в IDE.

Да опыт сила - никто наверное всего не знает и нужно погуглить/посмотреть время от времени, вот только человек с опытом знает куда смотреть и решение найдет сразу, а когда ты "вообще не в курсе" будешь копошиться целый день:(

Atum1Интересно было бы увидеть такую реализацию кеша .

Примерно так...






Тут далее выбираем данные из существующего кэша к примеру (ну надо знать в кэше с каким ключом они есть) и "довыбираем" уже некэшированными запросами из базы и т.п. Вариантов много и это уже дело техники - я реализовал и оно работает, но мне не очень нравится так что я это место не привожу буду переделывать немного иначе. Важно что в итоге мы "формируем" новый кэш и возвращаем его - таким образом запрос к базе получается "видит" что в кэше это уже есть и берет это а в базу не лезет. Профит в том что мы когда формировали "ответ" кэша или в базу вообще не лезли ("фильтровали" то что есть) или довыбирали данные частично, что много быстрее в моем случае. Плюшки от такой реализации а не решения "в лоб" с локальными переменнами - возможности конфигурирования размера, время жизни кэша и т.п.
Я конечно не профи может где не оптимально, но во всяком случае по скорости запросов (скажем было за последний год а я выбираю все - данные последнего года уже из базы не тянутся) прирост чувствуется. Как-то так..

Atum1А почему вы не стали рассматривать решение на уровне БД ?
Хранить Временную талицу/ View - «материализованных представлений»

Согласен подход хороший. Конкретно в моем случае проблема в "узкости" скороcти базы, отчего я о решениях на уровне БД если честно даже и не думал...

Atum1У вас задача сводится чисто к игре с датами - вам каждый раз нужно решать какой объем хранить в памяти - а что если выборка будет
за период смещенный на одни день влево /право - от дат вашего кеша? итд ... много сложных условий на перекрытие итд ....

Тут не совсем согласен. Игра с датами - да. Однико при "смещении" вопрос решается довыборкой только за период смещения, что сравнительно быстро (во всяком случае у меня "прирост" скорости раза в два хотя все от "перодов" конечно зависит). Все "остальная" часть это тупой перебор коллекции, вытаскиваемой из кэша, что осушествляется практически мгновенно. При выборке более "узких" перодов многотысячные строки "выскакивают" в течение секунды. В целом я доволен.

Решения конечно могут быть разные я не претендую на однозначный "бэст практик", но в целом доволен. Не берусь судить было ли бы быстрее через уровень БД - не уверен. Проще - да согласен.

Atum1может просто построить индексы? оптимизировать запросы ?

С этого все начиналось. Первое сделано. Второе в "меру моих способностей" тоже.

Atum1RuslanGab,
И так ваше решение :
Я правильно понял что у вас ключ в вашем кеше это дата_начала_идата_окончания диапазона ?!
и если вы попали во внутрь то вам повезло вы вытащили под коллекцию из кеша ...
Если вы не попали - и нет пересечений - у вас будет в кеше две коллекции
дата_начала_идата_окончания диапазона1
дата_начала_идата_окончания диапазона2

Да все так.

Atum1если у вас есть пересечение слева/справа с одним из диапазонов Вы делаете под выборку в базу и расширяете границы диапазона ?
сохраняя новый кеш
дата_начала_идата_окончания диапазона_новый границы.

По сути дела почти так, но это как раз место которое мне не понравилось решительно, так что я доизвратился и ввел "пустой" кэш с ключом "маркер" (грубо говоря), а также локальный лист с моими сушностями. При запросах если кэш "маркер" не существует (прошло "время жизни", вытеснено) лист чистится. Этот лист "набивается" запросами (по логике там "пересечения" невозмижны, потому что "запрос" выполняется только когда кэша "маркер" нет и лист чистится, а в остальных случаях идут "подзапросы". Дальше идет перебор и выборка из этого листа. Единственное - в самих кэшированных данных уже образуются дубликаты, но их не должно быть много по логике работы приложения да и настройки EhCache позволяют общий объем сконфигурировать. Зато при повторных запросах имеющиеся в кэше данные соответственно вылетают сращу уже вообще без проверок и всего прочего.

Atum1какой объем данных и сложность запросов на отчет ?
отчет не динамический ? ( данные это уже история и они не меняются ? так? - это Архив?)
тогда , как вариант вы можете заранее создать in memory data grids - и поместить в него все ваши отчеты постранично
... по месяцам, годам , дням ... (вопрос в доступном количестве памяти на сервере итд)
но это будет предпочтительнее что свой кеш на основе дат ?!

Объем не очень большой. 20-30 тыс. При этом имеется много связанных по внешним ключам таблиц (9 если не ошибаюсь), данные из которых тоже надо "вытягивать" (а две из них и дальше связаны, причем отношениями один ко многим, и тоже надо "тянуть"). Так что в итоге производительность этого места оставляет желать лучшего. C View я если честно ускорения не смог увидеть - где был запрос 10 секунд там оно так и осталось (может если бы речь шла о минутах оно и было бы заметно).
Данные это уже история, и тем не менее они могут меняться (редактируемые). Однако это происходит очень редко и единично, так что в первом приближении можно их считать архивом.
Про memory data grids простите мне мою неопытность никогда не слышал - сейчас вот открыл статью на Хабре - интересно. Возможно это именно то что нужно - поизучаю пожалуй. Спасибо.

А чем все же мое решение настолько плохо? Работает. Быстро. Я только за чтобы сделать лучше, но такой шквал критики:(

Боже мой, слава богу хоть здесь меня чему-то поучат! Это не сарказм. Обидно даже - на работе и спросить не у кого лишь бы работало а как и что... Сижу и тупею по ходу дела... Ладно это все лирика. За советы всем искренее спасибо. Буду изучать!