Elasticsearch Workshop Session

文章目錄

Elasticsearch Workshop Session
- 一、概述
- - 1.1 什么是全文檢索？
  - 1.2 Why Elasticsearch？
  - - 1.2.1 技術選型指南
    - 1.2.2 Lucene、Solr、ES
    - 1.2.3 ES常用模式
- 二、核心概念
- - 2.1 "You Know, for Search"
- 三、實戰
- - 3.1 搭建本地環境
  - 3.2 CRUD
  - - 3.2.1 Restful的增刪查改
    - 3.2.2 Java的增刪查改
  - 3.3 復雜的查詢
  - - 3.3.1 聚合（aggregations）
    - 3.3.2 Null值查詢
    - 3.3.3 分頁查詢
- 四、踩坑記錄
- - 4.1 和`JpaRepository`混用
  - 4.2 日期格式轉換
  - 4.2 使用`Jpa`方法名決議查詢兼容性
  - 4.3 加Field并支持排序
  - 4.4 ES中的Result Window
  - 4.5 查詢條件過多
- 參考

一、概述

1.1 什么是全文檢索？

全文檢索

以下摘自百度百科：

全文資料庫是全文檢索系統的主要構成部分，所謂全文資料庫是將一個完整的資訊源的全部內容轉化為計算機可以識別、處理的資訊單元而形成的資料集合，全文資料庫不僅存盤了資訊，而且還有對全文資料進行詞、字、段落等更深層次的編輯、加工的功能，而且所有全文資料庫無一不是海量資訊資料庫，

上面只是一個空泛的概念

在實際生產環境中全文檢索隨處可見

搜索引擎（百度、必應、搜狗、Google）

站內搜索（京東、淘寶、最大同性交友網站GitHub）

還有調查bug最常打交道的Kibana，底層就是使用ES作為全文搜索引擎

與傳統資料庫的區別

試想，如果讓你做一個類似于新浪新聞的輿情網站，現在用戶有一個需求，檢索包含“大連春節放假通知”關鍵詞的所有文章，按照上傳日期倒序輸出，用傳統資料庫如何實作？

用text型別的欄位去存盤文章，然后檢索的時候用like ‘%keyword%’ 去搜索，這樣檢索效率會大打折扣

可以看出，傳統資料庫善于組織高度結構化的資料，類似于文章這一類非結構化資料，在存盤和檢索上都不具備優勢

Tip

結構化資料和非結構化資料：

是大資料中的常用概念，

結構化資料，可以從名稱中看出，是高度組織和整齊格式化的資料，它是可以放入表格和電子表格中的資料型別，它可能不是人們最容易找到的資料型別，但與非結構化資料相比，無疑是兩者中人們更容易使用的資料型別，

非結構化資料本質上是結構化資料之外的一切資料，它不符合任何預定義的模型，因此它存盤在非關系資料庫中，并使用NoSQL進行查詢，它可能是文本的或非文本的，也可能是人為的或機器生成的，簡單的說，非結構化資料就是欄位可變的的資料，

ES起源

許多年前，一個剛結婚的名叫 Shay Banon 的失業開發者，跟著他的妻子去了倫敦，他的妻子在那里學習廚師，在尋找一個賺錢的作業的時候，為了給他的妻子做一個食譜搜索引擎，他開始使用 Lucene 的一個早期版本，

直接使用 Lucene 是很難的，因此 Shay 開始做一個抽象層，Java 開發者使用它可以很簡單的給他們的程式添加搜索功能，他發布了他的第一個開源專案 Compass，

后來 Shay 獲得了一份作業，主要是高性能，分布式環境下的記憶體資料網格，這個對于高性能，實時，分布式搜索引擎的需求尤為突出，他決定重寫 Compass，把它變為一個獨立的服務并取名 Elasticsearch，

第一個公開版本在2010年2月發布，從此以后，Elasticsearch 已經成為了 Github 上最活躍的專案之一，他擁有超過300名 contributors(目前736名 contributors )，一家公司已經開始圍繞 Elasticsearch 提供商業服務，并開發新的特性，但是，Elasticsearch 將永遠開源并對所有人可用，

據說，Shay 的妻子還在等著她的食譜搜索引擎…

這個故事告訴我們什么道理？

像 Banon這樣牛X的程式員也會失業
他做食譜搜索引擎可能只是為了學習Lucene

倒排索引

為什么全文檢索ES（搜索引擎）比傳統資料庫更具優勢？

核心就是倒排索引

以下是ES官網對倒排索引的簡單介紹：

Elasticsearch 使用一種稱為 倒排索引 的結構，它適用于快速的全文搜索，一個倒排索引由檔案中所有不重復詞的串列構成，對于其中每個詞，有一個包含它的檔案串列，

倒排索引一旦被寫入磁盤后永遠都不會被修改，

這個我們會在分片章節詳細講解為什么倒排索引不可變，

官網也為我們舉了一個例子，覺得枯燥的同學也可以通過阿里云棲上的這篇漫畫來了解

分詞器也會影響到查詢的效果，英文分詞相對容易，中文分詞較難，不過市面上有很多現成的中文分詞插件可以使用

1.2 Why Elasticsearch？

現在一提到搜索引擎、全文檢索，首先想到的就是ES

相較于別的全文搜索引擎，ES的魅力在哪里？

1.2.1 技術選型指南

ES是建立在索引上全文搜索引擎，這意味著ES在全文檢索的效率上絕對是不二之選

有人常常把ES和MongoDB用來比較，但是他們的初衷是不同的

ES是提供了一個完整的、分布式的搜索引擎，全文檢索是其優勢

而MongoDB是為了取代RDBMS，被認為是最像關系型資料庫的非關系型資料庫

ES支持PB級的快速檢索！

但是ES也有它的劣勢：不支持事務、不支持復雜的關聯關系

除此之外，ES支持復雜的聚合查詢，這一特點還使得ES非常適合做資料分析使用

如果你已經有一個在運行的復雜的系統，你的需求之一是在現有系統中添加檢索服務，一種非常冒險的方式是重構系統以支持ES，而相對安全的方式是：將ES作為新的組件添加到現有系統中，

更多的應用實體我們會在后面說明

比如：你要在現有網站上加全站搜索功能，并且可能面臨著將來并發量快速增長，那么天生支持分布式的ES能讓你快速擴展出新的節點來應對日益增長的流量，但是放棄RDBMS轉向ES顯然不是一個特別明智的決定

1.2.2 Lucene、Solr、ES

在ES出現之前，都是用什么做搜索引擎？

Lucene

Lucene是Apache基金會下的一個開源專案，是一個全文檢索引擎工具包，但它并不是一個完整的全文檢索引擎，
Solr

Solr是一個高性能，采用Java開發的全文搜索服務，在Lucene的基礎上提供了更為豐富的查詢語言，同時實作了可配置、可擴展并對查詢性能進行了優化，還有一個功能完善的管理界面，是一款非常優秀的全文搜索引擎，
ES

ES和Solr一樣，都是基于Lucene開發的全文搜索服務，不同于Solr的是，它天然支持分布式，且基于RESTful介面對外提供檢索服務，

可見，ES除了基于Lucene提供的接近實時的搜索以外，易用的介面，天然的分布式支持才是在這個資料爆炸的時代快速發展并被廣泛使用的核心原因，

1.2.3 ES常用模式

整合到已有系統中作為搜索引擎，提供快速檢索、高亮檢索能力

如同上文所述，將已有的系統遷移到ES上，雖然可以解決查詢性能問題，但是risk太大，我們可以建立ES和既有RDBMS的同步機制：
- 可以是存DB的時候同步更新ES，這個方法最簡單，同步延時最低，但是代碼侵入性較高
- 也可以用ETL工具定時同步到ES，該方法較為復雜，實時性較低，但是侵入性較低，適合統計一類對時間要求不是很高的系統
- 可以通過MQ的方式異步雙寫
- MySQL可以通過讀取binlog的方式同步寫到ES，代碼侵入性較低的同時也保證了實時性
作為新聞網站資料平臺，使用ES提供的強大聚合功能構建用戶畫像和分析用戶行為（點擊，瀏覽，收藏，評論）
為開源代碼網站的代碼倉庫提供代碼搜索功能
日志資料分析，最常見的組合就是ELK
BI（Business Intelligence 商業智能）系統

二、核心概念

以下的諸多核心概念可以在ES官網找到，這里只是做一個入門的前置知識普及

2.1 “You Know, for Search”

“你知道的，為了搜索…”

這是整個ES的開篇詞，言簡意賅，ES所做的一切都是為了能夠快速檢索
以下是開篇詞的節選

Elasticsearch 是一個開源的搜索引擎，建立在一個全文搜索引擎庫 Apache Lucene? 基礎之上， Lucene 可以說是當下最先進、高性能、全功能的搜索引擎庫—無論是開源還是私有，

但是 Lucene 僅僅只是一個庫，為了充分發揮其功能，你需要使用 Java 并將 Lucene 直接集成到應用程式中，更糟糕的是，您可能需要獲得資訊檢索學位才能了解其作業原理，Lucene 非常復雜，

Elasticsearch 也是使用 Java 撰寫的，它的內部使用 Lucene 做索引與搜索，但是它的目的是使全文檢索變得簡單，通過隱藏 Lucene 的復雜性，取而代之的提供一套簡單一致的 RESTful API，

然而，Elasticsearch 不僅僅是 Lucene，并且也不僅僅只是一個全文搜索引擎，它可以被下面這樣準確的形容：
- 一個分布式的實時檔案存盤，每個欄位 可以被索引與搜索
- 一個分布式實時分析搜索引擎
- 能勝任上百個服務節點的擴展，并支持 PB 級別的結構化或者非結構化資料
補充

最近ES因為諸多原因準備放棄開源

慶幸的是AWS站出來生成要發布一個免費的開源ES分支版本
Restful風格的介面（這個會在實戰環節講解）
面向檔案

Elasticsearch 是 面向檔案 的，意味著它存盤整個物件或檔案，Elasticsearch 不僅存盤檔案，而且索引每個檔案的內容，使之可以被檢索，在 Elasticsearch 中，我們對檔案進行索引、檢索、排序和過濾—而不是對行列資料，這是一種完全不同的思考資料的方式，也是 Elasticsearch 能支持復雜全文檢索的原因，
索引

索引在ES中有多重語境

索引（名詞）：

一個索引類似于傳統關系資料庫中的一個 資料庫 ，是一個存盤關系型檔案的地方，索引 (index) 的復數詞為 indices 或 indexes ，

索引（動詞）：

索引一個檔案 就是存盤一個檔案到一個索引（名詞）中以便被檢索和查詢，這非常類似于 SQL 陳述句中的 INSERT 關鍵詞，除了檔案已存在時，新檔案會替換舊檔案情況之外，

倒排索引：

關系型資料庫通過增加一個索引比如一個 B樹（B-tree）索引到指定的列上，以便提升資料檢索速度，Elasticsearch 和 Lucene 使用了一個叫做 倒排索引 的結構來達到相同的目的，
型別

型別相當于傳統關系型資料庫中的一張表
檔案

檔案相當于傳統關系型資料庫中的一條記錄
Shard（分片）
分片是ES中最小的作業單元，一個索引是若干個分片的集合

一個分片是一個底層的 作業單元 ，它僅保存了全部資料中的一部分，

一個查詢進來后索引會交由各個分片去執行查詢，最后匯總資料，

有點類似ForkJoin的作業原理，將一個大的任務拆分成若干個小任務執行后合并結果，

這也是ES說是“接近實時的搜索”原因之一，

說到Shard一定離不開我們上文提到的倒排索引不變，倒排索引的不變性有以下好處
- 不需要鎖，如果你從來不更新索引，你就不需要擔心多行程同時修改資料的問題，
- 一旦索引被讀入內核的檔案系統快取，便會留在哪里，由于其不變性，只要檔案系統快取中還有足夠的空間，那么大部分讀請求會直接請求記憶體，而不會命中磁盤，這提供了很大的性能提升，
- 其它快取(像filter快取)，在索引的生命周期內始終有效，它們不需要在每次資料改變時被重建，因為資料不會變化，
- 寫入單個大的倒排索引允許資料被壓縮，減少磁盤 I/O 和需要被快取到記憶體的索引的使用量，
當然，一個不變的索引也有不好的地方，主要事實是它是不可變的! 你不能修改它，如果你需要讓一個新的檔案可被搜索，你需要重建整個索引，這要么對一個索引所能包含的資料量造成了很大的限制，要么對索引可被更新的頻率造成了很大的限制，

怎樣在保留不變性的前提下實作倒排索引的更新？

答案是: 用更多的索引

通過增加新的補充索引來反映新近的修改，而不是直接重寫整個倒排索引，每一個倒排索引都會被輪流查詢到—從最早的開始—查詢完后再對結果進行合并，

更多的細節我們不再深究，感興趣的同學可以自行學習分片內部原理

三、實戰

3.1 搭建本地環境

自行百度安裝ES

傻瓜式的下一步即可在本地創建ES的服務

ES啟動后我們可以通過http://localhost:9200/來檢驗我們的ES是否啟動成功

如果成功，將會看到以下的畫面

由上至下分別是

name：ES實體的名稱，沒有特別指定的情況下就是你的計算機名
cluster_name：集群的名稱
cluster_uuid：集群的uuid
version：版本相關資訊
tagline：ES最經典的開篇詞，“You Know，For Search”

3.2 CRUD

程式員寫的最多的肯定就是CRUD了，前面是造火箭，現在就是如何去擰螺絲了

Talk is cheap，show me the code

以下所有的實戰環節，都會分為原生Restful介面呼叫方式和對應的Java兩種實作方式

因為我們在日常作業中往往是使用封裝好的框架，只要我們有一些JPA的基礎知識，都可以在不太了解ES的情況下寫出大部分的CRUD，這么做旨在讓大家理解框架底層是怎么去呼叫ES的Restful介面的，

3.2.1 Restful的增刪查改

一般本地呼叫Restful介面有兩種方式

DataGrip裝ES插件
PostMan

本教程采用第二種方式，方便大家使用和理解

增

Post{raw/JSON} localhost:9200/my_index/my_type
{
    "name" : "zhangsan",
    "age" : 18,
    "gender" : "MALE"
}

# Response
{
    "_index": "my_index",
    "_type": "my_type",
    "_id": "JeqXW3cBzyfdu7sj-tRZ",
    "_version": 1,
    "result": "created",
    "_shards": {
        "total": 2,
        "successful": 1,
        "failed": 0
    },
    "_seq_no": 0,
    "_primary_term": 1
}

一般來說不必特地去創建某個index或type，ES會自動根據發送的POST請求去創建對應的index和type

注意：在某些云產品上（如阿里云ES），為了安全起見不能直接創建index，可以到后臺手動新建index或通過設定清除這個限制

然后我們可以再加幾個屬性，發送Post請求

Post{raw/JSON} localhost:9200/my_index/my_type
{
    "name" : "zhangsan",
    "age" : 18,
    "gender" : "MALE",
    "company" : "Accenture",
    "hobby" : "swimming"
}

# Response
{
    "_index": "my_index",
    "_type": "my_type",
    "_id": "JuqpW3cBzyfdu7sjyNT5",
    "_version": 1,
    "result": "created",
    "_shards": {
        "total": 2,
        "successful": 1,
        "failed": 0
    },
    "_seq_no": 1,
    "_primary_term": 1
}

可見相較于傳統關系型資料庫，ES可以隨時改變我們存盤的資料結構

查

接下來我們查詢一下剛才插入的兩條資料

很簡單

GET localhost:9200/my_index/my_type/_search

#Response
{
    "took": 2,
    "timed_out": false,
    "_shards": {
        "total": 1,
        "successful": 1,
        "skipped": 0,
        "failed": 0
    },
    "hits": {
        "total": {
            "value": 2,
            "relation": "eq"
        },
        "max_score": 1.0,
        "hits": [
            {
                "_index": "my_index",
                "_type": "my_type",
                "_id": "JeqXW3cBzyfdu7sj-tRZ",
                "_score": 1.0,
                "_source": {
                    "name": "zhangsan",
                    "age": 18,
                    "gender": "MALE"
                }
            },
            {
                "_index": "my_index",
                "_type": "my_type",
                "_id": "JuqpW3cBzyfdu7sjyNT5",
                "_score": 1.0,
                "_source": {
                    "name": "zhangsan",
                    "age": 18,
                    "gender": "MALE",
                    "company": "Accenture",
                    "hobby": "swimming"
                }
            }
        ]
    }
}

改

下面的代碼我們實作了把_id為JeqXW3cBzyfdu7sj-tRZ的檔案的age field更新為20

POST localhost:9200/my_index/my_type/_update_by_query

{
  "script": {
    "source": "ctx._source['age'] = 20"
  },
  "query": {
    "bool": {
      "must": [
        {
          "match": {
            "_id": "JeqXW3cBzyfdu7sj-tRZ"
          }
        }
      ]
    }
  }
}

刪
```
DELETE localhost:9200/my_index/my_type/f-HjfHgBk74RyUBNEN-s
```
洗掉資料是不需要帶請求體的，只需要在url里跟上"_id"即可

3.2.2 Java的增刪查改

說明

本工程會在加載的時候默認初始化1000條資料到本地的ES

如果不希望自動生成資料可以將application.yml里的prepare更改為false

如果希望生成更多的測驗資料可以更改amount的值

很慶幸spring-data-elasticsearch已經為我們封裝了常用的CRUD方法

打開本地elasticsearch工程

在com.workshop.elasticsearch.representation.apis.PersonController中我們可以看到本教程中提到的所有知識點對應的Java實體

如果要嘗試StringQuery，可以嘗試以下請求（這樣我們就可以把撰寫query的重任交給前端同事了（開個玩笑））

POST http://localhost:8080/people
{
    "query_string": {
        "query": "name : 'ZHAO' and age : 1"
    }
}

注：spring-data 沒有專門封裝update方法，可以呼叫save方法，save的時候如果id已存在就會更新對應的記錄

3.3 復雜的查詢

3.3.1 聚合（aggregations）

聚合這個操作我們可以理解為MySQL中的group by操作

在講聚合之前不得不說兩個概念

桶
指標

專有名詞聽起來比較晦澀，我們可以通過MySQL的一條query來理解

SELECT COUNT(color)
FROM table
GROUP BY color

其中：

COUNT(color) 相當于指標

GROUP BY color 相當于桶

我們可以通過對person的job進行聚合來統計不同job各有多少人

GET localhost:9200/person_index/_search
{
  "from": 0,
  "size": 20,
  "aggs": {
    "myAggs": {
      "terms": {
        "field": "job.keyword"
      }
    }
  },
  "query": {
    "match_all": {}
  }
}

回傳的結果中有aggregations，里面封裝的就是各個“桶”，以及對應的數量

Java實作在工程中

這只是聚合的簡單實作，ES為我們提供了聚合的很多度量指標和桶，如果想要深入了解聚合可以參考官方檔案

3.3.2 Null值查詢

當我們需要查詢某個欄位為空/不為空的時候，需要用到以下的查詢

GET localhost:9200/person_index/_doc/_search
{
    "query":{
        "bool":{
            "must(Not)":{
                "exists":{
                    "field" : "job"
                }
            }
        }
    }
}

3.3.3 分頁查詢

// TODO 普通分頁和游標查詢

History工程實體講解

scroll 查詢可以用來對 Elasticsearch 有效地執行大批量的檔案查詢，而又不用付出深度分頁那種代價，

游標查詢允許我們先做查詢初始化，然后再批量地拉取結果，這有點兒像傳統資料庫中的 cursor ，

游標查詢會取某個時間點的快照資料，查詢初始化之后索引上的任何變化會被它忽略，它通過保存舊的資料檔案來實作這個特性，結果就像保留初始化時的索引視圖一樣，

深度分頁的代價根源是結果集全域排序，如果去掉全域排序的特性的話查詢結果的成本就會很低，游標查詢用欄位 _doc 來排序，這個指令讓 Elasticsearch 僅僅從還有結果的分片回傳下一批結果，

啟用游標查詢可以通過在查詢的時候設定引數 scroll 的值為我們期望的游標查詢的過期時間，游標查詢的過期時間會在每次做查詢的時候重繪，所以這個時間只需要足夠處理當前批的結果就可以了，而不是處理查詢結果的所有檔案的所需時間，這個過期時間的引數很重要，因為保持這個游標查詢視窗需要消耗資源，所以我們期望如果不再需要維護這種資源就該早點兒釋放掉，設定這個超時能夠讓 Elasticsearch 在稍后空閑的時候自動釋放這部分資源，

https://www.elastic.co/guide/cn/elasticsearch/guide/current/scroll.html

四、踩坑記錄

4.1 和`JpaRepository`混用

如果一個專案同時配置了ES的Repo和JPA的repo

那么這時候需要去配置ES的包掃描范圍，否則ES掃描到JPA的repo時會報錯

加上@EnableElasticsearchRepositories(basePackages = “com.daimler.otr.servicehistorymanagement.infrastructure.repository.es”)

4.2 日期格式轉換

ES存到資料庫的時間默認是時間戳的格式，

當我們需要指定日期存盤格式的時候

需要加上以下注解

@Field(type = FieldType.Date, format = DateFormat.date_time)
@JsonFormat(shape = JsonFormat.Shape.STRING, pattern = "yyyy-MM-dd'T'HH:mm:ss.SSS'Z'")

4.2 使用`Jpa`方法名決議查詢兼容性

當我們使用JPA決議方法名的方式去查詢的時候

JPA只支持最基礎的等值查詢

比如

findAllByNameAndAge(name, age)

一些特殊的查詢比如IsNull或者Between、LessThan等

不是生成不了就是生成的query可定制性不高、效率的不到保障

建議用NativeQuery

4.3 加Field并支持排序

text型別在ES中是比較特殊的一種型別

當我們要對文本型別的field進行排序、聚合的時候

一定要用keyword去做，并且mapping中必須顯式宣告text支持keyword

4.4 ES中的Result Window

在大資料組件中，常常會提到“深分頁”和“淺分頁”的問題

緣由是ES不同于傳統的RDBMS，需要分頁的資料都是一次性取到記憶體中在記憶體中進行分頁

一旦取的資料量超出ES result window上限，就會報錯

訪問GET /{index_name}/_settings

能夠清楚看到max_result_window即為我們設定的最大結果視窗，默認值為10000

[外鏈圖片轉存失敗,源站可能有防盜鏈機制,建議將圖片保存下來直接上傳(img-Q2zfRaLx-1623047845049)(image-20210327175143298.png)]

當然result window不是越大越好，視窗越大意味著更大的記憶體開銷

所以當發現代碼里存在“深分頁”的時候，務必換做游標查詢以防止報錯和提升查詢性能

4.5 查詢條件過多

場景復現

detailEsRepository.findAllByServiceNumberIn(serviceNumbers) --serviceNumbers.size() = 1045條

然后ES報錯query clause超過max size = 1024

解決方案

改elasticsearch.yml中最大查詢數相關配置，然后重啟集群
相對比較理智的改法，減少每次查詢粒度，

總結

參考4.4中result window過大的問題，我們可以得出ES中盡量采用“小步快跑”的方式去做批量查詢

條件數盡可能控制在500條以內（default max = 1024）
單次回傳的數量不要超過5000條（default max = 10000）

參考

Elasticsearch詳解-簡書

Elasticsearch官方中文檔案2.x

結構化資料和非結構化資料區別

Lucene、Solr、Elasticsearch區別

漫畫Elasticsearch原理

MySQL 資料實時同步到 ES

Mysql 同步到ES的最佳實踐

spring-data-elasticsearch method query (8.2.2 query creation)

轉載請註明出處，本文鏈接：https://www.uj5u.com/qita/286202.html

標籤：AI

上一篇：一文回顧 Java 入門知識（中）

ElasticSearch WorkShop 講義