.NET Core接入ElasticSearch 7.5

寫在前面

最近一段時間，團隊在升級ElasticSearch（以下簡稱ES），從ES 2.2升級到ES 7.5。也是這段時間，我從零開始，逐步的瞭解了ES，中間也踩了不少坑，所以特地梳理和總結一下相關的技術點。

ES小趣聞：

多年前，一個叫做Shay Banon的剛結婚不久的開發者，由於妻子要去倫敦學習廚師，他便跟著也去了。在他找工作的過程中，為了給妻子構建一個食譜的搜尋引擎，他開始使用Lucene進行嘗試。
直接基於Lucene工作會比較困難，所以Shay開始抽象Lucene程式碼以便可以在應用中新增搜尋功能。他釋出了他的第一個開源專案，叫做“Compass”。
後來Shay找到一份工作，這份工作處在高效能和記憶體資料網格的分散式環境中，因此高效能的、實時的、分散式的搜尋引擎也是理所當然需要的。
然後他決定重寫Compass庫使其成為一個獨立的服務叫做Elasticsearch。
Shay的妻子依舊等待著她的食譜搜尋……

由此看見，一個成功的男人背後總是站著一個女人，所以程式設計師們要早點找到物件，可程式設計師找到女朋友又談何容易，程式猿註定悲傷-_-||。

ElasticSearch基礎知識

EElasticsearch是一個開源的分散式、RESTful 風格的搜尋和資料分析引擎，ES底層基於開源庫Apache Lucene，不過Lucene使用門檻太高，ES隱藏了Lucene使用時的複雜性，使得分散式實時文件搜尋、實時分析引擎、高擴充套件性變得更加容易。

安裝

安裝ES，首先要配置Java SDK，然後配置一下環境變數即可。然後再從官網下載ES安裝包，可以選用預設配置，點選下一步—>安裝。

在瀏覽器上輸入http://localhost:9200/，顯示如下文字，就意味著安裝成功了。

{
  "name" : "XXXXXXXXXX",
  "cluster_name" : "elasticsearch",
  "cluster_uuid" : "mB04ov3OTvSz7OSe0GtZ_A",
  "version" : {
    "number" : "7.5.2",
    "build_flavor" : "unknown",
    "build_type" : "unknown",
    "build_hash" : "8bec50e1e0ad29dad5653712cf3bb580cd1afcdf",
    "build_date" : "2020-01-15T12:11:52.313576Z",
    "build_snapshot" : false,
    "lucene_version" : "8.3.0",
    "minimum_wire_compatibility_version" : "6.8.0",
    "minimum_index_compatibility_version" : "6.0.0-beta1"
  },
  "tagline" : "You Know, for Search"
}

部分基本概念

節點 & 叢集

叢集由多個節點組成，其中一個節點為主節點，主節點由內部選舉演算法選舉產生。當然主節點是相對的，是相對於內部而言的。ES去中心化，這是相對於外部而言的，從邏輯上說，與任何一個節點的的通訊和與叢集通訊是沒有區別的。如下圖所示。

索引

索引儲存相關資料的地方，是指向一個或者多個物理分片的邏輯名稱空間 。另外，每個Index的名字必須是小寫。

文件

Document的核心後設資料有三個：_index、_type(7.X已經弱化了，8.0開始就會移除)、_id。Document 使用 JSON 格式表示。

分片

一個分片是一個底層的工作單元，它僅儲存了全部資料中的一部分。我們的文件被儲存和索引到分片內，但是應用程式是直接與索引而不是與分片進行互動。

Elasticsearch 是利用分片將資料分發到叢集內各處的。分片是資料的容器，文件儲存在分片內，分片又被分配到叢集內的各個節點裡。 當你的叢集規模擴大或者縮小時， Elasticsearch 會自動的在各節點中遷移分片，使得資料仍然均勻分佈在叢集裡。

一個分片可以是主分片或者副本分片。索引內任意一個文件都歸屬於一個主分片，所以主分片的數目決定著索引能夠儲存的最大資料量。

一個副本分片只是一個主分片的拷貝。副本分片作為硬體故障時保護資料不丟失的冗餘備份，併為搜尋和返回文件等讀操作提供服務。

在索引建立的時候就已經確定了主分片數，但是副本分片數可以隨時修改。

理論上一個主分片最大能夠儲存Integer.MAX_VALUE^128 個文件。

寫操作探討

文件會被儲存到主分片，那麼在多個分片的情況下是如何寫入和精確搜尋的。實際上這是通過以下公式確定的：

shard = hash(routing) % number_of_primary_shards

以上的routing的值是一個任意的字串，它預設被設定成文件的_id欄位，但是也可以被設定成其他指定的值。這個routing字串會被傳入到一個雜湊函式(Hash Function)來得到一個數字，然後該數字會和索引中的主要分片數進行模運算來得到餘數。這個餘數的範圍應該總是在0和number_of_primary_shards - 1之間，它就是一份文件被儲存到的分片的號碼。

這就解釋了為什麼索引中的主要分片數量只能在索引建立時被指定，並且將來都不能在被更改：如果主要分片數量在索引建立後改變了，那麼之前的所有路由結果都會變的不正確，從而導致文件不能被正確地獲取。那麼如何水平擴充套件呢，可以移步Designing for scale。

所有的文件API(get, index, delete, bulk, update)都接受一個routing引數，它用來定製從文件到分片的對映。一個特定的routing值能夠確保所有相關文件 - 比如屬於相同使用者的所有文件 - 都會被儲存在相同的分片上。

寫操作原理圖：

寫入的請求流程如圖所示（此圖源自《Elasticsearch權威指南》）：

寫入到磁碟流程如下圖所示：

由此可見ES的實時並非是完全的實時，而是一種準實時(Near-Real-Time)。

讀操作探討

讀分為兩個階段，查詢階段（Query Phrase）以及聚合提取階段(Fetch Phrase)

查詢階段

協調節點接受到讀請求，並將請求分配到相應的分片上（有可能是主分片或是副本分片，這個機制後續會提及），預設情況下，每個分片建立10個結果（僅包含 document_id 和 Scores）的優先順序佇列，並以相關性排序，返回給協調節點。

查詢階段如果不特殊指定，落入的分片有可能是 primary 也有可能是 replicas，這個根據協調節點的負載均衡演算法來確定。

聚合提取階段

假設查詢落入的分片數為 N，那麼聚合階段就是對 N*10 個結果集進行排序，然後再通過已經拿到的 document_id 查到對應的 document 並組裝到佇列裡，組裝完畢後將有序的資料返回給客戶端。

• 客戶端傳送請求到任意一個Node，成為Coordinating node
• Coordinating node對Document進行路由，將請求轉發到對應的Node上，此時會使用Round-Robin隨機輪詢演算法，在Primary Shard以及其所有Replica中隨機選擇一個，讓讀請求負載均衡
• 接收請求的node返回Document給Coordinating node
• Coordinating node返回Document給客戶端

ElasticSearch實戰

ES在.NET平臺上的官方客戶端是NEST，以下操作都是基於該package的。

常用操作

以下操作均基於ES-Head，該工具是一個Chrome外掛，非常簡單實用，而且可以在GitHub上搜到原始碼，方便個性化開發。

寫入資料：

返回的資料中，可以看到Id是一段字串，這是因為在寫入的過程中並沒有指定，所以會由ES預設生成。當然可以指定：

更新資料：

_version值會隨著操作次數，逐漸迭代。

刪除資料：

查詢操作：

專案升級過程中遇到的問題

分頁查詢過慢：

初次的查詢使用了深度分頁(from-size)查詢，當資料達到百萬千萬級別時，已經慢的讓人忍無可忍。所謂深度查詢就是涉及到大量 shard 的查詢時，直接跳頁到幾千甚至上萬頁的資料，協調節點就有當機的風險，畢竟協調節點需要將大量資料彙總起來進行排序，耗費大量的記憶體和 CPU 資源。所以慎用！儘可能用 Scroll API ，即只允許拿到下一頁的資訊，不允許跳頁的情況出現，會避免這種情況的發生。

後來改用了快照分頁(scroll)，整個查詢過程非常穩定，方差幾乎可以忽略。該查詢會自動返回一個_scroll_id，通過這個id(經過base64編碼)可以繼續查詢。查詢語句如下：http://localhost:9200/_search/scroll?scroll=1m&scroll_id=c2MkjsjskMkkssllasKKKOzM0NDg1ODpksksks5566HHsaskLLLqi692215。這個語句雖然很快，但是無法做到跳頁查詢，只能一頁一頁的查詢。

快照分頁參考程式碼如下：

var searchResponse = client.Search<ElasticsearchTransaction>(p =>
                    p.Query(t =>
                    t.Bool(l => l.Filter(f => f.DateRange(m => m.GreaterThanOrEquals(startTime).Field(d => d.PostDate)))))
                    .From(0)
                    .Size(Configurations.SyncSize)
                    .Index("archive")
                    .Sort(s => s.Ascending(a => a.PostDate)).Scroll("60s"));


while(某條件)
{
    searchResponse = client.Scroll<ElasticsearchTransaction>("60s", searchResponse.ScrollId);

    //跳出迴圈的條件
}

模糊查詢：

該場景涉及到多個欄位的模糊查詢，當然，這種查詢是十分消耗效率的，使用的時候要慎重，同時還要控制模糊關鍵字的數量，以儘可能在滿足業務的情況下，提升查詢效率，參考程式碼如下：

public static List<IHit<TModel>> GetDataByFuzzy(ElasticClient client9200)
{
    string[] fieldList =
    {
        "filed1",
        "filed2",
        "filed3",
        "filed4",
        "filed5",
        "filed6",
        "filed7",
        "filed8",
        "filed9"
    };


    string term = string.Concat("*", string.Join("* *", "i u a n".Split(new[] { ' ' }, StringSplitOptions.RemoveEmptyEntries)), "*");

    var result = client9200.Search<TModel>(p => p.Query(q => q.Bool(b=>b.Must(t=>t.QueryString(c => c
                .Fields(fieldList)
                .Query(term)
                .Boost(1.1)
                .Fuzziness(Fuzziness.Auto)
                .MinimumShouldMatch(2)
                .FuzzyRewrite(MultiTermQueryRewrite.ConstantScoreBoolean)
                .TieBreaker(1)
                .Lenient()
                )).Filter(f=>
                f.Term(t=>
                t.Field(d=>d.AccountKey).Value("123456789")))))
                .ScriptFields(sf => sf.ScriptField("datetime1",
                sc => sc.Source("doc['datetime1'].value == null?doc['datetime2'].value: doc['datetime1'].value")))
                .Source(true)
                .Index("archive")
                .From(0)
                .Size(10000)
                .Sort(s => s.Descending(a => a.CreateDate)));


    return result.Hits.Select(p=>p.Source).ToList();
}

關於排序

在本次的ES優化升級過程中，關於排序的操作可以說是很糾結的。按照業務要求，要根據兩個時間型別的欄位進行排序，如果某個為空，就按照不為空的排序，使得其排序結果達到穿插的效果，而不是像SQL語句那樣order by field1, field2的排序結果那樣。

找出解決方案的過程很痛苦，因為官方的demo無法執行，這時間型別的操作是個巨坑，經過多方嘗試，終於在檢視ElasticSearch原始碼的情況下，找到了解決方案。

Github地址：https://github.com/elastic/elasticsearch/blob/master/server/src/main/java/org/elasticsearch/script/JodaCompatibleZonedDateTime.java，第411行

查詢語句如下：

{
    "from": 0,
    "query": {
        "bool": {
            "filter": [
                {
                    "term": {
                        "UserId": {
                            "value": "123456789"
                        }
                    }
                }
            ]
        }
    },
    "size": 10,
    "sort": [
        {
            "_script": {
                "script": {
                    "source": "doc.DateTime1.empty?doc.DateTime2.value.toInstant().toEpochMilli():doc.DateTime1.value.toInstant().toEpochMilli()"
                },
                "type": "number",
                "order": "desc"
            }
        }
    ]
}

C#參考程式碼如下：

var searchResponse = _elasticsearchClient.Search<T>(s => s
                    .Query(q => q.Bool(b => b
                    .Filter(m => m.Term(t => t.Field(f => f.UserId).Value(userId)),m => m.QueryString(qs => qs.Fields(fieldList).Query(term.PreProcessQueryString())))))
                    .Index(indexName)
                    .ScriptFields(sf => sf
                    .Source(true)
                    .Sort(s=>s.Script(sr=>sr.Script(doc => doc.Source("doc.DateTime1.empty ? doc.DateTime2.value.toInstant().toEpochMilli() : doc.DateTime1.value.toInstant().toEpochMilli()"))))
                    .From(startIndex)
                    .Size(pageSize));

參考連結：

https://www.dazhuanlan.com/2020/02/13/5e44f118b75cb/

https://www.toutiao.com/i6824365055832752653