ElasticSearch使用最佳實踐-集群規劃
1. 集群合理的規格
從業務側來看，主要是控制集群的shard數量，數據存儲量，segment數量在合理的范圍內。
1.單EsNode Shard數
以單EsNode實例31GB為例，管理500個shard為合理范圍。基于單EsNode數據量不超過15T及集群整體shard數不超過50000考慮。
2.Shard大小
每個分片大小20~30GB，最多不超過50G
3. 單集群數據實例數
推薦300以內，否則主節點管理壓力很大，集群穩定性和性能下降明顯
3.單集群支持的最大shard數
推薦50000以內，否則主節點管理壓力很大，集群穩定性和性能下降明顯
4.單EsNode實例，最大數據存儲量
推薦5TB以內，存儲數據過多會導致段文件占用過大內存
5.Segment數
segment個數合理范圍是分片數的1至5倍，段文件過多可以通過執行段文件合并命令
6.EsNode磁盤使用率
不允許超過85%，到達80%需要引起注意，及時擴容或老化數據
每個規格對應查看方式：
1.查看第1列shards：curl -XGET --tlsv1.2 --negotiate -k -u :? 'https://ip:port/_cat/allocation?v&s=disk.used:desc'
2.查看第6列store：? curl -XGET --tlsv1.2 --negotiate -k -u : ?'https://ip:port/_cat/shards?v&s=store'
3.查看number_of_data_nodes：? curl -XGET --tlsv1.2 --negotiate -k -u : ?'https://ip:port/_cluster/health?pretty'
4.查看active_shards：curl -XGET --tlsv1.2 --negotiate -k -u : ?'https://ip:port/_cluster/health?pretty'
5.查看第2列disk.indices：curl -XGET --tlsv1.2 --negotiate -k -u : 'https://ip:port/_cat/allocation?v&s=disk.used:desc'
6.列出所有索引的segement數量：curl -XGET --tlsv1.2 --negotiate -k -u : 'https://ip:port/_cat/segments?v'
段文件合并：
curl -XPOST --negotiate -k -u : https://ip:port/{index_name}/_forcemerge?max_num_segments=1
注意：segment merging要消耗CPU以及大量的I/O資源，建議在業務低峰期執行。
1. 查看第6列disk.percent：curl -XGET --tlsv1.2 --negotiate -k -u : 'https://ip:port/_cat/allocation?v&s=disk.used:desc'
2. 內存配置及實例個數建議
資源允許的情況下，單個實例分配的最大堆內存不要超過31GB，同時需要預留一半的物理內存作為Lucene緩存使用。以256GB內存為例，建議預留128GB內存供Lucene使用，剩余128GB內存可分配4個ES實例，每個實例分配31GB內存。
3. 創建索引建議
1）為了減少索引數量并避免非常龐大的映射，請考慮將相同索引結構的數據存儲在相同的索引中。
2）避免將不相關的數據放在同一個索引中，以避免稀疏，將這些文件放在不同的索引中通常會更好。
3）針對數據量比較大的索引，建議按周期進行分表，比如按天進行索引劃分。
4. 合理的mapping設置建議
寫入數據前進行合理的mapping設置是必須的：
1）elasticsearch可以對數據做動態mapping，但請不要這么做，盡量在創建index時便賦予index固定的mapping配置。設置動態mapping，當大量數據寫入的同時伴隨著新的字段的增加，會造成大量的put_mapping操作，從而造成EsMaster阻塞，影響整個ES集群的運行。不建議使用動態mapping，如果需要使用動態mapping，建議盡量使用較為精準的匹配規則，杜絕*通配符等暴力操作。
創建索引時指定動態mapping為false:
curl -XPUT --tlsv1.2 --negotiate -k -u : "https://127.0.0.1:24100/myindex" -H 'Content-Type: application/json' -d '
{
"mappings": {
"my_type": {
"dynamic":????? "false",
"properties": {
"title":? { "type": "text"},
"stash":? {
"type":???? "object",
"dynamic":? true
}
}
}
}
}'
如上條命令，指定dynamic策略時可以針對type和字段分別指定，且只能創建索引時指定。
2）如果數據量巨大，可以分的字段個數太多，如超過1000個字段，最好給字段賦予不同的級別索引到不同的index中。例如，常用的查詢字段可以寫入到一個index中，字段長度較長且不常用的索引到另一個index中。
3）合理的設計Mapping，根據實際的業務數據去設置優化Mapping，根據具體的字段和需求去選擇對應的類型設置，可參考如下幾點：
string類型默認分成：text和keyword兩種類型。需要分詞：text，否則keyword。
枚舉類型，基于性能keyword，即便是整形。
數值類型，盡量選擇貼近大小的類型。
日期類型，如果需要基于時間軸做分析，必須date類型，如果僅需秒級返回，建議使用keyword。
其他類型，布爾、日期、地理位置，使用對應的類型即可。
如果某個字段不需要被檢索，將“index”參數設置為“false”。
curl -XPUT --tlsv1.2 --negotiate -k -u : "https://127.0.0.1:24100/myindex" -H 'Content-Type: application/json' -d '
{
"mappings": {
"my_type": {
"properties": {
"content":? {
"type":"keyword",
"index": false
}
}
}
}
}'
“_all”字段，默認將寫入的字段拼接成一個大的字符串，并對該字段進行分詞，用于支持整個doc的全文檢索，“_all”字段能讓你在不知道要查找的內容是屬于哪個具體字段的情況下進行搜索，“_all”字段在查詢時占用更多的CPU，同時占用更多的磁盤存儲空間，默認為“false”，不建議開啟該字段。
curl -XPUT --tlsv1.2 --negotiate -k -u : "https://127.0.0.1:24100/myindex" -H 'Content-Type: application/json' -d '
{
"mappings": {
"my_type": {
"_all": {
"enable":? false
}
}
}
}'
norms字段，norm是索引評分因子，如果不用按評分對文檔進行排序，設置為“false”，默認是“true”。
curl -XPUT --tlsv1.2 --negotiate -k -u : "https://127.0.0.1:24100/myindex" -H 'Content-Type: application/json' -d '
{
"mappings": {
"my_type": {
"properties": {
"content":? {
"type":"keyword",
"norms": false
}
}
}
}
}'
_source字段，默認是開啟的，如果不需要update、reindex和高亮操作，可以禁止“_source”，節省更多的磁盤空間。
curl -XPUT --tlsv1.2 --negotiate -k -v -u : 'https://ip:httpport/myindex?pretty' -H 'Content-Type: application/json' -d'
{
"mappings": {
"tweet": {
"_source": {
"enabled": false
}
}
}
}'
5. 合理的setting設置建議
（1）?????修改索引刷新時間：默認為1s，即每1s都會將寫入到內存里面的數據刷新到磁盤里面，可修改為60s或者120s，減輕磁盤的IO壓力；
"refresh_interval" : "60s"
（2）?????修改Translog策略參數，默認translog的持久化策略默認為request，即每個請求都進行flush，影響ES寫入速度。將持久化策略改成async，表示按設置的sync_interval周期性進行刷新，同時調大translog刷盤間隔時間，默認為5s，調大至120s或者180s。調大translog flush的大小為3G，即大小超過3GB進行刷新操作；
"translog. durability ":" async "
"sync_interval": "180s"
"translog.flush_threshold_size":"3gb"
（3）?????設置index.type.store為niofs模式，可以減輕集群的IO負載；
"index.type.store" : "niofs"
（4）?????針對于5機器節點以上，為了讓各個實例上的分片均勻分布，添加如下參數，設置每個索引在單個實例上的分片個數，如下所示為每個索引在每個實例上的分片為2個。
"index.routing.allocation.total_shards_per_node":"2"
6. 數據的生命周期
ES中的open狀態的索引都會占用堆內存來存儲倒排索引，過多的索引會導致集群整體內存使用率多大，甚至引起內存溢出。所以需要根據自身業務管理歷史數據的生命周期，如近3個月的數據open用于快速查詢；過去3-6月的數據索引close以釋放內存，需要時再開啟；超過6個月的可以刪除索引。
可以使用索引模板的方式按照一定時間創建新的索引，例如按天創建索引，索引的命名可能是index-yyyy-mm-dd，每天生成不同的索引，清除歷史數據時可直接關閉或刪除。
EI企業智能 Elasticsearch FusionInsight
版權聲明：本文內容由網絡用戶投稿，版權歸原作者所有，本站不擁有其著作權，亦不承擔相應法律責任。如果您發現本站中有涉嫌抄襲或描述失實的內容，請聯系我們jiasou666@gmail.com 處理，核實后本網站將在24小時內刪除侵權內容。
相關文章
