DB與ES混合之應用系統場景分析探討

00mysql

名詞解釋web


db-engine 當前綜合排名算法

  • DB:database,泛指關係型數據庫,具備嚴格事務隔離機制的數據類庫產品,如 mysql、sqlserver、postgresql、oracle、db2 等,db-engine 綜合排名前面的所有是關係型數據庫;sql

  • ES:Elasticsearch,最好的開源搜索引擎產品,NoSQL 非關係型數據庫,不具有嚴格事務隔離機制,當前 db-engine 綜合排名第七;數據庫

  • 應用:本文泛指業務應用系統,是 OLTP 場景,非 OLAP 場景,大量運用事務型數據庫產品的業務系統;後端

  • 索引:在關係型數據庫中是指數據檢索的算法,在 Elasticsearch 是指數據存儲的虛擬空間概念,類同數據庫中的表。微信

01數據結構

背景需求架構


爲何單一 DB 不能知足應用系統?
爲何單一 ES 不能知足應用系統?
爲何要使用 DB 結合 ES 混用的模式?oracle

而不是結合其它 NoSQL?好比 MongoDB?

下面從技術層面與業務層面分析探討。

技術層面

DB 與 ES 的技術特性說明

DB 侷限性    

關係型數據庫索引基於最左優先原則,索引要按照查詢需求順序提早建立,不具有任意字段組合索引能力好比 某 xxx 表有 30 個字段,若要求依據任意字段組合條件查詢,此時關係型數據庫顯然沒法知足這種靈活需求,包括當下很受歡迎的 NoSQL 明星產品 Mongodb 也不能知足。


關係型數據庫支持有限度的關聯查詢,通常在業務應用系統中,關聯表會控制在 2~3 個表(我的觀點:有 3 個表關聯的業務場景須要由技術架構師評估是否允許,開發工程師只允許 2 個表關聯),且單表的數據量是要平衡考慮才能夠,跨同構數據庫源關聯就更加不允許。


那跨異構數據庫源呢?不是不允許,實在是有心無力。關係型數據庫廣泛採用 B+ 樹數據結構實現索引查詢,面對超大數據量處理有自然的瓶頸,數據量超過百萬千萬級,複雜點的查詢,性能降低很快,甚至沒法運行。

關係型數據庫雖然也支持主從同步,支持讀寫分離,但集羣是一種鬆散式的架構,集羣節點感知能力脆弱,不成體系,彈性擴展能力不行。

ES 互補性    

Elasticsearch 基於 Lucene 核心庫構建,以倒排索引算法爲基礎,集成多種高效算法。Elasticsearch 默認爲全部字段建立索引,任索引字段可組合使用,且查詢效率至關高,相比關係型數據庫索更加高效靈活。在業務系統中,有不少場景都須要這種任意字段組合查詢的能力,簡稱通用搜索(@跨越速運)。


Elasticsearch 的數據模型採用的是 Free Scheme 模式,以 JSON 主體,數據字段能夠靈活添加,字段層級位置也能夠靈活設置 ,關係數據庫中須要多表關聯查詢,在 Elasticsearch 中能夠經過反範式的關聯能力,將多個業務表數據合併到一個索引中,採用對象嵌套的方式。


Elasticsearch 自然分佈式設計,副本與分片機制使得集羣具有彈性擴展能力,能夠應付超大的數據量查詢,在單索引數據量十億級也能夠在亞秒內響應查詢。


Elasticsearch 的索引支持彈性搜索,能夠指定一個索引搜索,也能夠指定多個索引搜索,搜索結果由 ES 提供過濾合併,這就爲業務系統提供了很靈活的操做空間,特別是在實時數據與歷史數據方面,統一查詢條件語法皆可執行。


Elasticsearch 支持數據字段與索引字段分離,默認狀況下,數據字段與索引字段是同時啓用,實際在業務業務場景中,數據表中不少字段無需檢索,只是爲了存儲數據,在查詢時方便取回;不少檢索字段也無需存儲原始數據,只是檢索過濾使用。

DB 不等於 ES    

關係數據庫定位全能型產品,強事務機制,數據寫入性能通常,數據查詢能力通常。Elasticsearch 定位查詢分析型產品,弱事務機制,查詢性能很是不錯。DB 與 ES 各有優點劣勢,不能等同取代。

業務層面

DB 與 ES 業務背景說明

業務領域複雜度    

在進入互聯網/移動互聯網/物聯網以後,業務系統數據量的幾何倍數增加,傳統應當策略固然是採用分庫分表機制,包括物理層面分庫分表,邏輯層面分區等。非重要數據能夠採用非關係型數據庫存儲,重要的業務數據必定是採用關係數據庫存儲,好比物流速運行業的客戶訂單數據,不允許有丟失出錯。


面對複雜業務系統需求,當下最流行的解決方式是採用微服務架構模式,微服務不只僅侷限上層應用服務,更深層次的是底層數據服務(微服務不在本次討論以內),基於領域模型思惟拆分分解。應用服務拆分紅大大小小數個,能夠幾十個幾百個,也能夠更多,數據服務也拆分紅大大小小數個。

業務查詢複雜度    

分庫分表解決了數據的存儲問題,但須要作合併查詢倒是個很麻煩的事,業務系統的查詢條件通常是動態的,沒法固定,更加不可能在分庫分表時按照全部動態條件設計,這彷佛代價太大。通常會選擇更強大的查詢數據庫,好比 Elasticsearch 就很是合適。


微服務架構模式解決了業務系統的單一耦合問題,但業務系統的查詢複雜度確實提升很多,複雜點的應用服務執行一次查詢,須要融合多個領域數據服務才能完成,特別是核心領域數據服務,幾乎貫穿一個系統全部方面,好比物流速運行業訂單領域。

DB 與 ES 結合    

業務數據存儲由關係型數據庫負責,有強事務隔離機制,保障數據不丟失、不串亂、不覆蓋,實時可靠。

業務數據查詢由 Elasticsearch 負責,分庫分表的數據合併同步到 ES 索引;跨領域庫表數據合併到同步 ES 索引,這樣就能夠高效查詢。

DB與ES結合問題    

DB 與 ES 結合的問題

關於DB與Elasticsearch混合主要有如下兩個問題:同步實時性、數據一致性,本文不探討此問題,後續會有專題講述如何解決。

02

混合場景


前面已經論證了關係型數據庫與 Elasticsearch 混合使用的必要性,接下來是探討混合場景下的業務場景數據模型映射。

單數據表->單索引

單數據表映射到單一索引

  • 一對一映射關係,關係數據庫有多少個表,Elasticsearch 就有多少個索引;

  • 關係數據庫提供原始數據源,Elasticsearch 替代數據庫成爲查詢引擎,替代列表查詢場景;

  • 單數據表爲水平分庫分表設計,須要藉助Elasticsearch 合併查詢,如圖:電商行業訂單場景,日均訂單量超過百萬千萬級,後端業務系統有需求合併查詢;

  • 單數據表業務查詢組合條件多,數據庫索引查詢能力侷限,須要藉助 Elasticsearch 全字段索引查詢能力,主要替代列表查詢場景。如:電商行業商品搜索場景,商品基礎字段超過幾十個,幾乎所有均可以組合搜索。

單數據表->多索引

單數據表映射到多個索引

  • 一對多映射關係,單數據表映射到多個索引中;

  • 單數據表即做爲 A索引的主體對象,一對一映射;

  • 單數據表也做爲 B索引的子對象,嵌入到主體對象下面;

  • 基於微服務架構設計,在業務系統中,業務系統劃分多個子領域,子領域也能夠繼續細分,如電商行業,訂單領域與商品領域,訂單表須要映射到訂單索引,也須要與商品索引映射。

多數據表->單索引

多數據表映射到單一索引

  • 多對一映射關係,多個數據表映射到單一索引,索引能夠採用寬表結構,也能夠採用子對象映射方式;

  • 單業務領域,數據表設計時通常會遵循數據庫範式(注:1,2,3,4),即便是反範式設計,也只會增長一點冗餘,若是要多表聯合查詢,數據庫表的關聯效率很低,甚至是運行不起來,須要藉助 Elasticsearch 合併多個數據表到一個索引中;

  • 跨業務領域的數據表要聯合查詢,也須要藉助 Elasticsearch 整合。

多數據表->多索引

多數據表映射到多個索引

  • 多對多映射關係,多個數據表映射到多個索引,複雜度高;

  • 一箇中型以上的業務系統,會劃分紅多個領域,單領域會持續細分爲多個子領域,領域之間會造成網狀關係,業務數據相互關聯;

  • 數據庫表關聯查詢效率低,跨庫查詢能力侷限,須要藉助 Elasticsearch 合併;

  • 按照領域需求不一樣,合併爲不一樣的索引文件,各索引應用會有差別,部分是通用型的,面向多個領域公用;部分是特殊型的,面向單個領域專用。

多源數據表->多索引

多源數據表映射到多個索引

  • 多源多表,多對多映射關係,數據表與索引之間的映射關係是交叉型的,複雜度最高;

  • 一個大中型業務系統,不一樣的業務場景會採用不一樣的數據存儲系統;

  • 關係型數據庫多樣化,如 A 項目採用 MySQL,B 項目採用 PostgreSQL,C 項目選用 SQLServer,業務系統通用型的查詢幾乎不能實現;

  • 非關係型數據庫多樣化,如 A 項目採用鍵值類型的 Redis,B 項目選用文檔型的 MongoDB,業務系統一樣也不能實現通用型查詢;

  • 基於異構數據源通用查詢的場景需求,一樣須要藉助 Elasticsearch 合併數據實現。

03

結語


Elasticsearch 雖然早期定位是搜索引擎類產品,後期定位數據分析類產品,屬於 NoSQL 陣營,且不支持嚴格事務隔離機制,但因爲其先進的特性,在應用系統中也是能夠大規模使用,能有效彌補了關係型數據庫的不足。


本文主旨探討了 DB 與 ES 混合的需求背景與應用場景,目的不是評選 DB 與 ES 誰更優劣,是要學會掌握 DB 與 ES 平衡,更加靈活的運用到應用系統中去, 知足不一樣的應用場景需求,解決業務需求問題纔是評判的標準。


正文完


做者:李猛

https://www.jianshu.com/u/19522b124f97

本文編輯:筷子




活動預告




2020 年的 Elastic 中文社區技術分享交流活動開始啦!只不過咱們是以在線的方式進行的,第一期的分享嘉賓是來自京東零售計算存儲平臺的兩位架構師,他們帶來的主題是關於如何在 Elasticsearch 之上實現存儲與計算分離的實踐,存儲與計算分離是目前業界很是火的一個話題,要不要上車瞭解一下啊?


本次分享的嘉賓主持人爲 Elastic 中文社區創始人 Medcl 和現就任於 Google 的工程師吳斌,寶寶們快去註冊吧。


每期活動中,咱們會從經過百格活動網站報名並實時觀看直播的社區用戶中隨機抽取 5 名幸運觀衆,每人贈送 1 本博文視點計算機書籍或者 1 份 Elastic 定製記念品。詳細書單和 Elastic 記念品介紹在本頁面下方哦~


嗨,互動起來吧!

喜歡這篇文章麼?

歡迎留下你想說的,留言 100% 精選哦!

Elastic 社區公衆號長期徵稿,若是您有 Elastic  技術的相關文章,也歡迎投稿至本公衆號,一塊兒進步! 投稿請添加微信:medcl123



招聘信息

Job board

社區招聘欄目是一個新的嘗試,幫助社區的小夥伴找到心儀的職位,也幫助企業找到所需的人才,爲伯樂和千里馬牽線搭橋。有招聘需求的企業和正在求職的社區小夥伴,能夠聯繫微信 medcl123 提交招聘需求和發佈我的簡歷信息。


Elastic中文社區公衆號 (elastic-cn)

爲您聚集 Elastic 社區的最新動態、精選乾貨文章、精華討論、文檔資料、翻譯與版本發佈等。

喜歡本篇內容就請給咱們點個[在看]吧

本文分享自微信公衆號 - Elastic中文社區(elastic-cn)。
若有侵權,請聯繫 support@oschina.cn 刪除。
本文參與「OSC源創計劃」,歡迎正在閱讀的你也加入,一塊兒分享。

相關文章
相關標籤/搜索