Hibernate Search是一个库,通过自动索引实体,将Hibernate ORM与Apache Lucene或Elasticsearch集成,从而实现高级搜索功能:全文搜索、地理空间搜索、聚合等。更多信息,请参阅hibernate.org上的Hibernate Search。

Hibernate Search 4.3.0.Beta1版本现在可在Maven存储库和Sourceforge中找到。

有什么新功能?

  • NRT后端性能提升
  • 空间API变得更加友好
  • JBoss部署模块改进(错误修复)
  • 兼容JBoss EAP 6.1

更多详细信息可以在JIRA过滤器中找到。

NRT用户性能提升

我们获得了全新的性能测试套件,因此我们开始使用它并发现了之前测试中遗漏的一些有趣的优化机会。受影响的NRT后端(近实时)存在一些不必要的锁定竞争,在某些场景中可能导致显著减速。

那么我们讨论的修复是什么类型的?让我们先看看最新最终发布版本的新测试的性能结果。

性能报告:Hibernate Search 4.2.0.Final

SUMMARY
    Name   : FileSystemNearRealTimeTestScenario

    Memory usage (total-free):
        before : 37MB
        after  : 40MB

TASKS
    10000x InsertBookTask                      | sum 25:24.769 | avg 00:00.152
    10000x UpdateBookRatingTask                | sum 25:01.950 | avg 00:00.150
    10000x UpdateBookTotalSoldTask             | sum 22:54.125 | avg 00:00.137
    10000x QueryBooksByAuthorTask              | sum 20:22.324 | avg 00:00.122
    10000x QueryBooksByAverageRatingTask       | sum 30:21.692 | avg 00:00.182
    10000x QueryBooksByBestRatingTask          | sum 39:56.530 | avg 00:00.239
    10000x QueryBooksByNewestPublishedTask     | sum 27:02.078 | avg 00:00.162
    10000x QueryBooksBySummaryTask             | sum 27:19.568 | avg 00:00.163
    10000x QueryBooksByTitleTask               | sum 27:49.037 | avg 00:00.166
    10000x QueryBooksByTotalSoldTask           | sum 26:01.403 | avg 00:00.156

TEST CONFIGURATION
    threads              : 10
    measured cycles      : 10000
    warmup cycles        : 100
    initial book count   : 1000000
    initial author count : 10000

现在让我们看看有多少改进。

性能报告:Hibernate Search 4.3.0.Beta1

SUMMARY
    Name   : FileSystemNearRealTimeTestScenario

    Memory usage (total-free):
        before : 38MB
        after  : 40MB

TASKS
    10000x InsertBookTask                      | sum 04:53.440 | avg 00:00.029
    10000x UpdateBookRatingTask                | sum 04:32.154 | avg 00:00.027
    10000x UpdateBookTotalSoldTask             | sum 04:41.969 | avg 00:00.028
    10000x QueryBooksByAuthorTask              | sum 01:58.408 | avg 00:00.011
    10000x QueryBooksByAverageRatingTask       | sum 12:02.741 | avg 00:00.072
    10000x QueryBooksByBestRatingTask          | sum 12:26.415 | avg 00:00.074
    10000x QueryBooksByNewestPublishedTask     | sum 12:01.274 | avg 00:00.072
    10000x QueryBooksBySummaryTask             | sum 07:08.790 | avg 00:00.042
    10000x QueryBooksByTitleTask               | sum 02:03.112 | avg 00:00.012
    10000x QueryBooksByTotalSoldTask           | sum 11:54.997 | avg 00:00.071

[same configuration]

以下为传统免责声明:不要期望您的应用程序能够获得完全相同性能提升。其他应用程序很可能受益于这一点,但规模可能不同。这就是为什么我不分享硬件细节,它们并不相关:只需说这些测试是在相同的条件下进行的,因此它们是可比较的。

我们无法测试所有应用程序,但我认为我可以作为一个有根据的猜测来声明,我不期望出现性能恶化的情况。对于使用近实时IndexManager的任何应用程序,改进可能是可衡量的,如果您的竞争(更多线程)更高,存储性能较慢或索引显著更大,这些数字可能甚至更好。

感谢您

我想对这些令人兴奋的数字表示对整个Apache Lucene开发团队的感激之情,因为他们创造了Lucene的近实时改进,我们正在在此基础上构建这个功能,并感谢JBoss QA团队的Tomas Hradec创建了性能测试,这些测试解决了问题,并使我们能够对这

如果有人想贡献测试,即使是性能测试,我们将很高兴与他们合作,并使用它们作为未来改进的基础。

像往常一样,问题跟踪器是JIRA,所有代码都在GitHub上:欢迎pull请求和任何形式的反馈。

保持关注,并尽快测试此版本,因为最终版本将很快到来!我们计划下周发布候选版本(CR)。


返回顶部