存儲分頁和排序的搜索結果

Question

我一直在實施MS Search Server 2010，到目前爲止它確實不錯。我通過他們的網絡服務做搜索查詢，但由於results不一致，所以想着緩存結果。

該網站是一個小的內部網（500名員工），所以它不應該是任何問題，但我很好奇，如果它是一個更大的網站，你會採取什麼樣的方法。

我已經用Google搜索了一下，但是還沒有真正找到具體的東西。所以，幾個問題：

• 還有什麼其他的方法？爲什麼他們更好？
• 存儲400-500行數據視圖需要多少成本？什麼尺寸是可行的？
• 你應該考慮的其他問題。

任何投入都是歡迎的。

Answer 1

您需要使用許多技術才能成功完成此項任務。

第一個，你需要某種持久層。如果您使用的是普通的舊網站，那麼用戶的會話將是最合乎邏輯的層次。如果您使用的是Web服務（意思是無會話），只是通過客戶端進行調用，那麼您仍然需要爲您的服務提供某種應用程序層（共享會話）。爲什麼？這一層將是您的數據庫結果緩存的所在。

第二個，您需要將結果緩存到您正在使用的任何容器（會話或Web服務的應用程序層）中。你可以通過幾種方法做到這一點......如果查詢是任何用戶都可以做的事情，那麼查詢的一個簡單的哈希將起作用，並且你可以在其他用戶中共享這個存儲的結果。您可能仍然需要某種結果的GUID，以便您可以在客戶端應用程序中傳遞這些GUID，但是從查詢到結果的散列查找將會很有用。如果這些查詢是唯一的，那麼您可以使用查詢結果的唯一GUID並將其傳遞給客戶端應用程序。這樣，您可以執行你的緩存功能...

緩存機制可以將某種固定長度的緩衝或排隊的......讓老的結果將被自動地清理/隨着新的添加刪除。然後，如果查詢進入緩存未命中，它將正常執行並添加到緩存中。

三，你會想一些方法來頁的結果對象...迭代器模式運作良好這裏，雖然可能更簡單的東西可能工作......像取出發點X量結果Y。然而，Iterator模式會更好，因爲如果您願意的話，稍後可以刪除您的緩存機制並直接從數據庫中進行翻頁。

第四個，您需要某種預取機制（如其他建議）。你應該啓動一個線程，將做全搜索，並在你的主線程只是做與頂級X數量項目的快速搜索。希望通過在用戶嘗試呼叫的時候，第二個線程將完成，並完整結果現在是在緩存中。如果結果沒有準備好，你可以加入一些簡單的加載屏幕邏輯。

這應該給你一些的方式...讓我知道，如果你想了解任何特定部分澄清/詳細信息。

我將離開你一些更多的技巧...

1. 您不希望將整個結果發送到客戶端應用程序（如果您使用的是Ajax或類似iPhone的應用程序）。爲什麼？那是因爲這是一個巨大的浪費。用戶可能不會瀏覽所有結果......現在，您只需發送超過2MB的結果字段即可。

2. JavaScript是一種很棒的語言，但記住它仍然是一種客戶端腳本語言......您不希望通過向您的Ajax客戶端發送大量數據來處理太多的用戶體驗。只需將您的客戶端的預取結果和附加頁面結果作爲用戶頁面發送即可。

3. 抽象抽象抽象...你想抽象出緩存，查詢，分頁，預取...儘可能多的。爲什麼？那麼可以說，你想要切換數據庫，或者你想直接從數據庫中進行分頁，而不是在緩存中使用結果對象......好吧，如果你這樣做了，那麼稍後更容易進行更改。另外，如果使用Web服務，許多其他應用程序稍後可以使用此邏輯。

現在，我可能提出了一個過度設計的解決方案，您需要:)。但是，如果您可以使用所有正確的技術來解決這個問題，那麼您將學到很多東西，並且有一個非常好的基礎，以便您可以擴展功能或重新使用此代碼。

如果您有任何疑問，請告知我。

Answer 2

我不得不承認，我不是非常熟悉MS搜索服務器所以這可能並不適用。我經常遇到這樣的情況，即應用程序必須搜索數以百萬計的記錄才能找到需要在SQL Server中進行排序，分頁和再次搜索的結果集。通常我所做的是採取兩步走的方法。首先，我抓取需要顯示的第一個「x」結果，並將它們發送到瀏覽器進行快速顯示。其次，在另一個線程上，我完成了完整的查詢並將結果移至臨時表，可以更快地存儲和檢索結果。任何給定的查詢都可能具有數千或數萬個結果，但與數億甚至數十億個總記錄相比，這個較小的子集可以很容易地從臨時表中操縱。當查詢發生時，它也減少了對其他表格的壓力。如果用戶需要第二頁記錄，或者需要對它們進行排序，或者只需要原始查詢的一個子集，則這些都是從臨時表中提取的。

然後邏輯需要到位以檢查過時的臨時表並將其刪除。這很簡單，我讓SQL Server處理該功能。最後，當原始查詢發生變化時（重要的周長變化），必須將邏輯放置到位，以便可以拉出新的數據集並將其放入新的臨時表中供進一步查詢。所有這些都相對簡單。

用戶都習慣從分裂像谷歌排名第二返回時間而這種模式給了我足夠的靈活性，以真正實現這一目標，而不需要專門的軟件和硬件，他們使用。

希望這會有所幫助。

Answer 3

添的回答是處理事情，如果你要在第二個線程和邏輯（分頁/排序/過濾）運行初始查詢的能力被應用到結果的好方法，需要在服務器上的動作.. ...否則......

如果您可以使用AJAX，則可以在頁面中調用500行結果集並對客戶端進行分頁或排序。這可能會導致一些非常有趣的功能....查看jQueryUI和Dojo的數據網格解決方案以獲得靈感！

對於真正的密集型功能，如任意正則表達式過濾器和拖放式列重新排序，您可以完全釋放服務器。

數據加載到瀏覽器全部一次，您還可以支持數據（網頁預覽等）作爲用戶「請求」他們叫....

主要問題是將您按結果返回的數據限制爲您實際用於排序和過濾器的數據。

可能性是無窮無盡的:)

Answer 4

這聽起來像搜索慢的部分是全文搜索，沒有結果的檢索。如何緩存結果資源記錄ID？另外，由於搜索查詢通常可能是重複的，因此存儲搜索查詢，查詢和匹配資源的散列。然後你可以通過ID檢索結果的下一頁。也適用於AJAX。

由於它是一個內聯網，您可以控制搜索到的資源，甚至可以在空閒時間預先計算新的或更新的資源與熱門查詢的匹配。