elasticsSearch的示例分析

小編給大家分享一下elasticsSearch的示例分析，相信大部分人都還不怎么了解，因此分享這篇文章給大家參考一下，希望大家閱讀完這篇文章后大有收獲，下面讓我們一起去了解一下吧！

一、前言

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

二、核心概念

• 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刷新到磁盤的操作。

三、基本原理

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，由協調節點進行合并、排序、分頁等操作，然后返回給客戶端。

四、如何性能優化

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里拉取結果直到沒有結果剩下，缺點是只能一頁一頁往后翻，不能跳著翻。

以上是“elasticsSearch的示例分析”這篇文章的所有內容，感謝各位的閱讀！相信大家都有了一定的了解，希望分享的內容對大家有所幫助，如果還想學習更多知識，歡迎關注億速云行業資訊頻道！