在Java应用程序中查询内存中的一组对象的技术

时间:2010-05-18 09:26:47

标签: java database jpa in-memory-database

我们有一个系统通过调用另一个返回一组Java对象的系统上的接口来执行“粗略搜索”。一旦我们收到搜索结果,我需要能够根据描述属性状态的某些标准进一步过滤生成的Java对象(例如,从初始对象返回所有对象,其中xy> z&& ab == C)。

每次用于过滤对象集的标准部分是用户可配置的,我的意思是用户将能够选择要匹配的值和范围,但他们可以从中选择的属性将是固定集。

每次搜索的数据集可能包含< = 10,000个对象。搜索将由应用程序用户群手动执行,每天不超过2000次(大约)。值得一提的是,结果集中的所有对象都是已知的域对象类,它们具有描述其结构和关系的Hibernate和JPA注释。

可能的解决方案

我可以想到3种方法:

  1. 对于每次搜索,在我们的数据库中保留初始结果集对象,然后使用Hibernate使用更精细的标准重新查询它们。
  2. 使用内存数据库(例如hsqldb?)查询和优化初始结果集。
  3. 编写一些自定义代码,迭代初始结果集并提取所需的记录。
  4. 选项1

    选项1似乎涉及很多网络中的物理数据库(Oracle 10g),这可能会导致大量的网络和磁盘活动。还需要将每次搜索的结果与其他结果集隔离,以确保不同的搜索不会相互干扰。

    选项2

    选项2原则上似乎是一个好主意,因为它允许我在内存中进行更精细的查询,并且不需要结果数据的持久性,只有在搜索完成后才会丢弃。 Gut的感觉是,这可能也非常高效,但可能会导致更大的内存开销(这很好,因为我们可以非常灵活地调整JVM获得的内存量。)

    选项3

    选项3可能非常高效,但是我想避免这样做,因为我们编写的任何代码都需要经过仔细的测试,以至于实现灵活且足够强大的时间可能会令人望而却步。


    我没有时间对所有3个想法进行原型设计,因此我正在寻找人们对上述3个选项的评论,以及我未考虑过的任何进一步的想法,以帮助我确定哪个想法最合适。我目前正倾向于选项2(在内存数据库中),所以很想听到有人在内存中查询POJO的经验。

    希望我已经详细描述了这种情况,但是不要犹豫,询问是否需要任何进一步的信息来更好地理解这种情况。

    干杯,

    埃德

4 个答案:

答案 0 :(得分:1)

选项1和2非常兼容:通过实现一个,您可以使用persistence.xml的简单重新配置将其替换为另一个(假设内存数据库与JPA兼容,例如JavaDB,Derby等)。

选项3重新实现第三方软件(数据库)和您自己的代码(现有JPA实体)。您还列出了其优点。在你的情况下,这显然是一个不太可行的选择。我也想不出任何其他方法来推广选项3。

在给定用例及其时间跨度的情况下,内存数据库似乎更合适。如果需求演变为不太短暂的需求,那么您可以切换到Oracle。

答案 1 :(得分:1)

如果表达式不太复杂,可以使用表达式语言来评估Java对象(PO​​JO)上的字符串查询。我可以推荐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(google it,我不能添加多个链接)

答案 2 :(得分:0)

炼油标准有多复杂?如果大多数都很简单,那么我很想去选项(3)开始,但要确保它封装在一个合适的接口后面,这样如果你遇到的东西过于复杂或效率太低而无法自己编写代码可以在那时切换到内存数据库(对于所有查询都是批发的,或者如果在设置临时表时有开销,则只针对复杂的查询)。

答案 3 :(得分:0)

选项2似乎很好 - 因为你可以在1和1之间切换。 2根据需要。 3在未来数据大小调整问题方面也受到限制。查询对象意味着对存储和查询的代码结构有更大的依赖性。

可能最好包含一些缓存机制(ehcache / memcache)以及Option 2的使用,然后进行性能分析以检查性能差异。