將文檔同時存儲到雲數據存儲和搜索索引時，是否有可能在從搜索索引查詢而不是返回搜索索引文檔時，從雲數據存儲返回每個相應實體代替？換句話說，我基本上希望我的搜索查詢返回數據存儲查詢將返回的內容。將GAE搜索API與數據存儲集成
更多背景：當我在數據存儲中創建實體時，我傳遞實體標識，名稱和描述參數。建立一個搜索文檔，使其doc ID與相應的實體ID相同。目標是創建一個前端搜索實現，該實現將利用全文搜索API根據文本查詢檢索所有相關文檔。但是，我想返回存儲在數據存儲實體中的該文檔的所有詳細信息。
要做到這一點的唯一方法是爲查詢返回的每個搜索doc_id創建一個鍵，然後使用get_multi(keys)來檢索所有相關的數據存儲實體？
對此沒有一流的支持，最好的選擇是使文檔ID匹配數據存儲區密鑰，並通過單個DAO /存儲庫層路由所有put/get/search請求以確保一定程度的一致性。
您可以使用並行異步寫入來延遲等待時間，但對於不參與事務的搜索，您無能爲力。它也沒有定義的一致性，所以假設它是最終的，並且可能比數據存儲索引傳播慢得多。
如果我想擁有強大一致的數據，那麼我將不得不求助於僅使用數據存儲進行事務處理嗎？如果是這樣，那麼我是否必須創建自己的基於文本的搜索到數據存儲查詢的實現？ – yoonjesung
如果您想要強烈一致的查詢，則必須在數據存儲中使用祖先查詢。您可以自行干預並分詞，並將它們存儲在數據存儲區中，這幾乎與搜索服務所做的一樣。 – Nick
除了文本內容之外，您還可以在Search API文檔中存儲您需要的任何信息。
這將允許您在一次調用中檢索所有數據，但可能會在Search API文檔和數據存儲實體中存儲一些重複信息。顯然，重複數據並不理想，但它對於很少更改數據（例如文檔時間戳，作者ID，標題等）可能是一個很好的選擇，因爲它可以顯着提高性能。
您能否詳細介紹一下如何去存儲數據存儲鍵等對象？ Search API似乎不支持這種數據類型。我只問，因爲數據存儲中的某些值是引用其他實體的ndb KeyProperties，因此將這些類型的數據傳輸到Search API似乎不是一個可行的選項。 – yoonjesung
我更喜歡存儲實體ID而不是密鑰，因爲它們佔用的空間少得多，但如果您希望/需要存儲密鑰，則任何數據存儲區密鑰都可以轉換爲字符串，然後返回 - 這些轉換有標準方法。 –
這僅適用於某些數據 - 請記住，搜索服務僅支持日期，而不支持時間，並且數字上存在精確度和比例限制，以防止存儲許多數字，例如long。 Search API真的不適合作爲數據存儲，除非在特定情況下 - 這可能對您有用，否則它可能不會 – Nick
我猜想轉換爲純搜索文檔的替代方法是僅依賴數據存儲查詢並通過構建多個索引來重新創建全文搜索類型功能。希望有人比這些選擇更有見地的想法。 – yoonjesung
您需要對您的問題更具體，目前尚不清楚您想要回答什麼。 – danielx