亚洲中字慕日产2020,大陆极品少妇内射AAAAAA,无码av大香线蕉伊人久久,久久精品国产亚洲av麻豆网站

資訊專欄INFORMATION COLUMN

Elasticsearch 最佳實踐

IT那活兒 / 2585人閱讀
Elasticsearch 最佳實踐

點擊上方“IT那活兒”，關注后了解更多內(nèi)容，不管IT什么活兒，干就完了！??！

Elasticsearch是一個基于Apache Lucene的開源搜索引擎。無論在開源還是專有領域，Lucene可以被認為是迄今為止最先進、性能最好的、功能最全的搜索引擎庫。
它有如下特點：
  • 分布式的實時文件存儲，每個字段都被索引并可被搜索；
  • 分布式的實時分析搜索引擎--做不規(guī)則查詢；
  • 可以擴展到上百臺服務器，處理PB級結構化或非結構化數(shù)據(jù)。
生產(chǎn)環(huán)境的elasticsearch安裝是一個多節(jié)點的集群模式，一個節(jié)點(node)就是一個Elasticsearch實例，而一個集群(cluster)由一個或多個節(jié)點組成，它們具有相同的cluster.name，它們協(xié)同工作，分享數(shù)據(jù)和負載。
本文將自底向上的逐步推薦所謂的“最佳實踐”配置，畢竟拋開業(yè)務場景數(shù)據(jù)量等因素談所謂的“最佳實踐”其實都是耍流氓。但如果你對elasticsearch集群所需承載的業(yè)務或數(shù)據(jù)規(guī)模不是很清楚的時候，按本文比較常用的設置來安裝集群，是可以滿足絕大多數(shù)的應用場景的，本文所謂的“最佳實踐”也是基于此。



1. 節(jié)點數(shù)量
elasticsearch一般是用于構建業(yè)務的搜索需求，而且是垂直領域的搜索，在數(shù)據(jù)量橫跨幾千萬到數(shù)十億的級別的場景下，一般3-6臺的節(jié)點規(guī)模是安全的節(jié)點數(shù)量。
當用于大規(guī)模數(shù)據(jù)的實時OLAP（統(tǒng)計處理分析），比如elk stack和BI等，數(shù)據(jù)規(guī)?？赡軙_到千億甚至更多，此時我們elasticsearch的集群數(shù)量可能就會需要幾十上百臺的規(guī)模才能滿足了。
綜上，同時考慮我們elasticsearch集群擁有足夠優(yōu)秀的橫向擴展能力，所以我們在安裝elasticsearch集群時，可以使用5節(jié)點集群，當業(yè)務擴展性能瓶頸時，我們可以對集群進行擴容，增加節(jié)點數(shù)量。



2. 服務器硬件
CPU: 大多數(shù)的ES集群對cpu的要求并不高，一般當前時期服務器市場上中等甚至中等偏低的CPU都能滿足。
內(nèi)存：ES對內(nèi)存要求較高，主要不是吃JVM內(nèi)存，而是OS cache，ES會將頻繁訪問的一些數(shù)據(jù)緩存在操作系統(tǒng)內(nèi)存中，以達到較高的訪問效率，推薦機器內(nèi)存64G+。
磁盤：推薦使用SSD或者使用本地SAS盤或SATA盤存儲，轉(zhuǎn)速越高越好，磁盤選型可以在性能和成本因素中綜合考量，如對性能要求不十分苛刻的情況下，推薦使用廉價經(jīng)濟的SATA盤，容量可以依據(jù)數(shù)據(jù)規(guī)劃來存儲（規(guī)劃方法見本條下方），如無規(guī)劃，推薦使用2T-4T的SATA盤。
切記不要給ES使用NAS盤。
綜上，我們建議使用同時期的主流中等配置的機器，不建議使用過于強勁的硬件配置，不建議在一臺服務器上運行多個節(jié)點，因為一旦一臺服務器產(chǎn)生故障，會對集群產(chǎn)生比較大的影響，恢復的速度也會更慢。
（數(shù)據(jù)規(guī)劃方法：常用的經(jīng)驗計算法為磁盤容量大小=原始數(shù)據(jù)大小*3.38。也即假設一條文檔數(shù)據(jù)1k，預計數(shù)據(jù)量有10億條，那么會有100G的原始數(shù)據(jù)大小，磁盤占用預計是300G）。



3. 網(wǎng)絡
推薦單個集群不要跨數(shù)據(jù)中心進行部署（不要使用WAN），節(jié)點之間的hops越少越好。
如果有多塊網(wǎng)卡，最好將transport和 http綁定到不同的網(wǎng)卡，并設置不同的防火墻Rules，按需為Coordinating Node 或 Ingest Node配置負載均衡。



4. 集群角色規(guī)劃
一個節(jié)點node可以充當一個或多個角色，默認配置是三個角色（master節(jié)點、協(xié)調(diào)節(jié)點、數(shù)據(jù)節(jié)點）都有。
協(xié)調(diào)節(jié)點即凡是接收客戶端請求處理的默認就是協(xié)調(diào)節(jié)點，如果集群的負載較重時，可以將協(xié)調(diào)節(jié)點多帶帶抽取出來作為獨立角色部署。
一般我們將10節(jié)點作為小規(guī)模和中等規(guī)模分界點，一般小規(guī)模集群（小于10節(jié)點），我們無需嚴格進行區(qū)分，混合部署就可以了。中大規(guī)模集群（超過10節(jié)點甚至更多），則應該考慮多帶帶的角色，一般一臺服務器只部署一個node，當并發(fā)查詢量過大時，考慮增加獨立的協(xié)調(diào)節(jié)點。角色分開的好處是分工分開，互不影響。



5. 堆內(nèi)存設置及優(yōu)化建議
5.1 堆內(nèi)存設置
不要超過 32 GB，如果服務器內(nèi)存充足，可以設置為32G。
堆對于Elasticsearch絕對重要，它被許多內(nèi)存數(shù)據(jù)結構用來提供快速操作。
但還有另外一個非常重要的內(nèi)存使用者：Lucene。
Lucene旨在利用底層操作系統(tǒng)來緩存內(nèi)存中的數(shù)據(jù)結構。Lucene段(segment)存儲在單個文件中。因為段是一成不變的，所以這些文件永遠不會改變。這使得它們非常容易緩存，并且底層操作系統(tǒng)將愉快地將熱段（hot segments）保留在內(nèi)存中以便更快地訪問。這些段包括倒排索引（用于全文搜索）和文檔值（用于聚合）。
Lucene的性能依賴于與操作系統(tǒng)的這種交互。但是如果你把所有可用的內(nèi)存都給了Elasticsearch的堆，那么Lucene就不會有任何剩余的內(nèi)存。這會嚴重影響性能。
標準建議是將可用內(nèi)存的50％提供給Elasticsearch堆，而將其他50％空閑。它不會被閑置; Lucene會高興地吞噬掉剩下的東西。
JVM設定:
從ES 6開始，只支持64位的JVM，配置config/jvm.options，將內(nèi)存Xms和Xmx設置成一樣，避免heap resize時引發(fā)停頓。
5.2 堆內(nèi)存優(yōu)化建議
1）最好的辦法是在系統(tǒng)上完全禁用交換。
可以暫時用如下命令完成：
若要永久禁用它，需要在/etc/fstab中設置。
2）控制操作系統(tǒng)嘗試交換內(nèi)存的積極性。
如果完全禁用交換不是一種選擇，可以嘗試降低swappiness。該值控制操作系統(tǒng)嘗試交換內(nèi)存的積極性。這可以防止在正常情況下交換，但仍然允許操作系統(tǒng)在緊急內(nèi)存情況下進行交換。
對于大多數(shù)Linux系統(tǒng)，這是使用sysctl值配置的：
vm.swappiness = 1
注意：1的swappiness優(yōu)于0，因為在某些內(nèi)核版本上，swappiness為0可以調(diào)用OOM殺手。
3）mlockall允許JVM鎖定其內(nèi)存并防止其被操作系統(tǒng)交換。
最后，如果兩種方法都不可行，則應啟用mlockall文件。這允許JVM鎖定其內(nèi)存并防止其被操作系統(tǒng)交換。在elasticsearch.yml中，設置這個：



6. 數(shù)據(jù)目錄設置
數(shù)據(jù)目錄可以在配置中本地指定多個“path.data”，以支持使用多塊磁盤，如
path.data：/data01/es,/data02/es,/data03/es,/data04/es,/data05/es,/data06/es
因ES本身提供了很好的HA機制，所以我們無需對數(shù)據(jù)盤使用任何的RAID 1/5/10等冗余措施。
我們可以在Warm節(jié)點上使用Spinning Disk，但是需要關閉Concurrent Merges Index.merge.scheduler.max_thread_count: 1。



7. 索引設計
業(yè)務的索引設計至關重要一般要根據(jù)業(yè)務的場景來決定核心是要避免單個TB級甚至PB級的索引，大索引一般要進行拆分到GB級別，比如海量的日志場景可以采用Template+rollover+curator滾動創(chuàng)建索引，動態(tài)使用后的效果如下：
具體操作就是在索引模板的設計階段，定義一個全局變量名：用途是全局檢索，比如test_sms，每次更新到新的索引后，新索引指向一個用于實時新數(shù)據(jù)寫入的別名test_sms_2022.03.05，同時將舊索引的別名test_sms_2022.03.01移除。然后再通過curator按照日期定期刪除，歸檔歷史數(shù)據(jù)。



8. 分片及副本設置
合理的建議：每個分片數(shù)據(jù)大?。?0GB-50GB
分片是 Elasticsearch 在集群內(nèi)分發(fā)數(shù)據(jù)的單位。集群發(fā)生故障再恢復平衡的速度取決于分片的大小、分片數(shù)量、網(wǎng)絡以及磁盤性能。
在 Elasticsearch 中，每個查詢在每個分片的單個線程中執(zhí)行。但是，可以并行處理多個分片。針對同一分片的多個查詢和聚合也可以并行處理。
這意味著在不涉及緩存的情況下，最小查詢延遲將取決于數(shù)據(jù)、查詢類型以及分片的大小三個因素。
8.1 查詢很多小分片vs查詢少量大分片
查詢很多小分片，導致每個分片能做到快速響應，但是由于需要按順序排隊和處理結果匯集。因此不一定比查詢少量的大分片快。
如果存在多個并發(fā)查詢，那么擁有大量小分片也會降低查詢吞吐量。
8.2 分片數(shù)設定
選擇正確數(shù)量的分片是一個復雜問題，因為在集群規(guī)劃階段以及在數(shù)據(jù)寫入開始之前，一般不能確切知道文檔數(shù)。
對于集群而言，分片數(shù)多了以后，索引和分片管理可能會使主節(jié)點超載，并可能會導致集群無響應，甚至導致集群宕機。
建議：為主節(jié)點（Master 節(jié)點）分配足夠的資源以應對分片數(shù)過多可能導致的問題。
必須強調(diào)的是：主分片數(shù)是在索引創(chuàng)建時定義的，不支持借助 update API 實現(xiàn)類副本數(shù)更新的動態(tài)修改。創(chuàng)建索引后，更改主分片數(shù)的唯一方法是重新創(chuàng)建索引，然后將原來索引數(shù)據(jù) reindex 到新索引。
所以官方給出的合理的建議：每個分片數(shù)據(jù)大?。?0GB-50GB
8.3 副本設置
Elasticsearch 通過副本實現(xiàn)集群的高可用性，數(shù)據(jù)在數(shù)據(jù)節(jié)點之間復制，以實現(xiàn)主分片數(shù)據(jù)的備份，因此即便部分節(jié)點因異常下線也不會導致數(shù)據(jù)丟失。
默認情況下，副本數(shù)為 1，但可以根據(jù)產(chǎn)品高可用要求將其增加。副本越多，數(shù)據(jù)的容災性越高。
副本多的另一個優(yōu)點是，每個節(jié)點都擁有一個副本分片，有助于提升查詢性能。
建議：根據(jù)業(yè)務實際綜合考慮設置副本數(shù)。普通業(yè)務場景（非精準高可用）副本設置為 1 足夠了。
修改索引副本數(shù)：
PUT index/_settings
{
   "number_of_replicas": 1
}
查看索引分片：
GET index/_settings



9. 冷熱集群架構配置
根據(jù)產(chǎn)品業(yè)務數(shù)據(jù)特定和需求，我們可以將數(shù)據(jù)分為熱數(shù)據(jù)和冷數(shù)據(jù)，這是冷熱集群架構的前提。
訪問頻率更高的索引可以分配更多更高配（如：SSD）的數(shù)據(jù)節(jié)點，而訪問頻率較低的索引可以分配低配（如：機械磁盤）數(shù)據(jù)節(jié)點。
冷熱集群架構對于存儲諸如應用程序日志或互聯(lián)網(wǎng)實時采集數(shù)據(jù)（基于時間序列數(shù)據(jù)）特別有用。
數(shù)據(jù)遷移策略：通過運行定時任務來實現(xiàn)定期將索引移動到不同類型的節(jié)點。具體實現(xiàn)為使用curator工具或借助ILM 索引生命周期管理。



10. 集群安全設定
為Elasticsearch和 Kibana 配置安全功能，打開Authentication & Authorization，實現(xiàn)索引和和字段級的安全控制，節(jié)點間通信加密，Enable HTTPS，Audit logs。



11. 慢日志
慢日志的目的是捕獲那些超過指定時間閾值的查詢和索引請求。這個日志用來追蹤由用戶產(chǎn)生的很慢的請求很有用。
默認情況，慢日志是不開啟的。要開啟它，需要定義具體動作（query，fetch 還是 index），期望的事件記錄等級（ WARN 、 DEBUG 等），以及時間閾值。這是一個索引級別的設置，也就是說可以獨立應用給單個索引：
也可以在 elasticsearch.yml 文件里定義這些閾值。沒有閾值設置的索引會自動繼承在靜態(tài)配置文件里配置的參數(shù)。一旦閾值設置過了，你可以和其他日志器一樣切換日志記錄等級：


本文作者：何  青

本文來源：IT那活兒（上海新炬王翦團隊）

???

文章版權歸作者所有，未經(jīng)允許請勿轉(zhuǎn)載,若此文章存在違規(guī)行為，您可以聯(lián)系管理員刪除。

轉(zhuǎn)載請注明本文地址：http://www.ezyhdfw.cn/yun/129558.html

相關文章

  • FastD 最佳實踐五: 構建ELK日志分析

    摘要：點擊前往中文地址先決條件簡單安裝下載地址下載或者其他都可以。版本處理方案新建格式日志文件。配置日志會隨著配置進行生成，結果如下忽略上述日志內(nèi)容，程序看得懂即可配置推送到需要根據(jù)業(yè)務場景進行配置，現(xiàn)在顯示最簡單的配置。 過去咱們開發(fā)中，對日志這個環(huán)節(jié)其實并不太重視，直到有一天，應用出現(xiàn)異常，這個時候才想起來日志，但很可惜，為時已晚。 咱們做運維和開發(fā)，除了救火，還需要防火，因此一些防范的...

    djfml 評論0 收藏0

  • mysql到elasticsearch數(shù)據(jù)遷移踩坑實踐-Ali0th

    摘要：配置文件其中有兩個關鍵的配置和。啟動如上即為正常運行。因為我在啟動后一直報錯，，各種嘗試最后報錯依然存在，只好換用部署了。安裝部署安裝和插件獲取驅(qū)動下載配置配置使用時自行把下面注釋去掉。Author : Ali0th Date : 20190514 最近用go語言寫了個爬蟲，爬了幾百萬條數(shù)據(jù)，存在 mysql 里，數(shù)據(jù)量較大，一個表就一兩G的程度(mysql表一般不要超過2G)。 sho...

    littlelightss 評論0 收藏0

  • FastD 最佳實踐四: 構建系統(tǒng)可視化監(jiān)控

    摘要：的展示非常炫酷，絕對是運維提升逼格的一大利器。另外的可視化功能比強得多，而且以上版本將集成報警功能。它由寫成，著力于高性能地查詢與存儲時序型數(shù)據(jù)。被廣泛應用于存儲系統(tǒng)的監(jiān)控數(shù)據(jù)，行業(yè)的實時數(shù)據(jù)等場景。 原有監(jiān)控系統(tǒng) showImg(https://segmentfault.com/img/remote/1460000011082384); 整個系統(tǒng)以 Graphite (carbon ...

    khlbat 評論0 收藏0

  • JHipster技術簡介

    摘要：本文簡單介紹是什么，為什么用，怎么用。技術棧是什么是一個開發(fā)平臺，用于生成，開發(fā)，部署和。實現(xiàn)需定制化源碼。 本文簡單介紹Jhipster是什么，為什么用Jhipster，怎么用Jhipster。 WHAT - 技術棧 JHipster是什么 JHipster是一個開發(fā)平臺，用于生成，開發(fā)，部署Spring Boot + Angular/React Web Application和Sp...

    hightopo 評論0 收藏0

發(fā)表評論

0條評論

IT那活兒

男|高級講師

TA的文章

閱讀更多
最新活動
閱讀需要支付1元查看
<