基于文本聚類的垂直搜索引擎系統(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
最近更新
教材專著