『壹』 luncene特点及优势
Lucene，作为一款开源项目，自诞生以来在开发者社区中引起了广泛关注。它不仅被用于构建各类全文检索应用，还被广泛集成到系统软件、Web应用甚至商业软件中，如Apache软件基金会官网的全文检索引擎和IBM的Eclipse、Web Sphere。Lucene凭借其特性和优势赢得了广泛采用：
1. 独立的索引格式：Lucene采用8位字节为基础的索引文件格式，使得跨平台和兼容系统的应用能够共享同一索引文件，提升了兼容性和灵活性。
2. 分块索引与优化：它改进了传统的倒排索引，实现分块索引，新文件可快速建立小文件索引，通过与现有索引合并优化性能。
3. 面向对象架构：其优秀的系统设计降低了学习和扩展的难度，使得添加新功能更加便捷。
4. 通用的文本分析接口：Lucene提供了一个独立于语言和文件格式的接口，用户可以通过实现文本分析接口轻松扩展支持新的语言和文件格式。
5. 强大的查询引擎：Lucene内置了丰富的查询功能，如布尔运算、模糊查询和分组查询，无需用户编写大量代码即可实现强大查询能力。
对于商业全文检索引擎，Lucene有独特优势。首先，其Apache Software License的开源模式，不仅允许用户利用其功能，还提供了深入学习和创新的平台。其次，其面向对象架构为扩展提供了无限可能，如中文处理、HTML和PDF等格式的处理。最后，Lucene的开源特性使得程序员能够借助Apache社区的资源进行交流和协作，共享已完成的功能，且支持多种编程语言的实现，适应不同平台的需求。
Apache Lucene是一个开放源程序的搜寻器引擎，利用它可以轻易地为java软件加入全文搜寻功能。Lucene的最主要工作是替文件的每一个字作索引，索引让搜寻的效率比传统的逐字比较大大提高，Lucen提供一组解读，过滤，分析文件，编排和使用索引的API，它的强大之处除了高效和简单外，是最重要的是使使用者可以随时应自己需要自订其功能。
『贰』 Lucene源码索引文件结构反向
Lucene的索引结构复杂且详尽，不仅保存了从Term到Document的正向映射，还包括了从Document到Term的反向信息。这种反向信息的核心是反向索引，它由词典(Term Dictionary)和倒排表(Posting List)两部分组成。词典存储在tii和tis文件中，包含Term的频率、位置信息以及元数据；而倒排表分为文档号和词频的frq文件，以及位置信息的prx文件。
词典(.tim)存储Term的统计信息，如包含文档数量和词频，以及Term的元数据，包括其在文档中的位置。词典索引(.tip)则是对tim文件的索引，便于快速访问。在tim中，NodeBlock以25个entries为一组，包含Term的相关数据和FieldSummary。OuterNode和InnerNode是NodeBlock的两种类型，OuterNode按Term大小顺序存储，用RAMOutputStream记录相关信息。
倒排表的存储则更复杂，如PackedBlock压缩和SKIPLIST结构。LIV文件通过FixBitSet记录文档状态，而TermVector保存的信息与Field Data相似，Norms用于存储Boost加权信息，可能在Lucene7后减少。Doc Values和Point Values分别处理数字类型数据和多维数据索引，这些内容在后续的文章中会有更详细的解释。
总的来说，理解Lucene的索引结构对于优化搜索引擎性能、诊断生产环境问题至关重要，因为它构成了分布式搜索引擎如Solr和ElasticSearch的基础。深入剖析这些文件结构有助于我们从更高层次上进行问题分析。
『叁』 如何提高lucene的效率
如何提高Lucene的搜索速度 译自http://wiki.apache.org/lucene-java/ImproveSearchingSpeed 这里讨论了提高基于Lucene的应用程序搜索速度的几种方法。如果你想提高索引的速度请阅读“如何提高Lucene构建索引的速度”。 首先确定你需要加快搜索速度。这里的很多方法很容易尝试但是有些会增加你程序的复杂性。所以请首先确定搜索速度确实太慢而且速度问题确实是Lucene导致的。 确保你使用的是最新版本的Lucene。 使用本地文件系统。 远程文件系统搜索的速度总是会慢一些。如果你的索引必须放在远程文件系统之上那么可以考虑把远程文件系统用“只读方式”加载mount。某些时候这会改善性能。 使用更快的硬件尤其是更快的IO系统。 固态硬盘solid-state diskSSD非常适合Lucene的搜索。SSD的寻道时间大概是传统磁盘式硬盘的100倍也就是说常见的寻道时间造成的开销几乎可以忽略掉了。也就是说装有SSD的机器无需太多的内存作为文件缓存搜索器在允许反应之前需要的预热warm-up时间更短。 调节操作系统。 linux可以调节的一个典型的参数是swappiness参看http://kerneltrap.org/node/3000译注可理解为交换系统调节物理内存和交换分区使用倾向的这个参数控制了操作系统把内存交换出到IO缓存的倾向性。这个参数在大多数Linux发行版中的默认设置都是一个很大的数也就是说倾向于交换分区这容易造成严重的搜索延迟特别是在查询频率不高的情况下搜索一个大的索引时。请尝试把swappiness调低甚至关闭把它设置为0。Windows也有一个选框在我的电脑-属性-高级-性能设置-内存使用允许你选择倾向于应用程序还是系统缓存好像也是起这个作用的。 使用readOnlytrue选项打开IndexReader。 在多线程共享同一个reader的时候这将起巨大的作用因为这样会去掉处理线程冲突的代码。 在非Windows平台使用NIOFSDirectory取代FSDirectory。 这样访问这些文件的时候也会去掉处理线程冲突的代码。不幸的是由于Sun JRE Windows版本长期存在的bughttp://bugs.sun.com/bugdatabase/view_bug.dobug_id6265734NIOFSDirectory在Windows下表现很差。 使用IndexSearcher的同一个实例。 在程序的查询和线程之间使用单一的一个IndexSearcher的实例。 测量性能的时候忽视第一条查询。 对搜索器的第一次查询要付出初始化缓存的代价特别是按照字段排序的时候会干扰你的结论假设你重用搜索器进行多次查存。另外一方面如果你一遍遍的重复同样的查询结论也会被扭曲因为操作系统会使用它的缓存加速IO操作。Linux核心2.6.16或者更新版本下你可以用命令 sync echo 3 /proc/sys/vm/drop_caches 来清空缓存。参见http://linux-mm.org/Drop_Caches。 仅在需要的时候重新打开IndexSearcher。 只有在需要让最新提交的更新出现在搜索中的时候才应该重新打开IndexSearcher。注意重新打开搜索器有它的开销在大的索引和排序打开的情况下可以被察觉到的必须将这一开销最小化。可以考虑在面对第一个查询之前使用预热技术对缓存进行预热。 搜索前对你的索引进行优化optimize。 优化optimize过的索引只有一个段这样通常比多个段速度快得多尤其是对于大的索引。如果你的程序不经常更新索引那么最好是先构建索引然后优化使用优化过的索引进行搜索。如果你的索引更新频率很高而且更新后就要刷新搜索器的话那么优化对你的开销就太大了你可以采用降低合并因子的方法。 降低合并因子mergeFactor。 小的合并因子意味着更少的段和更快的搜索。然而这将降低索引的速度所以你应该测试这个值直到找到对于你的程序满足平衡的值。 限制保存字段和词向量的使用。 从索引中获取这些信息开销太大。一般来说你应该只获取用户看前可见的“页”内的条目的这些信息而不是整个结果集的。针对每个获取的文档Lucene必须寻道到不同文件的不同位置。尝试首先用docID排序你要获取的文档译注有可能提高寻道效率。 在你获取一个文档时使用FieldSelector仔细的选择要载入哪些字段以及如何载入他们。 不要枚举比所需命中结果更多的结果。 枚举所有的命中很慢有两个原因。首先返回Hits对象的search方法在你需要超过100个命中的时候需要内部重新执行搜索。解决方法用带有HitCollector的search方法代替。其次命中通常遍布磁盘的每个角落访问全部需要大量的I/O活动。这很难避免除非索引小到可以直接放到内存里。如果你不需要完整的文档而只需要一个小的字段那么你可以用FieldCache类来缓存它这样就可以告诉访问它了。 使用模糊查询fuzzy query的时候设置最小的前缀长度。 模糊查询执行耗费CPU的字符串比较——要避免将用户输入的词和所有的索引的词项进行比较应该只比较前“N”个字符相同的词项。前缀长度是QueryParser和FuzzyQuery都有的参数默认为0所有的词项都要比较。 考虑使用过滤器filter。 把结果限定在索引的一部分时使用缓存的位域过滤器比使用查询条件高效得多。尤其是在限制条件包含了一个大索引的大量文档时。过滤器通常用于限定一个分类下的结果但是可以在很多中情况下替代任何查询条件。查询和过滤之间的一个区别在于查询影响结果评分过滤不影响。 找到瓶颈。 复杂的查询分析或者对结果过度处理是隐藏的搜索瓶颈的例子。使用VisualVM这样的工具profile程序可以帮助定位这些问题。
『肆』 Lucene.Net建立索引 数据大概有百万条 可是需要好久好久 请问有没有办法让它变快呢
minMergeFactor还有一个这样的参数，控制在内存缓冲的文档数量我是建了500条数据后关闭IndexWriter.70万的数据都可以建就是创建索引速度的问题70万花了12小时
『伍』 Lucene 需要索引的文本文件太大,怎么解决
就报错来看，还没有用到Lucene就出错了，意思是只到第一行就虚拟机内存溢出了，可以考虑把源文件进行切割，如把10M的文本切成5个1M的，建议你试一下
给一个可以切分文件的程序，可把它作为预处理的一部分
public static void splitToSmallFiles(File file, String outputpath) throws IOException {
int filePointer = 0;
int MAX_SIZE = 10240000;
BufferedWriter writer = null;
BufferedReader reader = new BufferedReader(new FileReader(file));
StringBuffer buffer = new StringBuffer();
String line = reader.readLine();
while (line != null) {
buffer.append(line).append("\r\n");
if (buffer.toString().getBytes().length >= MAX_SIZE)
{
writer = new BufferedWriter(new FileWriter(outputpath + "output" + filePointer + ".txt"));
writer.write(buffer.toString());
writer.close();
filePointer++;
buffer = new StringBuffer();
}
line = reader.readLine();
}
writer = new BufferedWriter(new FileWriter(outputpath + "output" + filePointer + ".txt"));
writer.write(buffer.toString());
writer.close();
}