可搜索表格 - 你會做什麼？

Question

我正在嘗試確定如何最佳設計用於快速搜索文本的存儲設施。

• 將有針對每個客戶
• 這些文件是XML不同的文件格式，字段名和屬性都不是標準的，不遵循一個模式
• 客戶有一個選項可以選擇某些字段可搜索

• 每個客戶可能有每個文件100,000條記錄。

  我正在處理這些文件並根據客戶端配置指定的列生成表。

  你會選擇什麼類型的數據庫模式，無論是SQL，還是平面文件或其他技術。

  會有很多行要搜索，我不知道怎麼走最好。

創建一個名爲SearchColumns

Id 
CustomerId 
DisplayValue 

創建一個名爲 「SearchRecords」

Id 
SearchColumnId 
SearchText 

在這種情況下表中，SearchRecords表會變得非常大，非常快表，並且因爲SearchText將會是varchar（200），所以LIKE查詢會變得非常慢。

我也考慮過SearchRecords表上的全文搜索，但是在樣本表上測試時，我並沒有像我期望的那樣得到結果。

我也考慮過每個客戶使用不同的數據庫 這將有助於短期內的表格大小，但在數月或數年後，表格大小和速度會變慢。

你會做什麼來做一個快速搜索表，這將有可能擁有數百萬條記錄？

編輯：

我拉着值，如全名，地址，並從XML文件帳號：有關數據我存儲的信息。這些字段非常小，很可能永遠不會超過200個字符。

Answer 1

我不確定我是否理解這個問題。您是否選擇了記錄存儲架構，並且需要知道如何最好地獲取其中的內容，或者是否還需要存儲架構？您是否打算將XML解析爲nText列，或只是將XML文件，標記和所有內容加載到nText列中？

一般來說，如果您在尋找性能，請在廣泛的淺表上尋找狹窄的深層桌子。窄表通常需要較少的索引來加速在最常見列上的搜索，並且這些索引允許引擎將搜索分解爲可並行化的塊。大多數發動機也足夠聰明，可以將「便宜」的過濾條件優先於「昂貴」; LIKE子句（如果存在）幾乎肯定會在複合WHERE子句中最後執行，因此如果您可以提供任何其他信息來縮小搜索範圍，尤其是在索引列上，則可以加快查詢的一般性能。

您可以考慮（我不相信我會推薦這個）主要元素數據（每個元素的開始和結束標籤之間）的關鍵問題答案模式。對於即使是模式定義的一部分都是標準化的任何情況，傳統的靜態定義表格在幾乎所有方面都會更容易處理，但如果您甚至不知道數據的結構，除了XML之外，這種方法需要在特定文件的元數據和通用字段表之間進行某種映射，並且在這種情況下，鍵問題答案將結合這兩者以獲得更好的查詢性能。

無論您具有哪種唯一標識特定記錄（和/或您需要快速搜索以便以低成本縮小結果集的數據）的信息，都將是您的關鍵，元素名稱是您的問題，價值在於您的回答。這將支持非常靈活的數據命名標準。由於數據是XML，因此相關數據可以作爲元素的屬性（開始標記的一部分）存儲，因此您可能需要類似但更簡單的表來標記可搜索屬性數據，或者可以將屬性數據標準化爲主表基於一些着名的混搭。擁有這些非常窄的每列行數還可讓您輕鬆地將未搜索的列移動到「存檔」表中;你可能仍然需要保留這些數據以防他們想開始在列上搜索，但是如果你當前不在列上搜索，你可以將它從表格中刪除，大幅縮短查詢時間。

如果您正在查找CLOB字段的近似值，那麼您根本不會擊敗LIKE查詢。是的，對於非常大的文本值會很慢;唯一可以幫助的方法是以不會導致錯誤的不匹配的方式分割文本（LIKE在跨越邊界時不會找到匹配），我認爲您不會找到通用的這樣做的方法;你必須知道你正在存儲的內容，比如它在段落中，而且一場比賽永遠不會跨越段落邊界。當所有事情都說完之後，我想你會發現，無論數據大小如何，當給定足夠的處理器能力時，大多數SQL RDBMS都可以在任何智能模式上運行得相當好。在索引上搜索是對數性質的，而不是線性的，所以一個好的索引模式將幫助引擎大大地分解搜索空間。