Performance optimization with Lucene4.0

简介: 假期重新把之前在新浪博客里面的文字梳理了下,搬到这里

Performance optimization with Lucene4.0
原文链接http://www.google.com.hk/url?sa=t&rct=j&q=performance+optimization+with+lucene+4&source=web&cd=1&ved=0CDYQFjAA&url=http://archive.apachecon.com/eu2012/presentations/06-Tuesday/PR-Lucene/aceu-2012-lucene-4-performance-tuning.pdf&ei=axTMUPO9E8yViAfo_oDYDQ&usg=AFQjCNG4lXwTLU-MAl6czbUHhIrdez7AzQ&bvm=bv.1355325884,d.aGc&cad=rjt
该报告中不少亮点,例如:
1 Pluggable Codecs
2 Per Document Values
DocValues
3 Concurrent Flush  
无锁多线程写索引
4 Multiple Scoring Models flexible ranking
排序调优接口的开发、经典模型的调参
5 New Term Dictionary
6 From UTF-16 to UTF-8  no string ojbects anymore

最为关心的对应用来说,查询的性能相关
7 500% faster Filter
8 100x to 200x  FuzzyQuery
9 reduces memory footprint 30x
10 10x faster than FieldCache for a float field
11
近似2倍的索引构建性能提升

实践中
1
倒排结构的 可侵入,意味着倒排的结构细粒度的可控,针对具体数据类型。例如key-value型突出的,可以
针对性去掉一些信息
2
各部分codec的可以选择,意味者对特定的数据结构可以采取特定的优化编码
3
得分模型的可配置和可调参,意味着排序的灵活性和更加有针对性的可定制化
4
整个代码结构和接口命名更加规范,便于理解和扩展
5
第三方包的丰富和增强,拿来用成本更低
6 collector
的可定制,为查询优化开了一个极大地口子
7
方便新技术的实验,例如SSD的扩展,针对SSD特性指定有效的存储结构
8
新的结构更加松散和清晰,意味着lucene C++版本搜索借鉴,成本大大降低

目录
打赏
0
0
0
0
20
分享
相关文章
Optimization and Indexes
MySQL通过索引快速定位具有特定列值的行,避免全表扫描,提高查询效率。常用的索引如PRIMARY KEY、UNIQUE等大多存储在B树中,特殊情况使用R树或哈希索引。索引帮助快速匹配WHERE子句条件的行,减少候选行数,并在多列索引和表连接操作中优化查询。具体特性如B树和哈希索引的比较见特定章节。
Performance Optimization
Performance Optimization
1636 2
Adaptive Query Optimization
Adaptive Query Optimization
65 4
[SIGMOD 22 学习]《Adaptive Hybrid Indexes》解读
本文是学习总结,有错误处欢迎交流。
441 0
One SQL to Rule Them All: An Efficient and Syntactically Idiomatic Approach to Management of Streams and Tables 论文翻译
One SQL to Rule Them All: An Efficient and Syntactically Idiomatic Approach to Management of Streams and Tables[文件: One SQL to Rule Them All- An Efficient and Syntactically Idiomatic Approach to Manag
sbs
250 0
One SQL to Rule Them All: An Efficient and Syntactically Idiomatic Approach to Management of Streams and Tables 论文翻译
2020 SIGMOD:BinDex A Two-Layered Index for Fast and Robust Scan 笔记
目前的查询扫描主要归类为两种方法,一种是顺序扫描 如全表扫描,一种是通过索引扫描 如b-tree等。1. 顺序扫描可能需要访问大量的无用的数据,特别是当选择率低的时候。2. 索引扫描在选择率较高的时候,可能会导致大量的随机内存访问。这些都会导致性能的下降,所以在执行查询操作时,需要根据具体的查询情况(如选择率的高低),选择合适的方法(选择顺序扫描,还是索引扫描)用于查询。但随着数据库查询负载变得复杂,很难去选择合适的方法应对特定的查询(到底是选顺序扫描?还是索引扫描?)。 因此本文提出了一种新的索引方案—BinDex(后面简称BD),可在不同的选择率情况下,同样能够快速地进行查询。 BinDe
Optimizing Queries over Partitioned Tables in MPP Systems
随着互联网数据的爆炸性增长,传统数据库系统在单表数据容量方面承受了越来越大的压力。以前公司内部的数据库,存放的主要是来自公司业务或内部管理系统的信息,中小型公司甚至一个MySQL实例就搞定了。但现在数据源不仅更丰富,数据量也在指数级增长,从业务的角度,基于hash/range的分区表变得越来越有吸引力。
276 0
Optimizing Queries over Partitioned Tables in MPP Systems
AI助理

你好,我是AI助理

可以解答问题、推荐解决方案等