基于文本聚類的垂直搜索引擎系統(tǒng)設(shè)計(jì)與實(shí)現(xiàn)
發(fā)布時間：2021-03-10 03:56
隨著互聯(lián)網(wǎng)數(shù)據(jù)的快速增長,垂直搜索引擎也迅速發(fā)展起來。但是目前垂直搜索引擎仍然不能幫助用戶快速找到自己尋求的目標(biāo),只能通過輸入關(guān)鍵詞之后,對返回的結(jié)果集進(jìn)行人工排查。特別是在關(guān)鍵詞具有多重含義時,這種狀況尤其明顯。為了解決上述問題,本文提出了在文本預(yù)處理階段對數(shù)據(jù)集中的數(shù)據(jù)進(jìn)行聚類處理,并將聚類的結(jié)果用于以下三方面:第一個方面是將聚類的結(jié)果放入對應(yīng)的原始數(shù)據(jù)中,同時提高該聚類結(jié)果的權(quán)重,使得所屬聚類結(jié)果與關(guān)鍵詞相關(guān)度更高的文章位于前列。第二個方面是可以將聚類的結(jié)果通過搜索頁面的分類導(dǎo)航欄呈現(xiàn)給用戶,使得用戶能夠根據(jù)聚類結(jié)果,進(jìn)行相關(guān)篩選,更快找到自己需要的內(nèi)容。第三個方面,由于聚類結(jié)果的不穩(wěn)定性,本文提出了由系統(tǒng)人員參考聚類結(jié)果,并定義分類規(guī)則的方法,然后利用搜索引擎和分類規(guī)則對文本自動分類。為了適應(yīng)不同領(lǐng)域的數(shù)據(jù)特性,本文設(shè)計(jì)了企業(yè)數(shù)據(jù)管理與垂直搜索系統(tǒng),該系統(tǒng)針對不同領(lǐng)域的數(shù)據(jù)和不同行業(yè)的需求,輔助該領(lǐng)域人員定制自己的搜索引擎系統(tǒng),從而幫助搜索引擎更好地“理解”數(shù)據(jù)。本文主要工作如下:第一,提出了改進(jìn)的tf-idf算法與k-mean結(jié)合的聚類算法。為了體現(xiàn)位于文章中不同位置的詞對該...
【文章來源】：北京工業(yè)大學(xué)北京市 211工程院校
【文章頁數(shù)】：66 頁
【學(xué)位級別】：碩士
【部分圖文】：
垂直搜索引擎構(gòu)造Fig.2-1Thearchitectureofverticalsearchengine⑵索引模塊：根據(jù)需求建立分詞的詞庫，本文包括中文分詞詞庫與英文分
己的實(shí)際需求自定義 Solr 應(yīng)用。這些配置文件基本上都為 xml 格式，所以用戶可以選擇直接手動修改配置文件，或者使用 Solr 提供的 API 對配置文件進(jìn)行修改。本文主要使用的是 manage-schema.xml 來進(jìn)行自定義配置。Manage-schema 是控制 Solr 索引規(guī)范的配置文件。manage-schema 使用字段（fields）的集合來表示一篇文檔（document），用戶需要在里面定義字段類型（fieldtype）和字段本身的屬性。字段類型的定義，是索引時 Solr 對索引文章的字段處理，和查詢（query）時 Solr 對于關(guān)鍵詞的處理。一個字段類型包括以下 4 個屬性：字段類型的名稱（必須包含）；一個必要的該字段類型的實(shí)現(xiàn)類（implementclass）；如果該字段類型為“TextField”，那么就需要配置該字段類型對應(yīng)的分析器（analyzer）；根據(jù)選用的實(shí)現(xiàn)類，配置該實(shí)現(xiàn)類對應(yīng)的屬性。2.2.2 Solr 搜索過程Solr 搜索整體時序圖如圖 2-2 所示：
圖 2-3 SolrCloud 體系結(jié)構(gòu)Fig.2-3 The architecture of SolrCloud實(shí)線連接部分為 SolrCloud 的物理結(jié)構(gòu)，虛線連接部分為邏輯結(jié)構(gòu)。各部分詳細(xì)介紹如下：Collection：Collection 是 SolrCloud 邏輯意義上完整的索引,產(chǎn)品邏輯上可以理解為一個數(shù)據(jù)集，一個 SolrCloud 集群可以有多個 Collection。Shard：Shard 是 Collection 中的邏輯分片，一個 Collection 包含多個 Shard，每一個 Shard 包含 Collection 的一部分文檔，具體每個 Shard 包含那些文檔，包含多少文檔，由 Collection 的分片策略所決定。Shard 的數(shù)量控制著 Collection 理論上能包含的文檔數(shù)量和單個搜索請求可能的并行量。Leader：活躍狀態(tài)（active）的 Replica。每個 Shard 有多個 Replicas，但是一般只有一個 Replica 會處在活躍狀態(tài)，其他的位于備用狀態(tài)，而活躍的 Replica 就是被選舉出來的 Leader。Leader 的選舉初始化時是先來先得的方式，后續(xù)會根據(jù)Zookeeper 的規(guī)則進(jìn)行選舉。如果一個 Leader 故障了，其他 Replica 中的一個會被自動選為新的 Leader。當(dāng)文檔被發(fā)送到 Solr 節(jié)點(diǎn)進(jìn)行索引時，系統(tǒng)首先確定
本文編號：3074013
【文章來源】：北京工業(yè)大學(xué)北京市 211工程院校
【文章頁數(shù)】：66 頁
【學(xué)位級別】：碩士
【部分圖文】：
垂直搜索引擎構(gòu)造Fig.2-1Thearchitectureofverticalsearchengine⑵索引模塊：根據(jù)需求建立分詞的詞庫，本文包括中文分詞詞庫與英文分
己的實(shí)際需求自定義 Solr 應(yīng)用。這些配置文件基本上都為 xml 格式，所以用戶可以選擇直接手動修改配置文件，或者使用 Solr 提供的 API 對配置文件進(jìn)行修改。本文主要使用的是 manage-schema.xml 來進(jìn)行自定義配置。Manage-schema 是控制 Solr 索引規(guī)范的配置文件。manage-schema 使用字段（fields）的集合來表示一篇文檔（document），用戶需要在里面定義字段類型（fieldtype）和字段本身的屬性。字段類型的定義，是索引時 Solr 對索引文章的字段處理，和查詢（query）時 Solr 對于關(guān)鍵詞的處理。一個字段類型包括以下 4 個屬性：字段類型的名稱（必須包含）；一個必要的該字段類型的實(shí)現(xiàn)類（implementclass）；如果該字段類型為“TextField”，那么就需要配置該字段類型對應(yīng)的分析器（analyzer）；根據(jù)選用的實(shí)現(xiàn)類，配置該實(shí)現(xiàn)類對應(yīng)的屬性。2.2.2 Solr 搜索過程Solr 搜索整體時序圖如圖 2-2 所示：
圖 2-3 SolrCloud 體系結(jié)構(gòu)Fig.2-3 The architecture of SolrCloud實(shí)線連接部分為 SolrCloud 的物理結(jié)構(gòu)，虛線連接部分為邏輯結(jié)構(gòu)。各部分詳細(xì)介紹如下：Collection：Collection 是 SolrCloud 邏輯意義上完整的索引,產(chǎn)品邏輯上可以理解為一個數(shù)據(jù)集，一個 SolrCloud 集群可以有多個 Collection。Shard：Shard 是 Collection 中的邏輯分片，一個 Collection 包含多個 Shard，每一個 Shard 包含 Collection 的一部分文檔，具體每個 Shard 包含那些文檔，包含多少文檔，由 Collection 的分片策略所決定。Shard 的數(shù)量控制著 Collection 理論上能包含的文檔數(shù)量和單個搜索請求可能的并行量。Leader：活躍狀態(tài)（active）的 Replica。每個 Shard 有多個 Replicas，但是一般只有一個 Replica 會處在活躍狀態(tài)，其他的位于備用狀態(tài)，而活躍的 Replica 就是被選舉出來的 Leader。Leader 的選舉初始化時是先來先得的方式，后續(xù)會根據(jù)Zookeeper 的規(guī)則進(jìn)行選舉。如果一個 Leader 故障了，其他 Replica 中的一個會被自動選為新的 Leader。當(dāng)文檔被發(fā)送到 Solr 節(jié)點(diǎn)進(jìn)行索引時，系統(tǒng)首先確定
本文編號：3074013
本文鏈接：http://www.sikaile.net/kejilunwen/shengwushengchang/3074013.html
最近更新
教材專著
