主流全文索引工具的比较（ Lucene, Sphinx, solr, elastic search)
前几天的调研（Rails3下的fulltextsearch(全文本搜索，全文匹配？）），我发现了两个不错的候选：
1.lucene(solr,elasticsearch都是基于它）
2.sphinx
两者都有很不错的口碑。所以今天更加进一步的调查。把看到的有价值的文章记录在这里：
1.http://stackoverflow.com/questions/737275/comparison-of-full-text-search-engine-lucene-sphinx-postgresql-mysql
------------
回答1.Resultrelevancerankingisthedefault.Youcansetupyourownsortingshouldyouwish,andgivespecificfieldshigherweightings.
结果相关度是排序的默认条件。你也可以自行指定，也可以配置不同列的权重。
Indexingspeedissuper-fast,becauseittalksdirectlytothedatabase.AnyslownesswillcomefromcomplexSQLqueriesandun-indexedforeignkeysandothersuchproblems.I'venevernoticedanyslownessinsearchingeither.
由于直接跟数据库对话，它建立索引的速度超快，除非你的SQL语句非常复杂，或者某个列没有使用索引。我的项目中没遇到这些问题。
Thesearchservicedaemon(searchd)isprettylowonmemoryusage-andyoucansetlimitsonhowmuchmemorytheindexerprocessusestoo.
搜索服务进程占用资源极小，你也可以指定内存大小的分配。
Scalabilityiswheremyknowledgeismoresketchy-butit'seasyenoughtocopyindexfilestomultiplemachinesandrunseveralsearchddaemons.ThegeneralimpressionIgetfromothersthoughisthatit'sprettydamngoodunderhighload,soscalingitoutacrossmultiplemachinesisn'tsomethingthatneedstobedealtwith.
扩展性:我对它了解的不多。但是很容易把一份索引COPY到多个服务器上，然后再跑多个搜索进程。从其他人那里了解的情况是：在高压高并发下，单极表现就足够好了！所以没必要考虑把它做成分布式。。。
There'snosupportfor'did-you-mean',etc-althoughthesecanbedonewithothertoolseasilyenough.Sphinxdoesstemwordsthoughusingdictionaries,so'driving'and'drive'(forexample)wouldbeconsideredthesameinsearches.
它不支持查询纠正（“你是不是想搜索OOXX”？）Sphinx使用字典进行分词，所以driving和drive返回的搜索结果是一样的。
------------
回答2.
Idon'tknowSphinx,butasforLucenevsadatabasefull-textsearch,IthinkthatLuceneperformanceisunmatched.Youshouldbeabletodoalmostanysearchinlessthan10ms,nomatterhowmanyrecordsyouhavetosearch,providedthatyouhavesetupyourLuceneindexcorrectly.
我没用过Shpinx，但是跟数据库相比的话，lucene的能力是无可匹敌的。你几乎可以在10ms内做任何搜索，不管目标的数据量有多大。（前提是你正确的建立好了索引）
Herecomesthebiggesthurdlethough:personally,IthinkintegratingLuceneinyourprojectisnoteasy.Sure,itisnottoohardtosetitupsoyoucandosomebasicsearch,butifyouwanttogetthemostoutofit,withoptimalperformance,thenyoudefinitelyneedagoodbookaboutLucene.
这里有个最大的门槛：个人以为，在项目中集成lucene并不容易。当然了，建立具备基本功能的原型并不难，但是你想要优化的话，你手边有一本非常好的书才行。
AsforCPU&RAMrequirements,performingasearchinLucenedoesn'ttaskyourCPUtoomuch,thoughindexingyourdatais,althoughyoudon'tdothattoooften(maybeonceortwiceaday),sothatisn'tmuchofahurdle.
检索时它对CPU和内存的需求很小，建立索引时却不小，不过估计你每天重建索引的次数也不多，所以估计问题不大。
http://stackoverflow.com/a/2288211/445908
elasticsearch的作者的回答：
AsthecreatorofElasticSearch,maybeIcangiveyousomereasoningonwhyIwentaheadandcreateditinthefirstplace.
做为ElasticSearch的作者，也许我可以解释一下我建立这个项目的缘由。
UsingpureLuceneischallenging.Therearemanythingsthatyouneedtotakecareforifyouwantittoreallyperformwell,andalso,itsalibrary,sonodistributedsupport,itsjustanembeddedJavalibrarythatyouneedtomaintain.
使用Lucene有一定的挑战性。想要用好它的话，你需要时刻留心很多东西。而且它只是一个jar包，不支持分布式。
IntermsofLuceneusability,waybackwhen(almost6yearsnow),IcreatedCompass.ItsaimwastosimplifyusingLuceneandmakeeverydayLucenesimpler.WhatIcameacrosstimeandtimeagainistherequirementtobeabletohaveCompassdistributed.IstartedtoworkonitfromwithinCompass,byintegratingwithdatagridsolutionslikeGigaSpaces,CoherenceandTerracotta,butitsnotenough.
在使用性方面。。。还得谈及6年前我建立Compass这个项目。它的目的是把使用和维护Lucene变得简单些。而我当时屡次遇到这样的需求：让Compass支持分布式。于是我以此为起点开始工作，集成了datagrid解决方案（例如Gigaspaces....)但是这些努力还不够。
Atitscore,adistributedLucenesolutionneedstobesharded.Also,withtheadvancementofHTTPandJSONasubiquitousAPIs,itmeansthatasolutionthatmanydifferentsystemswithdifferentlanguagescaneasilybeused.
分布式Lucene解决方案的核心是：数据库需要水平分区的。(sharded,词条见：shard)同时，还要使用HTTP和JSON的形式来做为API。这样的优势是：不论什么语言，都可以轻易的调用它。
ThisiswhyIwentaheadandcreatedElasticSearch.Ithasaveryadvancedistributedmodel,speaksnativelyJSON,andexposesmanyadvancesearchfeatures,allseamlesslyexpressedthroughJSONDSL.
这就是我建立ElasticSearch的原因。它用有先进的分布式模型，本地语言是JSON,还提供了很多查询特性。这些都使用JSON形式的DSL来访问。
Solrisalsoasolutionforexposinganindexing/searchserveroverHTTP,butIwouldarguethatElasticSearchprovidesamuchsuperiordistributedmodelandeaseofuse(thoughcurrentlylackingonsomeofthesearchfeatures,butnotforlong,andinanycase,theplanistogetallCompassfeaturesintoElasticSearch).Ofcourse,Iambiased,sinceIcreatedElasticSearch,soyoumightneedtocheckforyourself.
Solr也是一个通过HTTP访问的检索/查询解决方案，但是我觉得ElasticSearch提供了更好的分布式模型，也更容易使用（尽管目前看来，ElasticSearch还缺少某些检索特性，但是在不远的将来，我保证，会把Compass所有的特性都移植到ElasticSearch中去）当然了，做为作者，我的话肯定会偏向于ElasticSearch，所以你最好亲自试一下。
AsforSphinx,Ihavenotusedit,soIcan'tcomment.WhatIcanreferyouistothisthreadatSphinxforumwhichIthinkprovesthesuperiordistributedmodelofElasticSearch.
对于Sphinx，我没用过。所以也就不评价它了。不过从Sphinx论坛的这篇文章看来，ElasticSearch提供了更好的分布式模型。
Ofcourse,ElasticSearchhasmanymorefeaturesthenjustbeingdistributed.Itisactuallybuiltwithcloudinmind.Youcancheckthefeaturelistonthesite.
当然了，除了更好的分布式模型，ElasticSearch还提供了很多其他的特性。因为它的诞生就是基于分布式的理念（builtwithcloudinmind)，你可以试一下站点中的特性里面所列举的特性。
http://stackoverflow.com/q/1284083/445908
I'vebeenusingSolrsuccessfullyforalmost2yearsnow,andhaveneverusedSphinx,soI'mobviouslybiased.However,I'lltrytokeepitobjectivebyquotingthedocsorotherpeople.I'llalsotakepatchestomyanswer:-)
过去两年我一直在用Solr，用的很好。从没用过Sphinx.所以我个人观点肯定不太客观。不过，我引用一下其他人的看法
Similarities:相同点：
BothSolrandSphinxsatisfyallofyourrequirements.They'refastanddesignedtoindexandsearchlargebodiesofdataefficiently.
两者都满足你的需求。它们都很快，面向于大数据量下的高效率的建立索引，搜索。
Bothhavealonglistofhigh-trafficsitesusingthem(Solr,Sphinx)
都有很长的大数据量网站列表
Bothoffercommercialsupport.(Solr,Sphinx)
都有商业支持。
BothofferclientAPIbindingsforseveralplatforms/languages(Sphinx,Solr)
都支持对不同语言的CLIENTAPI。
Bothcanbedistributedtoincreasespeedandcapacity(Sphinx,Solr)
都支持分布式。
Herearesomedifferences:几点不同：
Solr,beinganApacheproject,isobviouslyApache2-licensed.SphinxisGPLv2.Thismeansthatifyoueverneedtoembedorextend(notjust"use")Sphinxinacommercialapplication,you'llhavetobuyacommerciallicense(rationale)
Solr是apache的项目，是apache2的license.Sphinx是GPL,也就是说，如果你想把Sphinx放到某个商业性的项目中，你就得买个商业许可证。
SolriseasilyembeddableinJavaapplications.
Solr很容易就可以集成到JAVA项目中。
SolrisbuiltontopofLucene,whichisaproventechnologyover8yearsoldwithahugeuserbase(thisisonlyasmallpart).WheneverLucenegetsanewfeatureorspeedup,Solrgetsittoo.ManyofthedevscommittingtoSolrarealsoLucenecommitters.
Solr是基于Lucene的，后者已经8岁了，有着庞大的用户群体。Lucene有啥功能，Solr就能享受到啥功能。而且Solr的开发人员很多也参与了Lucene的开发。
SphinxintegratesmoretightlywithRDBMSs,especiallyMySQL.
SolrcanbeintegratedwithHadooptobuilddistributedapplications
SolrcanbeintegratedwithNutchtoquicklybuildafully-fledgedwebsearchenginewithcrawler.
Sphinx跟RDBMS（特别是MYSQL）绑定的特别紧密。而且Solr可以和Hadoop集成，成为分布式系统。也可以和Nutch集成，成为一个功能完备的搜索引擎，以及网络爬虫(crawler)
SolrcanindexproprietaryformatslikeMicrosoftWord,PDF,etc.Sphinxcan't.
Solr可以检索WORD，PDF。Sphinx不行
Solrcomeswithaspell-checkeroutofthebox.
Solr还带有拼写检查器。
Solrcomeswithfacetsupportoutofthebox.FacetinginSphinxtakesmorework.
Solr默认有facet支持。而Shphinx中就得做一些额外的工作才行
Sphinxdoesn'tallowpartialindexupdatesforfielddata.
Sphinx不支持针对fielddata的partialindex的更新
InSphinx,alldocumentidsmustbeuniqueunsignednon-zerointegernumbers.Solrdoesn'tevenrequireanuniquekeyformanyoperations,anduniquekeyscanbeeitherintegersorstrings.
Sphinx中，所有的documentid必须是unique,unsigned,non-zero整数（估计是用C语言的名词来解释）。Solr的很多操作，甚至不需要uniquekey。而且uniquekey可以是整数，也可以是字符串。
Solrsupportsfieldcollapsing(currentlyasanadditionalpatchonly)toavoidduplicatingsimilarresults.Sphinxdoesn'tseemtoprovideanyfeaturelikethis.
Solr支持fieldcollapsing来避免相似搜索结果的重复性。Sphinx没这个功能。
WhileSphinxisdesignedtoonlyretrievedocumentids,inSolryoucandirectlygetwholedocumentswithprettymuchanykindofdata,makingitmoreindependentofanyexternaldatastoreanditsavestheextraroundtrip.
Sphinx只是查询documentid,而solr则可以查询出整个的document.
Solr,exceptwhenusedembedded,runsinaJavawebcontainersuchasTomcatorJetty,whichrequireadditionalspecificconfigurationandtuning(oryoucanusetheincludedJettyandjustlaunchitwithjava-jarstart.jar).Sphinxhasnoadditionalconfiguration.
Solr跑在javaweb容器中，例如Tomcat或Jetty.所以我们就可以进行配置和调试，优化。Sphinx则没有额外的配置选项。
http://www.wikivs.com/wiki/Lucene_vs_Sphinx
有一点比较重要：sphinx不支持liveindexupdate.支持的话也非常有限。
有一个PPT，可以增加知识：
http://www.slideshare.net/billkarwin/practical-full-text-search-with-my-sql