如何評判基於中間件的分散式mysql與 雲資料庫？

阿里雲，騰訊雲，百度雲三家，只有阿里雲提供了分散式mysql的中間件drds，三家都有自己的雲資料庫。

1、是騰訊和百度在分散式中間件方面技術不行嗎？為什麼沒有提供中間件產品？

2、基於中間件的分散式mysql相比雲資料庫怎麼樣？不同點及優點缺點。

3、社區版的分散式中間件mycat怎麼樣？

---

利益相關，本尊是做DRDS的，當然也了解tidb，蟑螂資料庫, oceanbase，否則沒法做商業產品。

如果這個問題純粹從當前時間、單純技術層面去看，對比技術先進性，那就說不清楚，每個產品都能說出一堆的優點，比如pg非常優秀，有搞定全世界所有資料庫需求的架勢，但是實際上也有很多問題，就像 @郭寬 同學說的，業務想要銀彈，可惜沒有完美的銀彈：），所以必須加上業務場景來聊。

從業務領域來說：前台在線業務，後台adhoc+分頁+打標，後台adhoc+聚合，數據報表和分析。大概這4類業務。確實很多業務方將這4類需求混在了一塊，然後丟給一個NB資料庫處理，然後出來各種問題，可能一個單條數據主鍵查詢要個2秒鐘--(我們真碰到過這種情況)，因為這4類需求對資料庫資源要求是不一樣的，混用在一塊，導致workload分配非常難。所以目前看上去比較合理的做法是鏈路隔離，然後選用合適的產品。

DRDS選擇解決前台在線業務和後台adhoc+分頁+打標處理這樣的業務，其中前台業務最大的特點在於圍繞某一個或者某幾個數據主體進行操作，並且如果要達到超高性能，必須關注數據聚簇或者說data locality，所以拆分方式貼合數據特點是DRDS最大的優勢,當然也帶來架構設計上的問題,但是實際上所有的資料庫在使用的時候都有做表結構設計和數據分布設計，只是分散式突破了大家原來的認知而已。

那接下來有一個問題，我就一個屌絲用戶，能否不關注拆分？答案肯定是可以的，但是意味著你會碰到分散式事務或者分散式資料庫中所說的全局二級索引，而這個是目前上述我所列產品的重要區別。

先不評論其他產品，DRDS目前無法實現嚴格一致分散式事務的原因實際上就是在於MySQL, 分散式事務目前最好的方式要麼鎖，要麼MVCC，鎖我們評估下來坑比較多，涉及到狀態維持，所以基本上目前來看分散式mvcc是相對比較好的分散式強一致事務的實現(不過也有很多坑，各家實現上有些許區別，表現出來的能力也有差異)。

實際上DRDS對於分散式SQL引擎積累了很多優化經驗(我們積累了很多用戶SQL經驗)，我們的SQL引擎將在不久更新，將會有非常好的SQL兼容性和產品格局。另外實現強一致分散式事務+全局二級索引實際上並沒有想像的那麼困難，我們已經有這個版本，但是目前我不敢給各位用，原因看總結。

最後總結下：用最新的分散式資料庫，可能不需要關心拆分，那麼你的業務量一大，按照二級索引查詢，最起碼2次跨網路數據操作(要麼覆蓋索引)，然後索引一致性黑盒(分散式索引維持比單機難很多)，另外你的數據會放在一個發展小於5年的資料庫上，而且是最後一份數據(所以採用paxos,raft等加持)，如果你用DRDS，你可能會稍微痛苦點，需要選擇拆分欄位(實際上原則非常簡單，前台類業務肯定能找到一個數據主體，然後按這個拆就可以)，然後需要同步幾份數據做二級索引(開發中，18.4提供)，碰到分散式事務，需要用最終一致方式解決，但是你的數據是放在mysql上，當然還有三節點版本加持。

未來美好，現實殘酷，各取所需。

---

DRDS雖然名義上是分散式資料庫，但實際上阿里雲採用的是分庫分表的方式，業務上不得不進行耦合，屬於開發者深惡痛絕但是又不得不這麼做的架構(曾經在廣告系統中被折騰過很久)。

我認為百度和騰訊並非技術不到位，而是每家公司在不同階段有不同的優先順序，阿里雲在資料庫領域已經深耕很久了，面臨擴展業務的需要，想要儘可能覆蓋更多場景，而對於BT兩家，還處在打開局面的時代，只可能把精力用在用戶規模最大的群體(也就是單機或主從結構的MySQL，MongoDB)

未來分表分庫的架構設計勢必還會長期存在，同時這個領域的探索也愈發火熱，如TiDB, CockroachDB 在上層做分散式資料庫，PolarDB，Aurora 在存儲層做分散式，也有類似OneSQL這樣的商業中間件出現，但是到底哪一個方向會勝出，我們目前只能等待時間來檢驗了，不過我相信所有的方案都會殊途同歸，大家要解決的都是數據量越來越大的時代，如何做到性能和擴展性同步優化的事情，在相當長的時間裡各種產品會共存並找到自己最合適的位置。

從我們自身的利益相關角度，作為存儲引擎公司(TerarkDB)，我們期望自己成為各種解決方案背後的發動機，在上面的所有場景下為客戶提供服務和解決方案。事實上沒有最好的方案，只有最適合自己的方案。

另外，根據我得經驗，很多用戶往往過高預估自己的數據量，過低的預估現在的硬體承載能力(我們有個客戶單機2T內存)，甚至目前很多資料庫一體機可以承載幾百TB的數據量，這對在線事務場景是遠遠足夠的。之所以部分人依然認為自己在線服務的數據量會更大，是因為很多人沒有把OLTP和OLAP分開，把自己的在線服務業務和分析業務耦合在一起，給自己製造了很多不必要的麻煩，又期望尋找一顆銀彈解決問題，反而適得其反。當然有人提到HTAP，目前看還不好判斷趨勢。

---

這個問題正好就是資料庫選型的衍生類問題。

簡單說，就是分庫分表類的方案更貼近阿里的業務需求，而阿里主要用分庫分表的中間件解決了大寫入類且必須保證事務的場景，這類場景百度和騰訊並不多見。

百度可以用類elasticsearch的方式來解決數據sharding

而騰訊要存聊天記錄可以採用一些時序類或者是nosql的經典辦法

而唯有阿里擁有大流量事務 + 分散式一致性事務的場景，且在sharding後還有組合索引，多索引查詢的需求，所以發展出了txc tddl的解決方案

當然類似的還有youtube的vitess，由於強調存入e r 關係圖似的數據，所以雖然同為分庫類產品，但sharding key的設計又和tddl不同

---

題主提了三個問題，我之前的答案算是答非所問吧。 所以特來修改下。 個人感覺阿里資料庫的水平要高些。 雖然因為月餅事件，對阿里觀感不是特別好。但就事論事，阿里在資料庫方便的積累還是很足的。阿里內部會有至少三個組在做不同的資料庫的工作。我了解比較多的就是Ocean Base 和 AliSQL。

第二個問題：中間件和分散式資料庫的優缺點。 我覺得分散式資料庫是未來資料庫該有的樣子。 資料庫從成為一門學科到發展已經快五十年了。 窮則思變，這個時候資料庫本身也是要尋求自身的改變。 相較於分散式資料庫，中間件只是在原來的破船上修修補補。如果這樣可以有效果，大清就不會亡了。 分散式資料庫才是一劑猛葯。 中間件這種東西除了難為程序員，難為業務本身還能有啥用的？我能理解一個公司在技術選型的時候需要選擇成熟穩重的產品，但也要銘記於心的一點是：一旦選型確定，由於前期的成本，後期改變技術架構的成本是巨大的。所以在資料庫上這種影響巨大的選型上，是可以冒險風險的。 據我所知，很多用戶都是直接使用TiDB這款分散式資料庫而沒有跟我們直接聯繫的。

題主的第三個問題，不是很清楚就留給其他人回答吧。

====================修改前。

我猜測題主所謂的雲資料庫是指分散式資料庫？ 如果是的話，推薦TiDB。 谷歌Spanner的開源實現，全球poc三百多家。產品穩定，讓你避免分庫分表。

最後打個小廣告：歡迎各路分散式系統，存儲，資料庫大牛來勾搭我。我缺手機了。 郵箱：yzx at http://pingcap.com

---

1. 不知道..

2. 簡單分析下(雲資料庫指share nothing的分散式資料庫）

中間件優點：不改動或少改動現有生態和架構，兼容分庫分表，技術成熟。

中間件缺點：部分SQL不支持，仍需要指定sharding鍵，無法做到業務完全無感知，事務遷移複製都不太支持。

雲資料庫優點：避免分庫分表，屏蔽數據分布細節，少運維（畢竟DB幫你做了遷移複製元數據管理）。

雲資料庫缺點：沒有特別成熟的實現，對SQL的兼容目前看沒有特別好的方案(類似Spider的基於Percona前端的實現性能不好）。

3. 南哥比較熟... @南哥

我司(HW)有一個分散式DRDS剛上線歡迎使用。

---

對於資料庫領域的技術路線和產品成熟度，是有現成的國際經驗可以參考，建議參考下cmu 16年關於newsql的一篇論文https://www.google.com.hk/url?sa=trct=jq=esrc=ssource=webcd=1cad=rjauact=8ved=0ahUKEwirmuepyLfWAhWFjpQKHR8aACAQFgglMAAurl=https%3A%2F%2Fwww.cs.cmu.edu%2F~pavlo%2Fpapers%2Fpavlo-newsql-sigmodrec2016.pdfusg=AFQjCNGlAZpqkWm6z2TyhyKm6wUEJbZL5g。

分庫分表中間件在北美是2000年初比較流行的技術，05年之後各大互聯網公司轉向了自己的newsql，分庫分表的方案不再流行。google的spanner，amazon的aurora，facebook人出來搞了個memsql，stonebraker造的新輪子voltdb。

分庫分表中間件目前的現狀，限制太多，老業務很難平滑遷移過來。去年有個做業務同事找組裡dba諮詢mycat，聽說諸多限制就沒興趣了。

分庫分表中間件，方案簡單容易實現，實際上把很多資料庫的工作交給業務來做。這種情況的出現，只是業務爆髮式增長，而資料庫本身技術發展較慢情況下的折中方案。從rdbms發展歷史上看，app需要關心的越來越少，dbms才有其存在的合理性。編程語言、操作系統等系統軟體，都是如此。

---

就是是否原生支持分散式的區別。

像mongodb原生就有分散式，這樣直接上雲會非常簡單，所以各家都支持。像MySQL這種原本是單機的，要想真正在雲上做到分散式，往往需要藉助中間件，而實現一個通用且高效的中間件比較難，所以阿里雲做的好一點。側面說明阿里再資料庫上的積累更多。

---

DRDS 這種分庫分表做法,總感覺不夠徹底

或許這是一個在當時分散式資料庫不成熟情況下的 折中方案吧,

未來的資料庫形態應該是 oceanbase 或者 tidb這類吧.

---

推薦閱讀：