幾種常見的基于Lucene的開源搜索解決方案對比

一  直接使用 Lucene  ( http://lucene.apache.org )

1. 說明：Lucene 是一個 JAVA 搜索類庫，它本身并不是一個完整的解決方案，需要額外的開發工作
2. 優點：成熟的解決方案，有很多的成功案例。apache 頂級項目，正在持續快速的進步。龐大而活躍的開發社區，大量的開發人員。它只是一個類庫，有足夠的定制和優化空間：經過簡單定制，就可以滿足絕大部分常見的需求；經過優化，可以支持 10億+ 量級的搜索。
3. 缺點：需要額外的開發工作。所有的擴展，分布式，可靠性等都需要自己實現；非實時，從建索引到可以搜索中間有一個時間延遲，而當前的“近實時”(Lucene Near Real Time search)搜索方案的可擴展性有待進一步完善

二  Solr  ( http://lucene.apache.org/solr/ )

1. 說明：基于 Lucene 的企業級搜索的開箱即用的解決方案
2. 優點：比較成熟的解決方案，也有很多的成功案例。Lucene 子項目，實現了大部分常見的搜索功能需求，包括 facet 搜索（搜索結果分類過濾）等。
3. 缺點：可定制性比 Lucene 要差，一些不常見的需求，定制的難度比直接在 Lucene 上做要大的多。性能上，由于 Solr 的建索引和搜索是同一個進程，耦合度比較高，對于性能調優有一定的影響。

三 Katta ( http://katta.sourceforge.net/ )

1. 說明：基于 Lucene 的，支持分布式，可擴展，具有容錯功能，準實時的搜索方案。
2. 優點：開箱即用，可以與 Hadoop 配合實現分布式。具備擴展和容錯機制。
3. 缺點：只是搜索方案，建索引部分還是需要自己實現。在搜索功能上，只實現了最基本的需求。成功案例較少，項目的成熟度稍微差一些。因為需要支持分布式，對于一些復雜的查詢需求，定制的難度會比較大。

四 Hadoop contrib/index (http://svn.apache.org/repos/asf/hadoop/mapreduce/trunk/src/contrib/index/README )

1. 說明：Map/Reduce 模式的，分布式建索引方案，可以跟 Katta 配合使用。
2. 優點：分布式建索引，具備可擴展性。
3. 缺點：只是建索引方案，不包括搜索實現。工作在批處理模式，對實時搜索的支持不佳。

五 LinkedIn 的開源方案 ( http://sna-projects.com/ )

1. 說明：基于 Lucene 的一系列解決方案，包括 準實時搜索 zoie ，facet 搜索實現 bobo，機器學習算法 decomposer ，摘要存儲庫 krati ，數據庫模式包裝 sensei 等等
2. 優點：經過驗證的解決方案，支持分布式，可擴展，豐富的功能實現
3. 缺點：與 linkedin 公司的聯系太緊密，可定制性比較差

六 ElasticSearch  ( http://www.elasticsearch.com/ )

1. 說明：基于 Lucene 的，分布式，云端，提供 rest 接口的搜索解決方案
2. 優點：開箱即用，分布式，rest 接口，支持云端調用
3. 缺點：一個新的項目，沒有經過很多的驗證。（只有一個人在開發？）分片的數目不能動態調整，只能在初始化索引的時候指定（跟 HBase 不一樣的地方）

七 Lucandra ( https://github.com/tjake/Lucandra )

1. 說明：基于 Lucene，索引存在 cassandra 數據庫中
2. 優點：參考 cassandra 的優點
3. 缺點：參考 cassandra 的缺點。另外，這只是一個 demo，沒有經過大量驗證

八 HBasene ( https://github.com/akkumar/hbasene )

1. 說明：基于 Lucene，索引存在 HBase 數據庫中
2. 優點：參考 HBase 的優點
3. 缺點：參考 HBase 的缺點。另外，在實現中，lucene terms 是存成行，但每個 term 對應的 posting lists 是以列的方式存儲的。隨著單個 term 的 posting lists 的增大，查詢時的速度受到的影響會非常大

歡迎補充！請到 幾種常見的基于Lucene的開源搜索解決方案對比 原文處參與討論。

參考材料： http://mail-archives.apache.org/mod_mbox/hbase-user/201006.mbox/%3C149150.78881.qm@web50304.mail.re2.yahoo.com%3E