elasticsSearch的示例分析

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

一、前言

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

二、核心概念

• index: 索引，是一類數(shù)據(jù)的抽象。

• type: 類型，是一類數(shù)據(jù)的具體抽象。更多情況一個index只對應(yīng)一個type，type類似數(shù)據(jù)庫中的一張表，并且在邏輯定義上也經(jīng)常是1對1的關(guān)系，如elasticsSearch的type中存訂單數(shù)據(jù)需要被搜索的字段，并且有一個字段是訂單號，我們通過字段搜索到訂單號后通常會在數(shù)據(jù)庫再查一次，返回詳情。

• document: 與Lucene里面的Document一樣，就是表示可以被搜索的一條數(shù)據(jù)。

• field：與Lucene里面的field一樣，表示的是document的每個字段。

• shard：elasticsSearch集群中存儲數(shù)據(jù)的基本單位單位，一個索引有多個shard，在集群中不可以再次被分隔。

• 協(xié)調(diào)節(jié)點：集群中任意節(jié)點都可以接受客戶端請求，接受請求的節(jié)點稱為協(xié)調(diào)節(jié)點。

• segmentFile: shard中數(shù)據(jù)持久化的磁盤文件，一個shard對應(yīng)多個segmentFile。

• fsync：Unix系統(tǒng)調(diào)用函數(shù), 用來將內(nèi)存緩沖區(qū)buffer中的數(shù)據(jù)存儲到文件系統(tǒng). 這里具體是指將文件緩存cache中的所有segment刷新到磁盤的操作。

三、基本原理

1.分布式策略

（1）數(shù)據(jù)分布

索引創(chuàng)建可以指定分片的數(shù)量以及副本的數(shù)量，分片數(shù)量在創(chuàng)建之后無法改變，副本數(shù)量在之后可以改變，隨著集群中節(jié)點的增加與刪除，各個分片與副本會重新分配到各個節(jié)點中。分片和副本不會分配到一個節(jié)點上，分片通過hash算法平均分布在各個節(jié)點上，也可以自定義分片分布規(guī)則（讓在集群的某些節(jié)點和某個節(jié)點創(chuàng)建分片），如通過自定義分片分布規(guī)則實現(xiàn)冷熱分離提高性能。因為這種分片機制，我們可以通過增加集群中節(jié)點保證一臺機器的分片不會太多提高搜索性能。

（2）高可用

集群中會自動選舉一個master節(jié)點，master節(jié)點的主要作用是管理集群，維護索引元數(shù)據(jù)等。master掛掉，集群重新選舉master節(jié)點，master節(jié)點然后切換節(jié)點的身份為master。

（3）寫和讀

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

2.基本原理

（1）寫入過程

協(xié)調(diào)節(jié)點接收到寫入請求，將寫入請求數(shù)據(jù)通過哈希算法路由到對應(yīng)的shard的primaryShard上去。primaryShard的節(jié)點接收到請求數(shù)據(jù)，首先把segment fiel以及transLog（事務(wù)日志）寫入自己的應(yīng)用內(nèi)存buffer當(dāng)中，然后默認(rèn)每隔1s,將buffer中的數(shù)據(jù)refresh數(shù)據(jù)到osCache（文件系統(tǒng)緩存）中。此時客戶端就能查詢到數(shù)據(jù)了。這個過程非常快，因為并沒有涉及到數(shù)據(jù)的持久化（所以是準(zhǔn)實時的）。當(dāng)translog文件過大或達(dá)到一定時間（默認(rèn)30分鐘）會觸發(fā)flush操作，flush操作會將segmentfile統(tǒng)一flush到磁盤文件，同時生成一個commitpoint,記錄生成的segmentfile，然后清空translog。

注意：

• 故障恢復(fù)時，elasticsSearch將根據(jù)當(dāng)前的commitpoint文件加載segmentFile（恢復(fù)搜索功能），然后通過translog事務(wù)日志，重做所有操作來恢復(fù)數(shù)據(jù)。

• 當(dāng)數(shù)據(jù)尚且在buffer或osCache、translog也在osCache中時可能會丟數(shù)據(jù)，也可設(shè)定參數(shù)保證數(shù)據(jù)不丟失，但會犧牲吞吐量和性能。Elasticsearch 2.0之后, 每次寫請求(如index、delete、update、bulk等)完成時, 都會觸發(fā)fsync將translog中的segment刷到磁盤, 然后才會返回200 OK的響應(yīng);

（2）刪除數(shù)據(jù)的過程

刪除有點類似偽刪除，它先是通過將對應(yīng)刪除的記錄寫入磁盤上的.del文件，標(biāo)志那些document被刪除（如果此時搜索將會搜索到這些文檔但不會返回）。當(dāng)segment File多到一定程度時候，ES將執(zhí)行物理刪除操作, 徹底清除這些文檔。

（3）修改數(shù)據(jù)的過程

修改數(shù)據(jù)是先刪后增，將原來的數(shù)據(jù)標(biāo)志位deleted狀態(tài)，然后新寫入一個document。

（4）讀數(shù)據(jù)的過程（傳入document的id）

通過document 的id hash到指定分片，然后根據(jù)負(fù)載均衡算法（默認(rèn)輪詢），路由到該分片節(jié)點之一讀取數(shù)據(jù)。

（5）搜索數(shù)據(jù)的過程

協(xié)調(diào)節(jié)點，把請求發(fā)送到所有擁有該索引的節(jié)點上去，但是對于主parimaryShard和replicaShard只會查其中之一，每個shard把查詢結(jié)果的docId返回給協(xié)調(diào)節(jié)點。接著協(xié)調(diào)節(jié)點根據(jù)docId去實際存放數(shù)據(jù)的節(jié)點拉取docment，由協(xié)調(diào)節(jié)點進行合并、排序、分頁等操作，然后返回給客戶端。

四、如何性能優(yōu)化

1.提高osCache覆蓋率

elasticsSearch的高性能很大程度依賴于osCache的大小，畢竟走內(nèi)存肯定比走硬盤快，所以可以提高filesystemCache的大小盡可能覆蓋多的segment文件來提高性能。

2.數(shù)據(jù)預(yù)熱

做一個子系統(tǒng)，每隔一段對熱點數(shù)據(jù)搜索一下。因為osCache實際上還是基于LRU緩存的。

3.冷熱分離

將熱數(shù)據(jù)專門寫一個索引，冷數(shù)據(jù)又單獨寫個索引，通過控制分片規(guī)則分放在不同的機器，因為熱數(shù)據(jù)數(shù)據(jù)量少，沒有冷數(shù)據(jù)的話，可以保證盡可能多的數(shù)據(jù)都在osCache里面，而因為冷數(shù)據(jù)不走熱數(shù)據(jù)節(jié)點，避免oscache頻繁切換數(shù)據(jù)的開銷。

4.模型設(shè)計

寫入es模型的就完成Type之間的關(guān)聯(lián)，建立冗余字段（別在es中join）,因為如果在搜索中運用到了索引之間的關(guān)聯(lián)效率是很低的。

5.避免深度分頁

假設(shè)查詢100頁，會有1-100頁的數(shù)據(jù)到協(xié)調(diào)節(jié)點來，然后協(xié)調(diào)節(jié)點才完成排序、篩選、分頁，這是深度分頁。應(yīng)對方案有兩種，一是我們的系統(tǒng)設(shè)計不允許翻那么深的頁，或默認(rèn)翻的越深，性能越差。二是利用elasticsSearch的ScrollAPI，ScrollAPI允許我們做一個初始階段搜索并且持續(xù)批量從Elasticsearch里拉取結(jié)果直到?jīng)]有結(jié)果剩下，缺點是只能一頁一頁往后翻，不能跳著翻。

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