我使用Solr（SolrCloud）來索引和搜索我的推文。大約有1600萬條推文，索引大小約爲3GB。這些推文在實時搜索時會實時編入索引，以便啓用實時搜索。目前我使用lowercase字段類型作爲我的推特正文字段。對於搜索中的單個搜索詞，大約需要7秒，並且每增加一個搜索詞，搜索所需的時間就會線性增加。 3GB是爲solr進程分配的最大RAM。示例solr搜索查詢看起來像這樣提高Solr查詢速度超過1600萬條推文
tweet_body:*big* AND tweet_body:*data* AND tweet_tag:big_data
有關提高搜索速度的任何建議嗎？目前，我只運行1個包含整個推文集的分片。
查詢tweet_body:*big*預計表現不佳。尾隨通配符很容易，可以使用ReversedWildcardFilterFactory輕鬆處理前導通配符。但是，兩者都必須掃描每個文檔，而不是能夠使用索引來找到匹配的文檔。結合這兩種方法只會讓您搜索：
tweet_body:*big tweet_body:big*
這不是一回事。如果你真的必須搜索帶有前導和尾隨通配符的術語，那麼我建議你考慮將你的數據索引爲N-gram。
我以前沒有意識到這一點，但它似乎lowercase字段類型是小寫的過濾KeywordAnalyzer。這不是你想要的。這意味着整個領域被視爲一個單一的標記。適用於識別號碼等，但不適用於您希望進行全文搜索的文本。
所以是的，你需要改變它。 text_general可能是合適的。將指標正確標記化領域，你應該能夠performt他查詢你正在尋找：
tweet_body:big AND tweet_body:data AND tweet_tag:big_data
你將不得不重新索引，但沒有避免。在關鍵字字段上執行全文搜索沒有好的表現方式。
我需要在字段tweet_body中的任意位置搜索包含'big'和'data'的推文。我指定的查詢正在返回正確的結果，但時間太長，我對查詢做的任何更改都不會返回預期的結果。這可能是將該字段聲明爲「小寫」的結果。不確定是否將字段重新聲明爲「text_en」並重新索引整個事物是唯一的選擇。目前我發現查詢正在掃描所有文檔。 – user883499
是的，查詢正在掃描所有文檔（或至少所有匹配'tweet_tag：big_data'的文檔）。我已經添加了答案，解釋了爲什麼'小寫'類型會給你帶來麻煩。希望讓事情好轉一點。 – femtoRgon
嘗試使用過濾器的查詢，如查詢過濾器並聯
運行可能與經常使用（可能tweet_tag）多個碎片作爲片鍵可能的幫助。 – muruga
我不認爲這是一個碎片問題，因爲有另一個領域，我做了搜索，並返回非常快。該字段是推文句柄，它以10毫秒的速度返回。 – user883499
同意，但是當分割索引大小會減少（因爲它分散在多個碎片中）並可能會改善整體性能。另外，由於內存有限，因此索引內存不足。嘗試增加RAM，因爲整個索引可以存儲在RAM中以加快訪問速度。 – muruga