您好,登錄后才能下訂單哦!
這篇“ElasticSearch中NoSql應用優化的方法”文章的知識點大部分人都不太理解,所以小編給大家總結了以下內容,內容詳細,步驟清晰,具有一定的借鑒價值,希望大家閱讀完這篇文章能有所收獲,下面我們一起來看看這篇“ElasticSearch中NoSql應用優化的方法”文章吧。
再來說說NoSql應用,通常搜索引擎的取數據的過程是:
首先通過搜索詞匹配倒排表得到一個只有id的結果集,然后通過id匹配正排索引拿到對應的文檔字段,最后返回結果,這樣的好處是:
可以讓倒排索引盡量小,保證IO性能
id是由搜索引擎自行分配維護的,并不依賴外部映射關系,做到將文檔id和文檔內容分離,使得文檔內容可以像NoSql一樣橫向擴展字段
可以在返回搜索結果的同時把文檔原始內容帶上,通過一次查詢就返回前端展示所必須的信息(排序和內容),從而免去了從db取數據的IO開銷
這樣來說,搜索引擎確實可以一定程度上接替一部分db的工作,有做第二db(NoSql)的能力。
這次簡單聊聊搜索引擎在NoSql上的典型應用場景:
1. 業務寬表
業務寬表應該是最常遇見的一類NoSql應用,作用是關聯在db中相互獨立存儲的幾張業務表為一張大中間表,從而可以將復雜的取數邏輯簡化為一次查詢,看上去很有誘惑力。那為什么不直接把這些業務字段在db中就存儲為一張表呢,大致的原因是:
某個產品在由小到大的發展過程中必然隨著業務線的拆分,對應的業務db庫表也必然隨之拆分,方便開發維護(解耦)
如果表存儲的數據量很大,要進行一次ddl操作的代價會很高(鎖表),新的業務需求(新增字段)就不得不通過新建一張附表來避免鎖表帶來的業務中斷
事物都具有兩面性,拆表解決了上述的問題,同時也帶來了新的麻煩,如果某個業務同時依賴了多張業務表,那么進行一次數據交互就必然伴隨著多次db操作(復雜的取數邏輯),如果還需要對某個字段進行排序,就必須得借助join操作(增大db壓力)。
這時為了簡化邏輯或者是減輕db壓力,就可以在業務表之外新建一張業務寬表存儲到ES,即使數據量很大(上十億),依然可以快速的添加字段而不會引起鎖表操作,而且NoSql的特性也天然適合業務快速發展的場景。
Tips:搜索引擎一般響應時間在0-100ms左右,ES因為gc的原因偶爾會有秒級的rt,所以應用需要評估對引擎響應時間(rt)的敏感程度。
2. 大數據交換/存儲
離線計算有時得到的結果很大(比如根據各種消費規則算出一批潛在客戶),而又需要結果進行各種在線查詢計算,如果是千萬級別的數據,如果直接導入db,可能會嚴重影響在線業務,而傳統的大數據存儲,比如HBase,在二級索引方面又沒有那么給力,而ES可以支撐千萬級別離線數據的快速導入,也能在導入完成后提供在線查詢業務,相對會比較適合這個場景。
還有一個典型的大數據存儲場景就是日志存儲系統(ELK)了,一般情況下在線業務輸出的日志量都是很驚人的,而且是一個典型的寫多讀少應用,同時需要強大的寫入性能和比較強的搜索匹配能力,ES也是比較合適的載體。
Tips:在這個場景下,應用需要注意控制寫入速率,避免引擎因為merge或者垃圾回收而導致長時間無響應,另外盡量保證所在集群與在線業務集群物理隔離。
3. 增強關鍵字匹配
db(mysql)盡管也有全文索引能力,但是對于昂貴的db資源來說,用在全文搜索的場景上并不太合適,如果需要提供幾百萬數據的全文檢索能力,幾臺vm就足夠搜索引擎以足夠的性能跑了,這樣的場景,搜索引擎就可以作為一個具有全文檢索能力的廉價存儲資源使用。
Tips:作為存儲資源使用的情況下,需要注意的是搜索引擎提供的是“近實時”的查詢服務,經常性的是在數據寫入之后幾秒或者幾分鐘后才可見,應用需要評估對數據實時性的敏感程度,過于敏感的業務不建議應用在這個場景。
4. 外部索引
以HBase為例,其擁有廉價且強大的大數據存儲能力,可以自動分裂數據文件,保證讀寫性能穩定。但是要提供穩定的在線查詢能力,HBase的rowkey設計非常微妙,而且大數據量情況下重建rowkey是個高成本的操作,原生又不支持二級索引,這時要保證HBase查詢的靈活穩定,最好的辦法就是在外部建立一個二級索引,既擁有搜索引擎強大的檢索能力,又有自身穩定的存儲性能,而且即使外部索引需要重建,也只需要在新索引創建完成之后切換查詢流量就可以了。
Tips:保證兩側數據的一致性是這種場景下經常遇到的難題,如果還沒有有完善的雙寫機制,比較合適的是用合理的補償機制來保證。
5. 在線統計
ES在聚合查詢上確實下了不少功夫,從1.x版本到5.x版本,聚合查詢的功能一直在不斷完善,聚合查詢提供的是一定程度上的統計查詢能力,而且比較側重于ELK之類的日志分析,主要是:
只能提供top n功能,不支持翻頁
如果數據量比較大(億),而且數據變更比較頻繁,查詢的耗時經常是秒級的。
因此如果是對rt不很敏感的業務,又不能通過db在線查詢解決,在明確上述缺陷的前提下,也是可以用ES來做“在線”統計查詢工作的,當然建議還是:
盡量降低數據更新頻率,頻繁的更新會導致ES頻繁reopen index searcher,造成io壓力上升,導致查詢超時
盡量保證索引數據量不要太大(索引拆分)
以上就是關于“ElasticSearch中NoSql應用優化的方法”這篇文章的內容,相信大家都有了一定的了解,希望小編分享的內容對大家有幫助,若想了解更多相關的知識內容,請關注億速云行業資訊頻道。
免責聲明:本站發布的內容(圖片、視頻和文字)以原創、轉載和分享為主,文章觀點不代表本網站立場,如果涉及侵權請聯系站長郵箱:is@yisu.com進行舉報,并提供相關證據,一經查實,將立刻刪除涉嫌侵權內容。