本文轉(zhuǎn)載自微信公眾號「 寫PHP的老王」，轉(zhuǎn)載本文請聯(lián)系 寫PHP的老王公眾號。

[[330062]]

 業(yè)務(wù)需求痛點

• 業(yè)務(wù)增長，查詢條件越來越多，索引越來越多

業(yè)務(wù)發(fā)展初期，數(shù)據(jù)量不多。查詢，寫入都很快。隨著業(yè)務(wù)的發(fā)展，數(shù)據(jù)量增大，出現(xiàn)慢查詢，開始往表里不斷的加索引，保證數(shù)據(jù)查詢效率。但是當(dāng)數(shù)據(jù)量繼續(xù)增大，業(yè)務(wù)查詢越來越復(fù)雜。程序員天天想著這個表怎么加索引。索引的增加，寫入數(shù)據(jù)的時間成本越來越高。

• 表數(shù)據(jù)增加，數(shù)據(jù)拆分越來越復(fù)雜

數(shù)據(jù)量增大，開始進行分表處理。慢慢的發(fā)現(xiàn)，尼瑪，分的表越來越多。再這么下去，這臺數(shù)據(jù)庫服務(wù)器上都容不下他了，這是要做數(shù)據(jù)分片的操作啊。分表已經(jīng)夠費勁了，還要分片?

• 全文檢索功能

嗨，哥們，給我加個全文搜索的功能。簡單的一句話，你心里十萬個草泥馬。這么多的數(shù)據(jù)量你讓我搞全文搜索。

上面業(yè)務(wù)通點總結(jié)起來就是要查的快，要分布式，要全文搜。

ES 能解決什么問題

S主要運用于全文搜索、數(shù)據(jù)分析， 底層使用開源庫Lucene，擁有豐富的REST API。內(nèi)部分布式的數(shù)據(jù)存儲、倒排索引等設(shè)計，使其可以快速存儲、搜索、分析海量數(shù)據(jù)。典型的使用方和應(yīng)用場景，如github,StackOverflow，elasticsearch+logstash+kibana 一體化的日志分析。

ES 搜索為什么快的原因

對于mysql中如上的數(shù)據(jù)表，ES會對每個字段的值建立索引，通過索引的值去找數(shù)據(jù)，而且這些索引都是在內(nèi)存里面的。

name段索引：

age字段索引

address 字段索引

這樣，當(dāng)我們要找上海市，年齡為21歲的數(shù)據(jù)就能夠通過address,age索引快遞定位到數(shù)據(jù)id=2的是我們需要查找的。

然后在從磁盤中把數(shù)據(jù)id=2的數(shù)據(jù)讀取出來。

上面的其實就是ES中倒排索引的一個簡化版本。

實際上的ES的倒排序使用的是前綴作為索引，同時會使用*FST*對索引數(shù)據(jù)進行壓縮，以保證在內(nèi)存的數(shù)據(jù)量不會因為索引多而帶來比較大的內(nèi)存消耗。

對于上面的數(shù)據(jù)表，如果采用HashMap的方式對name字段索引的話，索引所占用內(nèi)存20個字節(jié)。

但是如果轉(zhuǎn)換成FST結(jié)構(gòu)的話，可以用四個字節(jié)表示name,總共占用內(nèi)存為4+4*3=16。(假設(shè)數(shù)據(jù)范圍只有M,i,e,c) 四個字符。

ES 分布式數(shù)據(jù)結(jié)構(gòu)設(shè)計

• 數(shù)據(jù)分片均衡

分片是 Elasticsearch 在集群中分發(fā)數(shù)據(jù)的關(guān)鍵。文檔存儲在分片中，然后分片分配到集群中的節(jié)點上。當(dāng)集群擴容或縮小，Elasticsearch 將會自動在節(jié)點間遷移分片，以使集群保持平衡。

• 數(shù)據(jù)可靠

分片有主分片，復(fù)制分片。復(fù)制分片只是主分片的一個副本，它可以防止硬件故障導(dǎo)致的數(shù)據(jù)丟失，同時可以提供讀請求，比如搜索或者從別的 shard 取回文檔。

每個主分片都有一個或多個副本分片，當(dāng)主分片異常時，副本可以提供數(shù)據(jù)的查詢等操作。主分片和對應(yīng)的副本分片是不會在同一個節(jié)點上的 。

• 分布式搜索

分片本身就是一個完整的搜索引擎，它可以使用單一節(jié)點的所有資源。主分片或者復(fù)制分片都可以處理讀請求——搜索或文檔檢索，所以數(shù)據(jù)的冗余越多，能處理的搜索吞吐量就越大

ES 集群中每個節(jié)點通過路由都知道集群中的文檔的存放位置，所以每個節(jié)點都有處理讀寫請求的能力。

在一個寫請求被發(fā)送到某個節(jié)點后，該節(jié)點即為協(xié)調(diào)節(jié)點，協(xié)調(diào)節(jié)點會根據(jù)路由公式計算出需要寫到哪個分片上，再將請求轉(zhuǎn)發(fā)到該分片的主分片節(jié)點上。如果是查詢操作，則協(xié)調(diào)節(jié)點會將請求分發(fā)到其他分片上，其他分片查詢結(jié)果之后再由協(xié)調(diào)節(jié)點將數(shù)據(jù)組裝返回。

所以，引入ES，能夠?qū)崿F(xiàn)幫你解決數(shù)據(jù)量多，分布式查詢問題。同時ES會自動的替你對所有字段建立索引，以實現(xiàn)高性能的復(fù)雜聚合查詢，因此只要是存入ES的數(shù)據(jù)，無論再復(fù)雜的聚合查詢也可以得到不錯的性能，而且你再也不用為如何建立各種復(fù)雜索引而頭痛了。另外，ES支持多種分詞器，對全文搜索支持更加高效。

ES引入會有什么樣的問題

• 字段類型無法修改、寫入性能較低和高硬件資源消耗

ES需要在創(chuàng)建字段前要預(yù)先建立Mapping，Mapping中包含每個字段的類型信息，ES需要根據(jù)Mapping為字段建立合適的索引。由于這個Mapping的存在，ES中的字段一但建立就不能再修改類型了。ES在數(shù)據(jù)結(jié)構(gòu)靈活度上高于MySQL但遠不如MongoDB

• 不支持事務(wù),JOIN
• 吃硬件

ES的排序和聚合(Aggregation)操作會把幾乎所有相關(guān)不相關(guān)的文檔都加載到內(nèi)存中，一個Query就可以很神奇地吃光所有內(nèi)存，現(xiàn)在新的Lucene版本優(yōu)化了基于硬盤的排序，但也僅當(dāng)你使用SSD的情況下，才不會犧牲過多的搜索性能。其他的問題還包括，大量的增量寫操作會導(dǎo)致大量的后臺Merge，CPU和硬盤讀寫都會很容易達到瓶頸。ES確實在橫向Scale方面做的很出色，但前提是有足夠的預(yù)算買硬件。

• 數(shù)據(jù)實時性

每當(dāng)有新增的數(shù)據(jù)時，就將其先寫入到內(nèi)存中，在內(nèi)存和磁盤之間是文件系統(tǒng)緩存，當(dāng)達到默認(rèn)的時間(1秒鐘)或者內(nèi)存的數(shù)據(jù)達到一定量時，會觸發(fā)一次刷新(Refresh)，將內(nèi)存中的數(shù)據(jù)生成到一個新的段上并緩存到文件緩存系統(tǒng) 上，稍后再被刷新到磁盤中并生成提交點。因此，從Index請求到對外可見能夠被搜到，最少要1秒鐘的數(shù)據(jù)延時。

• 不支持?jǐn)?shù)據(jù)的權(quán)限管理

總結(jié)

ES香不香看你怎么用。有人用的很爽，有人用的很痛苦。用好了就少加班調(diào)索引，調(diào)sql。用不好就常加班調(diào)ES。

優(yōu)點：

• 1.高并發(fā)
• 2.容錯能力比mg強。比如1主多從，主片掛了從片會自動頂上
• 3.滿足大數(shù)據(jù)下實時讀寫需求，無需分庫(不存在庫的概念)。
• 4.易擴展。分片數(shù)據(jù)自動均衡
• 5.支持較復(fù)雜的條件查詢，group by、排序都不是問題

缺點：

• 1.不支持事務(wù)
• 2.讀寫有一定延時
• 3.無權(quán)限管理
• 4.吃硬件