思考：大規(guī)模數(shù)據(jù)如何檢索?

如：當(dāng)系統(tǒng)數(shù)據(jù)量上了10億、100億條的時(shí)候，我們在做系統(tǒng)架構(gòu)的時(shí)候通常會(huì)從以下角度去考慮問題：

1)用什么數(shù)據(jù)庫好?(mysql、sybase、oracle、達(dá)夢、神通、mongodb、hbase…)

2)如何解決單點(diǎn)故障;(lvs、F5、A10、Zookeep、MQ)

3)如何保證數(shù)據(jù)安全性;(熱備、冷備、異地多活)

4)如何解決檢索難題;(數(shù)據(jù)庫代理中間件：mysql-proxy、Cobar、MaxScale等;)

5)如何解決統(tǒng)計(jì)分析問題;(離線、近實(shí)時(shí))

傳統(tǒng)數(shù)據(jù)庫的應(yīng)對解決方案

對于關(guān)系型數(shù)據(jù)，我們通常采用以下或類似架構(gòu)去解決查詢瓶頸和寫入瓶頸：

解決要點(diǎn)：

1)通過主從備份解決數(shù)據(jù)安全性問題;

2)通過數(shù)據(jù)庫代理中間件心跳監(jiān)測，解決單點(diǎn)故障問題;

3)通過代理中間件將查詢語句分發(fā)到各個(gè)slave節(jié)點(diǎn)進(jìn)行查詢，并匯總結(jié)果

非關(guān)系型數(shù)據(jù)庫的解決方案

對于Nosql數(shù)據(jù)庫，以mongodb為例，其它原理類似：

解決要點(diǎn)：

1)通過副本備份保證數(shù)據(jù)安全性;

2)通過節(jié)點(diǎn)競選機(jī)制解決單點(diǎn)問題;

3)先從配置庫檢索分片信息，然后將請求分發(fā)到各個(gè)節(jié)點(diǎn)，最后由路由節(jié)點(diǎn)合并匯總結(jié)果

另辟蹊徑——完全把數(shù)據(jù)放入內(nèi)存怎么樣?

我們知道，完全把數(shù)據(jù)放在內(nèi)存中是不可靠的，實(shí)際上也不太現(xiàn)實(shí)，當(dāng)我們的數(shù)據(jù)達(dá)到PB級別時(shí)，按照每個(gè)節(jié)點(diǎn)96G內(nèi)存計(jì)算，在內(nèi)存完全裝滿的數(shù)據(jù)情況下，我們需要的機(jī)器是：1PB=1024T=1048576G

節(jié)點(diǎn)數(shù)=1048576/96=10922個(gè)

實(shí)際上，考慮到數(shù)據(jù)備份，節(jié)點(diǎn)數(shù)往往在2.5萬臺左右。成本巨大決定了其不現(xiàn)實(shí)!

從前面討論我們了解到，把數(shù)據(jù)放在內(nèi)存也好，不放在內(nèi)存也好，都不能完完全全解決問題。

全部放在內(nèi)存速度問題是解決了，但成本問題上來了。

為解決以上問題，從源頭著手分析，通常會(huì)從以下方式來尋找方法：

1、存儲(chǔ)數(shù)據(jù)時(shí)按有序存儲(chǔ);

2、將數(shù)據(jù)和索引分離;

3、壓縮數(shù)據(jù);

這就引出了Elasticsearch。

1. ES 基礎(chǔ)一網(wǎng)打盡

1.1 ES定義

ES=elaticsearch簡寫， Elasticsearch是一個(gè)開源的高擴(kuò)展的分布式全文檢索引擎，它可以近乎實(shí)時(shí)的存儲(chǔ)、檢索數(shù)據(jù);本身擴(kuò)展性很好，可以擴(kuò)展到上百臺服務(wù)器，處理PB級別的數(shù)據(jù)。

Elasticsearch也使用Java開發(fā)并使用Lucene作為其核心來實(shí)現(xiàn)所有索引和搜索的功能，但是它的目的是通過簡單的RESTful API來隱藏Lucene的復(fù)雜性，從而讓全文搜索變得簡單。

1.2 Lucene與ES關(guān)系?

1)Lucene只是一個(gè)庫。想要使用它，你必須使用Java來作為開發(fā)語言并將其直接集成到你的應(yīng)用中，更糟糕的是，Lucene非常復(fù)雜，你需要深入了解檢索的相關(guān)知識來理解它是如何工作的。

2)Elasticsearch也使用Java開發(fā)并使用Lucene作為其核心來實(shí)現(xiàn)所有索引和搜索的功能，但是它的目的是通過簡單的RESTful API來隱藏Lucene的復(fù)雜性，從而讓全文搜索變得簡單。

1.3 ES主要解決問題：

1)檢索相關(guān)數(shù)據(jù);

2)返回統(tǒng)計(jì)結(jié)果;

3)速度要快。

1.4 ES工作原理

當(dāng)ElasticSearch的節(jié)點(diǎn)啟動(dòng)后，它會(huì)利用多播(multicast)(或者單播，如果用戶更改了配置)尋找集群中的其它節(jié)點(diǎn)，并與之建立連接。這個(gè)過程如下圖所示：

1.5 ES核心概念

1)Cluster：集群。

ES可以作為一個(gè)獨(dú)立的單個(gè)搜索服務(wù)器。不過，為了處理大型數(shù)據(jù)集，實(shí)現(xiàn)容錯(cuò)和高可用性，ES可以運(yùn)行在許多互相合作的服務(wù)器上。這些服務(wù)器的集合稱為集群。

2)Node：節(jié)點(diǎn)。

形成集群的每個(gè)服務(wù)器稱為節(jié)點(diǎn)。

3)Shard：分片。

當(dāng)有大量的文檔時(shí)，由于內(nèi)存的限制、磁盤處理能力不足、無法足夠快的響應(yīng)客戶端的請求等，一個(gè)節(jié)點(diǎn)可能不夠。這種情況下，數(shù)據(jù)可以分為較小的分片。每個(gè)分片放到不同的服務(wù)器上。

當(dāng)你查詢的索引分布在多個(gè)分片上時(shí)，ES會(huì)把查詢發(fā)送給每個(gè)相關(guān)的分片，并將結(jié)果組合在一起，而應(yīng)用程序并不知道分片的存在。即：這個(gè)過程對用戶來說是透明的。

4)Replia：副本。

為提高查詢吞吐量或?qū)崿F(xiàn)高可用性，可以使用分片副本。

副本是一個(gè)分片的精確復(fù)制，每個(gè)分片可以有零個(gè)或多個(gè)副本。ES中可以有許多相同的分片，其中之一被選擇更改索引操作，這種特殊的分片稱為主分片。

當(dāng)主分片丟失時(shí)，如：該分片所在的數(shù)據(jù)不可用時(shí)，集群將副本提升為新的主分片。

5)全文檢索。

全文檢索就是對一篇文章進(jìn)行索引，可以根據(jù)關(guān)鍵字搜索，類似于mysql里的like語句。

全文索引就是把內(nèi)容根據(jù)詞的意義進(jìn)行分詞，然后分別創(chuàng)建索引，例如”你們的激情是因?yàn)槭裁词虑閬淼?rdquo; 可能會(huì)被分詞成：“你們“，”激情“，“什么事情“，”來“ 等token，這樣當(dāng)你搜索“你們” 或者 “激情” 都會(huì)把這句搜出來。

1.6 ES數(shù)據(jù)架構(gòu)的主要概念(與關(guān)系數(shù)據(jù)庫Mysql對比)

(1)關(guān)系型數(shù)據(jù)庫中的數(shù)據(jù)庫(DataBase)，等價(jià)于ES中的索引(Index)

(2)一個(gè)數(shù)據(jù)庫下面有N張表(Table)，等價(jià)于1個(gè)索引Index下面有N多類型(Type)，

(3)一個(gè)數(shù)據(jù)庫表(Table)下的數(shù)據(jù)由多行(ROW)多列(column，屬性)組成，等價(jià)于1個(gè)Type由多個(gè)文檔(Document)和多Field組成。

(4)在一個(gè)關(guān)系型數(shù)據(jù)庫里面，schema定義了表、每個(gè)表的字段，還有表和字段之間的關(guān)系。 與之對應(yīng)的，在ES中：Mapping定義索引下的Type的字段處理規(guī)則，即索引如何建立、索引類型、是否保存原始索引JSON文檔、是否壓縮原始JSON文檔、是否需要分詞處理、如何進(jìn)行分詞處理等。

(5)在數(shù)據(jù)庫中的增insert、刪delete、改update、查search操作等價(jià)于ES中的增PUT/POST、刪Delete、改_update、查GET.

1.7 ELK是什么?

ELK=elasticsearch+Logstash+kibana elasticsearch：后臺分布式存儲(chǔ)以及全文檢索 logstash: 日志加工、“搬運(yùn)工” kibana：數(shù)據(jù)可視化展示。

ELK架構(gòu)為數(shù)據(jù)分布式存儲(chǔ)、可視化查詢和日志解析創(chuàng)建了一個(gè)功能強(qiáng)大的管理鏈。 三者相互配合，取長補(bǔ)短，共同完成分布式大數(shù)據(jù)處理工作。

2. ES特點(diǎn)和優(yōu)勢

1)分布式實(shí)時(shí)文件存儲(chǔ)，可將每一個(gè)字段存入索引，使其可以被檢索到。

2)實(shí)時(shí)分析的分布式搜索引擎。

分布式：索引分拆成多個(gè)分片，每個(gè)分片可有零個(gè)或多個(gè)副本。集群中的每個(gè)數(shù)據(jù)節(jié)點(diǎn)都可承載一個(gè)或多個(gè)分片，并且協(xié)調(diào)和處理各種操作;

負(fù)載再平衡和路由在大多數(shù)情況下自動(dòng)完成。

3)可以擴(kuò)展到上百臺服務(wù)器，處理PB級別的結(jié)構(gòu)化或非結(jié)構(gòu)化數(shù)據(jù)。也可以運(yùn)行在單臺PC上(已測試)

4)支持插件機(jī)制，分詞插件、同步插件、Hadoop插件、可視化插件等。

3、ES性能

3.1 性能結(jié)果展示

(1)硬件配置：

CPU 16核 AuthenticAMD內(nèi)存 總量：32GB硬盤 總量：500GB 非SSD

(2)在上述硬件指標(biāo)的基礎(chǔ)上測試性能如下：

1)平均索引吞吐量： 12307docs/s(每個(gè)文檔大�。�40B/docs)

2)平均CPU使用率： 887.7%(16核，平均每核：55.48%)

3)構(gòu)建索引大�。� 3.30111 GB

4)總寫入量： 20.2123 GB

5)測試總耗時(shí)： 28m 54s.

4、為什么要用ES?

4.1 ES國內(nèi)外使用優(yōu)秀案例

1) 2013年初，GitHub拋棄了Solr，采取ElasticSearch 來做PB級的搜索。 “GitHub使用ElasticSearch搜索20TB的數(shù)據(jù)，包括13億文件和1300億行代碼”。

2)維基百科：啟動(dòng)以elasticsearch為基礎(chǔ)的核心搜索架構(gòu)。

3)SoundCloud：“SoundCloud使用ElasticSearch為1.8億用戶提供即時(shí)而精準(zhǔn)的音樂搜索服務(wù)”。

4)百度：百度目前廣泛使用ElasticSearch作為文本數(shù)據(jù)分析，采集百度所有服務(wù)器上的各類指標(biāo)數(shù)據(jù)及用戶自定義數(shù)據(jù)，通過對各種數(shù)據(jù)進(jìn)行多維分析展示，輔助定位分析實(shí)例異�；驑I(yè)務(wù)層面異常。目前覆蓋百度內(nèi)部20多個(gè)業(yè)務(wù)線(包括casio、云分析、網(wǎng)盟、預(yù)測、文庫、直達(dá)號、錢包、風(fēng)控等)，單集群最大100臺機(jī)器，200個(gè)ES節(jié)點(diǎn)，每天導(dǎo)入30TB+數(shù)據(jù)。

4.2 我們也需要

實(shí)際項(xiàng)目開發(fā)實(shí)戰(zhàn)中，幾乎每個(gè)系統(tǒng)都會(huì)有一個(gè)搜索的功能，當(dāng)搜索做到一定程度時(shí)，維護(hù)和擴(kuò)展起來難度就會(huì)慢慢變大，所以很多公司都會(huì)把搜索單獨(dú)獨(dú)立出一個(gè)模塊，用ElasticSearch等來實(shí)現(xiàn)。

近年ElasticSearch發(fā)展迅猛，已經(jīng)超越了其最初的純搜索引擎的角色，現(xiàn)在已經(jīng)增加了數(shù)據(jù)聚合分析(aggregation)和可視化的特性，如果你有數(shù)百萬的文檔需要通過關(guān)鍵詞進(jìn)行定位時(shí)，ElasticSearch肯定是最佳選擇。當(dāng)然，如果你的文檔是JSON的，你也可以把ElasticSearch當(dāng)作一種“NoSQL數(shù)據(jù)庫”， 應(yīng)用ElasticSearch數(shù)據(jù)聚合分析(aggregation)的特性，針對數(shù)據(jù)進(jìn)行多維度的分析。

ES在某些場景下替代傳統(tǒng)DB

個(gè)人以為Elasticsearch作為內(nèi)部存儲(chǔ)來說還是不錯(cuò)的，效率也基本能夠滿足，在某些方面替代傳統(tǒng)DB也是可以的，前提是你的業(yè)務(wù)不對操作的事性務(wù)有特殊要求;而權(quán)限管理也不用那么細(xì)，因?yàn)镋S的權(quán)限這塊還不完善。

由于我們對ES的應(yīng)用場景僅僅是在于對某段時(shí)間內(nèi)的數(shù)據(jù)聚合操作，沒有大量的單文檔請求(比如通過userid來找到一個(gè)用戶的文檔，類似于NoSQL的應(yīng)用場景)，所以能否替代NoSQL還需要各位自己的測試。如果讓我選擇的話，我會(huì)嘗試使用ES來替代傳統(tǒng)的NoSQL，因?yàn)樗�的橫向擴(kuò)展機(jī)制太方便了。

5. ES的應(yīng)用場景是怎樣的?

通常我們面臨問題有兩個(gè)：

1)新系統(tǒng)開發(fā)嘗試使用ES作為存儲(chǔ)和檢索服務(wù)器;

2)現(xiàn)有系統(tǒng)升級需要支持全文檢索服務(wù)，需要使用ES。

一線公司ES使用場景：

1)新浪ES 如何分析處理32億條實(shí)時(shí)日志https://dockone.io/article/505

2)阿里ES 構(gòu)建挖財(cái)自己的日志采集和分析體系https://afoo.me/columns/tec/logging-platform-spec.html

3)有贊ES 業(yè)務(wù)日志處理https://tech.youzan.com/you-zan-tong-ri-zhi-ping-tai-chu-tan/

4)ES實(shí)現(xiàn)站內(nèi)搜索https://www.wtoutiao.com/p/13bkqiZ.html

【凡本網(wǎng)注明來源非中國IDC圈的作品，均轉(zhuǎn)載自其它媒體，目的在于傳遞更多信息，并不代表本網(wǎng)贊同其觀點(diǎn)和對其真實(shí)性負(fù)責(zé)�！�