кэширование данных только для чтения для Java-приложения

Question

У меня есть база данных, которая содержит около 150 тыс. Записей данных с первичным ключом в таблице. Размер данных для каждой записи займет менее 1 КБ. Время обработки для создания POJO из записи БД занимает около 1-2 секунд (есть некоторая бизнес-логика, которая занимает слишком много времени). Это данные только для чтения. Поэтому я планирую реализовать кэширование данных. То, что я думаю сделать, это. Загрузите данные в подмножества (200 записей каждый раз) и создайте поток, который будет создавать POJO и хранить их в хеш-таблице. Во время загрузки кэша (когда я запускаю приложение) пользователь увидит знак ожидания. Поскольку хранение данных в HashTable является проблемой, я на самом деле сохраню обработанные данные в другой таблице БД (перенаправив POJO в xml). Я использую сторонний API для загрузки данных из базы данных. После того, как я загружу запись, мне нужно будет загрузить данные. Мне нужно будет загрузить ассоциации для загруженных данных, а затем ассоциации для ассоциации, найденной на верхнем уровне. Это похоже на загрузку генеалогического древа.

1. Я не могу использовать Hibernate или любую среду ORM, так как я использую сторонний API для загрузки данных, которые поставляются вместе с базой данных (это продукт). Более того, я не думаю, что загрузка данных один раз не является большой проблемой.
2. Если бы была возможность настроить бизнес-логику, я бы не задавал этот вопрос здесь.

Кэширование данных по требованию - вариант, но я пытаюсь выяснить, могу ли я сделать что-нибудь лучше.

Предложите мне, если есть лучшая идея, о которой вы знаете. Спасибо ./

Answer 1

Подскажите, если есть лучшая идея, о которой вы знаете.

Да, исправьте бизнес-логику, чтобы она не занимала 1-2 секунды на запись.Это смехотворно много времени.

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

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

Answer 2

Звучит так, будто вы заново изобретаете колесо.Я хотел бы использовать спящий режим.Помимо упрощения кода для доступа к базе данных, hibernate имеет встроенное кэширование и отложенную загрузку данных, поэтому он создает объекты только по запросу.Итак, многое из того, что вы описали выше, уже на месте, и вы можете сосредоточиться на выяснении своей бизнес-логики.Я подозреваю, что, как только вы решите проблему с производительностью бизнес-логики, в этом не будет необходимости, поскольку сложная система кэширования будет достаточной по умолчанию.

Answer 3

Как сказал Максим в комментарии, предварительная загрузка всего этого займет много времени.Если ваша система не очень странная, пользователю не понадобятся все данные сразу.Вместо этого просто кэшируйте по требованию.Я также рекомендовал бы использовать установленное решение для кэширования, такое как EHCache , которое сохраняется через DiskStore - единственная проблема заключается в том, что все, что вы кэшируете в этом случае, должно быть Serializable.Поскольку вы можете маршалировать его как XML, могу поспорить, что вы также можете его сериализовать, что должно быть быстрее.

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

Answer 4

jdbm имеет хорошую постоянную реализацию карты (http://code.google.com/p/jdbm2/) - которая может помочь вам в локальном кэшировании - это, безусловно, будет намного быстрее, чем сериализация ваших POJO в XML и запись их обратно в базу данных SQL.

Если ваши данные действительно доступны только для чтения, то я думаю, что лучшим решением будет обработка исходной базы данных как входной очереди, которая питает базу данных вашего приложения. Создайте фоновый процесс (черт, сервислучше), и пусть он контролирует исходную базу данных и синхронизирует базу данных вашего приложения.