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

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

再來說說NoSql應用，通常搜索引擎的取數(shù)據(jù)的過程是：

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

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

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

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

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

這次簡單聊聊搜索引擎在NoSql上的典型應用場景：

1. 業(yè)務寬表

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

• 某個產(chǎn)品在由小到大的發(fā)展過程中必然隨著業(yè)務線的拆分，對應的業(yè)務db庫表也必然隨之拆分，方便開發(fā)維護（解耦）

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

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

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

Tips：搜索引擎一般響應時間在0-100ms左右，ES因為gc的原因偶爾會有秒級的rt，所以應用需要評估對引擎響應時間（rt）的敏感程度。

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

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

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

Tips：在這個場景下，應用需要注意控制寫入速率，避免引擎因為merge或者垃圾回收而導致長時間無響應，另外盡量保證所在集群與在線業(yè)務集群物理隔離。

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

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

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

4. 外部索引

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

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

5. 在線統(tǒng)計

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

• 只能提供top n功能，不支持翻頁

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

因此如果是對rt不很敏感的業(yè)務，又不能通過db在線查詢解決，在明確上述缺陷的前提下，也是可以用ES來做“在線”統(tǒng)計查詢工作的，當然建議還是：

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

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

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