Гарантированные попадания в кеш при получении данных

Question

Постановка проблемы

1. Объекты прибывают для обработки и проходят через ряд шагов, которые работают с этими объектами и, возможно, с другими, связанными объектами и генерируют некоторые результаты;
2. Некоторые объекты должны обрабатываться в режиме реального времени без доступа к базе данных;
3. В настоящее время реализация просто просматривает сущности в базе данных без кэширования.

Время оптимизации: -)

Возможные подходы

Простой кеш

Простой кэш в памяти имеет 2 недостатка:

1. может переполниться, поскольку речь идет о большом количестве объектов;
2. это не гарантирует, что требуемые сущности найдены в кеше, и у него нет никакого способа узнать о доступности или попросить «предварительно загрузить» себя.

Так что это не пойдет.

Анализ сущностей + предварительная загрузка

Я рассматриваю возможность создания своего рода анализатора, чтобы выяснить, какие данные необходимо извлечь для данного объекта, даже в больших формах, и выполнить запрос к кешам для загрузки необходимых данных вне диапазона.

Шаги будут:

1. Сущность прибывает. Если требуется обработка в памяти, отправьте запрос загрузки кэша;
2. Объект помещается в очередь ожидания кэша, пока не будет получен ответ загруженного кэша. Это может быть немедленным, если данные доступны;
3. Объект отправляется на обработку и использует загруженные данные;
4. Кэши очищены. У этого есть потенциал для очистки политики, но я не беспокоюсь о тех в настоящее время.

Вопросы

Что вы думаете об этом подходе? Я скучаю по некоторым известным шаблонам доступа к данным, которые могут быть применены в этом случае?

---

Обновление 1 : забыл упомянуть, что вся обработка однопоточная, и это значительно ограничивает возможности.

Answer 1

Вы сказали:

Простой кэш в памяти имеет 2 недостатка:

1. может переполниться, так как речь идет о большом количестве объектов
2. это не гарантирует, что требуемые сущности найдены в кеше, и не может быть запрошено о доступности или предложено "предварительно загрузить" себя.

Возможно, я полностью неправильно понимаю ваш вопрос и потребности, но это звучит неправильно на нескольких уровнях:

1. Многие решения для кэширования позволяют вам определить максимальное количество элементов, которое вы можете сохранить в кэше. После достижения максимального размера элементы могут быть удалены по принципу «первым пришел - первым обслужен» или на основе наименее недавно использованного.
2. Кеш не должен "гарантировать, что требуемые сущности найдены в кеше"; это не цель кэша.
3. API для большинства решений для кэширования позволяет вам проверить, присутствует ли ключ в кэше (фактически, если вы создали собственное решение с использованием Map, вы все равно могли бы сделать это ...).
4. Ehcache имеет самонаселенных кешей , которые можно использовать для предварительного заполнения кеша перед тем, как начинать извлекать элементы ( другая ссылка здесь ).

Answer 2

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

В качестве альтернативы проверьте, можете ли вы оптимизировать базу данных. Очень возможно, чтобы база данных отвечала на запросы в течение

В качестве другой альтернативы рассмотрите следующее: общий объем работы не уменьшается при предварительной выборке данных. Сущность должна ждать предварительной выборки, вне зависимости от того, находится она в очереди или нет. Так как работа должна быть выполнена в любом случае, вы могли бы также сделать это в рабочем процессе очереди? Подумайте об увеличении количества рабочих процессов, чтобы вы могли обрабатывать больше очередей одновременно.

РЕДАКТИРОВАТЬ: Как ваш комментарий говорит, что вы связаны с одним рабочим потоком:

• Может быть, разделить обработку на два этапа? Первый процесс извлекает данные базы данных и сохраняет обогащенную сущность в новой очереди. Второй процесс читает из новой очереди и выполняет работу с другими источниками данных в памяти
• Защита других объектов в памяти глобальным мьютексом. Это означает, что многие рабочие потоки могут общаться с базой данных, в то время как только один может обращаться к другим объектам в памяти.