處理Solr中

大量的id我需要執行的Solr即用戶需要查找的用戶與特定的標準是在線列表在線搜索。處理Solr中

如何我處理這樣的：我們的用戶的ID存儲在表中，我送Solr中要求所有的在線用戶ID喜歡

&fq=-id:(id1 id2 id3 ............id5000)

這種方法的問題是，當IDS變大，Solr的需要花費太多時間才能解決，我們需要通過網絡傳輸大量請求。

一種解決方案可以使用Solr的，但網上的數據變化定期參加的，我不能索引數據，每次（比如5-10分鐘，這應該是 - 至少一個小時）。

其他解決方案，我認爲基於URL中的某些參數從Solr的內部射擊這個查詢。我對Solr內部知識並不瞭解，所以不知道如何繼續。

來源

2013-05-01 chicharito

這是大多數solr用戶的問題，我想他們在solr4.0中沒有做任何事情。在這裏你需要一位java專家或solr內部專家 – 2013-05-01 09:03:15

隨着Solr4的軟提交，提交已經變得足夠便宜，實際上可以將「在線」標記直接存儲在用戶記錄中，並且在您的查詢中只有& fq = online：true。這降低了參與5000點發送的ID通過電線和分析他們的開銷，並讓Solr的優化查詢了一下。無論何時登錄或註銷，請設置其狀態並在更新中設置commitWithin。無論如何，這是值得的。

來源

2013-05-05 17:49:18 samkass

我也會先試試這個，因爲它比實現PostFilter更容易，並且保持與當前在線用戶最新的某種memcache。有關NearRealtimeSearch的更多詳細信息可以在Solr的Wiki http://wiki.apache.org/solr/NearRealtimeSearch中找到。但是如果這樣做不成功，我會按照lexk和Asaf描述的方式進行操作。 – cheffe 2013-05-06 15:31:59

我不認爲這將是一個想法的解決方案，因爲我已經提到索引是不可能的，它通常需要15-30分鐘 – chicharito 2013-05-06 15:52:56

你不應該根據這個想法重新創建整個索引。您也可以更新單個實體。在你的情況下，如果用戶只登錄他的用戶記錄 - 他的單個記錄 - 被更新。爲此，您可以發送例如json或xml更新請求到您的solr服務器。有關參考資料，請參閱http://yonik.com/solr/atomic-updates/或http://wiki.apache.org/solr/UpdateJSON或http://solr.pl/en/2012/07/09/solr-4-0-partial-documents-update/ – cheffe 2013-05-07 04:22:42

任何強大的解決方案將包括把接近SOLR（批）您的數據並在內部使用它。在搜索期間不會運行非常大的請求，這是低延遲的事情。你應該開發你自己的過濾器;過濾器會暫時緩存在線用戶數據（比如每分鐘）。如果數據非常頻繁地更改，請考慮實施PostFilter。

您可以在這裏找到濾波器實現的一個很好的例子： http://searchhub.org/2012/02/22/custom-security-filtering-in-solr/

來源

2013-05-06 05:56:01 lexk

如何創建自己的過濾器，這是我正在尋找的解決方案，但不知道如何創建自己的過濾器 – chicharito 2013-05-06 15:54:12

另外我怎樣才能連接mysql從該過濾器，因爲我是一個PHP開發人員，不知道如何使用php – chicharito 2013-05-06 16:56:57

我添加了一個鏈接來過濾實施示例。 – lexk 2013-05-06 17:40:54

我們合作解決此問題通過實現數據的分片。

基本上不打算大舉進軍代碼細節：

寫自己的索引代碼
- 使用consistent hashing決定哪個ID去到Solr的服務器
- 指數每個用戶數據到相關的碎片（它可以是幾臺機器）
- 確保你有冗餘
查詢Solr的碎片
- 使用shards參數
- 啓動EmbeddedSolr做碎片化查詢Solr中，並用它做一個分片查詢
- 的Solr將查詢所有的碎片和合並的結果，它也提供了超時，如果你需要限制查詢時間爲每個碎片

即使所有上面我所說的，我不相信Solr的是一個非常適合這種。Solr並不適合在不斷變化的索引上進行搜索，而且如果您主要按ID進行搜索，則不需要搜索引擎。

對於我們的項目，我們基本上實現了所有索引構建，負載平衡和查詢引擎，並且主要將Solr用作存儲。但是當分片是flaky而不是高性能時，我們開始使用Solr，我不確定它今天的狀態。最後需要注意的是，如果我從頭開始構建這個系統，但沒有我們在過去4年中所做的所有工作，我會建議使用緩存來存儲當前在線的所有用戶（比如說memcached或redis）和請求時間我會簡單地遍歷所有這些並根據條件篩選出來。按標準過濾可以獨立緩存並逐步更新，如果匹配邏輯非常簡單，對5000條記錄進行迭代不一定非常耗時。

來源

2013-05-06 09:14:40 Asaf

一種解決方案可以是使用Solr中加入的，但是在線數據定期更改和我不能索引數據每次（比方說5-10分鐘，它應該是在-至少一個小時）

我認爲你可以很好地使用Solr加入，但是在一點即興之後。

解決方案，我建議如下：

You can have 2 Indexes (Solr Cores) 

1. Primary Index (The one you have now) 
2. Secondary Index with only two fields , "ID" and "IS_ONLINE"

現在，您可以更新頻繁的二級索引（以秒級），並與你的表保持同步，用於存儲在線用戶。

注意：即使經常更新這種二次指數，不會降低提供我們做一些必要的調整像增量導入過程中適當的查詢使用任何性能等

您現在可以在ID進行Solr join這兩個索引字段來實現你想要的。以下是關於如何在索引/ Solr內核之間執行Solr連接的link。

來源

2013-05-07 05:57:11 Mavellin

回答

相關問題