名詞解釋
- DB：database，泛指關係型數據庫，具有嚴格事務隔離機制的數據類庫產品，如mysql、sqlserver、postgresql、oracle、db2等。db-engine綜合排名前面的全部是關係型數據庫。
- ES：elasticsearch，最好的開源搜索引擎產品，Nosql非關係型數據庫，不具備嚴格事務隔離機制。當前db-engine綜合排名第7。
- 應用：本文泛指業務應用系統，是OLTP場景，非OLAP場景，大量運用事務型數據庫產品的業務系統。
- 索引：在關係型數據庫中是指數據檢索的算法，在Elasticsearch是指數據存儲的虛擬空間概念，類同數據庫中的表。
背景需求
為什麼單一DB不能滿足應用系統？
為什麼單一ES不能滿足應用系統？
為什麼要使用DB結合ES混用的模式？而不是結合其他Nosql？比如Mongodb......
下面從技術層面與業務層面分析探討。
- 技術層面
db與elasticsearch的技術特性說明
* 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與elasticsearch業務背景說明
* 業務領域複雜度
* 在進入互聯網/移動互聯網/物聯網之後，業務系統數據量的幾何倍數增長，傳統應當策略當然是採用分庫分表機制，包括物理層面分庫分表，邏輯層面分區等。非重要數據可以採用非關係型數據庫存儲，重要的業務數據一定是採用關係數據庫存儲，比如物流速運行業的客戶訂單數據，不容許有丟失出錯。
* 面對複雜業務系統需求，當下最流行的解決方式是採用微服務架構模式，微服務不僅僅侷限上層應用服務，更深層次的是底層數據服務（（微服務不在本次討論之內），基於領域模型思維拆分分解。應用服務拆分成大大小小數個，可以幾十個幾百個，也可以更多，數據服務也拆分成大大小小數個。
* 業務查詢複雜度
* 分庫分表解決了數據的存儲問題，但需要做合併查詢卻是個很麻煩的事，業務系統的查詢條件一般是動態的，無法固定，更加不可能在分庫分表時按照所有動態條件設計，這似乎代價太大。一般會選擇更強大的查詢數據庫，比如Elasticsearch就非常合適
* 微服務架構模式解決了業務系統的單一耦合問題，但業務系統的查詢複雜度確實提高不少，複雜點的應用服務執行一次查詢，需要融合多個領域數據服務才能完成，特別是核心領域數據服務，幾乎貫穿一個系統所有方面，比如物流速運行業訂單領域。
* DB與ES結合
* 業務數據存儲由關係型數據庫負責，有強事務隔離機制，保障數據不丟失、不串亂、不覆蓋，實時可靠。
* 業務數據查詢由Elasticsearch負責，分庫分表的數據合併同步到ES索引；跨領域庫表數據合併到同步ES索引，這樣就可以高效查詢。
DB與ES結合問題
db與elasticsearch結合的問題
關於DB與Elasticsearch混合主要有以下兩個問題：
- 同步實時性
- 數據一致性
本文不探討此問題，後續會有專題講述如何解決。
混合場景
前面已經論證了關係型數據庫與Elasticsearch混合使用的必要性，接下來是探討混合場景下的業務場景數據模型映射。
1.單數據表->單索引
單數據表映射到單一索引
* 一對一映射關係，關係數據庫有多少個表，Elasticsearch就有多少個索引
* 關係數據庫提供原始數據源，Elasticsearch替代數據庫成為查詢引擎，替代列表查詢場景
* 單數據表為水平分庫分表設計，需要藉助Elasticsearch合併查詢。如圖：電商行業訂單場景，日均訂單量超過百萬千萬級，後端業務系統有需求合併查詢。
* 單數據表業務查詢組合條件多，數據庫索引查詢能力侷限，需要藉助Elasticsearch全字段索引查詢能力，主要替代列表查詢場景。如：電商行業商品搜索場景，商品基礎字段超過幾十個，幾乎全部都可以組合搜索
2.單數據表->多索引
單數據表映射到多個索引
* 一對多映射關係，單數據表映射到多個索引中
* 單數據表即作為 **A索引**的主體對象，一對一映射，如
* 單數據表也作為 **B索引**的子對象，嵌入到主體對象下面
* 基於微服務架構設計，在業務系統中，業務系統劃分多個子領域，子領域也可以繼續細分，如電商行業，訂單領域與商品領域，訂單表需要映射到訂單索引，也需要與商品索引映射
3.多數據表->單索引
多數據表映射到單個索引
* 多對一映射關係，多個數據表映射到單一索引，索引可以採用款表結構，也可以採用子對象映射方式
* 單業務領域，數據表設計時一般會遵循數據庫範式（注：1，2，3，4），即使是反範式設計，也只會增加一點冗餘，如果要多表聯合查詢，數據庫表的關聯效率很低，甚至是運行不起來，需要藉助Elasticsearch合併多個數據表到一個索引中。
* 跨業務領域的數據表要聯合查詢，也需要藉助Elasticsearch整合。
4.多數據表->多索引
多數據表映射到多個索引
* 多對多映射關係，多個數據表映射到多個索引，複雜度高。
* 一箇中型以上的業務系統，會劃分成多個領域，單領域會持續細分為多個子領域，領域之間會形成網狀關係，業務數據相互關聯。
* 數據庫表關聯查詢效率低，跨庫查詢能力侷限，需要藉助Elasticsearch合併；
* 按照領域需求不同，合併為不同的索引文件，各索引應用會有差異，部分是通用型的，面向多個領域公用；部分是特殊型的，面向單個領域專用。
5.多源數據表->多索引
多源數據表映射到多個索引
* 多源多表，多對多映射關係，數據表與索引之間的映射關係是交叉型的，複雜度最高。
* 一個大中型業務系統，不同的業務場景會採用不同的數據存儲系統。
* 關係型數據庫多樣化，如A項目採用mysql，B項目採用postgresql，C項目選用sqlserver，業務系統通用型的查詢幾乎不能實現。
* 非關係型數據庫多樣化，如A項目採用鍵值類型的Redis，B項目選用文檔型的mongodb，業務系統同樣也不能實現通用型查詢。
* 基於異構數據源通用查詢的場景需求，同樣需要藉助Elasticsearch合併數據實現。
結語
- 經驗總結
* Elasticsearch 雖然早期定位是搜索引擎類產品，後期定位數據分析類產品，屬於Nosql陣營，且不支持嚴格事務隔離機制，但由於其先進的特性，在應用系統中也是可以大規模使用，能有效彌補了關係型數據庫的不足。
* 本文主旨探討了DB與ES混合的需求背景與應用場景，目的不是評選DB與ES誰更優劣，是要學會掌握DB與ES平衡，更加靈活的運用到應用系統中去， 滿足不同的應用場景需求，解決業務需求問題才是評判的標準。
- 內容來源
* 內容來源在業務系統中大量運用DB與ES混合實戰，得出的一些實戰與思考，提供後來者借鑑參考，內容原創轉載請註明。
* 本文 2019-12-07 Elastic-北京開發者大會 已經分享，節選自『同步場景』重新整理編寫，更多詳細可以在Elasticsearch社區下載PPT
* 分享主題《CDC：DB到ES實時同步》
- 關於我們
* 作者本人（ynuosoft），Elastic-stack產品深度用戶，ES認證工程師，2012/2013年接觸Elasticsearch，對Elastic-Stack開發、架構、運維等方面有深入體驗，實踐過多種Elasticsearch項目，最暴力的大數據分析應用，最複雜的業務系統應用；業餘為企業提供Elastic-stack諮詢培訓以及調優實施。
* 深圳星圖智能 星圖智能是Elastic官方MSP技術合作夥伴
閱讀更多 一諾大咖 的文章
