不知道大家有沒有想過一個問題：資料庫服務也支援全文搜尋，但我們為什麼要用全文搜尋引擎！ 如果說是全文搜尋引擎更快或者效能更好，那為什麼呢？我們都知道solr和elasticsearch都是基於Lucene的，那Lucene又是基於什麼做的全文搜尋呢？

好吧，我只是有這些疑問，閒著沒事兒，權當玩兒，翻譯兩篇文章！

本寶寶總結兩點：1，全文搜尋引擎更適用於非結構化的文字查詢；2，對於類似於Mongo這種document型資料庫，全文搜尋引擎勝在對索引的維護

正文一：全文搜尋引擎 VS 資料庫管理系統

很多資料庫使用者經常在想：究竟是哪些內容，是一個數據庫不能做到，而一個全文搜尋引擎能做到的。畢竟，大多數資料庫都提供了基於文字的搜尋，即使這似乎有一些馬後炮的嫌疑。  但在同時，很多搜尋引擎提供了一些功能，比如：儲存和一些邏輯操作。 那麼，作為使用者究竟該如何做決定呢？ 在這篇文章裡，Marc Krellenstein 對比資料庫，給出了全文搜尋引擎的優勢。

簡介

全文搜尋引擎可以做什麼

全文搜尋引擎勝在快速和高效的查詢大批量非結構化的文字—文件或者其他包好自由結構文字的記錄，並且返回這些基於用於搜尋匹配的結果文件，他們可以根據具體的數值或者欄位去進行快速高效的排序、分類等。一個系統的 全文搜尋功能應該是豐富並且靈活的，並且還需要支援基本關鍵字的查詢：網際網路式+/-語法，布林運算子的使用，有限的真實或偽自然語言處理，鄰近操作，查詢類似等。關聯排序功能定義了一個查詢操作的最好匹配結果。在資料庫中，他們通常會作為一個整體：文件中鄰近的查詢術語的接近度，特定術語，欄位或文件的特殊權重等等。

這些傳統的文件通常只有一種型別或者結構。這種結構通常由主要的自由結構文字欄位（例如，文件的主體或產品的主要描述），附加的輔助自由結構文字欄位（例如，標題或摘要）和一些非文字或 更多約束的文字欄位（例如，出版日期，大小，價格，產品程式碼等）。 將主文字欄位稱為主要資料或文字以及與其相關的其他欄位（標題，價格等）通常是作為元資料。 然而，這些檔案或記錄 - 這些術語可以互換使用來指代全文搜尋系統中的單個索引“專案” - 也可以被視為簡單的欄位連線。 任何數量的這些欄位可以是自由結構文字，並且它們中的任何一個可以是非文字或更多約束的文字資料（例如，一些數量的商品程式碼之一）

全文搜尋系統通常採用這些資料索引和搜尋的檢視：每個文件/記錄只是欄位的集合。 給定的搜尋總是針對單個欄位或某些欄位的組合執行，儘管終端使用者可能不知道這一點，特別是如果預設是一起搜尋所有欄位。

全文搜尋系統通常依賴某些型別的索引來執行查詢。 最常見的是反向索引，它有效地列出了每個文件中的每個術語 - 每個單詞，數字等 - 以及哪些文件包含該術語的指示（以及如果搜尋短語或其他鄰近操作被支援的位置） 他們通常是這樣）。 每個欄位可能有一個單獨的索引，或者所有欄位可以包含在單個索引中。 在給定的文件中，一個或多個欄位可能沒有價值。 然而，所有文件的結構是相同的，因為給定全文索引的所有文件的可能欄位集合是相同的。 全文搜尋系統通常包含處理非文字欄位的一些功能，例如範圍搜尋，按任何欄位排序結果的能力等。但是這些功能並不像關係資料庫那麼強大。

搜尋結果將來自一組具有一組欄位的索引文件。該集合可能是許多來源和許多型別的文件的彙總。為索引定義的一組欄位將需要包括從任何文件來源搜尋的所有欄位。這可能意味著某些資訊需要重複某些欄位，例如，如果城市欄位是波士頓，還需要儲存或搜尋狀態資訊，州將需要是馬薩諸塞州每個城市波士頓的記錄。在“歸一化”的關係資料庫中，波士頓在馬薩諸塞州的事實只會儲存一次。一些全文系統可以提供一些有效“連線”不同型別的資料的能力，從而最小化這種冗餘。這可以通過附加的特殊索引結構，通過預定義的“過濾器”查詢來完成，該查詢保留關於常見查詢約束的資訊（有效地加入具有儲存查詢的查詢）或通過多遍搜尋技術。這些多記錄型別的功能不像在關係資料庫中一樣豐富或直截了當。

除索引資料之外，大多數現代全文搜尋系統（包括Lucene / Solr）可讓您實際儲存和檢索其原始形式的資料。他們這樣做的一個原因是能夠輕鬆地填充具有實際資料的搜尋結果列表。檔案的標題或摘要 - 以便更容易檢視哪些文件最相關並值得開放以進行全面稽核。所選檔案/記錄通常從原始位置開始開啟，但也可以將整個文件/記錄儲存在搜尋系統中，並從系統內檢視。現代全文搜尋系統還支援增量索引，包括新增，刪除或更新記錄的能力。儘管如此，全文系統在快速安全地處理事務更新的能力上有所限制。這部分是因為文字搜尋的全文系統的速度和規模優勢很好地歸功於複雜的索引壓縮，以表示在數百萬個特定文件中可能出現給定的單詞。這種壓縮限制了選擇性索引更新的能力。然而，一些全文搜尋引擎通常在基於記憶體的索引分割槽中支援近實時更新，後者在後臺的某個時刻將其轉換為更充分的基於磁碟的索引。

全文搜尋系統的最優功能可以歸納如下：

1，子秒搜尋結果指出哪些檔案可能在數百萬或數十億的使用者搜尋中包含一個或多個術語（單詞，數字等）。 這包括對所有文字欄位的良好搜尋，以及搜尋非文字資料的功能有限。 這還可以包括基於特定領域的具體值的有效內容或搜尋結果的分類或搜尋結果。 

2，豐富靈活的文字查詢工具和複雜的排名功能，以找到最好的文件/記錄。 

3，新增，刪除或更新文件/記錄的基本功能。

4，儲存資料的基本功能（而不是簡單的索引和搜尋）。 並不是所有的全文搜尋系統都支援這種功能，但大多數都包括Lucene / Solr。 

5，搜尋和操縱實際表示不同記錄型別的資料的功能有限。

什麼時候使用全文搜尋引擎

可能建議在關係資料庫中選擇全文搜尋系統的應用程式要求是與全文搜尋系統的上述優點和限制相對應的應用要求：

1，大量的自由結構的文字資料（或包含此類資料的記錄）要搜尋或 方面/分類 - 數十萬或數百萬個檔案/記錄（或更多）。

2， 支援大量基於互動式文字的查詢。 

3，需求非常靈活的全文搜尋查詢。 

4，對高度相關的搜尋結果的需求未被可用的關係資料庫所滿足。

5， 對不同記錄型別，非文字資料操作或安全事務處理的需求相對較少。

該列表首先提供了選擇全文搜尋系統的一些原因，或者遷移關係資料庫應用程式的部分或全部。這種資料庫應用程式在應用程式開始時可能已經足夠了，但由於資料增加，使用者數量或搜尋請求的型別，現在具有一個或另一個性能或有效性問題。移動到全文搜尋系統的許多人實際上只是在尋找其非結構化內容的情況下發現自己。在某些情況下，這是因為關係資料庫的原始選擇因為應用程式的真正“關係”（多表）或“資料庫管理”（事務處理）要求而減少，而只是因為需要持久儲存資料和資料庫似乎是一個自然的選擇，可用。資料庫技能的提供和缺乏全文搜尋技能也可能是一個原因。但是，雖然資料庫可能已經足夠一段時間的全文搜尋需求，但它正在支援，環境的變化或僅僅是對更好的文字搜尋的需求，現在激勵使用者尋找更好的解決方案。

即使資料庫中存在多個記錄型別，一旦資料平坦化，全文字搜尋系統仍然可能是更有效的工具，即來自不同表格的記錄被組合成適合全文的單個更長記錄格式 搜尋引擎。 只要沒有大量的表組成要搜尋的資料，並且前提是多表記錄操縱（和複雜的事務處理）不是應用程式的關鍵元件，這通常是有效的。 許多關係資料庫應用程式屬於這一類別，只有一個或幾個表格和有限的豐富的事務處理或恢復的需求。 （事實上，如果真正的DBMS需求足夠小，那麼即使全文搜尋需求不顯著，搜尋引擎也可能會更快，但功能上更為充分。

在某些情況下，由於應用程式需求，資料將需要保留在關係資料庫中，但資料庫提供的全文搜尋在某些方面是不夠的。 在這些情況下，資料可能會匯出到文本系統中，以進行全文索引和搜尋，兩個系統一起使用。 這樣的出口可能是相對靜態的（例如，夜間過程）或更加動態 - 資料在飛行中提取和/或更快地被索引，或許是實時的。 最好的全文搜尋系統提供了一種機制，可以將關係資料庫中的表格資料輕鬆對映到全文系統的索引欄位。

總結

全文搜尋系統擅長高速搜尋和大量資料的分析。 它們在處理多記錄型別或事務處理方面不如關係資料庫那麼強大，但在許多情況下它們可能適合這些需求。 一些DBMS應用程式真的在那裡，因為方便，而不是因為他們要求關係型資料庫管理系統的功能。 如果DBMS不再滿足應用程式的需要，這些應用程式可以成功遷移到全文搜尋系統。 其他應用程式可以部分遷移到全文搜尋系統，以支援全文搜尋需求，或者可以將資料索引到兩者中以提供每種優點。

---------------------------機翻結束，懶是一種病，得治---------------------------------------

正文二：Elasticsearch—高效能全文搜尋引擎

一般而言，在我們的腦子裡會很快的浮現出一個疑問：在這種場景下，哪一種全文搜尋方案是效能最優的呢？

閱讀這篇短文，看看我們是怎麼回答這個問題的！

大部分的開發人員會學習到幾個好的解決方案，這些解決方案可以高效的處理百萬級別的全文搜尋：

MongoDB，使用自定義功能、mysql、postgreSQL、Elasticsearch

所有這些都是可靠的資料管理系統，但是，當我們在選擇一個最好的全文搜尋方案時，我們仍然需要考慮2個點。第一：SQL 全文搜尋對於設定索引和查詢來說，相當簡單。但是，這裡有幾個缺陷：

1，我們幾乎無法控制索引

2，在特定的索引、詞法、內容方面，我們幾乎無能為力

3，搜尋將會執行在DBMS伺服器，而這通常是我們最無力擴充套件的基礎設施

第二：我們知道，在前期，Elasticsearch需要做更多的工作，因為我們需要設定並且維護分散式叢集節點。我們也需要提供程式碼去控制我們的索引——這也可能是一個有計劃的工作：根據更改後的日誌（處理新的/更改的資料），去構建用於索引的片段。與SQL一樣，我們還需要花費時間來構建查詢。 但是，我們擁有一個巨大的驚喜，這個驚喜是來源於我們對於Elasticsearch所做的一切努力：

1，精確控制我們的索引和查詢

2，完美的可擴充套件性，因為我們可以提供我們需要的叢集節點

3，本地文件、索引訪問

現在，我們讓你進入一個“祕密”。與SQL系統相反，使用Elasticsearch，完全不需要修改資料的本地形式（或執行初步對映）來適應查詢的結構。

很多應用的資料層，一個很重要緊急的開發工作就是去設計關於資料恢復的方法。在Elasticsearch裡面，這仍然是一件極其重要的工作，但是，這也正是其精妙所在：我們可以讓資料在本地（源文件），並且根據這些本地資料建立索引。然後，我們可以配置Elasticsearch去匹配這些在源文件的資料。這樣做的優勢是：我們不需要去建立一些額外的欄位去繫結文件。

至此，有人可能會說：“但是，我依然沒有發現Elasticsearch有什麼吸引人的，我還是喜歡用DBMS” 是的，我們曾經也這樣認為。

可能你也正在尋找其他的應用場景去增長自信，但是，請思考：我們的一些在Qbox的職工通常會活躍在StackOverflow.com。我們也瞭解到，Stack Overflow是建立在SQL 全文搜尋的平臺上的。 伴隨著Stack Overflow平臺的發展，當功能和效能成為主要的限制時，他們也從SQL 全文搜尋變成了Elasticsearch。

我們可以很有信心的說，這是值得的。是的，我們必須進行額外的初始配置工作。但是，當我們考慮使用Elasticsearch在大資料集上返回Sub-Second響應的總體工作量和成本時，這是SQL資料庫或Mongo解決方案所需的總體工作量的很小一部分。對於SQL系統，需要在資料儲存之外執行如此多的預處理才能使資料可搜尋。使用這些傳統系統，實現Elasticsearch提供的效能和查詢靈活性的平衡將是一個巨大的挑戰。