2012-06-07 37 views
5

我已經開始嘗試使用新的搜索API,演示運行順利,但是,仍然有一些問題我仍然對作爲搜索世界的外部人員感到困惑。澄清AppEngine搜索API的用法

首先是如何構建一個文檔。顯然,你不能將每一行硬編碼到一個文檔中,但我還能做什麼。假設我有一個用戶類(我使用的是Java,但我認爲Python在這裏沒有任何區別),我會將用戶的信息添加到文檔中,並且能夠對地址字段進行全文搜索。

class User { 
    String username; 
    String password; 
    String address; 
} 

在數據存儲區,我有10000個實例有這個實體,如果我需要建立這個文件,我必須

第1步:從數據存儲檢索10000實例

第2步:通過每個用戶實體的迭代,並創造10000個文檔

步驟3:所有的10000個文檔添加到索引,然後我就能夠搜索到

如果我上面提到的三個步驟是錯誤的,請糾正我。

如果是這樣的話,那麼以後每次新用戶註冊後,我們需要創建一個新文檔,並添加到索引?

+1

我認爲這是主意,是的... – Thilo

+0

謝謝@Thilo。在我看來,索引看起來像是關係數據庫中的手動維護映射,但每次插入/刪除/更新發生時都必須將其與數據庫同步。我知道支持全文搜索的好處,但如果這是唯一的好處,是否值得做所有這些開銷? –

+1

開銷總是伴隨着全文搜索。你需要這個索引。它能否比當前的API更自動,更具說明性,代碼密集度更低?也許。如果FTS是值得的,那麼成本取決於你自己決定。 – Thilo

回答

6

不幸的是,我還沒有玩過那麼多。我學到了一些東西。

  • 當首次實現它時,我也會創建大量文檔(如您所描述的)。但一直運行到截止日期的例外。所以我結束了upp使用任務隊列爲我的所有舊記錄構建文檔。

  • 請記住在搜索文檔和您的數據存儲實體之間創建一個交叉引用。所以你可以輕鬆地更新你的文件記錄。並從搜索結果中獲得匹配實體。

對於交叉引用您叫什麼數據存儲模型像search_document_id添加新的屬性,你存儲doc_id(我前綴我的所有DOC_ID與數據存儲型號名稱)。然後在包含實體鍵的文檔上添加一個文本字段作爲字符串。

但我想簡單地說,你是正確的。

+5

對於交叉引用,爲什麼不將文檔的doc_id設置爲實體的鍵?這樣你就不需要額外的search_document_id在你的實體上,你不需要在文檔中存儲實體鍵的文本屬性?我還沒有嘗試過,但我需要做一個這樣的交叉引用實體/文檔,我想知道爲什麼不這樣做。 – Romz

+6

我確認我的建議是有效的。 – Romz