Elasticsearch 深度解析：從原理到實(shí)踐

一、為什么選擇 Elasticsearch？

數(shù)據(jù)模型
Elasticsearch 是基于文檔的搜索引擎，它使用 JSON 文檔來存儲(chǔ)數(shù)據(jù)。在 Elasticsearch 中，相關(guān)的數(shù)據(jù)通常存儲(chǔ)在同一個(gè)文檔中，而不是分散在多個(gè)表中。

MySQL 是一個(gè)關(guān)系型數(shù)據(jù)庫管理系統(tǒng)，它使用表、行和列的結(jié)構(gòu)來組織數(shù)據(jù)。數(shù)據(jù)通過外鍵關(guān)系分散在多個(gè)表中。

查詢語言
Elasticsearch 使用 Query DSL（Domain Specific Language），這是一種非常靈活的查詢語言，基于 JSON，支持全文搜索、復(fù)合查詢、過濾以及聚合等。

MySQL 使用 SQL（Structured Query Language），這是一種強(qiáng)類型和非常成熟的語言，專門用于查詢和管理關(guān)系數(shù)據(jù)庫。

全文搜索
Elasticsearch 的核心功能是全文搜索。它對(duì)數(shù)據(jù)進(jìn)行索引時(shí)會(huì)自動(dòng)建立全文搜索索引，使其在搜索大量文本數(shù)據(jù)時(shí)表現(xiàn)優(yōu)異。

MySQL 雖然也提供了基本的全文搜索功能，但其主要設(shè)計(jì)目標(biāo)是處理結(jié)構(gòu)化數(shù)據(jù)的存儲(chǔ)和查詢，對(duì)全文搜索的支持不如 Elasticsearch 那樣強(qiáng)大。

事務(wù)支持
Elasticsearch 不支持傳統(tǒng)的 ACID（原子性、一致性、隔離性、持久性）事務(wù)。雖然它確保了單個(gè)文檔操作的原子性，但不適用于跨多個(gè)文檔的復(fù)雜事務(wù)。雖然 Elasticsearch 不支持傳統(tǒng)的事務(wù)，但是他是可以確保單個(gè)文檔的更改（如創(chuàng)建、更新、刪除）是原子性的。這意味著任何文檔級(jí)的操作都完整地成功或完整地失敗，但不保證跨多個(gè)文檔或操作的一致性。

MySQL 支持 ACID 事務(wù)，這使得它非常適合需要嚴(yán)格數(shù)據(jù)一致性的應(yīng)用，如金融服務(wù)和其他商業(yè)數(shù)據(jù)處理。

支持樂觀鎖：

Elasticsearch 支持通過使用文檔版本控制來實(shí)現(xiàn)樂觀鎖。

6.7之前。在 ES 中，每個(gè)文檔存儲(chǔ)時(shí)都有一個(gè) _version 字段，這個(gè)版本號(hào)在每次文檔更新時(shí)自動(dòng)增加。當(dāng)我們執(zhí)行更新、刪除或者使用腳本處理文檔時(shí)，可以指定這個(gè)版本號(hào)來確保正在操作的文檔是預(yù)期中的版本。如果操作中的版本號(hào)與存儲(chǔ)在索引中的文檔版本號(hào)不一致，說明文檔已被其他操作更改，當(dāng)前操作將會(huì)失敗。（CAS）

為什么_version在后續(xù)版本被拋棄

_version 機(jī)制是基于單一遞增整數(shù)，它主要適用于簡(jiǎn)單的沖突檢測(cè)，但在復(fù)雜的分布式系統(tǒng)中，僅依靠版本號(hào)可能無法準(zhǔn)確地反映數(shù)據(jù)的歷史和復(fù)制狀態(tài)。尤其是在發(fā)生網(wǎng)絡(luò)分區(qū)或節(jié)點(diǎn)故障時(shí)，僅憑 _version 可能導(dǎo)致數(shù)據(jù)丟失或過時(shí)的數(shù)據(jù)被錯(cuò)誤地寫入。

主要還是在高并發(fā)和高可用的環(huán)境下，單一的-version不足以處理因節(jié)點(diǎn)故障或網(wǎng)絡(luò)問題導(dǎo)致的多個(gè)副本之間的數(shù)據(jù)不一致問題。

然而if_seq_no 和 if_primary_term這兩個(gè)參數(shù)可以更準(zhǔn)確地確定操作是否應(yīng)當(dāng)被執(zhí)行，可以跟蹤每個(gè)文檔變更的序列號(hào)和主分片的期限。這種機(jī)制幫助確保即使在集群狀態(tài)發(fā)生變化（如分片重新分配到新的節(jié)點(diǎn)）的情況下，也不會(huì)應(yīng)用基于過時(shí)副本的更新。它有效地防止了腦裂問題。

6.7之后，使用 _version 關(guān)鍵字進(jìn)行樂觀鎖已經(jīng)被廢棄了，替代方法是使用

if_seq_no （是一個(gè)遞增的序列號(hào)，表示文檔的每次修改）和

if_primary_term（表示主分片的當(dāng)前任期，每當(dāng)主分片發(fā)生變化時(shí)，這個(gè)值會(huì)增加。） 

來指定版本。

1. 核心優(yōu)勢(shì)()

Elasticsearch是一個(gè)開源的分布式搜索和分析引擎，主要適用于以下場(chǎng)景：

1:搜索引擎：用于快速檢索文檔、商品、新聞等。

2:日志分析：通過分析日志數(shù)據(jù)，幫助企業(yè)了解其業(yè)務(wù)的性能情況。

3:數(shù)據(jù)分析：幫助數(shù)據(jù)科學(xué)家和數(shù)據(jù)分析師進(jìn)行數(shù)據(jù)分析，以獲取有價(jià)值的信息。

4:商業(yè)智能：幫助企業(yè)制定數(shù)據(jù)驅(qū)動(dòng)的決策，以實(shí)現(xiàn)商業(yè)上的成功。

5:實(shí)時(shí)監(jiān)控：幫助企業(yè)實(shí)時(shí)監(jiān)測(cè)系統(tǒng)性能、監(jiān)控?cái)?shù)據(jù)變化，以保證系統(tǒng)正常運(yùn)行。

6:安全性：幫助企業(yè)保證數(shù)據(jù)的安全性，保證數(shù)據(jù)不被非法竊取。

7:應(yīng)用程序開發(fā)：幫助開發(fā)人員開發(fā)基于搜索的應(yīng)用程序，以增加用戶體驗(yàn)。

Elasticsearch具有以下幾個(gè)優(yōu)勢(shì)：

1:高性能：Elasticsearch具有高性能的搜索和分析能力，其中涵蓋了多種查詢語言和數(shù)據(jù)結(jié)構(gòu)。

2:可擴(kuò)展性：Elasticsearch是分布式的，可以通過增加節(jié)點(diǎn)數(shù)量擴(kuò)展搜索和分析能力。

3:靈活性：Elasticsearch支持多種數(shù)據(jù)類型，支持多種語言，支持動(dòng)態(tài)映射，允許快速地調(diào)整模型以適應(yīng)不同的需求。

4:實(shí)時(shí)分析：Elasticsearch支持實(shí)時(shí)分析，可以對(duì)數(shù)據(jù)進(jìn)行實(shí)時(shí)查詢，這對(duì)于快速檢索數(shù)據(jù)非常有用。

5:可靠性：Elasticsearch具有可靠性和高可用性，支持?jǐn)?shù)據(jù)備份和恢復(fù)。

ES為什么塊：

1：分布式存儲(chǔ)：Elasticsearch使用分布式存儲(chǔ)技術(shù)，將數(shù)據(jù)存儲(chǔ)在多個(gè)節(jié)點(diǎn)上，從而減少單個(gè)節(jié)點(diǎn)的壓力，提高整體性能。

2：索引分片：Elasticsearch把每個(gè)索引劃分成多個(gè)分片，這樣可以讓查詢操作并行化，從而提高查詢速度。

3：全文索引：Elasticsearch使用了高效的全文索引技術(shù)，把文檔轉(zhuǎn)化成可搜索的結(jié)構(gòu)化數(shù)據(jù)，使得搜索操作快速高效。

4：倒排索引：Elasticsearch支持倒排索引這種數(shù)據(jù)結(jié)構(gòu)，倒排索引將文檔中的每個(gè)詞與該詞出現(xiàn)在哪些文檔中進(jìn)行映射，并存儲(chǔ)這些信息。當(dāng)搜索請(qǐng)求發(fā)生時(shí)，ES可以快速查找包含所有搜索詞的文檔，從而返回結(jié)果。

5：索引優(yōu)化：Elasticsearch通過索引優(yōu)化技術(shù)，可以使查詢速度更快。例如，它支持索引覆蓋、索引下推等優(yōu)化技術(shù)，使得查詢速度更快。

6：預(yù)存儲(chǔ)結(jié)果：Elasticsearch在插入數(shù)據(jù)時(shí)，對(duì)數(shù)據(jù)進(jìn)行預(yù)處理，把結(jié)果預(yù)存儲(chǔ)到索引中，從而在查詢時(shí)不需要再重新計(jì)算，提高查詢速度。

7：高效的查詢引擎：Elasticsearch使用了高效的查詢引擎，支持各種類型的查詢，并對(duì)復(fù)雜查詢提供了優(yōu)化策略，從而提高查詢速度。

8：異步請(qǐng)求處理：ES使用了異步請(qǐng)求處理機(jī)制，能夠在請(qǐng)求到達(dá)時(shí)立即返回，避免長(zhǎng)時(shí)間的等待，提高用戶體驗(yàn)。

9：內(nèi)存存儲(chǔ)：ES使用了內(nèi)存存儲(chǔ)技術(shù)，能夠在讀寫數(shù)據(jù)時(shí)大大減少磁盤訪問次數(shù)，提高數(shù)據(jù)存儲(chǔ)和查詢效率。

我覺得最重要就是倒排索引了：它 用于快速搜索文檔中的某個(gè)詞匯。

假設(shè)我們有一個(gè)原始文檔：

主要分為倆個(gè)過程：

分詞（Tokenization）：

• Doc1 → ["elasticsearch", "is", "fast"]

• Doc2 → ["redis", "is", "fast", "too"]

• Doc3 → ["elasticsearch", "and", "redis"]

生成詞項(xiàng)-文檔映射：

Term            DocIDs (Postings List)
─────────────────────────────────────
"and"           → [Doc3]
"elasticsearch" → [Doc1, Doc3]
"fast"          → [Doc1, Doc2]
"is"            → [Doc1, Doc2]
"redis"         → [Doc2, Doc3]
"too"           → [Doc2]

2. 倒排索引的核心組件

倒排索引的優(yōu)化技術(shù)

1. 壓縮存儲(chǔ)：

   • FST：壓縮詞項(xiàng)字典，減少內(nèi)存占用。

   • Delta Encoding：對(duì)文檔ID差值編碼（如[100, 102, 105]→[100, +2, +3]）。

2. 跳表（SkipList）：

   • 加速倒排列表的合并操作（如AND查詢）。

3. 多級(jí)索引：

   • 內(nèi)存中保留熱點(diǎn)詞項(xiàng)，磁盤存全量數(shù)據(jù)。

二、Elasticsearch 核心技術(shù)細(xì)節(jié)

1. 分詞器（Analyzer）

自定義分詞器：

PUT /my_index
{
  "settings": {
    "analysis": {
      "analyzer": {
        "my_ik": {
          "type": "custom",
          "tokenizer": "ik_max_word",
          "filter": ["lowercase"]
        }
      }
    }
  }
}

2. 底層原理

• 倒排索引（Inverted Index）：

  • Term → Document ID 的映射（如“手機(jī)” → [Doc1, Doc3]）。

  • 通過 FST（Finite State Transducer） 壓縮存儲(chǔ)，減少內(nèi)存占用。

• 分片（Shard）機(jī)制：

  • 索引自動(dòng)拆分為多個(gè)分片（默認(rèn)5個(gè)），分散到不同節(jié)點(diǎn)。

  • 每個(gè)分片有1個(gè)主副本和N個(gè)從副本（通過_settings調(diào)整）。

• 近實(shí)時(shí)（NRT）：

  • 數(shù)據(jù)寫入后默認(rèn)1秒（refresh_interval）可被搜索，通過 translog 保證持久化。

3. 查詢高效的原因

• 分布式計(jì)算：

  • 查詢并行發(fā)送到所有分片，結(jié)果聚合（Scatter-Gather模式）。

• 緩存優(yōu)化：

  • Query Cache：緩存過濾條件結(jié)果。

  • Fielddata：文本字段啟用內(nèi)存緩存（慎用，易OOM）。

• 列式存儲(chǔ)（Doc Values）：

  • 對(duì)排序、聚合字段預(yù)先構(gòu)建磁盤數(shù)據(jù)結(jié)構(gòu)，避免實(shí)時(shí)計(jì)算。

4. 增刪改操作

• 寫入流程：

  1. 請(qǐng)求發(fā)送到協(xié)調(diào)節(jié)點(diǎn)。

  2. 路由到對(duì)應(yīng)分片的主副本。

  3. 寫入Lucene內(nèi)存Buffer和translog。

  4. 定期刷新（Refresh）生成新Segment（可搜索）。

  5. 后臺(tái)合并（Merge）Segment優(yōu)化存儲(chǔ)。

• 刪除：

  • 標(biāo)記文檔為deleted，Merge時(shí)物理刪除。

• 更新：

  • 先刪除舊文檔，再寫入新文檔（版本號(hào)_version遞增）。

三、關(guān)鍵問題解決方案

1. 深度分頁優(yōu)化

• 問題：from 10000, size 10 需遍歷所有分片的10010條記錄。在Elasticsearch中進(jìn)行分頁查詢通常使用from和size參數(shù)。當(dāng)我們對(duì)Elasticsearch發(fā)起一個(gè)帶有分頁參數(shù)的查詢（如使用from和size參數(shù)）時(shí)，ES需要遍歷所有匹配的文檔直到達(dá)到指定的起始點(diǎn)（from），然后返回從這一點(diǎn)開始的size個(gè)文檔。跟MySQL的深度分頁原因差不多，

• 方案：

  • Search After：search_after 是 Elasticsearch 中用于實(shí)現(xiàn)深度分頁的一種機(jī)制。與傳統(tǒng)的分頁方法（使用 from 和 size 參數(shù)）不同，search_after 允許你基于上一次查詢的結(jié)果來獲取下一批數(shù)據(jù)，這在處理大量數(shù)據(jù)時(shí)特別有效。
    
    在第一次查詢時(shí)，你需要定義一個(gè)排序規(guī)則。不需要指定 search_after 參數(shù)：

    {
      "query": { "match_all": {} },
      "size": 10,
      "sort": [{"_id": "asc"}],//在第一次查詢時(shí)，你需要定義一個(gè)排序規(guī)則。
      "search_after": [last_id]
    //第一次查詢不要定義，在后續(xù)的查詢中，使用上一次查詢結(jié)果中最后一條記錄的排序值
    //search_after包含timestamp和last_id 的值，對(duì)應(yīng)上一次查詢結(jié)果的最后一條記錄。
    
    }

    search_after 可以有效解決深度分頁問題，原因如下：
    避免重復(fù)處理數(shù)據(jù)：與傳統(tǒng)的分頁方式不同，search_after 不需要處理每個(gè)分頁請(qǐng)求中所有先前頁面上的數(shù)據(jù)。這大大減少了處理數(shù)據(jù)的工作量。
    
    提高查詢效率：由于不需要重復(fù)計(jì)算和跳過大量先前頁面上的數(shù)據(jù)，search_after 方法能顯著提高查詢效率，尤其是在訪問數(shù)據(jù)集靠后部分的數(shù)據(jù)時(shí)。
    
    但是這個(gè)方案有一些局限，一方面需要有一個(gè)全局唯一的字段用來排序，另外雖然一次分頁查詢時(shí)不需要處理先前頁面中的數(shù)據(jù)，但實(shí)際需要依賴上一個(gè)頁面中的查詢結(jié)果。

  • 適用于深度分頁和大數(shù)據(jù)集的遍歷。

• • Scroll API：Scroll API在Elasticsearch中的主要目的是為了能夠遍歷大量的數(shù)據(jù)，它通常用于數(shù)據(jù)導(dǎo)出或者進(jìn)行大規(guī)模的數(shù)據(jù)分析?？梢杂糜谔幚泶罅繑?shù)據(jù)的深度分頁問題。

• POST /_search/scroll { "scroll": "1m", "scroll_id": "DXF1ZXJ5QW..." }
  //如上方式初始化一個(gè)帶有scroll參數(shù)的搜索請(qǐng)求。這個(gè)請(qǐng)求返回一個(gè)scroll ID，用于后續(xù)的滾動(dòng)。Scroll參數(shù)指定了scroll的有效期，例如1m表示一分鐘。
  
  //接下來就可以使用返回的scroll ID來獲取下一批數(shù)據(jù)。每次請(qǐng)求也會(huì)更新scroll ID的有效期。

• • 業(yè)務(wù)妥協(xié)：限制最大頁碼（如只展示前100頁）。

  • 避免重復(fù)排序：在傳統(tǒng)的分頁方式中，每次分頁請(qǐng)求都需要對(duì)所有匹配的數(shù)據(jù)進(jìn)行排序，以確定分頁的起點(diǎn)。Scroll避免了這種重復(fù)排序，因?yàn)樗３至艘粋€(gè)游標(biāo)。

  • 穩(wěn)定視圖：Scroll提供了對(duì)數(shù)據(jù)的“穩(wěn)定視圖”。當(dāng)你開始一個(gè)scroll時(shí)，Elasticsearch會(huì)保持搜索時(shí)刻的數(shù)據(jù)快照，這意味著即使數(shù)據(jù)隨后被修改，返回的結(jié)果仍然是一致的。

  • 減少資源消耗：
    由于不需要重復(fù)排序，Scroll減少了對(duì)CPU和內(nèi)存的消耗，特別是對(duì)于大數(shù)據(jù)集。

  • Scroll非常適合于處理需要訪問大量數(shù)據(jù)但不需要快速響應(yīng)的場(chǎng)景，如數(shù)據(jù)導(dǎo)出、備份或大規(guī)模數(shù)據(jù)分析。
    
    但是，需要知道，使用Scroll API進(jìn)行分頁并不高效，因?yàn)槟阈枰全@取所有前面頁的數(shù)據(jù)。Scroll API主要用于遍歷整個(gè)索引或大量數(shù)據(jù)，而不是用于快速訪問特定頁數(shù)的數(shù)據(jù)。

2. 數(shù)據(jù)一致性

第一種方法：雙寫一致性

對(duì)MySQL和ES進(jìn)行雙寫，先更新數(shù)據(jù)庫，再更新ES，放在一個(gè)事務(wù)里面，需要保證事務(wù)的一致性。有數(shù)據(jù)不一致的風(fēng)險(xiǎn)，比如MySQL寫入成功，但是ES發(fā)生了寫入成功但因?yàn)槌瑫r(shí)拋異常了就會(huì)出現(xiàn)數(shù)據(jù)不一致的情況。

第二種方法：使用消息隊(duì)列MQ進(jìn)行處理

在更新數(shù)據(jù)庫時(shí)，發(fā)送一個(gè)消息到MQ中，然后數(shù)據(jù)庫和ES各設(shè)置一個(gè)監(jiān)聽者，監(jiān)聽消息之后各自去做數(shù)據(jù)變更，如果失敗了就基于消息的重試在重新執(zhí)行。

好處是進(jìn)行了異步解耦，性能稍后，但是有延遲

第三種方法：定時(shí)掃描MySQL

如果ES中的數(shù)據(jù)變更的實(shí)時(shí)性要求不高，可以考慮定時(shí)任務(wù)掃表來批量更新ES。

這個(gè)方案優(yōu)點(diǎn)是沒有侵入性，數(shù)據(jù)庫的寫操作處不需要改代碼。

缺點(diǎn)是實(shí)時(shí)性很差，并且輪詢可能存在性能問題、效率問題以及給數(shù)據(jù)庫帶來壓力。

第四種方法：監(jiān)聽binlog日志（基于canal做數(shù)據(jù)同步的方案)

對(duì)業(yè)務(wù)代碼完全沒有侵入性，業(yè)務(wù)也非常解耦，不需要關(guān)心這個(gè)ES的更新操作。

缺點(diǎn)就是需要基于binlog監(jiān)聽，需要引入第三方框架。存在一定的延遲。

與Canal集成：主要的過程

1. MySQL Binlog → Canal Server 解析變更。

2. Canal Client → Kafka 發(fā)送變更事件。

3. Logstash/自定義Consumer → 寫入ES。

關(guān)于Logstash和自定義Consumer

. Logstash 是什么？

• 定位：開源的數(shù)據(jù)處理管道工具，屬于 Elastic Stack（ELK）的一部分。

• 核心功能：

  • 數(shù)據(jù)輸入（Input）：從 Kafka、MySQL、文件等讀取數(shù)據(jù)。

  • 數(shù)據(jù)過濾（Filter）：清洗、轉(zhuǎn)換、豐富數(shù)據(jù)（如字段重命名、類型轉(zhuǎn)換）。

  • 數(shù)據(jù)輸出（Output）：將處理后的數(shù)據(jù)寫入 ES、MySQL、文件等。

• 特點(diǎn)：

  • 配置驅(qū)動(dòng)：通過配置文件定義數(shù)據(jù)處理流程，無需編碼。

  • 插件化：支持 200+ 官方/社區(qū)插件（如 kafka、elasticsearch、grok）。

Canal → ES 場(chǎng)景中的用途

將 Canal 發(fā)送到 Kafka 的 MySQL Binlog 數(shù)據(jù)轉(zhuǎn)換為 ES 所需的格式，并寫入 ES。

 自定義 Consumer 是什么？

• 定位：用戶自行編寫的程序（通常用 Java/Python/Go），用于消費(fèi) Kafka 消息并處理。

• 核心功能：

  • 從 Kafka 拉取 Canal 生成的 Binlog 消息。

  • 解析消息并轉(zhuǎn)換為 ES 支持的格式（如 JSON）。

  • 調(diào)用 ES 的 API 寫入數(shù)據(jù)。

• 特點(diǎn)：

  • 靈活可控：可自定義業(yè)務(wù)邏輯（如特殊字段處理、錯(cuò)誤重試）。

  • 高性能：通過批量寫入、異步請(qǐng)求等優(yōu)化吞吐量。

整體架構(gòu)流程：

3. ES支持的數(shù)據(jù)結(jié)構(gòu)

• 核心類型：

  • Text：用于存儲(chǔ)全文文本數(shù)據(jù)。

  • Keyword：用于存儲(chǔ)文本值，通常用于索引結(jié)構(gòu)化內(nèi)容，如郵件地址、標(biāo)簽或任何需要精確匹配的內(nèi)容。

  • Nested：類似于 Object 類型，但用于存儲(chǔ)數(shù)組列表，其中列表中的每個(gè)元素都是完全獨(dú)立且可搜索的。

  • Long, Integer, Short, Byte, Double, Float: 這些是數(shù)值類型，用于存儲(chǔ)各種形式的數(shù)字。

  • Date: 存儲(chǔ)日期或日期和時(shí)間。

  • Boolean: 存儲(chǔ) true 或 false 值。

  • Binary: 用于存儲(chǔ)二進(jìn)制數(shù)據(jù)。

  • Object: 用于嵌套文檔，即文檔內(nèi)部可以包含文檔。

• 特殊類型：

  • Flattened：避免深層JSON字段爆炸。

  • Join：父子文檔（性能較差，慎用）。

• text 和 keyword 有啥區(qū)別？
  
  text 類型被設(shè)計(jì)用于全文搜索。這意味著當(dāng)文本被存儲(chǔ)為 text 類型時(shí)，Elasticsearch 會(huì)對(duì)其進(jìn)行分詞，把文本分解成單獨(dú)的詞或短語，便于搜索引擎進(jìn)行全文搜索。因?yàn)?text 字段經(jīng)過分詞，它不適合用于排序或聚合查詢。
  
  text適用于存儲(chǔ)需要進(jìn)行全文搜索的內(nèi)容，比如新聞文章、產(chǎn)品描述等。
  
  keyword 類型用于精確值匹配，不進(jìn)行分詞處理。這意味著存儲(chǔ)在 keyword 字段的文本會(huì)被當(dāng)作一個(gè)完整不可分割的單元進(jìn)行處理。因?yàn)?keyword 類型字段是作為整體存儲(chǔ)，它們非常適合用于聚合（如計(jì)數(shù)、求和、過濾唯一值等）和排序操作。由于不進(jìn)行分詞，keyword 類型字段不支持全文搜索，但可以進(jìn)行精確匹配查詢。
  
  keyword適用于需要進(jìn)行精確搜索的場(chǎng)景，比如標(biāo)簽、ID 編號(hào)、郵箱地址等。

• ES 不支持 decimal，如何避免丟失精度？

五種方法：

一：使用字符串類型（比較好用）

完全保留數(shù)字的精度。簡(jiǎn)單易于實(shí)現(xiàn)，數(shù)據(jù)遷移時(shí)不需特別處理。但是作為字符串存儲(chǔ)的數(shù)字不能直接用于數(shù)值比較或數(shù)學(xué)運(yùn)算，需要在應(yīng)用層處理轉(zhuǎn)換。但也不是什么大毛病。

二：擴(kuò)大浮點(diǎn)類型的精度

就是直接使用 double 類型，在理論上可能會(huì)有精度損失，但實(shí)際上 double 類型提供的精度對(duì)于許多業(yè)務(wù)需求已經(jīng)足夠使用。需要接受減小精度損失。

三：使用scaled_float（推薦）

Elasticsearch 的 scaled_float 類型是一種數(shù)值數(shù)據(jù)類型，專門用于存儲(chǔ)浮點(diǎn)數(shù)。其特點(diǎn)是通過一個(gè)縮放因子（scaling factor）將浮點(diǎn)數(shù)轉(zhuǎn)換為整數(shù)來存儲(chǔ)，從而在一定范圍內(nèi)提高存儲(chǔ)和計(jì)算的效率。他使用一個(gè)縮放因子將浮點(diǎn)數(shù)轉(zhuǎn)換為整數(shù)存儲(chǔ)。例如，如果縮放因子是 100，那么值 123.45 會(huì)存儲(chǔ)為 12345。這樣可以避免浮點(diǎn)數(shù)存儲(chǔ)和計(jì)算中的精度問題。

四：使用多個(gè)字段

在某些情況下，可以將 decimal 數(shù)值拆分為兩個(gè)字段存儲(chǔ)：一個(gè)為整數(shù)部分，另一個(gè)為小數(shù)部分。這樣做可以在不丟失精度的情況下，將數(shù)值分開處理?？梢员３?jǐn)?shù)值精確，同時(shí)可進(jìn)行部分?jǐn)?shù)學(xué)運(yùn)算。但是增加了數(shù)據(jù)處理的復(fù)雜性，需要在應(yīng)用層重建數(shù)值。

五：使用自定義腳本

用 Elasticsearch 的腳本功能（如 Painless 腳本）來處理數(shù)值計(jì)算，確保在處理過程中控制精度。優(yōu)點(diǎn)：靈活控制數(shù)據(jù)處理邏輯。缺點(diǎn)：可能影響查詢性能，增加系統(tǒng)復(fù)雜性。

四、實(shí)際應(yīng)用場(chǎng)景

1. 電商搜索

• 需求：支持顏色、品牌、價(jià)格區(qū)間等多維度過濾。

• 實(shí)現(xiàn)：

{
  "query": {
    "bool": {
      "must": [
        { "term": { "brand": "華為" } },
        { "range": { "price": { "gte": 1000, "lte": 2000 } } }
      ],
      "filter": { "term": { "color": "紅色" } }
    }
  },
  "aggs": {
    "price_stats": { "stats": { "field": "price" } }
  }
}

2. 日志告警

• 需求：實(shí)時(shí)檢測(cè)ERROR日志并觸發(fā)告警。

• 實(shí)現(xiàn)：

  • Watcher 插件定時(shí)查詢：

• {
    "query": { "match": { "level": "ERROR" } },
    "condition": { "compare": { "ctx.hits.total": { "gt": 0 } } },
    "actions": { "email": { "to": "admin@example.com" } }
  }

3. 數(shù)據(jù)同步容災(zāi)

• 雙寫方案：

  • 應(yīng)用同時(shí)寫MySQL和ES，通過本地事務(wù)表記錄同步狀態(tài)。

• 補(bǔ)償機(jī)制：

  • 定時(shí)任務(wù)掃描MySQL與ES差異數(shù)據(jù)，修復(fù)不一致。

五、性能調(diào)優(yōu)

集群和硬件優(yōu)化

負(fù)載均衡: 確保查詢負(fù)載在集群中均衡分配。

硬件資源: 根據(jù)需要增加 CPU、內(nèi)存或改善 I/O 性能（例如使用 SSD）。

配置 JVM: 優(yōu)化 JVM 設(shè)置，如堆大小，以提高性能。

• 硬件：SSD磁盤、32GB+內(nèi)存（堆內(nèi)存不超過31GB）。

• 索引設(shè)計(jì)：

• • 選擇合適的分詞器

    冷熱分離：hot-warm架構(gòu)（熱數(shù)據(jù)用SSD，冷數(shù)據(jù)用HDD）。

  • 生命周期管理（ILM）：自動(dòng)滾動(dòng)到新索引。

• 查詢優(yōu)化：

  • 避免wildcard、regexp查詢（如*test*）。

  • 使用constant_score過濾不相關(guān)文檔。

  • 使用過濾器: 對(duì)于不需要評(píng)分的查詢條件，使用 filter 而不是 query，因?yàn)?filter 可以被緩存以加快后續(xù)相同查詢的速度。

  • 合理使用聚合：聚合可以用于高效地進(jìn)行數(shù)據(jù)分析，但復(fù)雜的聚合也可能非常消耗資源。優(yōu)化聚合查詢，如通過限制桶的數(shù)量，避免過度復(fù)雜的嵌套聚合。

  • 查詢盡可能少的字段: 只返回查詢中需要的字段，減少數(shù)據(jù)傳輸和處理時(shí)間。

  • 避免深度分頁: 避免深度分頁，對(duì)于需要處理大量數(shù)據(jù)的情況，考慮使用 search_after。

總結(jié)

• 選型：ES適合搜索/分析，MySQL適合事務(wù)/精準(zhǔn)查詢。

• 核心能力：分詞器、倒排索引、分布式計(jì)算支撐高效查詢。

• 一致性：通過refresh、Canal同步等方案平衡實(shí)時(shí)性與性能。

• 實(shí)踐：結(jié)合業(yè)務(wù)場(chǎng)景選擇分頁策略、數(shù)據(jù)結(jié)構(gòu)、同步機(jī)制。

到此這篇關(guān)于為什么用ElasticSearch以及和傳統(tǒng)數(shù)據(jù)庫MySQL有什么區(qū)別的文章就介紹到這了,更多相關(guān)es和mysql對(duì)比內(nèi)容請(qǐng)搜索腳本之家以前的文章或繼續(xù)瀏覽下面的相關(guān)文章希望大家以后多多支持腳本之家！