es效能優化沒有什麼銀彈。不要指望調乙個引數，就可以萬能的應對所有場景。
做乙個快取預熱系統，專門用於對那些比較熱的資料，每隔一段時間訪問一下，讓資料進入filesystem cache。比如微博，看的人很多的資料；再比如電商的熱門商品p30。
大量的冷門資料乙個索引；熱資料另乙個索引。這可確保熱資料在被預熱後，盡量都留在filesystem os cache裡，別讓冷資料給沖刷掉。
訂單表：id、order_code、total_price
訂單條目表：id、order_id、goods_id、purchase_count、price
order索引：id、order_code、total_price
orderitem索引：id、order_code、total_price、id、order_id、goods_id、purchase_count、price
總之，對於太複雜的操作，比如join，nested，parent-child搜尋都要盡量避免。對於要執行一些複雜操作的思路：
1）在寫入時，就設計好模型，加幾個字段專門用於存放處理好的資料。
2）用es查出來，然後在程式中封裝。
sparkline 在大資料量下的應用
常在前端業務應用中，圖形視覺化方案大都是基於基本的幾種圖形型別，比如line,bar column,area,pie,scatter,heatmap,histogram 等等開發，輔以使用者可自定義的選項，來實現目的和功能比較明確和單一的圖形化需求。當單一的圖形化應用過於笨重，或者難以組合來達到更多...
面對十億資料量的技術挑戰，如何對系統進行效能優化？
這篇文章，我們來聊一聊在十億級的大資料量技術挑戰下，世界上最優秀的大資料系統之一的hadoop是如何將系統效能提公升數十倍的?首先一起來畫個圖，回顧一下hadoop hdfs中的超大資料檔案上傳的原理。其實說出來也很簡單，比如有個十億資料量級的超大資料檔案，可能都達到tb級了，此時這個檔案實在是太大...
mysql在百萬資料量下查詢慢的問題
這兩天，越來越覺得自己做的玩家歷史表，查詢速度很慢，開始還以為是網路的問題，然後持續了一兩天很快pass了這個想法。很可能是自己的查詢速度慢，於是進入資料庫看了一下，發現歷史記錄已經達到了600多萬條了。隨著dau的上公升，玩家越來越多，乃至於歷史記錄也成倍的增長，雖然自己做了定時刪除七天以前的記錄...