㈠ 什麼叫分布式資料庫，有什麼優點和缺點
1.分布式資料庫是資料庫的一種，是資料庫技術和網路技術的結合產物。
2.各有優點和缺點.分布式資料庫分為邏輯上分部物理上分布及邏輯上分布物理上集中兩種。
是的,分布式數據文件便於資料庫的管理維護。
㈡ 資料庫分庫,分表有哪些要注意的以及解決辦法
數據百庫設計的一個原則就是，一個庫里的表越少越好，一張表裡的欄位越少越好。當然也度要畝彎碼看你的UI是怎麼設計的，如果一個頁面只查詢一張表，不涉版及到多表連接，那麼無論放在哪迅哪個庫里都可以，那就建權議分庫。否則就要跨表鬧拍跨庫查詢，那真是噩夢！
㈢ 分布式資料庫相比自建資料庫具備哪些優勢
自建資料庫：
容易產生容量與性能瓶頸
當前的硬體條件下，主流資料庫可以支持單表千萬級數據量的存儲，但是難以支撐密集的並發讀寫，存在性能瓶頸。
分區分表或分庫方案限制太多
採用分區表方案，數據不能跨實例存儲，擴展性和維護性較差。
採用分庫方案，客戶端需要自行管理各庫連接，資料庫連接管理和升級復雜，擴容遷移困難。
伺服器成本高昂
普通X86伺服器支撐能力有限，品牌廠商的伺服器價格高昂，通過增加硬體規格來提升並發性能的成本太高，且能到達的性能高度有限。
在分布式資料庫面前，上面這些都不是問題，有很長廠商都已經把分布式資料庫做的不錯了，如阿里雲，華為雲等。
如下以我熟悉的華為雲分布式資料庫中間件DDM為例為你介紹下，如果感興趣可以去官網了解一下，現在好像還有試用活動：華為雲分布式資料庫中間件DDM
分布式資料庫：
數據分布存儲
DDM採用水平拆分方式，將數據記錄數龐大的單表，按指定的拆分規則，分布式存儲到各個分片中。同時DDM提供路由分發功能，應用服務無需考慮數據該寫入哪個分片，該從哪個分片讀取。
讀寫分離
用戶可以根據數據讀取壓力負載情況，為每個RDS實例配置一個或者多個只讀實例，提高查詢並發性能。
高性能
在實際業務訪問中，sql主要的性能瓶頸集中在物理資料庫節點上。
DDM實例關聯多個RDS節點，減少單個RDS存儲的數據量，同時實現並行計算，支持PB級數據量訪問，以及百萬級高並發。
在線平滑擴容
DDM在不中斷業務的情況下，支持新增RDS實例，水平擴容存儲空間。一鍵式擴容，輕松解決單機資料庫的容量瓶頸。
㈣ 什麼是分布式資料庫
分布式計算機系統空差所支撐的分布式數斗培皮據庫是資料庫技術與計算機網路技術相中蔽結合的產物。與常見的集中式資料庫相比，雖然分布式資料庫的數據分散存儲在網路上的各點，但它可以為網上所有的用戶所共享，任何地方的合法用戶都可以十分方便地獲取和處理所需的數據，就像數據在他們本地的計算機上一樣。
㈤ 分布式資料庫片段查詢是什麼
一些多機查詢計算場景下，要求合並多機數據源，假設某個需求需要將數據再次計算。
計算的列不在select查詢中，拿回來的多機數據源因為沒有需要計算的列，就無法計算。
通過記錄原來select的列數，將需要再次計算的列附加到select列中，待計算完畢後，按照原來的select列數將數據發送給客戶端。
本方案應用於多機查詢處理中（分布式資料庫），結合數據定義配置，使用本方法能夠獲取到查詢需要的額外列是否真實有效，結合數據散列方法優化本方法的使用。
Original query：原始查詢，一般是用戶發給資料庫的查詢語句；Sytax tree：語法樹，用戶發送給資料庫的查詢語句，通過解析器生成的一個可供代碼處理的邏輯結構；Fetch select list:這個動作是獲取SELECT查詢語句中的查詢列。
Have group:這個動作是檢查SELECT查詢語句中是否存在GROUP關鍵字。Have order:這個動作是檢查SELECT查詢語句中是否存在ORDER關鍵字。Select list:一個存儲SELECT語句中查詢列的數據結構。
Select list, [group list, order list]：修改後的查詢語句格式，括弧裡面的新增列，是附加到原始列後面的。
原始SQL解析成語法樹結構，該語法樹能夠提供一個代碼結構，後續處理流程會使用到這個代碼結構。首先掃描SELECT查詢的列，將SELECT的列存儲到SELECT LIST結構中。
掃描語法樹查看是否有GROUP（分組）關鍵字存在，如果存在，需要判斷GROUP分組的列在SELECT LIST中是否已經存在，如果不存在，則將GROUP分組列增加到SELECT LIST中，並將GROUP分組列附加到原查詢語句的查詢列尾部，並且記錄下分組列在查詢列中的位置。
掃描語法樹查看是否有ORDER（排序）關鍵字存在，如果存在，需要判斷SELECT LIST是否已經存在ORDER排序列，如果ORDER排序列沒有包含在SELECT LIST中，則將ORDER排序列放入SELECT LIST中，並且將ORDER排序列附加到查詢語句尾部，標記ORDER排序列在查詢語句中的位置。
經過處理流程1，2，3，4就將客戶端發送給資料庫的原始查詢語句改寫為新的查詢語句，下面使用一個具體例子來說明實際處理過程。
例：Original query（原始查詢語句，客戶端發送給資料庫的查詢語句）：SELECT email FROM userInfo WHERE create_time > 『2011-11-11』 GROUP BY name order by id desc。
syntax tree：SQL解析後的語法樹（略，這是其他獨立模塊提供的），Fetch select list：掃描語法樹，可以發現SELECT查詢的列有email，因此，將email存放到SELECT LIST。
Have group:掃描語法樹，發現有GROUP關鍵字，分組列name不存在與SELECT LIST中，因將name放入SELECT LIST中，並且將name附加到查詢列後面。
這時候SQL語句為SELECT email, name FROM…，標記分組列name在查詢中的位置為1（從左到右，從0開始，email位置為0，name為1）。
Have order掃描語法樹，發現有ORDER關鍵字，排序列為id，該列不在SELECT LIST中，因此將排序列ID附加到查詢語句中，查詢語句變為SELECT email, name, id FROM … ，標記排序列在查詢中的位置為2。
經過一系列處理流程，那麼為了實現這次查詢，已經將查詢重寫改寫為形成一個新的查詢：SELECT email,name, id FROM userInfo WHERE create_time > 『2011-11-11』 GROUP BY name ORDER BY id DESC。
所得到的信息有：原始查詢的列數，改寫後的列數，分組列位置，排序列的位置。使用處理後的SQL語句從數據存放點取回數據，根據所得到的信息，依次執行分組，排序，然後再發送的時候，按照原始查詢的列數發送數據到客戶端。
分庫分表後能夠支持復雜查詢，如GROUP、ORDER等等；數據存儲節點參與計算，相比直接把數據全部查詢到應用程序中進行計算，具有更小的網路開銷，更快的計算速度。
在多機查詢中，不需要應用程序參與查詢計算；通過關系代數等價變化的方式，重寫查詢語句，讓數據節點參與查詢計算的方式，相比常規方案性價比要高。
㈥ 資料庫分庫分表（二）Twitter-Snowflake（64位分布式ID演算法）分析與JAVA實現
Twitter-Snowflake演算法產生的背景相當簡單，為了滿足Twitter每秒上萬條消息的請求，每條消息都必須分配一條唯一的id，這些id還需要一些大致的順序（方便客戶端排序），並灶核且在掘頃分布式系統中不同機器產生的id必須不同。各種主鍵ID生成策略對比，見 常見分布式主鍵ID生成策略
把 41位的時間前綴 ， 10位的節點標識 ， 12位的sequence 組合在一起。
除了最高位bit標記為不可用以外，其餘三組bit佔位均可浮動，看具體的業務需求而定。 默認情況下41bit的時間戳，1970年算起可以支持該演算法使用到2038年，10bit的工作機器id可以支持1024台機器，序列號支持1毫秒產生4096個自增序列id 。
Snowflake是Twitter在2010年用Scala語言寫的一套主鍵生成策略，用Thrift對外發布主鍵生成服務，其中依賴了Twitter內部的Infrastructure，後來Twitter用 Twitter-server 代替了Snowflake，自2012年起就未更新。見 Twitter-Snowflake項目地址（Tags:snowflake-2010）
之前寫了一個Java的實現，改自網上一個版本: Twitter的分布式自增ID演算法Snowflake實現分析及其Java、Php和Python版 。後來看到當當網的 Sharding-JDBC 分庫分表中間件已實現了此演算法。就直接在其中添隱散掘加了一些新特性，已merge。( 具體實現 , 說明文檔 )
添加3種IdGenerator實現。
用筆記本（i7-3632QM 2.2GHz 四核八線程）測試了下，每秒生成409萬（理論上的峰值），CPU佔用率18.5%。
㈦ 資料庫架構選型與落地，看這篇就夠了
隨著時間和業務的發展，資料庫中的數據量增長是不可控的，庫和表中的數據會越來越大，隨之帶來的是更高的 磁碟 、 IO 、 系統開銷 ，甚至 性能 上的瓶頸，而單台伺服器的 資源終究是有限 的。
因此在面對業務擴張過程中，應用程序對資料庫系統的 健壯性 ， 安全性 ， 擴展性 提出了更高的要求。
以下，我從資料庫架構、選型與落地來讓大家入門。
資料庫會面臨什麼樣的挑戰呢？
業務剛開始我們只用單機資料庫就夠了，但隨著業務增長，數據規模和用戶規模上升，這個時候資料庫會面臨IO瓶頸、存儲瓶頸、可用性、安全性問題。
為了解決上述的各種問題，資料庫衍生了出不同的架構來解決不同的場景需求。
將資料庫的寫操作和讀操作分離，主庫接收寫請求，使用多個從庫副本負責讀請求，從庫和主庫同步更新數據保持數據一致性，從庫可以水平擴展，用於面對讀請求的增加。
這個模式也就是常說的讀寫分離，針對的是小規模數據，而且存在大量讀操作的場景。
因為主從的數據是相同的，一旦主庫宕機的時候，從庫可以 切換為主庫提供寫入 ，所以這個架構也可以提高資料庫系統的 安全性 和 可用性 ；
優點：
缺點：
在資料庫遇到 IO瓶頸 過程中，如果IO集中在某一塊的業務中，這個時候可以考慮的就是垂直分庫，將熱點業務拆分出去，避免由 熱點業務 的 密集IO請求 影響了其他正常業務，所以垂直分庫也叫 業務分庫 。
優點：
缺點：
在資料庫遇到存儲瓶頸的時候，由於數據量過大造成索引性能下降。
這個時候可以考慮將數據做水平拆分，針對數據量巨大的單張表，按照某種規則，切分到多張表裡面去。
但是這些表還是在同一個庫中，所以庫級別的資料庫操作還是有IO瓶頸（單個伺服器的IO有上限）。
所以水平分表主要還是針對 數據量較大 ，整體業務 請求量較低 的場景。
優點：
缺點：
四、分庫分表
在資料庫遇到存儲瓶頸和IO瓶頸的時候，數據量過大造成索引性能下降，加上同一時間需要處理大規模的業務請求，這個時候單庫的IO上限會限制處理效率。
所以需要將單張表的數據切分到多個伺服器上去，每個伺服器具有相應的庫與表，只是表中數據集合不同。
分庫分表能夠有效地緩解單機和單庫的 性能瓶頸和壓力 ，突破IO、連接數、硬體資源等的瓶頸。
優點：
缺點：
註：分庫還是分表核心關鍵是有沒有IO瓶頸 。
分片方式都有什麼呢？
RANGE（范圍分片）
將業務表中的某個 關鍵欄位排序 後，按照順序從0到10000一個表，10001到20000一個表。最常見的就是 按照時間切分 （月表、年表）。
比如將6個月前，甚至一年前的數據切出去放到另外的一張表，因為隨著時間流逝，這些表的數據被查詢的概率變小，銀行的交易記錄多數是採用這種方式。
優點：
缺點：
HASH（哈希分片）
將訂單作為主表，然後將其相關的業務表作為附表，取用戶id然後 hash取模 ，分配到不同的數據表或者資料庫上。
優點：
缺點：
講到這里，我們已經知道資料庫有哪些架構，解決的是哪些問題，因此， 我們在日常設計中需要根據數據的特點，數據的傾向性，數據的安全性等來選擇不同的架構 。
那麼，我們應該如何選擇資料庫架構呢？
雖然把上面的架構全部組合在一起可以形成一個強大的高可用，高負載的資料庫系統，但是架構選擇合適才是最重要的。
混合架構雖然能夠解決所有的場景的問題，但是也會面臨更多的挑戰，你以為的完美架構，背後其實有著更多的坑。
1、對事務支持
分庫分表後（無論是垂直還是水平拆分），就成了分布式事務了，如果依賴資料庫本身的分布式事務管理功能去執行事務，將付出高昂的性能代價（XA事務）；如果由應用程序去協助控制，形成程序邏輯上的事務，又會造成編程方面的負擔（TCC、SAGA）。
2、多庫結果集合並 （group by，order by）
由於數據分布於不同的資料庫中，無法直接對其做分頁、分組、排序等操作，一般應對這種多庫結果集合並的查詢業務都需要採用數據清洗、同步等其他手段處理（TIDB、KUDU等）。
3、數據延遲
主從架構下的多副本機制和水平分庫後的聚合庫都會存在主數據和副本數據之間的延遲問題。
4、跨庫join
分庫分表後表之間的關聯操作將受到限制，我們無法join位於不同分庫的表（垂直），也無法join分表粒度不同的表（水平）， 結果原本一次查詢就能夠完成的業務，可能需要多次查詢才能完成。
5、分片擴容
水平分片之後，一旦需要做擴容時。需要將對應的數據做一次遷移，成本代價都極高的。
6、ID生成
分庫分表後由於資料庫獨立，原有的基於資料庫自增ID將無法再使用，這個時候需要採用其他外部的ID生成方案。
一、應用層依賴類（JDBC）
這類分庫分表中間件的特點就是和應用強耦合，需要應用顯示依賴相應的jar包（以Java為例），比如知名的TDDL、當當開源的 sharding-jdbc 、蘑菇街的TSharding等。
此類中間件的基本思路就是重新實現JDBC的API，通過重新實現 DataSource 、 PrepareStatement 等操作資料庫的介面，讓應用層在 基本 不改變業務代碼的情況下透明地實現分庫分表的能力。
中間件給上層應用提供熟悉的JDBC API，內部通過 sql解析 、 sql重寫 、 sql路由 等一系列的准備工作獲取真正可執行的sql，然後底層再按照傳統的方法（比如資料庫連接池）獲取物理連接來執行sql，最後把數據 結果合並 處理成ResultSet返回給應用層。
優點
缺點
二、中間層代理類（Proxy）
這類分庫分表中間件的核心原理是在應用和資料庫的連接之間搭起一個 代理層 ，上層應用以 標準的MySQL協議 來連接代理層，然後代理層負責 轉發請求 到底層的MySQL物理實例，這種方式對應用只有一個要求，就是只要用MySQL協議來通信即可。
所以用MySQL Navicat這種純的客戶端都可以直接連接你的分布式資料庫，自然也天然 支持所有的編程語言 。
在技術實現上除了和應用層依賴類中間件基本相似外，代理類的分庫分表產品必須實現標準的MySQL協議，某種意義上講資料庫代理層轉發的就是MySQL協議請求，就像Nginx轉發的是Http協議請求。
比較有代表性的產品有開創性質的Amoeba、阿里開源的Cobar、社區發展比較好的 Mycat （基於Cobar開發）等。
優點
缺點
JDBC方案 ：無中心化架構，兼容市面上大多數關系型資料庫，適用於開發高性能的輕量級 OLTP 應用（面向前台）。
Proxy方案 ：提供靜態入口以及異構語言的支持，適用於 OLAP 應用（面向後台）以及對分片資料庫進行管理和運維的場景。
混合方案 ：在大型復雜系統中存在面向C端用戶的前台應用，也有面向企業分析的後台應用，這個時候就可以採用混合模式。
JDBC 採用無中心化架構，適用於 Java 開發的高性能的輕量級 OLTP 應用；Proxy 提供靜態入口以及異構語言的支持，適用於 OLAP 應用以及對分片資料庫進行管理和運維的場景。
ShardingSphere是一套開源的分布式資料庫中間件解決方案組成的生態圈，它由 Sharding-JDBC 、 Sharding-Proxy 和 Sharding-Sidecar （計劃中）這3款相互獨立的產品組成，他們均提供標准化的數據分片、分布式事務和資料庫治理功能，可適用於如Java同構、異構語言、容器、雲原生等各種多樣化的應用場景。
ShardingSphere提供的核心功能：
Sharding-Proxy
定位為透明化的 資料庫代理端 ，提供封裝了 資料庫二進制協議的服務端版本 ，用於完成對 異構語言的支持 。
目前已提供MySQL版本，它可以使用 任何兼容MySQL協議的訪問客戶端 (如：MySQL Command Client, MySQL Workbench, Navicat等)操作數據，對DBA更加友好。
向 應用程序完全透明 ，可直接當做MySQL使用。
適用於任何兼容MySQL協議的客戶端。
Sharding-JDBC
定位為 輕量級Java框架 ，在Java的JDBC層提供的額外服務。 它使用客戶端直連資料庫，以jar包形式提供服務，無需額外部署和依賴，可理解為 增強版的JDBC驅動，完全兼容JDBC和各種ORM框架 。
以電商SaaS系統為例，前台應用採用Sharding-JDBC，根據業務場景的差異主要分為三種方案。
分庫（用戶）
問題解析：頭部企業日活高並發高，單獨分庫避免干擾其他企業用戶，用戶數據的增長緩慢可以不分表。
拆分維度：企業ID分庫
拆分策略：頭部企業單獨庫、非頭部企業一個庫
分庫分表（訂單）
問題解析：訂單數據增長速度較快，在分庫之餘需要分表。
拆分維度：企業ID分庫、用戶ID分表
拆分策略：頭部企業單獨庫、非頭部企業一個庫，分庫之後用戶ID取模拆分表
單庫分表（附件）
問題解析：附件數據特點是並發量不大，只需要解決數據增長問題，所以單庫IO足以支撐的情況下分表即可。
拆分維度：用戶ID分表
拆分策略：用戶ID取模分表
問題一：分布式事務
分布式事務過於復雜也是分布式系統最難處理的問題，由於篇幅有限，後續會開篇專講這一塊內容。
問題二：分布式ID
問題三：跨片查詢
舉個例子，以用戶id分片之後，需要根據企業id查詢企業所有用戶信息。
sharding針對跨片查詢也是能夠支持的，本質上sharding的跨片查詢是採用同時查詢多個分片的數據，然後聚合結果返回，這個方式對資源耗費比較大，特別是對資料庫連接資源的消耗。
假設分4個資料庫，8個表，則sharding會同時發出32個SQL去查詢。一下子消耗掉了32個連接；
特別是針對單庫分表的情況要注意，假設單庫分64個表，則要消耗64個連接。如果我們部署了2個節點，這個時候兩個節點同時查詢的話，就會遇到資料庫連接數上限問題（mysql默認100連接數）
問題四：分片擴容
隨著數據增長，每個片區的數據也會達到瓶頸，這個時候需要將原有的分片數量進行增加。由於增加了片區，原先的hash規則也跟著變化，造成了需要將舊數據做遷移。
假設原先1個億的數據，hash分64個表，現在增長到50億的數據，需要擴容到128個表，一旦擴容就需要將這50億的數據做一次遷移，遷移成本是無法想像的。
問題五：一致性哈希
首先，求出每個 伺服器的hash值 ，將其配置到一個 0~2^n 的圓環上 （n通常取32）
其次，用同樣的方法求出待 存儲對象的主鍵 hash值 ，也將其配置到這個圓環上。
然後，從數據映射到的位置開始順時針查找，將數據分布到找到的第一個伺服器節點上。
一致性hash的優點在於加入和刪除節點時只會影響到在哈希環中相鄰的節點，而對其他節點沒有影響。
所以使用一致性哈希在集群擴容過程中可以減少數據的遷移。
好了，這次分享到這里，我們日常的實踐可能只會用到其中一種方案，但它不是資料庫架構的全貌，打開技術視野，才能更好地把存儲工具利用起來。
老規矩，一鍵三連，日入兩千，點贊在看，年薪百萬！
本文作者：Jensen
7年Java老兵，小米主題設計師，手機輸入法設計師，ProcessOn特邀講師。
曾涉獵航空、電信、IoT、垂直電商產品研發，現就職於某知名電商企業。
技術公眾號 【架構師修行錄】 號主，專注於分享日常架構、技術、職場干貨，Java Goals：架構師。
交個朋友，一起成長！
㈧ 阿里巴巴採用自己研發的分布式資料庫系統叫什麼,它有哪些特點
上層的是分布式資料庫分表分庫中間件，負責和上層應用打交道，對應用可表現為一個獨立的資料庫，而屏蔽底層復雜的系統細節。分布式資料庫中間件除了基本的分表分庫功能，還可以豐富一下，比如講讀寫分離或者水平擴容功能集成在一起，或者比如讀寫分離本身也可以作為一個獨立的中間件。（Cobar, MyCAT, TDDL, DRDS, DDB）
增量數據訂閱和消費，用戶對資料庫操作，比如DML, DCL, DDL等，這些操作會產生增量數據，下層應用可以通過監測這些增量數據進行相應的處理。典型代表Canal，根據MySQL的binlog實現。也有針對Oracle(redolog)的增量數據訂閱與消費的中間件。（Canal, Erosa）
資料庫同步中間件涉及資料庫之間的同步操作，可以實現跨（同）機房同步以及異地容災備份、分流等功能。可以涉及多種資料庫，處理之後的數據也可以以多種形式存儲。（Otter, JingoBus, DRC）
資料庫與資料庫之間會有數據遷移（同步）的動作，同款數據同步原理比較簡單，比如MySQL主備同步，只要在資料庫層進行相應的配置既可，但是跨資料庫同步就比較復雜了，比如Oracle->MySQL. 數據遷移一般包括三個步驟：全量復制，將原資料庫的數據全量遷移到新資料庫，在這遷移的過程中也會有新的數據產生；增量同步，對新產生的數據進行同步，並持續一段時間以保證數據同步；原庫停寫，切換新庫。將「跨資料庫」這個含義擴大一下——「跨數據源」，比如HDFS, HBase, FTP等都可以相互同步。（yugong, DataX）
㈨ 分庫分表 VS newsql資料庫
最近與同行 科技 交流，經常被問到分庫分表與分布式資料庫如何選擇，網上也有很多關於中間件+傳統關系資料庫（分庫分表）與NewSQL分布式資料庫的文章，但有些觀點與判斷是我覺得是偏激的，脫離環境去評價方案好壞其實有失公允。
本文通過對兩種模式關鍵特性實現原理對比，希望可以盡可能客觀、中立的闡明各自真實的優缺點以及適用場景。
首先關於「中間件+關系資料庫分庫分表」算不算NewSQL分布式資料庫問題，國外有篇論文pavlo-newsql-sigmodrec，如果根據該文中的分類，Spanner、TiDB、OB算是第一種新架構型，Sharding-Sphere、Mycat、DRDS等中間件方案算是第二種（文中還有第三種雲資料庫，本文暫不詳細介紹）。
基於中間件（包括SDK和Proxy兩種形式）+傳統關系資料庫（分庫分表）模式是不是分布式架構？我覺得是的，因為存儲確實也分布式了，也能實現橫向擴展。但是不是"偽"分布式資料庫？從架構先進性來看，這么說也有一定道理。"偽"主要體現在中間件層與底層DB重復的SQL解析與執行計劃生成、存儲引擎基於B+Tree等，這在分布式資料庫架構中實際上冗餘低效的。為了避免引起真偽分布式資料庫的口水戰，本文中NewSQL資料庫特指這種新架構NewSQL資料庫。
NewSQL資料庫相比中間件+分庫分表的先進在哪兒？畫一個簡單的架構對比圖：
這些大多也是NewSQL資料庫產品主要宣傳的點，不過這些看起來很美好的功能是否真的如此？接下來針對以上幾點分別闡述下的我的理解。
這是把雙刃劍。
CAP限制
想想更早些出現的NoSQL資料庫為何不支持分布式事務（最新版的mongoDB等也開始支持了），是缺乏理論與實踐支撐嗎？並不是，原因是CAP定理依然是分布式資料庫頭上的頸箍咒，在保證強一致的同時必然會犧牲可用性A或分區容忍性P。為什麼大部分NoSQL不提供分布式事務？
那麼NewSQL資料庫突破CAP定理限制了嗎？並沒有。NewSQL資料庫的鼻主Google Spanner（目前絕大部分分布式資料庫都是按照Spanner架構設計的）提供了一致性和大於5個9的可用性，宣稱是一個「實際上是CA」的，其真正的含義是 系統處於 CA 狀態的概率非常高，由於網路分區導致的服務停用的概率非常小 ，究其真正原因是其打造私有全球網保證了不會出現網路中斷引發的網路分區，另外就是其高效的運維隊伍,這也是cloud spanner的賣點。詳細可見CAP提出者Eric Brewer寫的《Spanner, TrueTime 和CAP理論》。
完備性 ：
兩階段提交協議是否嚴格支持ACID，各種異常場景是不是都可以覆蓋？
2PC在commit階段發送異常，其實跟最大努力一階段提交類似也會有部分可見問題，嚴格講一段時間內並不能保證A原子性和C一致性（待故障恢復後recovery機制可以保證最終的A和C）。完備的分布式事務支持並不是一件簡單的事情，需要可以應對網路以及各種硬體包括網卡、磁碟、CPU、內存、電源等各類異常，通過嚴格的測試。之前跟某友商交流，他們甚至說目前已知的NewSQL在分布式事務支持上都是不完整的，他們都有案例跑不過，圈內人士這么篤定，也說明了 分布式事務的支持完整程度其實是層次不齊的。
但分布式事務又是這些NewSQL資料庫的一個非常重要的底層機制，跨資源的DML、DDL等都依賴其實現，如果這塊的性能、完備性打折扣，上層跨分片SQL執行的正確性會受到很大影響。
性能
傳統關系資料庫也支持分布式事務XA，但為何很少有高並發場景下用呢？ 因為XA的基礎兩階段提交協議存在網路開銷大，阻塞時間長、死鎖等問題，這也導致了其實際上很少大規模用在基於傳統關系資料庫的OLTP系統中。
NewSQL資料庫的分布式事務實現也仍然多基於兩階段提交協議，例如google percolator分布式事務模型，
採用原子鍾+MVCC+ Snapshot Isolation（SI），這種方式通過TSO(Timestamp Oracle)保證了全局一致性，通過MVCC避免了鎖，另外通過primary lock和secondary lock將提交的一部分轉為非同步，相比XA確實提高了分布式事務的性能。
但不管如何優化，相比於1PC，2PC多出來的GID獲取、網路開銷、prepare日誌持久化還是會帶來很大的性能損失，尤其是跨節點的數量比較多時會更加顯著，例如在銀行場景做個批量扣款，一個文件可能上W個賬戶，這樣的場景無論怎麼做還是吞吐都不會很高。
雖然NewSQL分布式資料庫產品都宣傳完備支持分布式事務，但這並不是說應用可以完全不用關心數據拆分，這些資料庫的最佳實踐中仍然會寫到，應用的大部分場景盡可能避免分布式事務。
既然強一致事務付出的性能代價太大，我們可以反思下是否真的需要這種強一致的分布式事務？尤其是在做微服務拆分後，很多系統也不太可能放在一個統一的資料庫中。嘗試將一致性要求弱化，便是柔性事務，放棄ACID(Atomicity,Consistency, Isolation, Durability)，轉投BASE(Basically Available,Soft state,Eventually consistent)，例如Saga、TCC、可靠消息保證最終一致等模型，對於大規模高並發OLTP場景，我個人更建議使用柔性事務而非強一致的分布式事務。關於柔性事務，筆者之前也寫過一個技術組件，最近幾年也涌現出了一些新的模型與框架（例如阿里剛開源的Fescar），限於篇幅不再贅述，有空再單獨寫篇文章。
HA與異地多活
主從模式並不是最優的方式，就算是半同步復制，在極端情況下（半同步轉非同步）也存在丟數問題，目前業界公認更好的方案是基於paxos分布式一致性協議或者其它類paxos如raft方式，Google Spanner、TiDB、cockcoachDB、OB都採用了這種方式，基於Paxos協議的多副本存儲，遵循過半寫原則，支持自動選主，解決了數據的高可靠，縮短了failover時間，提高了可用性，特別是減少了運維的工作量，這種方案技術上已經很成熟，也是NewSQL資料庫底層的標配。
當然這種方式其實也可以用在傳統關系資料庫，阿里、微信團隊等也有將MySQL存儲改造支持paxos多副本的，MySQL也推出了官方版MySQL Group Cluster，預計不遠的未來主從模式可能就成為 歷史 了。
需要注意的是很多NewSQL資料庫廠商宣傳基於paxos或raft協議可以實現【異地多活】，這個實際上是有前提的，那就是異地之間網路延遲不能太高 。以銀行「兩地三中心」為例，異地之間多相隔數千里，延時達到數十毫秒，如果要多活，那便需異地副本也參與資料庫日誌過半確認，這樣高的延時幾乎沒有OLTP系統可以接受的。
資料庫層面做異地多活是個美好的願景，但距離導致的延時目前並沒有好的方案。 之前跟螞蟻團隊交流，螞蟻異地多活的方案是在應用層通過MQ同步雙寫交易信息，異地DC將交易信息保存在分布式緩存中，一旦發生異地切換，資料庫同步中間件會告之數據延遲時間，應用從緩存中讀取交易信息，將這段時間內涉及到的業務對象例如用戶、賬戶進行黑名單管理，等數據同步追上之後再將這些業務對象從黑名單中剔除。由於雙寫的不是所有資料庫操作日誌而只是交易信息，數據延遲隻影響一段時間內數據，這是目前我覺得比較靠譜的異地度多活方案。
另外有些系統進行了單元化改造，這在paxos選主時也要結合考慮進去，這也是目前很多NewSQL資料庫欠缺的功能。
Scale橫向擴展與分片機制
paxos演算法解決了高可用、高可靠問題，並沒有解決Scale橫向擴展的問題，所以分片是必須支持的。NewSQL資料庫都是天生內置分片機制的，而且會根據每個分片的數據負載(磁碟使用率、寫入速度等)自動識別熱點，然後進行分片的分裂、數據遷移、合並，這些過程應用是無感知的，這省去了DBA的很多運維工作量。以TiDB為例，它將數據切成region，如果region到64M時，數據自動進行遷移。
分庫分表模式下需要應用設計之初就要明確各表的拆分鍵、拆分方式（range、取模、一致性哈希或者自定義路由表）、路由規則、拆分庫表數量、擴容方式等。相比NewSQL資料庫，這種模式給應用帶來了很大侵入和復雜度，這對大多數系統來說也是一大挑戰。
這里有個問題是NewSQL資料庫統一的內置分片策略（例如tidb基於range）可能並不是最高效的，因為與領域模型中的劃分要素並不一致，這導致的後果是很多交易會產生分布式事務。 舉個例子，銀行核心業務系統是以客戶為維度，也就是說客戶表、該客戶的賬戶表、流水表在絕大部分場景下是一起寫的，但如果按照各表主鍵range進行分片，這個交易並不能在一個分片上完成，這在高頻OLTP系統中會帶來性能問題。
分布式SQL支持
常見的單分片SQL，這兩者都能很好支持。NewSQL資料庫由於定位與目標是一個通用的資料庫，所以支持的SQL會更完整，包括跨分片的join、聚合等復雜SQL。中間件模式多面向應用需求設計，不過大部分也支持帶拆分鍵SQL、庫表遍歷、單庫join、聚合、排序、分頁等。但對跨庫的join以及聚合支持就不夠了。
NewSQL資料庫一般並不支持存儲過程、視圖、外鍵等功能，而中間件模式底層就是傳統關系資料庫，這些功能如果只是涉及單庫是比較容易支持的。
NewSQL資料庫往往選擇兼容MySQL或者PostgreSQL協議，所以SQL支持僅局限於這兩種，中間件例如驅動模式往往只需做簡單的SQL解析、計算路由、SQL重寫，所以可以支持更多種類的資料庫SQL。
SQL支持的差異主要在於分布式SQL執行計劃生成器，由於NewSQL資料庫具有底層數據的分布、統計信息，因此可以做CBO，生成的執行計劃效率更高，而中間件模式下沒有這些信息，往往只能基於規則RBO（Rule-Based-Opimization），這也是為什麼中間件模式一般並不支持跨庫join，因為實現了效率也往往並不高，還不如交給應用去做。
存儲引擎
傳統關系資料庫的存儲引擎設計都是面向磁碟的，大多都基於B+樹。B+樹通過降低樹的高度減少隨機讀、進而減少磁碟尋道次數，提高讀的性能，但大量的隨機寫會導致樹的分裂，從而帶來隨機寫，導致寫性能下降。NewSQL的底層存儲引擎則多採用LSM，相比B+樹LSM將對磁碟的隨機寫變成順序寫，大大提高了寫的性能。不過LSM的的讀由於需要合並數據性能比B+樹差，一般來說LSM更適合應在寫大於讀的場景。當然這只是單純數據結構角度的對比，在資料庫實際實現時還會通過SSD、緩沖、bloom filter等方式優化讀寫性能，所以讀性能基本不會下降太多。NewSQL數據由於多副本、分布式事務等開銷，相比單機關系資料庫SQL的響應時間並不佔優，但由於集群的彈性擴展，整體QPS提升還是很明顯的，這也是NewSQL資料庫廠商說分布式資料庫更看重的是吞吐，而不是單筆SQL響應時間的原因。
成熟度與生態
分布式資料庫是個新型通用底層軟體，准確的衡量與評價需要一個多維度的測試模型，需包括發展現狀、使用情況、社區生態、監控運維、周邊配套工具、功能滿足度、DBA人才、SQL兼容性、性能測試、高可用測試、在線擴容、分布式事務、隔離級別、在線DDL等等，雖然NewSQL資料庫發展經過了一定時間檢驗，但多集中在互聯網以及傳統企業非核心交易系統中，目前還處於快速迭代、規模使用不斷優化完善的階段。
相比而言，傳統關系資料庫則經過了多年的發展，通過完整的評測，在成熟度、功能、性能、周邊生態、風險把控、相關人才積累等多方面都具有明顯優勢，同時對已建系統的兼容性也更好。
對於互聯網公司，數據量的增長壓力以及追求新技術的基因會更傾向於嘗試NewSQL資料庫，不用再考慮庫表拆分、應用改造、擴容、事務一致性等問題怎麼看都是非常吸引人的方案。
對於傳統企業例如銀行這種風險意識較高的行業來說，NewSQL資料庫則可能在未來一段時間內仍處於 探索 、審慎試點的階段。基於中間件+分庫分表模式架構簡單，技術門檻更低，雖然沒有NewSQL資料庫功能全面，但大部分場景最核心的訴求也就是拆分後SQL的正確路由，而此功能中間件模式應對還是綽綽有餘的，可以說在大多數OLTP場景是夠用的。
限於篇幅，其它特性例如在線DDL、數據遷移、運維工具等特性就不在本文展開對比。
總結
如果看完以上內容，您還不知道選哪種模式，那麼結合以下幾個問題，先思考下NewSQL資料庫解決的點對於自身是不是真正的痛點：
如果以上有2到3個是肯定的，那麼你可以考慮用NewSQL資料庫了，雖然前期可能需要一定的學習成本，但它是資料庫的發展方向，未來收益也會更高，尤其是互聯網行業，隨著數據量的突飛猛進，分庫分表帶來的痛苦會與日俱增。當然選擇NewSQL資料庫你也要做好承擔一定風險的准備。
如果你還未做出抉擇，不妨再想想下面幾個問題：
如果這些問題有多數是肯定的，那還是分庫分表吧。在軟體領域很少有完美的解決方案，NewSQL資料庫也不是數據分布式架構的銀彈。相比而言分庫分表是一個代價更低、風險更小的方案，它最大程度復用傳統關系資料庫生態，通過中間件也可以滿足分庫分表後的絕大多數功能，定製化能力更強。 在當前NewSQL資料庫還未完全成熟的階段，分庫分表可以說是一個上限低但下限高的方案，尤其傳統行業的核心系統，如果你仍然打算把資料庫當做一個黑盒產品來用，踏踏實實用好分庫分表會被認為是個穩妥的選擇。
很多時候軟體選型取決於領域特徵以及架構師風格，限於筆者知識與所屬行業特點所限，以上僅為個人粗淺的一些觀點，歡迎討論。