目錄
什么是ElasticSearch？
ES和MySQL使用場景的比較
Elasticsearch和MySQL具體應用場景：
如何優(yōu)化：
索引效率優(yōu)化
批量提交
優(yōu)化硬件、
減少副本數(shù)量
查詢效率優(yōu)化
路由
不帶 routing 查詢
Filter VS Query
大翻頁
JVM 設置
TP5如何接入ElasticSearch？
什么是ElasticSearch？
Elasticsearch 是一個分布式、高擴展、高實時的搜索與數(shù)據(jù)分析
引擎。它能很方便的使大量數(shù)據(jù)具有搜索、分析和探索的能力。充分利用Elasticsearch的水平伸縮性，能使數(shù)據(jù)在生產(chǎn)環(huán)境變得更有價值。
Elasticsearch 的實現(xiàn)原理主要分為以下幾個步驟，首先用戶將數(shù)據(jù)提交到Elasticsearch 數(shù)據(jù)庫中，再通過分詞控制器去將對應的語句分詞，將其權重和分詞結果一并存入數(shù)據(jù)，當用戶搜索數(shù)據(jù)時候，再根據(jù)權重將結果排名，打分，再將返回結果呈現(xiàn)給用戶
簡而言之：Elasticsearch 則是一款分布式搜索和分析引擎。它可以幫助你快速搜索和分析海量數(shù)據(jù)，并提供了豐富的查詢語言和可視化工具。Elasticsearch 也支持 ACID 事務，但這并不是它的主要功能。
然而，這并不意味著 Elasticsearch 就不能用于存儲數(shù)據(jù)。實際上，Elasticsearch 可以作為一種 NoSQL 數(shù)據(jù)庫來使用，允許你將非結構化數(shù)據(jù)存儲在其中。但是，Elasticsearch 沒有 MySQL 那樣強大的數(shù)據(jù)模型和關系管理功能。因此，如果你需要一個用于存儲和管理復雜數(shù)據(jù)模型的工具，MySQL 可能更加適合。
ES和MySQL使用場景的比較
1、MySQL更擅長的是事務類型的操作，可以確保數(shù)據(jù)的安全和一致性；如果是有事務要求，如商品的下單支付等業(yè)務操作，無疑使用MySQL。
2、ES更擅長的是海量數(shù)據(jù)的搜索，分析和計算；如果是復雜搜索，無疑可以使用Elasticsearch。
3、兩者是一個互補而不是替代的關系。
Elasticsearch和MySQL具體應用場景：
MySQL 可以用于存儲和管理結構化數(shù)據(jù)，而 Elasticsearch 可以用于快速搜索和分析這些數(shù)據(jù)。在這種情況下，你可以將數(shù)據(jù)存儲在 MySQL 中，并使用 Elasticsearch 對數(shù)據(jù)進行搜索和分析。這樣，你就可以充分利用 MySQL 和 Elasticsearch 的優(yōu)勢，同時避免它們的劣勢。
MySQL 和 Elasticsearch 聯(lián)合使用，以提供更全面的功能。例如，可以使用 MySQL 存儲和管理結構化數(shù)據(jù)，并使用 Elasticsearch 對數(shù)據(jù)進行搜索和分析。還可以使用 MySQL 的觸發(fā)器和存儲過程，在數(shù)據(jù)發(fā)生變化時自動將數(shù)據(jù)同步到 Elasticsearch 中。這樣，就可以在 MySQL 和 Elasticsearch 之間建立聯(lián)系，實現(xiàn)數(shù)據(jù)的雙向同步。
如何優(yōu)化：
索引效率優(yōu)化
索引優(yōu)化主要是在 Elasticsearch 插入層面優(yōu)化，如果瓶頸不在這塊，而是在產(chǎn)生數(shù)據(jù)部分，比如 DB 或者 Hadoop 上，那么優(yōu)化方向就需要改變下。同時，Elasticsearch 本身索引速度其實還是蠻快的，具體數(shù)據(jù)，我們可以參考官方的 benchmark 數(shù)據(jù)。
批量提交
當有大量數(shù)據(jù)提交的時候，建議采用批量提交。
比如在做 ELK 過程中 ，Logstash indexer 提交數(shù)據(jù)到 Elasticsearch 中 ，batch size 就可以作為一個優(yōu)化功能點。但是優(yōu)化 size 大小需要根據(jù)文檔大小和服務器性能而定。
像 Logstash 中提交文檔大小超過 20MB ，Logstash 會請一個批量請求切分為多個批量請求。
如果在提交過程中，遇到 EsRejectedExecutionException 異常的話，則說明集群的索引性能已經(jīng)達到極限了。這種情況，要么提高服務器集群的資源，要么根據(jù)業(yè)務規(guī)則，減少數(shù)據(jù)收集速度，比如只收集 Warn、Error 級別以上的日志。
優(yōu)化硬件、
優(yōu)化硬件設備一直是最快速有效的手段。
在經(jīng)濟壓力能承受的范圍下， 盡量使用固態(tài)硬盤 SSD。SSD 相對于機器硬盤，無論隨機寫還是順序寫，都較大的提升。
磁盤備份采用 RAID0。因為 Elasticsearch 在自身層面通過副本，已經(jīng)提供了備份的功能，所以不需要利用磁盤的備份功能，同時如果使用磁盤備份功能的話，對寫入速度有較大的影響。
增加 Refresh 時間間隔
為了提高索引性能，Elasticsearch 在寫入數(shù)據(jù)時候，采用延遲寫入的策略，即數(shù)據(jù)先寫到內存中，當超過默認 1 秒 （index.refresh_interval）會進行一次寫入操作，就是將內存中 segment 數(shù)據(jù)刷新到操作系統(tǒng)中，此時我們才能將數(shù)據(jù)搜索出來，所以這就是為什么 Elasticsearch 提供的是近實時搜索功能，而不是實時搜索功能。
當然像我們的內部系統(tǒng)對數(shù)據(jù)延遲要求不高的話，我們可以通過延長 refresh 時間間隔，可以有效的減少 segment 合并壓力，提供索引速度。在做全鏈路跟蹤的過程中，我們就將 index.refresh_interval 設置為 30s，減少 refresh 次數(shù)。
同時，在進行全量索引時，可以將 refresh 次數(shù)臨時關閉，即 index.refresh_interval 設置為 -1，數(shù)據(jù)導入成功后再打開到正常模式，比如 30s。
減少副本數(shù)量
Elasticsearch 默認副本數(shù)量為 3 個，雖然這樣會提高集群的可用性，增加搜索的并發(fā)數(shù)，但是同時也會影響寫入索引的效率。
在索引過程中，需要把更新的文檔發(fā)到副本節(jié)點上，等副本節(jié)點生效后在進行返回結束。使用 Elasticsearch 做業(yè)務搜索的時候，建議副本數(shù)目還是設置為 3 個，但是像內部 ELK 日志系統(tǒng)、分布式跟蹤系統(tǒng)中，完全可以將副本數(shù)目設置為 1 個。
查詢效率優(yōu)化
路由
當我們查詢文檔的時候，Elasticsearch 如何知道一個文檔應該存放到哪個分片中呢？它其實是通過下面這個公式來計算出來
shard = hash(routing) % number_of_primary_shards
routing 默認值是文檔的 id，也可以采用自定義值，比如用戶 id。
不帶 routing 查詢
在查詢的時候因為不知道要查詢的數(shù)據(jù)具體在哪個分片上，所以整個過程分為 2 個步驟
分發(fā)：請求到達協(xié)調節(jié)點后，協(xié)調節(jié)點將查詢請求分發(fā)到每個分片上。
聚合: 協(xié)調節(jié)點搜集到每個分片上查詢結果，在將查詢的結果進行排序，之后給用戶返回結果。
帶 routing 查詢
查詢的時候，可以直接根據(jù) routing 信息定位到某個分配查詢，不需要查詢所有的分配，經(jīng)過協(xié)調節(jié)點排序。
向上面自定義的用戶查詢，如果 routing 設置為 userid 的話，就可以直接查詢出數(shù)據(jù)來，效率提升很多。
Filter VS Query
Ebay 曾經(jīng)分享過他們使用 Elasticsearch 的經(jīng)驗中說到：
Use filter context instead of query context if possible.
盡可能使用過濾器上下文（Filter）替代查詢上下文（Query
Query：此文檔與此查詢子句的匹配程度如何？
Filter：此文檔和查詢子句匹配嗎？
Elasticsearch 針對 Filter 查詢只需要回答「是」或者「否」，不需要像 Query 查詢一下計算相關性分數(shù)，同時 Filter 結果可以緩存。
大翻頁
在使用 Elasticsearch 過程中，應盡量避免大翻頁的出現(xiàn)。
正常翻頁查詢都是從 From 開始 Size 條數(shù)據(jù)，這樣就需要在每個分片中查詢打分排名在前面的 From + Size 條數(shù)據(jù)。協(xié)同節(jié)點收集每個分配的前 From + Size 條數(shù)據(jù)。協(xié)同節(jié)點一共會受到 N * （ From + Size ）條數(shù)據(jù)，然后進行排序，再將其中 From 到 From + Size 條數(shù)據(jù)返回出去。
如果 From 或者 Size 很大的話，導致參加排序的數(shù)量會同步擴大很多，最終會導致 CPU 資源消耗增大。
可以通過使用 Elasticsearch scroll 和 scroll-scan 高效滾動的方式來解決這樣的問題。具體寫法，可以參考 ?Elasticsearch: 權威指南 - scroll 查詢
JVM 設置
32G 現(xiàn)象
Elasticsearch 默認安裝后設置的堆內存是 1 GB。 對于任何一個業(yè)務部署來說， 這個設置都太小了。
比如機器有 64G 內存，那么我們是不是設置的越大越好呢？
其實不是的。
主要 Elasticsearch 底層使用 Lucene。Lucene 被設計為可以利用操作系統(tǒng)底層機制來緩存內存數(shù)據(jù)結構。 Lucene 的段是分別存儲到單個文件中的。因為段是不可變的，這些文件也都不會變化，這是對緩存友好的，同時操作系統(tǒng)也會把這些段文件緩存起來，以便更快的訪問。
如果你把所有的內存都分配給 Elasticsearch 的堆內存，那將不會有剩余的內存交給 Lucene。 這將嚴重地影響全文檢索的性能。
標準的建議是把 50％ 的可用內存作為 Elasticsearch 的堆內存，保留剩下的 50％。當然它也不會被浪費，Lucene 會很樂意利用起余下的內存。
同時了解過 ES 的同學都聽過過「不要超過 32G」的說法吧。
其實主要原因是 ：JVM 在內存小于 32 GB 的時候會采用一個內存對象指針壓縮技術。
在 Java 中，所有的對象都分配在堆上，并通過一個指針進行引用。 普通對象指針（OOP）指向這些對象，通常為 CPU 字長 的大?。?2 位或 64 位，取決于你的處理器。指針引用的就是這個 OOP 值的字節(jié)位置。
對于 32 位的系統(tǒng)，意味著堆內存大小最大為 4 GB。對于 64 位的系統(tǒng)， 可以使用更大的內存，但是 64 位的指針意味著更大的浪費，因為你的指針本身大了。更糟糕的是， 更大的指針在主內存和各級緩存（例如 LLC，L1 等）之間移動數(shù)據(jù)的時候，會占用更多的帶寬.
所以最終我們都會采用 31 G 設置
-Xms 31g
-Xmx 31g
假設你有個機器有 128 GB 的內存，你可以創(chuàng)建兩個節(jié)點，每個節(jié)點內存分配不超過 32 GB。 也就是說不超過 64 GB 內存給 ES 的堆內存，剩下的超過 64 GB 的內存給 Lucene
TP5如何接入ElasticSearch？
安裝環(huán)境：window安裝為列，Elasticsearch版本Elasticsearch7.14.1
官方下載地址?Download Elasticsearch | Elastic
1、下載后解壓安裝包
2、打開config->修改elasticsearch.yml
3、修改配置elasticsearch.yml允許外部訪問
http.cors.enabled: true
http.cors.allow-origin: "*"
http.cors.allow-methods: OPTIONS, HEAD, GET, POST, PUT, DELETE
http.cors.allow-headers: "X-Requested-With, Content-Type, Content-Length, X-User"
4、運行es雙擊以下文件即可
?
5 、使用head可視化插件，解壓直接雙擊即可，點擊連接可以查看是否連接成功
看到以下頁面恭喜你安裝成功了
6、tp5安裝es擴展使用即可
composer require elasticsearch/elasticsearch
<?php
namespace app\index\controller;
use think\Db;
use Elasticsearch\ClientBuilder;
class Es
{
private $client;
public function __construct()
{
$this->client = ClientBuilder::create()->setHosts(['localhost:9200'])->build();
dump($this->client);
}
}
看到以下界面說明你成功完成了es和php配置es的安裝完整流程
好了，今天的干貨有點多，有問題的留個言，別忘了一鍵三連，下次我們還會再見！文章來源：http://www.zghlxwxcb.cn/news/detail-792050.html
我是黃啊碼，碼字的碼，退。。。退。。。退。。。朝！?文章來源地址http://www.zghlxwxcb.cn/news/detail-792050.html
到了這里，關于【黃啊碼】什么是ElasticSearch？它會替代MySQL成為主流嗎？如何優(yōu)化？TP5如何接入ElasticSearch？的文章就介紹完了。如果您還想了解更多內容，請在右上角搜索TOY模板網(wǎng)以前的文章或繼續(xù)瀏覽下面的相關文章，希望大家以后多多支持TOY模板網(wǎng)！
