国产xxxx99真实实拍_久久不雅视频_高清韩国a级特黄毛片_嗯老师别我我受不了了小说

資訊專欄INFORMATION COLUMN

Elasticsearch 最佳實踐

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

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

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



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



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



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



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



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



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



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



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



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



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



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


本文作者：何  青

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

???

文章版權歸作者所有，未經允許請勿轉載,若此文章存在違規行為，您可以聯系管理員刪除。

轉載請注明本文地址：http://specialneedsforspecialkids.com/yun/129558.html

相關文章

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

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

    djfml 評論0 收藏0

  • mysql到elasticsearch數據遷移踩坑實踐-Ali0th

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

    littlelightss 評論0 收藏0

  • FastD 最佳實踐四: 構建系統可視化監控

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

    khlbat 評論0 收藏0

  • JHipster技術簡介

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

    hightopo 評論0 收藏0

發表評論

0條評論

IT那活兒

男|高級講師

TA的文章

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