1.es 一臺機器一般爲一個節點。一臺機器不設置的情況下是無法創建副本集的，副本集和主本必須不在一個節點下，方便故障轉移等
2.es7.x後一個索引後只能創建一個類型，可以通過修改更改
出現這個的原因是，elasticsearch7默認不在支持指定索引類型，默認索引類型是_doc，如果想改變，則配置include_type_name: true 即可(這個沒有測試，官方文檔說的，無論是否可行，建議不要這麼做，因爲elasticsearch8後就不在提供該字段)。官方文檔：https://www.elastic.co/guide/en/elasticsearch/reference/current/removal-of-types.html
3.創建索引定義數據類型 相當於sqlserver中的創建表
postman工具來進行請求發送
{ "settings": { "number_of_shards": 3, "number_of_replicas": 0 }, "mappings": { "properties": { "wordid": { "type": "integer" }, "word": { "type": "text" }, "wordsign": { "type": "long" }, "wordhint": { "type": "integer" }, "searchcount": { "type": "integer" }, "createtime": { "type": "date", "format": "yyyy-MM-dd HH:mm:ss||yyyy-MM-dd||epoch_millis" }, "appstoreids": { "type": "nested", "properties": { "appstoreid": { "type": "long" }, "rank": { "type": "integer" }, "apptype": { "type": "integer" }, "change":{ "type":"integer" }, "isnew":{ "type":"integer" } } } } } }
4.es的數據類型
//修改默認查詢條數 不過不起作用好像
alarm/_settings
{
"max_result_window" : 200000000
}
2. 開啓最佳壓縮
對於打開了上述_source字段的index，可以通過下面的命令來把lucene適用的壓縮算法替換成 DEFLATE，提高數據壓縮率。
http://127.0.0.1:9200/searchresult/_settings
{
"index.codec": "best_compression"
}
3. bulk批量寫入
寫入數據時儘量使用下面的bulk接口批量寫入，提高寫入效率。每個bulk請求的doc數量設定區間推薦爲1k~1w，具體可根據業務場景選取一個適當的數量。
4. 調整translog同步策略
默認情況下，translog的持久化策略是，對於每個寫入請求都做一次flush，刷新translog數據到磁盤上。這種頻繁的磁盤IO操作是嚴重影響寫入性能的，如果可以接受一定概率的數據丟失（這種硬件故障的概率很小），可以通過下面的命令調整 translog 持久化策略爲異步週期性執行，並適當調整translog的刷盤週期。
http://127.0.0.1:9200/searchresult/_settings
{
"index": {
"translog": {
"sync_interval": "5s",
"durability": "async"
}
}
}
5. 調整refresh_interval
寫入Lucene的數據，並不是實時可搜索的，ES必須通過refresh的過程把內存中的數據轉換成Lucene的完整segment後，纔可以被搜索。默認情況下，ES每一秒會refresh一次，產生一個新的segment，這樣會導致產生的segment較多，從而segment merge較爲頻繁，系統開銷較大。如果對數據的實時可見性要求較低，可以通過下面的命令提高refresh的時間間隔，降低系統開銷。
http://127.0.0.1:9200/searchresult/_settings
{
"index": {
"refresh_interval": "30s"
}
}
6. merge併發控制
ES的一個index由多個shard組成，而一個shard其實就是一個Lucene的index，它又由多個segment組成，且Lucene會不斷地把一些小的segment合併成一個大的segment，這個過程被稱爲merge。默認值是Math.max(1, Math.min(4, Runtime.getRuntime().availableProcessors() / 2))，當節點配置的cpu核數較高時，merge佔用的資源可能會偏高，影響集羣的性能，可以通過下面的命令調整某個index的merge過程的併發度：
PUT /my_index/_settings
{
"index.merge.scheduler.max_thread_count": 2
}
7. 寫入數據不指定_id，讓ES自動產生
當用戶顯示指定_id寫入數據時，ES會先發起查詢來確定index中是否已經有相同_id的doc存在，若有則先刪除原有doc再寫入新doc。這樣每次寫入時，ES都會耗費一定的資源做查詢。如果用戶寫入數據時不指定doc，ES則通過內部算法產生一個隨機的_id，並且保證_id的唯一性，這樣就可以跳過前面查詢_id的步驟，提高寫入效率。
所以，在不需要通過_id字段去重、update的使用場景中，寫入不指定_id可以提升寫入速率。騰訊雲CES技術團隊的測試結果顯示，無_id的數據寫入性能可能比有_id的高出近一倍，實際損耗和具體測試場景相關。
3. 禁止swap，一旦允許內存與磁盤的交換，會引起致命的性能問題。 通過： 在elasticsearch.yml 中 bootstrap.memory_lock: true， 以保持JVM鎖定內存，保證ES的性能。
對於數據量較小（100GB以下）的index，往往寫入壓力查詢壓力相對較低，一般設置3~5個shard，number_of_replicas設置爲1即可（也就是一主一從，共兩副本） 。
對於數據量較大（100GB以上）的index：
一般把單個shard的數據量控制在（20GB~50GB）
讓index壓力分攤至多個節點：可通過index.routing.allocation.total_shards_per_node參數，強制限定一個節點上該index的shard數量，讓shard儘量分配到不同節點上
綜合考慮整個index的shard數量，如果shard數量（不包括副本）超過50個，就很可能引發拒絕率上升的問題，此時可考慮把該index拆分爲多個獨立的index，分攤數據量，同時配合routing使用，降低每個查詢需要訪問的shard數量。
//複製索引和數據
http://127.0.0.1:9200/_reindex
{
"source": {
"index": "searchresult"
},
"dest": {
"index": "searchresult2"
}
}