1.如果條件允許，內存和cpu一定要足夠多，要超過總數據量的1半以上最好，當然數據量很大的時候要在經常查詢數據的2倍以上。
2.數據分離存儲，經常查詢的數據放一些索引，不經常查詢的放一部分索引，然后通過唯一的id關聯即可，需要查那些不經常查的數據的時候通過id查詢即可，這里可以和hbase聯合使用。把條件字段和經常查看的字段放在es中，不經常查看的放hbase中，這樣既可以省es的空間，性能效果也俱佳
3.數據大時，每個索引的數據量不要太大，一般很大的時候可以每天一個索引，或者每月一個索引，具體看業務來選擇
4.進行數據預熱，即，每天或者定期后台去訪問那些經常查詢的數據，把它們加載到filesys_cache中去，因為es查詢時，如果緩存里有該數據就直接從緩存讀取，沒有就去硬盤把數據加載到該緩存中，下次再查時就快很多了，所以有時候es第一次查詢時會有點慢，后面就快很多了
5.es中不要做太復雜的查詢，尤其是關聯查詢，如果有些一定要關聯，關聯的條件也要盡量少，比如id即可
6.可以使用fitter過濾會快很多，盡量不要存為全文索引的數據類型，
7.es不適合做長期存儲，一般只挑近期的，常用的放進去即可，久遠的數據或者不常查詢的，可以放到hive中，那些查的少，肯定速度也不要求，所以放hive中最合適
8.查詢的時候當然是副本多一些比較好，但是一般3個副本就可以了，太多也不合適
9.有錢的話，多加一點cpu和內存是最好的，這是最實在的辦法，有錢了，有資源了，上面那些就顯得微不足到了。
10.另外es查詢的時候盡量不要排序，看情況而定吧，排序的時候可能會有點慢。
11.kibana是個好東西，很多功能足夠了，唯一的缺點就是不能進行權限控制，社區版已經具備不少功能了，當然有能力可以使用付費的，效果肯定更好，這是對沒有開發能力和不想花太多時間去寫es代碼的同學說的。有時間，當然自己寫一個系統來事先es查詢肯定定制化開發更好的。