Методы для запросов ряда объекта, в оперативной памяти в JAVA-приложении
У нас есть система, которая выполняет 'крупный поиск' путем вызова интерфейса на другую систему, которая возвращает ряд объектов Java. После того как мы получили результаты поиска, я должен смочь далее отфильтровать получающиеся объекты Java на основе определенных критериев, описывающих состояние атрибутов (например, от начальных объектов возвращают все объекты где x.y> z && a.b == c).
Критерии, используемые для фильтрации набора объектов, каждый раз является частично настраивающимся пользователем этим, я подразумеваю, что пользователи смогут выбрать значения и диапазоны для соответствия на, но атрибуты они могут выбрать от, будут фиксированным набором.
Наборы данных, вероятно, будут содержать <= 10 000 объектов для каждого поиска. Поиск будет выполняться вручную основой пользователя приложения, вероятно, не больше, чем 2000 раз в день (приблизительно). Вероятно, стоит упомянуть, что все объекты в наборе результатов являются известными классами объекта области, которые имеют, в спящем режиме и аннотации JPA, описывающие их структуру и отношения.
Возможные решения
Первое, что пришло на ум я могу думать о 3 способах сделать это:
- Поскольку каждый поиск сохраняет начальные объекты набора результатов в нашей базе данных, затем используйте, в спящем режиме, чтобы повторно запросить их использующий более прекрасные гранулярные критерии.
- Используйте Базу данных в оперативной памяти (такую как hsqldb?), чтобы запросить и совершенствовать начальный набор результатов.
- Запишите некоторый пользовательский код, который выполняет итерации начального набора результатов и вытаскивает желаемые записи.
Опция 1
Опция 1, кажется, включает много toing и froing через сеть к физической Базе данных (Oracle 10 г), который мог бы привести к большой сетевой активности и активности диска. Это также потребовало бы, чтобы результаты каждого поиска были изолированы от других наборов результатов, чтобы гарантировать, чтобы различные поиски не вмешивались друг в друга.
Опция 2
Опция 2 походит на хорошую идею в принципе, поскольку она позволила бы мне делать более прекрасный запрос в памяти и не потребует персистентности данных результата, которые были бы только отброшены после того, как поиск был завершен. Инстинктивное чувство состоит в том, что это могло быть довольно производительно также, но могло бы привести к большим издержкам памяти (который прекрасен, поскольку мы можем быть довольно гибкими на объеме памяти, который наша JVM получает).
Опция 3
Опция 3 могла быть очень производительной, но является чем-то, чего я хотел бы избежать как любой код, который мы пишем, потребовал бы такого тщательного тестирования, что время, потраченное для достигания чего-то гибкого и достаточно устойчивого, будет, вероятно, препятствовать.
У меня нет времени для разработки прототипа всех 3 идей, таким образом, я ищу людей комментариев, может иметь на этих 3 опциях выше, плюс дальнейшие идеи, которые я не рассмотрел, чтобы помочь мне решить, какая идея могла бы наиболее подойти. Я в настоящее время склоняюсь к опции 2 (в базе данных памяти), так стремилось бы получить известие от людей с опытом запросов POJOs в памяти также.
Надо надеяться, я описал ситуацию достаточно подробно, но спросите, требуется ли дальнейшая информация, чтобы лучше понимать сценарий.
Удачи,
Edd
4 ответа
Насколько сложны критерии уточнения? Если большинство из них довольно просты, я бы хотел начать с варианта (3), но убедитесь, что он инкапсулирован за подходящий интерфейс, чтобы, если вы столкнетесь с чем-то слишком сложным или неэффективным для написания кода самостоятельно, вы в этот момент может переключиться на БД в памяти (либо оптом для всех запросов, либо только для сложных, если есть накладные расходы при настройке временных таблиц).
Вариант 2 кажется хорошим, так как вы можете переключаться между 1 и 2 по мере необходимости. 3 также ограничен с точки зрения будущего размера данных. Запросы к объектам предполагают большую зависимость от структуры кода для хранения и запросов.
Вероятно, было бы неплохо включить какой-либо механизм кэширования (ehcache / memcache) вместе с использованием варианта 2, а затем профилирование для проверки разницы в производительности.
Варианты 1 и 2 вполне совместимы: реализовав один, вы можете заменить его другим простым изменением конфигурации persistence.xml (при условии, что база данных в памяти совместима с JPA, например, JavaDB, Derby , так далее.).
Вариант 3 повторно реализует как стороннее программное обеспечение (базу данных), так и ваш собственный код (существующие объекты JPA). Вы также перечислили его преимущества в качестве проблемных. В вашем случае это явно менее осуществимый вариант. Я не могу придумать ничего другого для продвижения Варианта 3.
Похоже, что база данных в памяти более подходит с учетом вариантов использования и их временного интервала. Если требования превращаются в менее преходящие, вы можете перейти на Oracle.
Если ваши выражения не слишком сложные, вы можете использовать язык выражений для оценки строковых запросов к вашим объектам Java (POJO). Могу порекомендовать MVEL http://mvel.codehaus.org .
Идея в том, что вы помещаете свои объекты в контекст MVEL. Затем вы предоставляете строковый запрос, написанный в простой нотации MVEL, и, наконец, оцениваете выражение.
Пример взят с сайта MVEL:
Map vars = new HashMap();
vars.put("x", new Integer(5));
vars.put("y", new Integer(10));
Integer result = (Integer) MVEL.eval("x * y", vars);
assert result.intValue() == 50; // Mind the JDK 1.4 compatible code :)
Обычно языки выражений поддерживают обход вашего графа объектов (коллекций) и доступ к членам в стиле JSP EL (точечная запись).
Также я могу предложить взглянуть на OGNL (погуглите, я не могу добавить больше одной ссылки)