轉自：
https://juejin.im/entry/5905ac37a22b9d0065e1199c
基於關系型數據庫的水平擴展方案有很多開源的解決方案，但成熟穩定的產品鳳毛麟角。當當自研的數據庫中間層 Sharding-JDBC 在公司內部已廣泛使用，並在開源社區推廣且初見成果。目前的 Sharding-JDBC 已經歷從初出茅廬到穩定運行，再到變革的關鍵點。
Sharding-JDBC 采用在 JDBC 協議層擴展分庫分表，是一個以 jar 形式提供服務的輕量級組件，其核心思路是小而美地完成最核心的事情。
對於這么優秀的一個項目， 在高手問答第 144 期中，我們策划了 “ 輕量級數據庫中間層 Sharding-JDBC 深度解析 ” 的主題，並邀請了 @當當_亮（張亮）作為高手嘉賓。
本文整理了此次高手問答中一些精彩的問答。
對於這樣一個項目，想必大家都會關心它的開發初衷和適用場景等相關問題。下面先來看看張亮老師對於這些問題的解答。
Q：Sharding-JDBC 的設計初衷是什么？旨在解決什么場景的問題？
Sharding-JDBC 的設計初衷是想提供一個數據庫中間層，用於透明的處理分庫分表，而無需業務開發人員在業務代碼中根據分片鍵生成 SQL。
第一版的分庫分表並不是現有的 Sharding-JDBC，而是當當的一個內部框架 ddframe 的數據庫模塊，dd-rdb 的其中一項功能就是分庫，沒有分表功能，當時只是做了簡單的 SQL 解析。后來隨着 ddframe 被各個團隊采用，只分庫的需求漸漸不夠用了，而 dd-rdb 里面有大量的數據庫 ORM 相關的東西，為了使分庫分表這一核心需求更加純粹，我們才將其中的分片的部分單獨提煉出來並命名為 Sharding-JDBC，用於在 Java 的 JDBC 層面提供一層驅動，無縫的處理這方面的需求。
Q：Sharding-JDBC 適用於哪些場景，不適用於哪些場景？是否有性能評估？
對於關系型數據庫數據量很大的情況，需要進行水平拆庫和拆表，這種場景很適合使用 Sharding-JDBC。
舉例說明：假設有一億數據的用戶庫，放在 MySQL 數據庫里查詢性能會比較低，而采用水平拆庫，將其分為 10 個庫，根據用戶的 ID 模 10，這樣數據就能比較平均的分在 10 個庫中，每個庫只有 1000w 記錄，查詢性能會大大提升。分片策略類型非常多，大致分為 Hash + Mod、Range、Tag 等。
Sharding-JDBC 還提供了讀寫分離的能力，用於減輕寫庫的壓力。
此外，Sharding-JDBC 可以用在 JPA 場景中，如 JPA、Hibernate、Mybatis，Spring JDBC Template 等任何 Java 的 ORM 框架。
Java 的 ORM 框架也都是采用 JDBC 與數據庫交互。這也是我們選擇在 JDBC 層，而非選擇一個 ORM 框架進行開發的原因。我們希望 Sharding-JDBC 可以盡量的兼容所有的 Java 數據庫訪問層，並且無縫的接入業務應用。
不合適的場景主要是兩方面：
- 不適合 OLAP 的場景。雖然 Sharding-JDBC 也能做聚合分組查詢，但大量的 OLAP 場景，仍然會比較慢，而且復雜的 SQL（如子查詢等）目前還沒有支持。這種查詢不太適合大數據和高並發的互聯網 online 數據庫，建議使用合理的 OLTP 查詢。
- 不適合事務強一致的要求。目前 Sharding-JDBC 的事務支持兩種，一種是弱 XA，另一種是柔性事務（BASE）。因為 XA 的兩階段或三階段提交其性能較低，因此互聯網公司基本不會采用。而無論是弱 XA 還是柔性事務，都無法保證事務在任意時間段完全保證一致，其中柔性事務能保證數據的最終一致性，但達到最終一致性的時間仍然不可控。因此對於對跨庫事務強一致要求很高的場景，需要從設計方面去考慮數據庫 schema 的合理性。
對於 JTA 事務，目前 Shariding-JDBC 沒有實現 JTA 的標准。而且由於在互聯網場景下使用 JTA 比較少見，因此暫時不支持 JIA 事務。
在 osgit 上有性能測試文檔。單庫的場景下，由於需要進行 SQL 解析以及路由，器性能損失是 0.02%。雙庫的場景下，采用了分布式的方式存取數據，性能提升越 94%。
那么對於同類的項目，老師又是如何看待的呢？
Q：Sharding-JDBC 和其他同類產品有什么區別？能不能集成到 SparkSQL 或者 Hive？
目前和 Sharding-JDBC 這種基於 JDBC 層架構類似的，據我所知只有 TDDL，而 TDDL 並未將分庫分表這塊開源。基於 JDBC 層進行分片的好處是輕量、簡單、兼容性好以及無需額外的運維工作。缺點是無法跨語言，目前僅支持 Java。
現在暫時未考慮集成 SparkSQL 或者 Hive。因為 Sharding-JDBC 的定位還是關系型數據庫中間層，為了穩定性的考慮，不會改變數據庫的存儲引擎。未來我們會做基於 Proxy 版本的 Sharding-JDBC-Server，會漸漸的考慮將 Spark 等大數據的查詢方式引入進來。
Q：Sharding-JDBC 與 Mycat 有一定的相似性，區別點在於對於 SQL 語句的自解析上，是否可以這么理解？
從設計理念上看確實有一定的相似性。主要流程都是 SQL 解析 -> SQL 改寫 -> SQL 路由 -> SQL 執行 -> 結果歸並。但架構設計上是不同的。Mycat 是基於 Proxy，它復寫了 MySQL 協議，將 Mycat Server 偽裝成一個 MySQL 數據庫，而 Sharding-JDBC 是基於 JDBC 接口的擴展，是以 jar 包的形式提供輕量級服務的。
SQL 解析這塊，現在的 Shariding-JDBC 和 Mycat 也比較相似，都是使用 Druid 作為 SQL 解析的基礎類庫。但 Sharding-JDBC 正在重寫 SQL 解析這塊，是去掉 Duird 的完全自研版本。不可否認 Druid 是一個優秀的連接池，而且 SQL 解析這塊做得也很強，但它畢竟不是一個專門為了 Sharding 而做的 SQL 解析器，它的大致解析流程是 Lexer -> Parser -> AST -> Vistor，使用者需要實現它的 Vistor 接口，將自己的業務邏輯在 Vistor 中實現，因此需要通過 Vistor 再生成 SharidingContext，而抽象語法樹 AST，也需要對 SQL 完全理解。Sharding-JDBC 自研的 SQL 解析器，對於 Sharding 不相關的關鍵詞采用跳過的方法，整體解析流程簡化為 Lexer -> Parser -> SharidingContext，在性能以及實現復雜度上都有所突破。
接下來老師和大家分享了一些關於 Sharding-JDBC 功能的問題
Q：Sharding-JDBC 是否支持讀寫分離？
Sharding-JDBC 從 1.3.0 開始支持讀寫分離。其功能包括：
- 根據配置區分寫庫和多個讀庫，目前暫時只有輪訓策略選取讀庫，可以配合分庫分表使用。
- 通過 Hint 強制指定某次查詢走寫庫。
- 如果在同一線程且同一數據庫連接中有發現 DML 語句，則該 DML 之后的查詢都從寫庫查詢，DML 之前的 DQL 語句不受影響，仍然查詢讀庫。其目的是保持同一用戶線程的數據一致性。
但限於 Sharding-JDBC 本身設計的考慮，數據庫層面的主從切換以及主從數據同步，Sharding-JDBC 並不負責。Sharding-JDBC 定位仍然是輕量級的增強版數據庫驅動。因此由於主庫和從庫同步延遲導致的數據不一致，並不是 Sharding-JDBC 的處理范疇。
另外由於 Sharding-JDBC 本身是分庫分表中間件，讀寫分離也是后加入的功能，因此可以支持分庫分表+讀寫分離，但是僅讀寫分離目前還不容易配置，未來也會將讀寫分離提煉出來作為獨立的 API 使用。
Q：在現有的系統架構的基礎上，Sharding-JDBC 能否與第三方數據庫連接池（如：C3P0，Druid 等）集成，實現分庫分表+讀寫分離？
是的，可以支持。Shariding-JDBC 本意就是只做分片 + 讀寫分離，連接池應該交由連接池去處理，各做各的互不影響。
Q：分庫分表使用 like 查詢，是否能查詢出來？性能如何？會去查詢所有的庫和表嗎？
- 分庫分表使用 like 查詢是有限制的。目前 Shariding-JDBC 不支持 like 語句中包含分片鍵，但不包含分片鍵的 like 語句可以正確執行。
- 至於 like 性能問題，是與數據庫相關的，Shariding-JDBC 僅僅是解析 SQL 以及路由至正確的數據源而已。
- 是否會查詢所有的庫和表是根據分片鍵決定的，如果 SQL 中不包括分片鍵，就會查詢所有庫和表，這個和是否有 like 沒有關系。
Q：Sharding-JDBC 是否有完善的管理配置界面？
目前 Sharding-JDBC 還沒來得及做配置界面。目前主要集中於以 jar 包的形式提供服務，和業務應用一起發布，旨在簡化開發，對 DBA 無影響，因此 DBA 看到的還是分庫后的零散的數據庫。
未來會做配置中心，用於動態的修改分片數據源，也會配套的提供管理界面。未來還會將數據庫的 Metadata 統一管理起來，為 DBA 提供更加友好的服務。
Q：Sharding-JDBC 如何強制查詢走主庫？
讀寫分離的文檔地址：dangdangdotcom.github.io/sharding-jd…
大致使用方式如下：
HintManager hintManager = HintManager.getInstance(); hintManager.setMasterRouteOnly(); // 繼續JDBC操作
還有一些與 Sharding-JDBC 相關的問題，張亮老師也進行了詳盡的解答
Q：Sharding-JDBC 是如何解決系統魯棒性的問題的？我們的后台對服務的可靠性要求比較高，目前還在考慮異地災備的情況。如使用 Sharding-JDBC 的話，碎片化的庫表結構是否會增加運維難度？
因為 Sharding-JDBC 是一個 jar，它與業務應用的生命周期是一致的，同生同死。因此只要解決好使用 Sharding-JDBC 的業務系統的魯棒性就可以了。
碎片化庫表的問題，即使不用 Shariding-JDBC 分庫分表，也會同樣存在的，Shariding-JDBC 確實沒處理這塊，不過也不會更加惡化。
等核心穩定后，未來會考慮為 DBA 做運維工具。
Q：請問 Sharding-JDBC 自研的 SQL 解析器開源否？性能能否有大的提升？另外，現在當當的業務中，數據庫的分庫分表遷移可否自動化？
Sharding-JDBC 自研的 parser 是開源的，目前在 parser 這個分支，但是還未做完，仍然在快速的迭代中。
SQL 解析原理和 Druid 基本相同，但是簡化了一些流程。Duird 的初衷是對 SQL 進行監控、分析以及規范化，因此它的 SQL 解析場景需要對 SQL 進行完全的理解。采用 Druid 的作為基礎解析器的 Sharding-JDBC 解析流程為：（Lexer -> Parser -> AST -> Vistor） -> SharidingContext，其中括號內是 Duird 框架的流程，無法修改。而 Sharding-JDBC 僅需理解與 Sharding 相關的關鍵字，無關內容則采取跳過的方式，因此將直接生成分片上下文，無需再通過抽象語法樹的訪問器再獲取。
New Parser 的解析流程簡化為：Lexer -> Parser -> SharidingContext。因此在性能以及實現復雜度上都有所突破。具體的性能測試報告目前還未做，會隨着 New Parser 分支完全一起發布。
關於分庫分表自動遷移的事，當當還沒有做到自動化。由於數據遷移更加貼近於數據庫運維工具，和 JDBC關系不大，因此 Shariding-JDBC 也暫時未將數據遷移納入范圍。
關於 Sharding-JDBC 未來的規划，張亮老師也和我們分享了很多干貨
Q：Sharding-JDBC 下一步規划是什么？
Sharding-JDBC 目前正在進行 SQL Parser 部分的重寫。之前的 Sharding-JDBC 使用 Duird 作為 SQL 解析的基礎工具，但基於各方面的考慮，我們決定采用自研的方式解析 SQL，能進一步的提升性能和 Sharding 的准確性以及兼容性。
New SQL Parser 完成之后，我們會着重處理之前沒有完成的柔性事務 TCC 部分，更多類型 SQL 的支持以及配置動態化。
這些做完之后會考慮將 Sharding-JDBC 分為 Sharding-Driver 以及 Sharding-JDBC-Server 兩個版本，用於滿足不同用戶的需要。Sharding-JDBC-Driver 會更加輕量級，而 Sharding-JDBC-Server 會以 Proxy 的形式提供服務，能更好的處理數據遷移，事務以及 OLAP 等需求。
Shariding-JDBC 的核心應該就是 JDBC 驅動的增強，以 jar 形式提供輕量級的服務。大體上看，Sharding-JDBC 的生態應該大致分為 3 個環路：
- 一環是 JDBC 相關的核心功能，包括分庫分表、讀寫分離、分布式主鍵等。這個是小而美的核心部分。
- 二環是和數據庫相關，但不屬於 JDBC 范疇的，將以插件的形式提供，包括柔性事務、數據庫的 HA、數據庫 Metadata 管理、配置動態化等。
- 三環是業務或使用友好度相關的，包括多租戶、賬戶安全、Spring 自定義命名空間、Yaml 配置等。
有很多朋友提到關於對其他語言的支持，因為 Shariding-JDBC 是基於 Java 提供的 JDBC 規范的接口所開發，因此目前暫時不支持 Python、Node.js 等。
但其核心的解析、路由、結果歸並等功能模塊和基於 Proxy 版本開發幾乎是一致的。因此，未來我們有打算提供 Shariding-JDBC-Server 版本，將會支持全語言。
有朋友看到我們在考慮開發 Sharding-JDBC-Server，以為目前的 Sharding-JDBC 模式遇到了某些不可解決的問題。其實 Shariding-JDBC 以當前的定位來說，沒有遇到不可解決的問題，但如果想做的更多（前面提到的數據遷移，分布式事務，元數據管理等），則需要向 Proxy 的方式靠攏。Shariding-JDBC 想提供兩種不同的使用方式，給使用者更自由的選擇。
還有就是對 SQL 語句的支持。由於時間和精力有限，目前無法做到全 SQL 的兼容。我們現階段的目標是盡量支持 OLTP 最常用的 80% 的 SQL。目前支持聚合、分組、排序等查詢。暫時不支持 distinct，對 or 的支持也不是特別完善，但是 distinct 和 group by 可以互換，or 也可以用 in 代替。因此絕大部分 SQL 經過修改是可以使用的。
有朋友提到，既然 distinct 和 group by 可以互換，or 可以用 in 代替，那么是不是可以考慮直接在 SQL 解析的時候自動切換？
對於這個問題，雖然這樣做在技術上是可行的，但是設計上來說還有待商榷。
如果已經做了 distinct 和 or 的解析，其實完全沒有必要改寫 SQL，直接支持就可以了。而改寫 SQL，對於 DBA 的調試就比較痛苦，因此我們希望做到盡量不修改 SQL，僅修改必要的部分，如：分表的名稱、avg 轉化為 count 和 sum、limit 的 offset 和 rowCount。
對於過於復雜的 SQL，如子查詢等，不一定適合在大數據量的分片數據庫中使用，也許需要重新梳理。
未來我們也會對 SQL 兼容性這塊持續進行提升。
目前 Sharding-JDBC 僅支持 MySQL，對其他數據庫的支持（比如 Oracle）也正在進行。現在 New SQL Parser 正在進行中。計划在這個版本發布對 Oracle、PG 以及 SQLServer 的支持。對於 Oracle 以及 SQLServer 主要的支持在於特殊關鍵詞識別和分頁。
New SQL Parser 確實工作量比較大，雖然目前整體代碼已經梳理得差不多了，但想穩定的提供服務還需要一些時間。預計 4 月份提供 snapshot，6 月份提供穩定版。
New SQL Parser 在 Git 的 parser 分支持續更新中，歡迎繼續關注。
還和大家分享了很多數據庫相關的使用經驗和心得
Q：現在用着自己寫的 Sharding，不過在解析語句這塊比較尷尬，有些語句解析不來，所以自己封裝 jsqlparser，Druid，自寫正則三個方法來取表名，老師有什么建議？
jsqlparser 用的是 JavaCC 的方式解析 SQL，相對於 Druid 來說，性能比較低。正則解析的話，性能應該會更低，而且這兩種方式都比較難調優。
Druid 采用的詞法和語法分析的方式解析 SQL，編碼工作量大，但性能會提升很多。Druid 的 SQL 解析器對於開發者而言稍微有些不易上手。Shariding-JDBC 采用與 Druid 相同的 SQL 解析方式，但為 Sharding 做了優化。
只是獲取表名的話，jsqlparser 和 Duird 都沒問題，如果考慮性能問題，還是建議用 Druid 或者參考下 Sharing-JDBC 的做法。
Q：對於分布式事務這塊，有什么實踐經驗分享嗎？
分布式事務這塊，我們認為 XA 多階段提交的方式，雖然對分布式數據的完整性有比較好的保障，但會極大的降影響應用性能，並未考慮采用。我們采用的是兩種方式，一種稱之為弱 XA，另一種是柔性事務，即 BASE。
弱 XA 就是分庫之后的數據庫各自負責自己事務的提交和回滾，沒有統一的調度器集中處理。這樣做的好處是天然就支持，對性能也沒有影響。但一旦出問題，比如兩個庫的數據都需要提交，一個提交成功，另一個提交時斷網導致失敗，則會發生數據不一致的問題，而且這種數據不一致是永久存在的。
柔性事務是對弱 XA 的有效補充。柔性事務類型很多。
Sharding-JDBC 主要實現的是最大努力送達型。即認為事務經過反復嘗試一定能夠成功。如果每次事務執行失敗，則記錄至事務庫，並通過異步的手段不斷的嘗試，直至事務成功（可以設置嘗試次數，如果嘗試太多仍然失敗則入庫並需要人工干預）。在嘗試的途中，數據會有一定時間的不一致，但最終是一致的。通過這種手段可以在性能不受影響的情況下犧牲強一致性，達到數據的最終一致性。最大努力送達型事務的缺點是假定事務一定是成功的，無法回滾，因此不夠靈活。
還有一種柔性事務類型是 TCC，即 Try Confirm Cancel。可以通過事務管理器控制事務的提交或回滾，更加接近原生事務，但仍然是最終一致性。其缺點是需要業務代碼自行實現 Try Confirm Cancel 的接口，對現有業務帶來一定沖擊。未來 Sharding-JDBC 會帶來對 TCC 的支持。
還有一些其他的分布式事務，如 Google 提出的 F1 等，由於 Shariding-JDBC 仍然使用數據庫的原有存儲引擎，並未改變，因此暫時不考慮對此類型事務的支持。
Q：請問何時需要分表？目前我們都是按照業務分庫。
分庫分表分為水平拆分和垂直拆分。按照業務分庫或分表屬於垂直拆分。水平拆分是將同樣的庫或表按照一定的分片規則拆成多個。
分庫和分表都可以有效的處理由於數據量大而導致的查詢性能下降的問題。分庫還可以緩解高並發對數據庫帶來的壓力，但僅分表可以使用本地事務代替分布式事務。因此分庫和分表的合理使用是需要根據業務場景來決定的。
Sharding-JDBC 作為開發的基礎類庫，支持分庫和分表，將選擇的余地留給業務開發的工程師。
Q：請教一下，根據主鍵分片，以用戶名登錄，如何知道用戶落在哪個分片上？
如果用戶名是主鍵，則可以直接根據您定義的分片策略計算，算出該用戶最終落在哪個庫的哪張表上。
如果用戶名不是主鍵，則必須通過全路由查詢，一個一個的找，直到找到為止。
張亮老師還和大家暢談了很多其他關於數據庫的問題
Q：我有一個很大的問題，就是如何判斷自己需要搞魔改還是換數據庫呢？MySQL 各種魔改的成本恐怕未必比買高端數據庫便宜吧。特別是現在數據庫很多都有雲服務可以選擇，買個 Oracle 或者微軟的雲服務數據庫，入門成本現在應該可以被中小企業接受了吧。
這個問題比較大，需要從整體的角度來討論一下。
MySQL + 開源分片中間件是公司將技術核心抓在了自己的手里，互聯網公司大多願意采用。這個不僅是眼前的經濟成本問題，還包括了技術問題解決成本、對業務發生變化時對技術的控制能力等。比較成熟的公司都會沉淀出適合自己的中間件架構，以及各種監控、治理等輔助系統。
NoSQL 也是一種選擇，但它們的定位是關系型數據庫的有益補充，並不是要完全替換掉關系型數據庫，因此，關系型數據庫 + 分片仍然有其存在價值。
對於 Oracle，我的看法是重要的業務數據可以考慮，而一些周邊數據，就沒什么必要。當然如果公司不差錢，定位又非技術導向，而是純業務導向的話，完全依賴 Oracle 也是可以的。只不過 Oracle 不能滿足互聯網的全部場景。各種雲數據庫和 Oracle 差不多，公司對自我的定位很重要。如果有核心業務，完全可以把技術全包出去。
個人理解，當業務量較小或適中的情況下，采用 Oracle 和雲數據庫是合理的選擇。而在公司的業務爆炸式增長的大型互聯網公司，這些方案未可行，因為獨角獸級別的公司遇到業務場景基本都是獨一無二的，其解決方案並不是第三方功能能夠直接給予的。成長到一定程度的公司大多會選擇自研 + 開源的組合，保證其技術的適應度以及和業務的匹配度。
Q：所以說選型其實是針對 OLTP 業務模型和數據量的變化作為主要考慮指標？在初期未必有足夠的技術和資金的時候，選擇免費的 MySQL 先用起來。然后等活下來有能力做大，數據也暴漲了，這時候就招人來魔改，或者選擇已有魔改方案。傳統商業數據庫集中在財務等關鍵地方，或者 OLAP 這種 MySQL “草雞”的領域（也可能完全不用數據庫選擇大數據產品）。不知道我理解得是否正確。
是的，正確。
簡單說，剛起步用 MySQL；有錢並且業務量適中用 Oracle，核心業務用 Oracle，非核心業務用雲數據庫；資金不充足業務量較大用 MySQL + 開源中間層；業務量超大只能自研。
大數據和關系型數據庫不是一個方向，主要用於存儲其他類型數據了，訂單、交易等數據一般不會放大數據，更適合日志，瀏覽記錄等。
Q：另外在選型上，我還想提一下 PG 這個數據庫。業內選擇 MySQL 比較多，PG 比較少。是不是就是因為 PG 在大規模集群魔改方面一直沒有成功案例的關系？起碼自從谷歌魔改 MySQL 開始，我們聽說了太多的案例。PG就好像沒聽說過了。
用了 MySQL，哪怕有各種糟糕，但是因為有各種成功案例和各種第三方開源魔改集群方案，起碼我知道可以做得夠大。但是 PG 雖然特性上遠遠強過 MySQL，但是因為本身不像 MySQL 那么靈活，所以采用的反而少。有錢的買商業，沒錢的 MySQL+Hadoop。
Sharding-JDBC 的服務對象是任何關系型數據庫，無論是 MySQL 還是 PG。
不過針對這個問題可以再大致聊一下。很多公司的技術選型在於平衡，尤其是數據庫選型這塊。不一定 MySQL 就是最好的數據庫，某些方面 PG 確實要更好，但 MySQL 是在各個方面受認可最多的數據庫。比如周邊的 MHA 套件、開發和 DBA 對數據庫的熟悉程度等。因此，即使是 MySQL 的分支版本 MariaDB 或 Percona，無論功能性能再怎么提升、引擎再怎么變化，其總體的認可度也還是不如 MySQL 的。
Q：有一個問題一直很疑惑，目前分庫分表的中間件有兩種思想，分別是：
- 類似 Sharding-JDBC 及 TDDL 的增強版 JDBC 驅動思想
- 類似 Mycat 增加中間層，然后在中間層進行分庫分表思想
我想問的是，這兩種思想都有什么優勢和劣勢呢，大公司的主流選型又是哪種？
兩種方式各有優缺點。
JDBC 驅動版的優點：
- 輕量，范圍更加容易界定，只是 JDBC 增強，不包括 HA、事務以及數據庫元數據管理
- 開發的工作量較小，無需關注 nio，各個數據庫協議等
- 運維無需改動，無需關注中間件本身的 HA
- 性能高，JDBC 直連數據庫，無需二次轉發
- 可支持各種基於 JDBC 協議的數據庫，如：MySQL，Oralce，SQLServer
Proxy 版的優點：
- 可以負責更多的內容，將數據遷移，分布式事務等納入 Proxy 的范疇
- 更有效的管理數據庫的連接
- 整合大數據思路，將 OLTP 和 OLAP 分離處理
因此兩種方式互相可以互補，建議使用 Java 的團隊，且僅 OLTP 的互聯網前端操作。有可能會使用多種數據庫的情況，可以選擇 JDBC 層的中間件；如果需要 OLAP 和 OLTP 混合，加以重量級的操作，如數據遷移，分布式事務等，可以考慮 Proxy 層的中間件。但目前開源的數據遷移和分布式事務的完善解決方案還不常見。NewSQL 這種改變數據庫引擎的方式就不在這里討論了。