ElasticSearch中NoSql應(yīng)用優(yōu)化的方法

這篇“ElasticSearch中NOSQL應(yīng)用優(yōu)化的方法”文章的知識(shí)點(diǎn)大部分人都不太理解，所以小編給大家總結(jié)了以下內(nèi)容，內(nèi)容詳細(xì)，步驟清晰，具有一定的借鑒價(jià)值，希望大家閱讀完這篇文章能有所收獲，下面我們一起來(lái)看看這篇“ElasticSearch中NoSql應(yīng)用優(yōu)化的方法”文章吧。

定海網(wǎng)站制作公司哪家好，找創(chuàng)新互聯(lián)建站！從網(wǎng)頁(yè)設(shè)計(jì)、網(wǎng)站建設(shè)、微信開(kāi)發(fā)、APP開(kāi)發(fā)、成都響應(yīng)式網(wǎng)站建設(shè)公司等網(wǎng)站項(xiàng)目制作，到程序開(kāi)發(fā)，運(yùn)營(yíng)維護(hù)。創(chuàng)新互聯(lián)建站2013年至今到現(xiàn)在10年的時(shí)間，我們擁有了豐富的建站經(jīng)驗(yàn)和運(yùn)維經(jīng)驗(yàn)，來(lái)保證我們的工作的順利進(jìn)行。專(zhuān)注于網(wǎng)站建設(shè)就選創(chuàng)新互聯(lián)建站。

再來(lái)說(shuō)說(shuō)NoSql應(yīng)用，通常搜索引擎的取數(shù)據(jù)的過(guò)程是：

首先通過(guò)搜索詞匹配倒排表得到一個(gè)只有id的結(jié)果集，然后通過(guò)id匹配正排索引拿到對(duì)應(yīng)的文檔字段，最后返回結(jié)果，這樣的好處是：

• 可以讓倒排索引盡量小，保證IO性能

• id是由搜索引擎自行分配維護(hù)的，并不依賴(lài)外部映射關(guān)系，做到將文檔id和文檔內(nèi)容分離，使得文檔內(nèi)容可以像NoSql一樣橫向擴(kuò)展字段

• 可以在返回搜索結(jié)果的同時(shí)把文檔原始內(nèi)容帶上，通過(guò)一次查詢(xún)就返回前端展示所必須的信息（排序和內(nèi)容），從而免去了從db取數(shù)據(jù)的IO開(kāi)銷(xiāo)

這樣來(lái)說(shuō)，搜索引擎確實(shí)可以一定程度上接替一部分db的工作，有做第二db（NoSql）的能力。

這次簡(jiǎn)單聊聊搜索引擎在NoSql上的典型應(yīng)用場(chǎng)景：

1. 業(yè)務(wù)寬表

業(yè)務(wù)寬表應(yīng)該是最常遇見(jiàn)的一類(lèi)NoSql應(yīng)用，作用是關(guān)聯(lián)在db中相互獨(dú)立存儲(chǔ)的幾張業(yè)務(wù)表為一張大中間表，從而可以將復(fù)雜的取數(shù)邏輯簡(jiǎn)化為一次查詢(xún)，看上去很有誘惑力。那為什么不直接把這些業(yè)務(wù)字段在db中就存儲(chǔ)為一張表呢，大致的原因是：

• 某個(gè)產(chǎn)品在由小到大的發(fā)展過(guò)程中必然隨著業(yè)務(wù)線(xiàn)的拆分，對(duì)應(yīng)的業(yè)務(wù)db庫(kù)表也必然隨之拆分，方便開(kāi)發(fā)維護(hù)（解耦）

• 如果表存儲(chǔ)的數(shù)據(jù)量很大，要進(jìn)行一次ddl操作的代價(jià)會(huì)很高（鎖表），新的業(yè)務(wù)需求（新增字段）就不得不通過(guò)新建一張附表來(lái)避免鎖表帶來(lái)的業(yè)務(wù)中斷

事物都具有兩面性，拆表解決了上述的問(wèn)題，同時(shí)也帶來(lái)了新的麻煩，如果某個(gè)業(yè)務(wù)同時(shí)依賴(lài)了多張業(yè)務(wù)表，那么進(jìn)行一次數(shù)據(jù)交互就必然伴隨著多次db操作（復(fù)雜的取數(shù)邏輯），如果還需要對(duì)某個(gè)字段進(jìn)行排序，就必須得借助join操作（增大db壓力）。

這時(shí)為了簡(jiǎn)化邏輯或者是減輕db壓力，就可以在業(yè)務(wù)表之外新建一張業(yè)務(wù)寬表存儲(chǔ)到ES，即使數(shù)據(jù)量很大（上十億），依然可以快速的添加字段而不會(huì)引起鎖表操作，而且NoSql的特性也天然適合業(yè)務(wù)快速發(fā)展的場(chǎng)景。

Tips：搜索引擎一般響應(yīng)時(shí)間在0-100ms左右，ES因?yàn)間c的原因偶爾會(huì)有秒級(jí)的rt，所以應(yīng)用需要評(píng)估對(duì)引擎響應(yīng)時(shí)間（rt）的敏感程度。

2. 大數(shù)據(jù)交換/存儲(chǔ)

離線(xiàn)計(jì)算有時(shí)得到的結(jié)果很大（比如根據(jù)各種消費(fèi)規(guī)則算出一批潛在客戶(hù)），而又需要結(jié)果進(jìn)行各種在線(xiàn)查詢(xún)計(jì)算，如果是千萬(wàn)級(jí)別的數(shù)據(jù)，如果直接導(dǎo)入db，可能會(huì)嚴(yán)重影響在線(xiàn)業(yè)務(wù)，而傳統(tǒng)的大數(shù)據(jù)存儲(chǔ)，比如HBase，在二級(jí)索引方面又沒(méi)有那么給力，而ES可以支撐千萬(wàn)級(jí)別離線(xiàn)數(shù)據(jù)的快速導(dǎo)入，也能在導(dǎo)入完成后提供在線(xiàn)查詢(xún)業(yè)務(wù)，相對(duì)會(huì)比較適合這個(gè)場(chǎng)景。

還有一個(gè)典型的大數(shù)據(jù)存儲(chǔ)場(chǎng)景就是日志存儲(chǔ)系統(tǒng)（ELK）了，一般情況下在線(xiàn)業(yè)務(wù)輸出的日志量都是很驚人的，而且是一個(gè)典型的寫(xiě)多讀少應(yīng)用，同時(shí)需要強(qiáng)大的寫(xiě)入性能和比較強(qiáng)的搜索匹配能力，ES也是比較合適的載體。

Tips：在這個(gè)場(chǎng)景下，應(yīng)用需要注意控制寫(xiě)入速率，避免引擎因?yàn)閙erge或者垃圾回收而導(dǎo)致長(zhǎng)時(shí)間無(wú)響應(yīng)，另外盡量保證所在集群與在線(xiàn)業(yè)務(wù)集群物理隔離。

3. 增強(qiáng)關(guān)鍵字匹配

db（MySQL）盡管也有全文索引能力，但是對(duì)于昂貴的db資源來(lái)說(shuō)，用在全文搜索的場(chǎng)景上并不太合適，如果需要提供幾百萬(wàn)數(shù)據(jù)的全文檢索能力，幾臺(tái)vm就足夠搜索引擎以足夠的性能跑了，這樣的場(chǎng)景，搜索引擎就可以作為一個(gè)具有全文檢索能力的廉價(jià)存儲(chǔ)資源使用。

Tips：作為存儲(chǔ)資源使用的情況下，需要注意的是搜索引擎提供的是“近實(shí)時(shí)”的查詢(xún)服務(wù)，經(jīng)常性的是在數(shù)據(jù)寫(xiě)入之后幾秒或者幾分鐘后才可見(jiàn)，應(yīng)用需要評(píng)估對(duì)數(shù)據(jù)實(shí)時(shí)性的敏感程度，過(guò)于敏感的業(yè)務(wù)不建議應(yīng)用在這個(gè)場(chǎng)景。

4. 外部索引

以HBase為例，其擁有廉價(jià)且強(qiáng)大的大數(shù)據(jù)存儲(chǔ)能力，可以自動(dòng)分裂數(shù)據(jù)文件，保證讀寫(xiě)性能穩(wěn)定。但是要提供穩(wěn)定的在線(xiàn)查詢(xún)能力，HBase的rowkey設(shè)計(jì)非常微妙，而且大數(shù)據(jù)量情況下重建rowkey是個(gè)高成本的操作，原生又不支持二級(jí)索引，這時(shí)要保證HBase查詢(xún)的靈活穩(wěn)定，最好的辦法就是在外部建立一個(gè)二級(jí)索引，既擁有搜索引擎強(qiáng)大的檢索能力，又有自身穩(wěn)定的存儲(chǔ)性能，而且即使外部索引需要重建，也只需要在新索引創(chuàng)建完成之后切換查詢(xún)流量就可以了。

Tips：保證兩側(cè)數(shù)據(jù)的一致性是這種場(chǎng)景下經(jīng)常遇到的難題，如果還沒(méi)有有完善的雙寫(xiě)機(jī)制，比較合適的是用合理的補(bǔ)償機(jī)制來(lái)保證。

5. 在線(xiàn)統(tǒng)計(jì)

ES在聚合查詢(xún)上確實(shí)下了不少功夫，從1.x版本到5.x版本，聚合查詢(xún)的功能一直在不斷完善，聚合查詢(xún)提供的是一定程度上的統(tǒng)計(jì)查詢(xún)能力，而且比較側(cè)重于ELK之類(lèi)的日志分析，主要是：

• 只能提供top n功能，不支持翻頁(yè)

• 如果數(shù)據(jù)量比較大（億），而且數(shù)據(jù)變更比較頻繁，查詢(xún)的耗時(shí)經(jīng)常是秒級(jí)的。

因此如果是對(duì)rt不很敏感的業(yè)務(wù)，又不能通過(guò)db在線(xiàn)查詢(xún)解決，在明確上述缺陷的前提下，也是可以用ES來(lái)做“在線(xiàn)”統(tǒng)計(jì)查詢(xún)工作的，當(dāng)然建議還是：

• 盡量降低數(shù)據(jù)更新頻率，頻繁的更新會(huì)導(dǎo)致ES頻繁reopen index searcher，造成io壓力上升，導(dǎo)致查詢(xún)超時(shí)

• 盡量保證索引數(shù)據(jù)量不要太大（索引拆分）

以上就是關(guān)于“ElasticSearch中NoSql應(yīng)用優(yōu)化的方法”這篇文章的內(nèi)容，相信大家都有了一定的了解，希望小編分享的內(nèi)容對(duì)大家有幫助，若想了解更多相關(guān)的知識(shí)內(nèi)容，請(qǐng)關(guān)注創(chuàng)新互聯(lián)行業(yè)資訊頻道。

分享標(biāo)題：ElasticSearch中NoSql應(yīng)用優(yōu)化的方法
文章URL：http://muchs.cn/article48/picchp.html

成都網(wǎng)站建設(shè)公司_創(chuàng)新互聯(lián)，為您提供網(wǎng)站設(shè)計(jì)、網(wǎng)站策劃、云服務(wù)器、用戶(hù)體驗(yàn)、網(wǎng)站制作、App設(shè)計(jì)

廣告

聲明：本網(wǎng)站發(fā)布的內(nèi)容（圖片、視頻和文字）以用戶(hù)投稿、用戶(hù)轉(zhuǎn)載內(nèi)容為主，如果涉及侵權(quán)請(qǐng)盡快告知，我們將會(huì)在第一時(shí)間刪除。文章觀點(diǎn)不代表本網(wǎng)站立場(chǎng)，如需處理請(qǐng)聯(lián)系客服。電話(huà)：028-86922220；郵箱：631063699@qq.com。內(nèi)容未經(jīng)允許不得轉(zhuǎn)載，或轉(zhuǎn)載時(shí)需注明來(lái)源： 創(chuàng)新互聯(lián)