2009-06-27 14 views
2

假設我有一組百萬個標籤和一個需要爲這些標籤和可能新標籤解析的文本。這裏的標籤數量僅僅是一個例子來說明我的思維問題 - 太多以線性方式循環,太多以至於不能保存在內存中等等。如何在保持效果的同時自動標記文本?

不知何故,我無法想出一種低佔用空間的解決方案(並保持快速)。我意識到,人們必須期待取捨,但我認爲我忽略了一些概念。

這對於智能標記(「邁克爾傑克遜」=「藝術家」等)尤其有意思,因爲應用標記可能不是文本本身的一部分。

除了做單詞黑名單,緩存熱門標籤和巨大的sql查詢,什麼是最有效的方法來處理呢?

(夠搞笑,我有標記這個問題我自己:-))

由於我的評論空間有限,讓我在這裏補充一些想法:

  • 我同意使用整數哈希提高了速度。好主意。
  • 哈希將不會解決迭代問題(循環每個哈希/標籤,同時檢查一個單詞或字組合與標籤列表)
  • 要改進問題:假設一個像「hello world」這樣的文本。該文本有3個潛在標籤(「hello」,「world」和「hello world」)。標籤列表可能只包含「hello」,但在解析後可能會添加「world」或「hello world」,這意味着這些標籤不適用於文本。

問題:

  • 假設本書大小的文本,通過所有的組合迭代(如「九寸釘」,但讓我們假設組合限制爲4個字)的數據庫中提取,以比較它們的標籤很長一段時間,甚至假定使用整數哈希。
  • 標籤列表可能很長,因此迭代存儲的標籤也可能很慢。
  • 標籤更新將意味着對文本進行額外的全文搜索 - 取決於文本的數量和長度,這可能是一個數據庫殺手,並且效率不高?
  • 如何自動找到「相關」的新標籤? (在一篇關於音樂的文章中再次提到「Nine Inch Nails」 - 但是「發佈新歌曲」並不會成爲一個好標籤)。雖然這可能是一個問題。

回答

1

在傳入文本中散列每個單詞,並使用它來匹配要匹配的標記的散列值。您可以使用數據庫來存儲和查找哈希值,因此您不必在內存中執行它。

+0

我不明白這將如何提高效率?我仍然需要對所有哈希運算迭代,例如SELECT x FROM table WHERE hash =? - 這實際上與不使用散列(SELECT x FROM table WHERE tag =?)完全相同,似乎沒有提供任何優勢,但散列的缺點通常比平均關鍵字更長,因此會增加存儲要求和查詢權重? – Flim 2009-06-28 08:37:57

相關問題