1. 程式人生 > 其它 >Elasticsearch全文檢索實戰小結——覆盤我帶的第二個專案

Elasticsearch全文檢索實戰小結——覆盤我帶的第二個專案

一、專案概述

這是一個被我稱之為“沒有槍、沒有炮,硬著頭皮自己造”的專案。專案是和其它公司合作的三個核心模組開發。

使用ES的目的是: 1)、採集資料、網站資料清洗後存入ES; 2)、對外提供精確檢索、萬用字元檢索、模糊檢索、分詞檢索、全文檢索介面等二次封裝介面。

二、專案架構

如上圖所示,ES作為中間層,一方面儲存資料清洗後儲存的資料,另一方面對外提供插入、更新、刪除、檢索介面的。

三、ES使用小結

3.1 ES版本選型

1.X,2.X版本有太多侷限性,5.X做了較大效能提升的改進。比如:string欄位型別分成了keyword和text兩種型別,keyword用於精確匹配,text結合設定的分詞器用於全文檢索。

選擇5.X需要勇氣,實踐證明當時“向前一小步”的正確性。

3.2 ES安裝部署

ELK都有安裝。

ES安裝了head外掛,用途:檢視叢集狀態、檢視索引資訊、檢視mapping資訊、檢視每個索引下資料資訊、進行簡單欄位查詢操作。

安裝了ik分詞外掛,用途:分詞,實現全文檢索。

安裝了Kibana,用途:資料對接展示;用DevTool替代postman執行DSL驗證,以驗證增、刪、改、查功能。

安裝了logstash,用途:藉助“logstash-input-jdbc”實現資料庫到ES之間的同步。

3.3 ES API選型與使用

調研了ES提供的原生API以及Jest等,最終選擇Jest。將Maven工程相關jar包匯出到專案中使用。

3.4 後端框架選型

play new 工程名 play eclipsify 工程名 play clean play deps play run 測試模式 play start release模式

3.5 ES分頁處理

ES Java介面能返回的預設的最大記錄數為10000行。如果想返回超過1W+條的記錄,需要做如下設定:

PUT ting_index/_settings { "max_result_window" : 500000}

3.6 如何只刪除資料,而不刪除索引

類似Mysql等關係型資料庫的delete from mtable操作,而不是drop掉表,參考如下:

POST my_store/products/_delete_by_query
{  "query": {  "match_all": {}
  }
}

參考:

https://www.elastic.co/guide/en/elasticsearch/reference/master/docs-delete-by-query.html

3.7 Jest update更新操作

資料前新增doc一層,如下所示: strJson = “{” + ” ”doc” :” + strJson + “}”;

3.8 叢集中所有節點都安裝ik分詞器

叢集裡每一個例項都要安裝ik外掛。 否則,當我們更新包含指定分詞的mapping的時候會報錯。

3.9 最大位元組數限制

報錯資訊如下:“whose UTF8 encoding is longer than the max length 32766 “, 這個問題是某個欄位size過大導致lucence不能索引引起的。 如果要儲存超過32766位元組的資料,那麼需要在mapping中設定欄位時,新增ignore_above = 256就可以了。

舉例,新增Mapping的操作如下:

POST tingindex/tingtype/_mapping
{    "tingtype":{            "properties":{                     "content":{                             "type":"text",                             "analyzer":"ik_max_word",                             "search_analyzer":"ik_max_word",                                  "fields":{                                        "keyword":{                                             "ignore_above":256,                                              "type":"keyword"
                      }
                    }
                },                    "publish_time":{                            "type":"date",                            "format":"YYYY-MM-dd HH:mm:ss"
            },                      "author":{                                 "ignore_above":256,                                "type":"keyword"
            },
        }
    }
}

參考: https://www.elastic.co/guide/en/elasticsearch/reference/5.5/ignore-above.html

3.10 出現未分派, elasticsearch叢集,在新增節點調整分片數時,出現UNASSIGNED。

排查方案: GET /_cluster/allocation/explain

3.11 kibana修改時區

kibana->management->advanced setting->dateFormat:tz, 編輯,改成GMT +0。

3.12 ES檢索(URL訪問方式)

不指定索引的全文檢索舉例: http://192.168.11.174:9200/_search?pretty&q=北京 指定索引的全文檢索舉例: http://192.168.11.174:9200/articles/articles_info/_search?pretty&q=北京 指定欄位檢索舉例: http://192.168.11.174:9200/articles/articles_info/_search?pretty&q=title:我愛北京天安門

3.13 ES高效能配置(from ES中文社群)

【1】分詞對效能的影響: 索引過程中,分詞會對索引速度有所影響,建議你可以優化一下你的mapping,不必要的就不必分詞,甚至不必設成可搜尋的了。 舉例:5.X中不必要分詞的設定為keyword型別。

【2】分片和副本對效能影響: 分片和副本的設計,應該根據節點數來調整,正常情況下 節點數= (副本數+1)*分片數,若是你希望提高搜尋效能,可是適當提高副本數。

【3】記憶體對效能的影響:

1)節點的記憶體分配的不能太少了。 ES其實很佔記憶體,大部分的操作都是建立在記憶體足夠的基礎上。 舉例:你的資料量應該在150G-200G左右,我覺得可以把記憶體調整到10G左右。

2)ES的記憶體使用分為兩部分ES快取和Lucene通過核心快取加速一些資料。

3)如果伺服器記憶體 nG > 64G,ES的記憶體儘量設定低於32G,建議最大31G.

因為es使用“記憶體指標壓縮”技術,一旦記憶體記憶體大於32G這項技術將失效,記憶體有效使用只有原來的60%~70%。

你不必為記憶體浪費而擔心,因為lucene會通過系統把一些聚合和排序的資料快取起來方便你快速查詢使用。

4)如果伺服器記憶體 nG < 64G,建議給ES分配 記憶體 (n-2)/2G. 首先2G是給系統預留,然後es和lucene。

5)如果你想繼續你的實時查詢,儘量不要使用swap(交換分割槽),建議關閉系統swap使用

【4】ES執行緒設定 執行緒數方法:執行緒數:=(核心數*3)/2+1

舉例:檢索伺服器是24核,所以:執行緒池的大小=(24*3)/2+1=37 。 參考: https://www.elastic.co/guide/en/elasticsearch/reference/current/modules-threadpool.html

四、專案整體小結

4.1、需求要細化

切記: 1)不要拿到合同或需求就開發。 2)欲速則不達。 3)需求細化後形成《需求規格說明書》,並一定郵件或電話或當面找使用者確認。 對於需求,由頂向下知道需要實現的核心功能,團隊核心敲定分幾個模組? 逐個模組細化需求點。

4.2、預研要充分

對於新的技術點,在專案啟動後的需求細化階段即可同步進行。 作為專案經理的我,沒有事必躬親,多關注預研點方案選型、預研難點、預研報告,小細節如:下載、安裝部署、引數驗證、英文翻譯安排團隊其它成員執行。

4.3、文件要跟進

需求有需求文件,設計根據專案需要和進度安排有概要設計或詳細設計文件。 設計文件千萬不能少,設計的過程就是開發“路演”的過程。 設計文件一定要梳理清楚架構圖、模組圖、資料流圖、流程圖。 需求文件是設計的基礎,需求和設計文件是開發的基礎。

4.4、思維要活躍

技術方案的選型很重要,大的方面包括:

1)檢索儲存叢集部署,叢集節點個數選擇等。 2)前後端選型,前端用jquery,jsp還是js? 後端使用spring,tomcat,還是play框架? 3)開源方案選型,要提早預研可用性、需求點覆蓋程度、二次開發或封裝難度等。 4)前後端介面對接格式敲定。 5)對外提供檢索服務介面名稱,引數敲定。

思維活躍主要體現在:

1)方案選型、技術調研快刀斬亂麻,時間緊,不糾結。此路不通,另尋他路。 2)自己不能解決,不要太拖沓,及時google,stackoverflow解決或者和架構師討論解決。

4.5、開發要同步

1)介面對接溝通要充分。 介面提供方和介面使用方,要反覆多花時間溝通業務,要定義好資料介面。 此時的耗時,事後你會發現是好事,溝通越充分要好。

2)介面對接要實時同步。 一方修改了,要第一時間告訴對方。

五、專案管理小結

5.1、多方溝通要郵件

郵件是證據,避免不必要賴賬或扯皮。 qq溝通和微信都不是好方式,最主要原因是不利於檢視聊天記錄、不利於快速檢索。

5.2、進度彙報要詳細

包含但不限於專案整體情況、本週已完成、下週計劃、專案風險與應對。

5.3、任務分工要明確

團隊成員特點不同,切記口頭分工。團隊人少,我用excel做了詳細記錄。

5.4、每週例會要及時

周例會起到承上啟下的作用,有效協調控制專案進度、團隊成員工作飽和度。

六、後記

1、ES要學習的東西非常多。不糾結,多去官網、官方論壇、stackoverflow、Google檢索答案, 相信我,你並不孤獨。

2、ES還有很長的路要走,繼續精進閱讀與思考,繼續加油!