在巨大的表格搜索

我得到了超過100萬行的表。此表代表用戶信息，例如用戶名，電子郵件地址，性別，婚姻狀況等。在巨大的表格搜索

我將在應用某些條件時在此表中的所有行上編寫搜索。

在簡單情況下，僅在userName上執行搜索時，需要4-7秒才能找到結果。

select from u where u.name ilike " ... "

是的，我得到了一些fileds索引。我檢查了他們是使用解釋分析命令應用的。

如何搜索可以提高？

我對Lucene有一些想法，能幫忙嗎？

我想知道Facebook的搜索工作如何，他們得到了數十億用戶，他們的搜索工作更快。

來源

2011-05-01 user12384512

其實Facebook的剛剛超過5億活躍用戶，http://www.facebook.com/press/info.php?statistics – 2011-05-01 13:41:56

目前你使用的是哪種數據庫？我會猜測PostgreSQL是使用ilike。 – 2011-05-01 15:55:54

是的，PostgreSQL – user12384512 2011-05-01 15:58:12

有這三個查詢之間的巨大差異：

a) SELECT * FROM u WHERE u.name LIKE "George%" 

b) SELECT * FROM u WHERE u.name LIKE "%George" 

c) SELECT * FROM u WHERE u.name LIKE "%George%"

一）第一個將採用指數u.name（如果有的話），並會非常快。

b）第二個將不能夠使用任何指數u.name但有辦法規避相當容易。

例如，您可以在存儲REVERSE(name)的表中添加另一個字段nameReversed。隨着該領域中的索引，查詢將被改寫爲（並會以最快的速度第一個）：

b2) SELECT * FROM u WHERE u.nameReversed LIKE REVERSE("%George")

c）第三查詢帶來的最大困難是沒有前兩次的索引將會有幫助，查詢將掃描整個表格。替代方案如下：

使用專用於此類問題的解決方案（搜索「全文搜索」），如Sphinx。看到這個問題的SO更多的細節：which-is-best-search-technique-to-search-records

如果你的領域只有名稱（或另一組有限的話，說了幾百不同的話），你可以創建另一個輔助的表，這些名字（單詞）和存儲表u中只有一個外鍵。

如果當然不是這種情況，並且您擁有數萬或數百萬個不同的單詞或者該字段包含整個短語，那麼爲了解決許多輔助表的問題，就像爲自己創建一個全文搜索工具。這是一個很好的練習，除了RDBMS之外，您不必使用Sphinx（或其他），但它不是微不足道的。

來源

2011-05-01 22:06:16

這實際上並不正確，在ILIKE中選擇與前面的％可以使用索引，我在文檔中讀取並測試自己。至少在Postgres。無論如何，我接受你的答案，因爲它是最龐大的。在這種情況下，使用Lucene或Sphinx可能是最好的解決方案。 – user12384512 2011-05-02 09:46:48

我不知道（ILIKE中的*之前的％可以使用索引*）。你能提供關於Postgres這種行爲的文檔參考嗎？ – 2011-05-02 10:32:22

對不起，你完全正確。只是檢查文件，甚至不知道爲什麼我想的是相反的。 – user12384512 2011-05-02 13:57:00

看看 Hibernate Search的 這是使用Lucene但很多更容易實現。

谷歌或Facebook正在使用不同的方法。他們有分佈式系統。谷歌BigTable是一個很好的關鍵詞，或者「Map and Reduce」概念（Apache Hadoop）是進行更多研究的一個很好的起點。

來源

2011-05-01 13:43:38 Omnaest

據我所知地圖減少不適合在線搜索。 Hadopp用於大型數據集分析，地圖縮減作業需要太多時間，並且作爲後臺任務 – user12384512 2011-05-01 13:46:42

需要索引太多，而不僅僅是搜索。而對於分佈式系統，您需要一個良好的基礎，那就是hadoop正在做的事情。但是，我確定這個問題超出了原始問題的範圍，因此我剛剛提到了它，因爲谷歌和其他大公司都有「其他」方法，這些方法在一天內不是一個簡單的解決方案。 – Omnaest 2011-05-02 14:58:17

嘗試使用表分區。在大表格場景中可能有助於分區表格。對於PostgreSQL在這裏嘗試PostgreSQL Partitioning。對於高擴展性的快速性能搜索，有時可能會採用NoSQL數據庫（如Facebook）。

來源

2011-05-01 18:53:01

我對Lucene的一些想法有幫助嗎？

是的，它可以。我相信，你會愛上它！

我有同樣的問題：一個表大約有120萬條消息。通過搜索這些消息它需要幾秒鐘。「消息」列上的全文搜索需要大約10秒。

在相同的服務器硬件lucene返回約200-400ms的結果。

速度非常快。

緩存結果大概在5-10毫秒左右返回。

Lucene能夠連接到你的SQL數據庫（例如mysql） - 掃描你的數據庫並構建一個可搜索的索引。

要搜索此索引，它取決於應用程序的種類。我的情況是，我的PHP Webaplication使用solr在lucene中搜索。 http://lucene.apache.org/solr/

來源

2011-05-02 08:19:14

在巨大的表格搜索

回答

相關問題