當我意識到我的Zend Lucene實現的一個主要缺點時,我正在開發一個應用程序使用Symfony 1.4和Doctrine。與Zend Lucene和相關模型(與外鍵)Symfony
我有一個叫做出版物的模型,與其他一些模型(主題,流派,語言,作者等)相關(通過外鍵關係),我在添加新文檔時得到它們的名稱到索引(使用Jobeet教程方式),以便我可以搜索具有給定主題,流派,語言,作者等的出版物......問題是如果由於某種原因,我決定更改其中一個相關名稱模型的Zend Lucene索引不會得到更新。
僅有的兩個解決方案,我能想出是:
重建索引所有的定期出版物,以保證對相關模型所做的任何更改大幹快上的索引更新(但是這個解決方案沒有按」允許索引實時更新)
獲取與給定模型相關的所有出版物,並在更新後重新編制索引(使用save(),postSave(),postUpdate()或者你可以在Doctrine上找到的東西)。 - >這個解決方案看起來很棒......它只會重建鏈接到更新模型的出版物的索引嗎?那麼,如果你有幾千(1000)個與其鏈接的出版物需要幾分鐘更新(是的,我測試了它),並且在用戶表單上,它會超時,因爲它需要超過30秒(並且即使它不是'如果用戶在屏幕上等待頁面完成加載幾分鐘,這將會很糟糕)。
所以我想知道的是,如果有另一種解決方案?有沒有辦法根據相關模型的變化即時更新索引而無需掛上整個pahe?也許把任務放在後臺運行?有沒有這樣的方式?
如果沒有辦法使用Lucene做,這是有什麼辦法可以使用全文搜索與MySQL(和InnoDB表),而不使用Zend Lucene的不具有這樣的缺點?如果有這樣一個工具,我會鄙視重構我的代碼以適應不同的庫。
你能幫我解決嗎?提前致謝!
據我所知,Zend_Search_Lucene不再更新。當你遇到大型索引(10k +文檔)時,它的表現也很糟糕。請記住,Zend Lucene是一個真正的Lucene的php端口。獅身人面像或solr(建立在原始lucene庫上的solr)將大大提高性能並提供更好的結果。 – benlumley 2010-10-10 14:35:15
就我所知,Zend_Search_Lucene仍然與Zend Framework的其餘部分一起維護。但是我同意Apache所做的原始Java實現更快(主要是因爲即使它不是機器代碼,Java比在運行時解釋的PHP更快)。 另外Solr是Lucene的獨立服務器,因此它比在自己的應用程序中運行它更快。 Finnaly Sphinx是一個用C/C++編寫的無關項目,使其非常快速(並且可以使用綁定和其他語言使用)。 – petersaints 2010-10-15 00:08:30