lucene(为什么说Lucene不好)
大家好，今天来为大家分享lucene的一些知识点，和为什么说Lucene不好的问题解析，大家要是都明白，那么可以忽略，如果不太清楚的话可以看看本篇文章，相信很大概率可以解决您的问题，接下来我们就一起来看看吧！
nutch和lucene的区别
Lucene其实是一个提供全文文本搜索的函数库，它不是一个应用软件。它提供很多API函数让你可以运用到各种实际应用程序中。现在，它已经成为Apache的一个项目并被广泛应用着。
Nutch是一个建立在Lucene核心之上的Web搜索的实现，它是一个真正的应用程序。也就是说，你可以直接下载下来拿过来用。它在Lucene的基础上加了网络爬虫和一些和Web相关的东东。其目的就是想从一个简单的站内索引和搜索推广到全球网络的搜索上，就像Google和Yahoo一样。当然，和那些巨人竞争，你得动一些脑筋，想一些办法。我们已经测试过100M的网页，并且它的设计用在超过1B的网页上应该没有问题。当然，让它运行在一台机器上，搜索一些服务器，也运行的很好。
总的来说，我认为LUCENE会应用在本地服务器的网站内部搜索，而Nutch则扩展到整个网络、Internet的检索。当然LUCENE加上爬虫程序等就会成为Nutch，这样理解应该没错吧。
Lucene实战的目录
目录
第1部分Lucene核心
第1章初识Lucene 3
1.1应对信息爆炸 4
1.2Lucene是什么 5
1.2.1Lucene能做些什么 6
1.2.2Lucene的历史 7
1.3Lucene和搜索程序组件 9
1.3.1索引组件 10
1.3.2搜索组件 13
1.3.3搜索程序的其他模块 16
1.3.4Lucene与应用程序的整合点 18
1.4Lucene实战：程序示例 18
1.4.1建立索引 19
1.4.2搜索索引 22
1.5理解索引过程的核心类 25
1.5.1IndexWriter 25
1.5.2Directory 25
1.5.3Analyzer 26
1.5.4Document 26
1.5.5Field 27
1.6理解搜索过程的核心类 27
1.6.1IndexSearcher 27
1.6.2Term 28
1.6.3Query 28
1.6.4TermQuery 28
1.6.5TopDocs 29
1.7小结 29
第2章构建索引30
2.1Lucene如何对搜索内容进行建模 31
2.1.1文档和域 31
2.1.2灵活的架构 32
2.1.3反向规格化(Denormalization) 32
2.2理解索引过程 33
2.2.1提取文本和创建文档 33
2.2.2分析文档 34
2.2.3向索引添加文档 34
2.3基本索引操作 35
2.3.1向索引添加文档 35
2.3.2删除索引中的文档 38
2.3.3更新索引中的文档 39
2.4域选项 41
2.4.1域索引选项 41
2.4.2域存储选项 42
2.4.3域的项向量选项 42
2.4.4Reader、TokenStream和byte[ ]域值 42
2.4.5域选项组合 43
2.4.6域排序选项 44
2.4.7多值域 44
2.5对文档和域进行加权操作 45
2.5.1文档加权操作 45
2.5.2域加权操作 46
2.5.3加权基准(Norms) 47
2.6索引数字、日期和时间 48
2.6.1索引数字 48
2.6.2索引日期和时间 49
2.7域截取(Field truncation) 50
2.8近实时搜索(Near-real-time search) 51
2.9优化索引 51
2.10其他Directory子类 52
2.11并发、线程安全及锁机制 55
2.11.1线程安全和多虚拟机安全 55
2.11.2通过远程文件系统访问索引 56
2.11.3索引锁机制 57
2.12调试索引 59
2.13高级索引概念 60
2.13.1用IndexReader删除文档 61
2.13.2回收被删除文档所使用过的磁盘空间 62
2.13.3缓冲和刷新 62
2.13.4索引提交 63
2.13.5ACID事务和索引连续性 65
2.13.6合并段 66
2.14小结 68
第3章为应用程序添加搜索功能70
3.1实现简单的搜索功能 71
3.1.1对特定项的搜索 72
3.1.2解析用户输入的查询表达式：QueryParser 73
3.2使用IndexSearcher类 76
3.2.1创建IndexSearcher类 76
3.2.2实现搜索功能 78
3.2.3使用TopDocs类 78
3.2.4搜索结果分页 79
3.2.5近实时搜索 79
3.3理解Lucene的评分机制 81
3.3.1Lucene如何评分 81
3.3.2使用explain()理解搜索结果评分 83
3.4Lucene的多样化查询 84
3.4.1通过项进行搜索：TermQuery类 85
3.4.2在指定的项范围内搜索：TermRangeQuery类 86
3.4.3在指定的数字范围内搜索：NumericRangeQuery类 87
3.4.4通过字符串搜索：PrefixQuery类 88
3.4.5组合查询：BooleanQuery类 88
3.4.6通过短语搜索：PhraseQuery类 91
3.4.7通配符查询：WildcardQuery类 93
3.4.8搜索类似项：FuzzyQuery类 94
3.4.9匹配所有文档：MatchAllDocsQuery类 95
3.5解析查询表达式：QueryParser 96
3.5.1Query.toString方法 97
3.5.2TermQuery 97
3.5.3项范围查询 98
3.5.4数值范围搜索和日期范围搜索 99
3.5.5前缀查询和通配符查询 99
3.5.6布尔操作符 100
3.5.7短语查询 100
3.5.8模糊查询 101
3.5.9MatchAllDocsQuery 102
3.5.10分组查询 102
3.5.11域选择 103
3.5.12为子查询设置加权 103
3.5.13是否一定要使用QueryParse 103
3.6小结 104
第4章Lucene的分析过程 105
4.1使用分析器 106
4.1.1索引过程中的分析 107
4.1.2QueryParser分析 109
4.1.3解析vs分析：分析器何时不再适用 109
4.2剖析分析器 110
4.2.1语汇单元的组成 111
4.2.2语汇单元流揭秘 112
4.2.3观察分析器 115
4.2.4语汇单元过滤器：过滤顺序的重要性 119
4.3使用内置分析器 121
4.3.1StopAnalyzer 122
4.3.2StandardAnalyzer 122
4.3.3应当采用哪种核心分析器 123
4.4近音词查询 123
4.5同义词、别名和其他表示相同意义的词 126
4.5.1创建SynonymAnalyzer 127
4.5.2显示语汇单元的位置 131
4.6词干分析 132
4.6.1StopFilter保留空位 133
4.6.2合并词干操作和停用词移除操作 134
4.7域分析 134
4.7.1多值域分析 135
4.7.2特定域分析 135
4.7.3搜索未被分析的域 136
4.8语言分析 139
4.8.1Unicode与字符编码 139
4.8.2非英语语种分析 140
4.8.3字符规范化处理 140
4.8.4亚洲语种分析 141
4.8.5有关非英语语种分析的其他问题 143
4.9Nutch分析 144
4.10小结 146
第5章高级搜索技术147
5.1Lucene域缓存 148
5.1.1为所有文档加载域值 149
5.1.2段对应的reader 149
5.2对搜索结果进行排序 150
5.2.1根据域值进行排序 150
5.2.2按照相关性进行排序 153
5.2.3按照索引顺序进行排序 154
5.2.4通过域进行排序 154
5.2.5倒排序 155
5.2.6通过多个域进行排序 156
5.2.7为排序域选择类型 157
5.2.8使用非默认的locale方式进行排序 157
5.3使用MultiPhraseQuery 158
5.4针对多个域的一次性查询 160
5.5跨度查询 162
5.5.1跨度查询的构建模块：SpanTermQuery 165
5.5.2在域的起点查找跨度 166
5.5.3彼此相邻的跨度 167
5.5.4在匹配结果中排除重叠的跨度 169
5.5.5SpanOrQuery类 170
5.5.6SpanQuery类和QueryParser类 171
5.6搜索过滤 172
5.6.1TermRangeFilter 173
5.6.2NumericRangeFilter 174
5.6.3FieldCacheRangeFilter 174
5.6.4特定项过滤 174
5.6.5使用QueryWrapperFilter类 175
5.6.6使用SpanQueryFilter类 175
5.6.7安全过滤器 176
5.6.8使用BooleanQuery类进行过滤 177
5.6.9PrefixFilter 178
5.6.10缓存过滤结果 178
5.6.11将filter封装成query 179
5.6.12对过滤器进行过滤 179
5.6.13非Lucene内置的过滤器 180
5.7使用功能查询实现自定义评分 180
5.7.1功能查询的相关类 180
5.7.2使用功能查询对最近修改过的文档进行加权 182
5.8针对多索引的搜索 184
5.8.1使用MultiSearch类 184
5.8.2使用ParallelMultiSearcher进行多线程搜索 186
5.9使用项向量 186
5.9.1查找相似书籍 187
5.9.2它属于哪个类别 190
5.9.3TermVectorMapper类 193
5.10使用FieldSelector加载域 194
5.11停止较慢的搜索 195
5.12小结 196
第6章扩展搜索198
6.1使用自定义排序方法 199
6.1.1针对地理位置排序方式进行文档索引 199
6.1.2实现自定义的地理位置排序方式 200
6.1.3访问自定义排序中的值 203
6.2开发自定义的Collector 204
6.2.1Collector基类 205
6.2.2自定义Collector：BookLinkCollector 206
6.2.3AllDocCollector类 207
6.3扩展QueryParser类 208
6.3.1自定义QueryParser的行为 208
6.3.2禁用模糊查询和通配符查询 209
6.3.3处理数值域的范围查询 210
6.3.4处理日期范围 211
6.3.5对已排序短语进行查询 213
6.4自定义过滤器 215
6.4.1实现自定义过滤器 215
6.4.2搜索期间使用自定义过滤器 216
6.4.3另一种选择：FilterQuery类 217
6.5有效载荷(Payloads) 218
6.5.1分析期间生成有效载荷 219
6.5.2搜索期间使用有效载荷 220
6.5.3有效载荷和跨度查询 223
6.5.4通过TermPositions来检索有效载荷 223
6.6小结 223
第2部分Lucene应用
第7章使用Tika提取文本227
7.1Tika是什么 228
7.2Tika的逻辑设计和API 230
7.3安装Tika 231
7.4Tika的内置文本提取工具 232
7.5编程实现文本提取 234
7.5.1索引Lucene文档 234
7.5.2Tika工具类 237
7.5.3选择自定义分析器 238
7.6Tika的局限 238
7.7索引自定义的XML文件 239
7.7.1使用SAX进行解析 239
7.7.2使用Apache Commons Digester进行解析和索引 242
7.8其他选择 244
7.9小结 245
第8章Lucene基本扩展246
8.1Luke：Lucene的索引工具箱 247
8.1.1Overview标签页：索引的全局视图 248
8.1.2浏览文档 249
8.1.3使用QueryParser进行搜索 251
8.1.4Files and Plugins标签页 252
8.2分析器、语汇单元器和语汇单元过滤器 253
8.2.1SnowballAnalyzer 255
8.2.2Ngram过滤器 256
8.2.3Shingle过滤器 258
8.2.4获取捐赠分析器 258
8.3高亮显示查询项 259
8.3.1高亮显示模块 259
8.3.2独立的高亮显示示例 262
8.3.3使用CSS进行高亮显示处理 263
8.3.4高亮显示搜索结果 264
8.4FastVector Highlighter类 266
8.5拼写检查 269
8.5.1生成提示列表 269
8.5.2选择最佳提示 271
8.5.3向用户展示搜索结果 272
8.5.4一些加强拼写检查的考虑 273
8.6引人注目的查询扩展功能 274
8.6.1MoreLikeThis 274
8.6.2FuzzyLikeThisQuery 275
8.6.3BoostingQuery 275
8.6.4TermsFilter 276
8.6.5DuplicateFilter 276
8.6.6RegexQuery 276
8.7构建软件捐赠模块(contrib module) 277
8.7.1源代码获取方式 277
8.7.2contrib目录的Ant插件 277
8.8小结 278
第9章Lucene高级扩展279
9.1链式过滤器 280
9.2使用Berkeley DB存储索引 282
9.3WordNet同义词 284
9.3.1建立同义词索引 285
9.3.2将WordNet同义词链接到分析器中 287
9.4基于内存的快速索引 289
9.5XML QueryParser：超出“one box”的搜索接口 289
9.5.1使用XmlQueryParser 291
9.5.2扩展XML查询语法 295
9.6外围查询语言 296
9.7Spatial Lucene 298
9.7.1索引空间数据 299
9.7.2搜索空间数据 302
9.7.3Spatial Lucene的性能特点 304
9.8远程进行多索引搜索 306
9.9灵活的QueryParser 309
9.10其他内容 312
9.11小结 313
第10章其他编程语言使用Lucene314
10.1移植入门 315
10.1.1移植取舍 316
10.1.2选择合适的移植版本 317
10.2CLucene(C++) 317
10.2.1移植目的 318
10.2.2API和索引兼容 319
10.2.3支持的平台 321
10.2.4当前情况以及未来展望 321
10.3Lucene-Net(C#和其他.NET编程语言) 321
10.3.1API兼容 323
10.3.2索引兼容 324
10.4KinoSearch和Lucy(Perl) 324
10.4.1KinoSearch 325
10.4.2Lucy 327
10.4.3其他Perl选项 327
10.5Ferret(Ruby) 328
10.6PHP 329
10.6.1Zend Framework 329
10.6.2PHP Bridge 330
10.7PyLucene(Python) 330
10.7.1API兼容 332
10.7.2其他Python选项 332
10.8Solr(包含多种编程语言) 332
10.9小结 334
第11章Lucene管理和性能调优335
11.1性能调优 336
11.1.1简单的性能调优步骤 337
11.1.2测试方法 338
11.1.3索引-搜索时延调优 339
11.1.4索引操作吞吐量调优 340
11.1.5搜索时延和搜索吞吐量调优 344
11.2多线程和并行处理 346
11.2.1使用多线程进行索引操作 347
11.2.2使用多线程进行搜索操作 351
11.3资源消耗管理 354
11.3.1磁盘空间管理 354
11.3.2文件描述符管理 357
11.3.3内存管理 361
11.4热备份索引 364
11.4.1创建索引备份 365
11.4.2恢复索引 366
11.5常见错误 367
11.5.1索引损坏 367
11.5.2修复索引 369
11.6小结 369
第3部分案例分析
第12章案例分析1：Krugle373
12.1Krugle介绍 374
12.2应用架构 375
12.3搜索性能 376
12.4源代码解析 377
12.5子串搜索 378
12.6查询VS搜索 381
12.7改进空间 382
12.7.1FieldCache内存使用 382
12.7.2合并索引 382
12.8小结 383
第13章案例分析2：SIREn384
13.1SIREn介绍 385
13.2SIREn优势 385
13.2.1通过所有域进行搜索 387
13.2.2一种高效词典 388
13.2.3可变域 388
13.2.4对多值域的高效处理 388
13.3使用SIREn索引实体 388
13.3.1数据模型 389
13.3.2实现问题 389
13.3.3索引概要 390
13.3.4索引前的数据准备 390
13.4使用SIREn搜索实体 392
13.4.1搜索内容 392
13.4.2根据单元限制搜索范围 393
13.4.3将单元合并成元组 393
13.4.4针对实体描述进行查询 394
13.5在Solr中集成SIREn 394
13.6Benchmark 395
13.7小结 397
第14章案例分析3：LinkedIn398
14.1使用Bobo Browse进行分组搜索 398
14.1.1Bobo Browse的设计 400
14.1.2深层次分组搜索 403
14.2使用Zoie进行实时搜索 405
14.2.1Zoie架构 406
14.2.2实时VS近实时 409
14.2.3文档与索引请求 411
14.2.4自定义IndexReaders 411
14.2.5与Lucene的近实时搜索进行比较 412
14.2.6分布式搜索 413
14.3小结 415
附录A安装Lucene416
A.1二进制文件安装 416
A.2运行命令行演示程序 417
A.3运行Web应用演示程序 418
A.4编译源代码 419
A.5排错 420
附录BLucene索引格式421
B.1逻辑索引视图 421
B.2关于索引结构 422
B.2.1理解多文件索引结构 422
B.2.2理解复合索引结构 425
B.2.3转换索引结构 426
B.3倒排索引 427
B.4小结 430
附录CLucene/contrib benchmark431
C.1运行测试脚本 432
C.2测试脚本的组成部分 435
C.2.1内容源和文档生成器 438
C.2.2查询生成器 439
C.3控制结构 439
C.4内置任务 441
C.4.1建立和使用行文件 445
C.4.2内置报表任务 446
C.5评估搜索质量 446
C.6出错处理 449
C.7小结 449
附录D资源450
D.1Lucene知识库 450
D.2国际化 450
D.3语言探测 451
D.4项向量 451
D.5Lucene移植版本 451
D.6案例分析 452
D.7其他 452
D.8信息检索软件 452
D.9Doug Cutting的著作 453
D.9.1会议论文 453
D.9.2美国专利 454
为什么说Lucene不好
在Lingway公司，我们使用了Lucene至进今已有好几年时间。对那些刚接触Lucene的人来说，这里是使用它的关键：Apache Lucene是一个由java编写的高性能，全方位的单词搜索引擎库。
在批评它之前，我必须承认Lucene是一个高性能的划词搜索引擎。几年来，Lucene已经被看作是用java编写的嵌入式搜索引擎中的一等公民。它的声誉每日剧增，并且仍然是开源java搜索引擎中的最佳。每个人都在说：“Doug Cutting做了一项伟大的工作”。然而，最近的几个月内，开发的进程变得缓慢，我认为Lucene将不会满足现代的文档处理需求。不要把东西搞糟：我不是搜索引擎开发者，我只是个开发者，使用搜索引擎，来提供合适信息的检索科技。
Lucene不是最好选择，至少对我们而言如此，并且情况并没有得到改变。我们列出Lucene的局限性：Lingway公司基于语意来生成复杂的查询。例如当你正在查找关于“中东地区冲突”的文章，你也许还需要找关于“伊拉克战争”文章。在上面这个用例中，“战争”和“伊拉克”分别是“冲突”和“中东”的扩展。我们使用一种技术能分析你的查询，产生相应的最合适的扩展，为它们生成查询。然而，为了得到相关的结果，这些还是不够的：通过Lucene实现的类似Google的等级或是经常变化积分的并不能满足语意级别积分。例如，一个包含“中”和“东”短语，但是被超过一个以上的单词隔开，这种情况并不是我们想要查找的。更重要的是，相对常规的单词，我们应该给扩展更低的分数。比如，我们应该给“中东地区冲突”这个短语更高的分数，而不是“伊拉克战争”。
在Lingway公司，我们认为这种文章相关性技术是一种未来的搜索引擎。Google在文章搜索上做的很出色。但我们想要的却是最相关的文章。但是，大部分的当代搜索引擎都没有对这样复杂查询做相关的设计…Lucene被wikipedia使用，如果你注意到当你查询查过一个单词时，大多数的查询结果并不是由关联的…
为了演示需求，这里有一个Lingway公司即将上线的KM3.7产品的界面截图。这里我们用法语写一个查询，用来查找那些同样主题，而用英语写的文章。注意，这可不仅仅是简简单单的翻译，我们称之为语言交叉模式：
注意到那些绿色的匹配:chanteur变成了singer,但是我们也发现singing被匹配了。同样情况流行乐成为蓝调的扩展。
6大理由不选用Lucene
6.没有对集群的内置支持。
如果你创建集群，你可以写出自己对Directory的实现，或是使用Solr或者使用Nutch+Hadoop。Solr和Nutch都支持Lucene，但不是直接的替代。Lucene是可嵌入的，而你必须支持Solr和Nutch..我认为Hadoop从Lucene团队中产生并不惊讶:Lucene并不是通用的。它的内在性决定了对大多数场合来说它是非常快速的，但是对大型文档集合时,你不得不排除Lucene。因为它在内核级别上并没有实现集群，你必须把Lucene转换到别的搜索引擎，这样做并不直接。转换到Solr或者Nutch上的问题会让你遇到许多不必要的麻烦:Nutch中的集成crawling和Solr中的检索服务。
5.跨度查询太慢
这对Lingway公司来说可能是个特殊的问题。我们对跨度查询有很强要求,Lucene检索结构已经开始添加这一细节，但它们当初可没这么想。最基础的实现导致了复杂的算法并且运行缓慢，尤其是当某些短语在一份文档中重复了许多次出现。这是为什么我倾向说Lucene是一个高性能的划词检索引擎当你仅仅使用基本的布尔查询时。
4.积分不能被插件化
Lucene有自己对积分算法的实现,当条件增加时使用Similarity类。但很快它显示出局限性当你想要表示复杂的积分,例如基于实际匹配和元数据的查询。如果你这样做，你不得不继承Lucene的查询类。因为Lucene使用类似tf/idf的积分算法，然而在我们遇到的场合，在语意上的积分上Lucene的积分机制并不合适。我们被迫重写每一个Lucene的查询类使得它支持我们自定义的积分。这是一个问题。
3.Lucene并非良好设计
作为一个系统架构师，我倾向认为(1)Lucene有一个非常糟糕的OO设计。虽然有包，有类的设计，但是它几乎没有任何设计模式。这让我想起一个由C(++)开发者的行为，并且他把坏习惯带到了java中。这造成了，当你需要自定义Lucene来满足你的需求(你将来必定会遇到这样的需求)，你必须面对这样的问题。例如：
<!--[if!supportLists]--><!--[endif]-->几乎没有使用接口。查询类（例如BooleanQuery,SpanQuery,TermQuery…）都是一个抽象类的子类。如果你要添加其中的一个细节，你会首先想到写一个接口来描述你扩展的契约，但是抽象的Query类并没有实现接口，你必须经常的变化自己的查询对象到Query中并在本地Lucene中调用。成堆的例子如(HitCollecor,…)这对使用AOP和自动代理来说也是一个问题.
<!--[if!supportLists]--><!--[endif]-->别扭的迭代实现.没有hasNext()方法,next()方法返回布尔类型并刷新对象内容.这对你想要保持对迭代的元素跟踪来说非常的痛苦.我假定这是故意用来节省内存但是它又一次导致了算法上的杂乱和复杂.
2.一个关闭的API使得继承Lucene成为痛苦
在Lucene的世界中,它被称之为特性。当某些用户需要得到某些细节，方针是开放类。这导致了大多数的类都是包保护级别的，这意味着你不能够继承他们（除非在你创建的类似在同一个包下，这样做会污染客户代码）或者你不得不复制和重写代码。更重要的是，如同上面一点提到的，这个严重缺乏OO设计的结构，一些类应该被设为内部类却没有，匿名类被用作复杂的计算当你需要重写他们的行为。关闭API的理由是让代码在发布前变得整洁并且稳定。虽然想法很光荣，但它再一次让人感到痛苦。因为如果你有一些代码和Lucene的主要思路并不吻合，你不得不经常回归Lucene的改进到你自己的版本直到你的补丁被接受。
然而当开发者开始越来越长的限制API的更改，你的补丁很少有机会被接受。在一些类和方法上加上final修饰符会让你遇到问题。我认为如果Spring框架有这样的限制，是觉不会流行起来。
<!--[if!supportLists]-->1. Lucene搜索算法不适合网格计算<!--[endif]-->
Lucene被写出来的时候硬件还没有很大的内存，多处理器也不存在。因此，索引结构是被设计成使用线性的内存开销很小的方式。我花了很长的时间来重写跨度查询算法，并使用多线程内容（使用双核处理器），但是基于迭代器的目录读取算法几乎不能实现。在一些罕见的场合你能做一些优化并能迭代一个索引通过并行方式，但是大多数场合这是不可能的。我们遇到的情况是，当我们有一个复杂的，超过50+的内嵌跨度查询，CPU还在空闲但I/O却一直忙�担踔猎谑褂昧薘AMDirectory.
有没有替代品？
我认为最后一个观点充满疑问:Lucene到达了它的极限当它在现在硬件基础的条件下，检索大型数据集合时。那就是我为什么寻找下一个可以替代Lucene的出现。在阅读了博客目录和 Wikia的讨论后，我发现并没有很多的替代品。然而我最后推荐一个有希望的方案：MG4J。它有一个良好的面向对象设计，性能良好的检索（索引比Lucene慢），内存开销上也很小，达到10倍于Lucene速度的跨度查询，在我的跨度查询基准上，并且是原生上支持集群。同样它也内置了负载平衡，而Lucene最近才加入这项功能并且还是实验性质的。然而MG4J仍然缺少一些特性例如简单的索引指数，文档移除和更简单的使用索引处理。让我感到高兴的是我可以自定义Lucene上的功能在MG4J上只需花几个小时，而在Lucene上却需要数天。
我认为对开源的搜索引擎来说仍然有发展空间，它不是通过单台电脑用有限的内存来索引批量文档，而是通过透明的分布式索引来提供对大型数据集合检索更为快捷的答案。你不必利用应用来获得集群特性。Lucene对第一类搜索引擎有了很好的实现，单我认为它并不符合我们的需求：在一个合理的时间内找到最佳的答案。基于tf/idf的搜索算法和google的等级并不是未来搜索引擎的趋势。实现对原数据和语义的复杂查询并找出相关的信息，这是Lingway公司(通过Lucene和其他搜索引擎技术)所作的，不过它要求有更多支持新硬件的新技术。
使用Lucene的一个好理由
无论我如何指责Lucene,它仍然是java开源解决方案中的最佳实现。
关于lucene和为什么说Lucene不好的介绍到此就结束了，不知道你从中找到你需要的信息了吗 ？如果你还想了解更多这方面的信息，记得收藏关注本站。