問(wèn)題描述
我正在構(gòu)建一個(gè) Django 站點(diǎn)，我正在尋找一個(gè)搜索引擎.
I'm building a Django site and I am looking for a search engine.
一些候選人:
Lucene/Lucene with Compass/Solr
Lucene/Lucene with Compass/Solr
獅身人面像
Postgresql 內(nèi)置全文搜索
Postgresql built-in full text search
MySQl 內(nèi)置全文搜索
MySQl built-in full text search
選擇標(biāo)準(zhǔn):
- 結(jié)果相關(guān)性和排名
- 搜索和索引速度
- 易于使用且易于與 Django 集成
- 資源要求 - 網(wǎng)站將托管在 VPS 上，因此理想情況下，搜索引擎不會(huì)t 需要大量 RAM 和 CPU
- 可擴(kuò)展性
- 額外功能，例如您的意思是?"、相關(guān)搜索等
- result relevance and ranking
- searching and indexing speed
- ease of use and ease of integration with Django
- resource requirements - site will be hosted on a VPS, so ideally the search engine wouldn't require a lot of RAM and CPU
- scalability
- extra features such as "did you mean?", related searches, etc
任何使用過(guò)上述搜索引擎或不在列表中的其他引擎的人 -- 我很想聽(tīng)聽(tīng)您的意見(jiàn).
Anyone who has had experience with the search engines above, or other engines not in the list -- I would love to hear your opinions.
至于索引需求，隨著用戶不斷向站點(diǎn)輸入數(shù)據(jù)，這些數(shù)據(jù)需要不斷地被索引.它不一定是實(shí)時(shí)的，但理想情況下，新數(shù)據(jù)會(huì)出現(xiàn)在索引中，延遲不超過(guò) 15 - 30 分鐘
As for indexing needs, as users keep entering data into the site, those data would need to be indexed continuously. It doesn't have to be real time, but ideally new data would show up in index with no more than 15 - 30 minutes delay
推薦答案
很高興看到有人對(duì) Lucene 表示贊同 - 因?yàn)槲也恢肋@一點(diǎn).
Good to see someone's chimed in about Lucene - because I've no idea about that.
Sphinx，另一方面，我很清楚，所以讓我們看看是否能幫上忙.
Sphinx, on the other hand, I know quite well, so let's see if I can be of some help.
- 結(jié)果相關(guān)性排名是默認(rèn)設(shè)置.您可以根據(jù)需要設(shè)置自己的排序，并為特定字段賦予更高的權(quán)重.
- 索引速度非常快，因?yàn)樗苯优c數(shù)據(jù)庫(kù)對(duì)話.任何緩慢都來(lái)自復(fù)雜的 SQL 查詢和未索引的外鍵以及其他此類問(wèn)題.我也從未發(fā)現(xiàn)搜索有任何緩慢.
- 我是一個(gè) Rails 人，所以我不知道用 Django 實(shí)現(xiàn)它有多么容易.不過(guò)，Sphinx 源代碼附帶了一個(gè) Python API.
- 搜索服務(wù)守護(hù)進(jìn)程 (searchd) 的內(nèi)存使用量非常低 - 您可以對(duì) 索引器進(jìn)程也使用了多少內(nèi)存.
- 可擴(kuò)展性是我的知識(shí)比較粗略的地方 - 但是將索引文件復(fù)制到多臺(tái)機(jī)器并運(yùn)行多個(gè) searchd 守護(hù)程序很容易.不過(guò)，我從其他人那里得到的總體印象是，它在高負(fù)載下非常好，因此不需要在多臺(tái)機(jī)器上擴(kuò)展它.
- 不支持did-you-mean"等 - 盡管這些可以很容易地用其他工具完成.Sphinx 確實(shí)使用字典進(jìn)行詞干，因此駕駛"和駕駛"(例如)在搜索中會(huì)被視為相同.
- Sphinx 不允許字段數(shù)據(jù)的部分索引更新.對(duì)此的常用方法是維護(hù)包含所有最近更改的 delta 索引，并在每次更改后重新索引(這些新結(jié)果會(huì)在一兩秒內(nèi)出現(xiàn)).由于數(shù)據(jù)量很小，這可能需要幾秒鐘的時(shí)間.不過(guò)，您仍然需要定期重新索引主數(shù)據(jù)集(盡管頻率取決于數(shù)據(jù)的波動(dòng)性 - 每天?每小時(shí)?).不過(guò)，快速的索引速度讓這一切變得輕松自如.
我不知道這對(duì)你的情況有多適用，但是 Evan Weaver 比較了一些常見(jiàn)的 Rails 搜索選項(xiàng)(Sphinx、Ferret(Ruby 的 Lucene 端口)和 Solr)，并運(yùn)行了一些基準(zhǔn)測(cè)試.可能有用，我猜.
I've no idea how applicable to your situation this is, but Evan Weaver compared a few of the common Rails search options (Sphinx, Ferret (a port of Lucene for Ruby) and Solr), running some benchmarks. Could be useful, I guess.
我沒(méi)有研究過(guò) MySQL 全文搜索的深度，但我知道它在速度和功能方面都無(wú)法與 Sphinx、Lucene 或 Solr 競(jìng)爭(zhēng).
I've not plumbed the depths of MySQL's full-text search, but I know it doesn't compete speed-wise nor feature-wise with Sphinx, Lucene or Solr.
這篇關(guān)于全文搜索引擎對(duì)比——Lucene、Sphinx、Postgresql、MySQL?的文章就介紹到這了，希望我們推薦的答案對(duì)大家有所幫助，也希望大家多多支持html5模板網(wǎng)！