elasticsSearch學習筆記

1、前言

在分佈式搜索引擎中，elasticsSearch逐漸變成一種標準了，其經過簡單連貫的RESTful API讓全文搜索變得簡單並隱藏Lucene的複雜性。但底層仍是使用Lucene來實現搜索功能。

2、核心概念

• index: 索引，是一類數據的抽象。
• type: 類型，是一類數據的具體抽象。更多狀況一個index只對應一個type，type相似數據庫中的一張表，而且在邏輯定義上也常常是1對1的關係，如elasticsSearch的type中存訂單數據須要被搜索的字段，而且有一個字段是訂單號，咱們經過字段搜索到訂單號後一般會在數據庫再查一次，返回詳情。
• document: 與Lucene裏面的Document同樣，就是表示能夠被搜索的一條數據。
• field：與Lucene裏面的field同樣，表示的是document的每一個字段。
• shard：elasticsSearch集羣中存儲數據的基本單位單位，一個索引有多個shard，在集羣中不能夠再次被分隔。
• 協調節點：集羣中任意節點均可以接受客戶端請求，接受請求的節點稱爲協調節點。
• segmentFile: shard中數據持久化的磁盤文件，一個shard對應多個segmentFile。
• fsync：Unix系統調用函數, 用來將內存緩衝區buffer中的數據存儲到文件系統. 這裏具體是指將文件緩存cache中的全部segment刷新到磁盤的操做。

3、基本原理

1.分佈式策略

（1）數據分佈

索引建立能夠指定分片的數量以及副本的數量，分片數量在建立以後沒法改變，副本數量在以後能夠改變，隨着集羣中節點的增長與刪除，各個分片與副本會從新分配到各個節點中。分片和副本不會分配到一個節點上，分片經過hash算法平均分佈在各個節點上，也能夠自定義分片分佈規則（讓在集羣的某些節點和某個節點建立分片），如經過自定義分片分佈規則實現冷熱分離提升性能。由於這種分片機制，咱們能夠經過增長集羣中節點保證一臺機器的分片不會太多提升搜索性能。

（2）高可用

集羣中會自動選舉一個master節點，master節點的主要做用是管理集羣，維護索引元數據等。master掛掉，集羣從新選舉master節點，master節點而後切換節點的身份爲master。

（3）寫和讀

寫請求被路由到只往primaryShard寫，而後會自動同步到replicaShard，讀的話primaryShard和replicaShard讀均可以。

2.基本原理

（1）寫入過程

協調節點接收到寫入請求，將寫入請求數據經過哈希算法路由到對應的shard的primaryShard上去。primaryShard的節點接收到請求數據，首先把segment fiel以及transLog（事務日誌）寫入本身的應用內存buffer當中，而後默認每隔1s,將buffer中的數據refresh數據到osCache（文件系統緩存）中。此時客戶端就能查詢到數據了。這個過程很是快，由於並無涉及到數據的持久化（因此是準實時的）。當translog文件過大或達到必定時間（默認30分鐘）會觸發flush操做，flush操做會將segmentfile統一flush到磁盤文件，同時生成一個commitpoint,記錄生成的segmentfile，而後清空translog。

注意：

• 故障恢復時，elasticsSearch將根據當前的commitpoint文件加載segmentFile（恢復搜索功能），而後經過translog事務日誌，重作全部操做來恢復數據。
• 當數據尚且在buffer或osCache、translog也在osCache中時可能會丟數據，也可設定參數保證數據不丟失，但會犧牲吞吐量和性能。Elasticsearch 2.0以後, 每次寫請求(如index、delete、update、bulk等)完成時, 都會觸發fsync將translog中的segment刷到磁盤, 而後纔會返回200 OK的響應;

（2）刪除數據的過程

刪除有點相似僞刪除，它先是經過將對應刪除的記錄寫入磁盤上的.del文件，標誌那些document被刪除（若是此時搜索將會搜索到這些文檔但不會返回）。當segment File多到必定程度時候，ES將執行物理刪除操做, 完全清除這些文檔。

（3）修改數據的過程

修改數據是先刪後增，將原來的數據標誌位deleted狀態，而後新寫入一個document。

（4）讀數據的過程（傳入document的id）

經過document 的id hash到指定分片，而後根據負載均衡算法（默認輪詢），路由到該分片節點之一讀取數據。

（5）搜索數據的過程

協調節點，把請求發送到全部擁有該索引的節點上去，可是對於主parimaryShard和replicaShard只會查其中之一，每一個shard把查詢結果的docId返回給協調節點。接着協調節點根據docId去實際存放數據的節點拉取docment，由協調節點進行合併、排序、分頁等操做，而後返回給客戶端。

4、如何性能優化

1.提升osCache覆蓋率

elasticsSearch的高性能很大程度依賴於osCache的大小，畢竟走內存確定比走硬盤快，因此能夠提升filesystemCache的大小盡量覆蓋多的segment文件來提升性能。

2.數據預熱

作一個子系統，每隔一段對熱點數據搜索一下。由於osCache實際上仍是基於LRU緩存的。

3.冷熱分離

將熱數據專門寫一個索引，冷數據又單獨寫個索引，經過控制分片規則分放在不一樣的機器，由於熱數據數據量少，沒有冷數據的話，能夠保證儘量多的數據都在osCache裏面，而由於冷數據不走熱數據節點，避免oscache頻繁切換數據的開銷。

4.模型設計

寫入es模型的就完成Type之間的關聯，創建冗餘字段（別在es中join）,由於若是在搜索中運用到了索引之間的關聯效率是很低的。

5.避免深度分頁

假設查詢100頁，會有1-100頁的數據到協調節點來，而後協調節點才完成排序、篩選、分頁，這是深度分頁。應對方案有兩種，一是咱們的系統設計不容許翻那麼深的頁，或默認翻的越深，性能越差。二是利用elasticsSearch的ScrollAPI，ScrollAPI容許咱們作一個初始階段搜索而且持續批量從Elasticsearch里拉取結果直到沒有結果剩下，缺點是隻能一頁一頁日後翻，不能跳着翻。