儘可能不要把數據結構不一樣的數據放到同一索引中，而且能夠考慮將數據量較少的集合建立較少的分片存儲。固然若數據之間存在父子關係則例外，畢竟父子關係的數據不能存儲在不一樣的索引當中。node
1、索引速度
一、儘可能使用批量索引
二、客戶端儘可能使用多線程批量索引
三、增長刷新機制的間隔 默認是1s -1表明禁用Es從數據索引到能不查詢整個過程默認爲1s，使用index.refresh_interval參數控制。若對數據的實時性要求不高的話，可適當調整該參數到業務系統可接受的範圍。在該間隔時間內es會強制建立一個新的segment（段），時間間隔越大則建立的段也會越大，也減少了後續字段合併段的壓力（段其實的lucene底層的數據結構，詳細可查詢lucene與segment的關係）。
四、數據初始索引時禁用刷新和副本機制如有一大批數據須要索引的時候（前提條件），因爲刷新和副本機制對數據索引性能影響較大，能夠將index.refresh_interval設置爲-1，將index.number_of_replicas設置爲0以禁用該兩機制。直到本次數據所有索引完成後再將這兩個參數調整至合理的值，然而應該明白性能與數據安全老是不能同時獲得知足，徹底看業務數據的重要性。
五、禁止內存交換nginx
- 暫時禁用交換 sudo swapoff - a
- 永久禁用它 須要編輯該/etc/fstab文件並註釋掉包含該單詞的全部行swap
六、文件系統緩存的內存不能低於服務器的一半文件系統緩存將被用來緩衝輸入/輸出操做，這對於es來講很是的重要，要求內存不能少於服務器內存的一半，即es的jvm heap的值設置應該小於服務器內存的一半。
七、儘可能使用es自動生成的id做爲es的document id應該知道其做用第一是肯定文檔的惟一性，第二默認狀況下使用id做爲route值計算文檔應該被分配到哪一個shard，同時也是生成uid的成員。若索引時制定id的狀況下，會先檢測其惟一性，其代價是比較大的，而且隨着索引文檔數的增長消耗會愈來愈大，若沒有業務須要最好使用自動生成的id（會跳過檢查過程）。
九、索引緩存的大小
十、string類型字段不分詞
精細設置全文域：string類型字段默認會分詞，不只會額外佔用資源，並且會影響建立索引的速度。因此，把不須要分詞的字段設置爲not_analyzed
十一、 設置段合併的線程數量 ：
curl -XPUT 'your-es-host:9200/nginx_log-2018-03-20/_settings' -d '{
"index.merge.scheduler.max_thread_count" : 1
}'
十二、不用開啓http服務。將其中的配置 參數這樣設置：http.enabled: false
1三、Elastic官方文檔建議：一個Node中一個索引最好不要多於三個shards.配置total_shards_per_node參數，限制每一個index每一個節點最多分配多少個發片.
1四、分片（Shard）：一個索引會分紅多個分片存儲，分片數量在索引創建後不可更改，推薦【分片數*副本數=集羣數量】
1四、 段和合並Elasticsearch 默認設置在這塊比較保守：不但願搜索性能被後臺合併影響。不過有時候（尤爲是 SSD，或者日誌場景）限流閾值過低了。
默認值是 20 MB/s，對機械磁盤應該是個不錯的設置。若是你用的是 SSD，能夠考慮提升到 100–200 MB/s。測試驗證對你的系統哪一個值合適：
PUT /_cluster/settings
{
"persistent" : {
"indices.store.throttle.max_bytes_per_sec" : "100mb"
}
}緩存
能夠增大index.translog.flush_threshold_size參數，默認是200M，能夠增大到如1GB。
增大這個參數能夠容許translog在flush前存放更大的段(segment);更大的段的建立會減小flush的頻率，
而且更大的段合併越少，會減小磁盤IO，索引性能更高。安全
2、查詢速度
一、 查詢緩存
分片查詢緩存的主要目的是緩存聚合，提示詞和命中數（不會緩存返回的文檔）
若是想要開啓mastering索引的查詢緩存，能夠執行相似下面的操做
PUT /mastering/_settings
{ "index.requests.cache.enable": true }
二、 查詢緩存默認使用節點堆棧的1%內存，能夠經過下列方式對該值進行設置：
indices.requests.cache.size: 2%服務器