關係型資料庫服務(Relational Database
Service，簡稱RDS)：是一種即開即用、穩定可靠、可彈性伸縮的線上資料庫服務。具有多重安全防護措施和完善的效能監控體系，並提供專業的資料庫備份、恢復及優化方案，使您能專注於應用開發和業務發展。

阿里DRDS的前世今生：

【淘寶分散式資料庫層】TDDL——->【阿里分散式資料庫服務】DRDS

支撐更大的訪問量和資料量—->分散式—->網路通訊的延遲

針對延遲會導致鎖持有時間變長，使得高衝突條件下分散式事務的效能不升反降

Amdahl定律：不可平行計算的存在是很重要的，因為它將限制並行化的潛在好處。阿姆達爾定律指明如果一個計算的1/S本質上是順序的，那麼最大的效能改進將受限於因數S。其論證如下，一個平行計算的執行時間TP將是順序部分計算時間和可並行化部分計算時間兩者的和。如果該計算順序地執行需要花費的時間是TS，則當有P個處理器時，TP可表示為S=n/[1+(n-1)f]
假想P值非常大，使得可並行化部分的執行時間可以忽略不計，則最大可改進的效能將是因數S。也就是說，順序執行程式碼在計算中所佔的比例決定了使用並行手段所能改進效能的潛力。

傳統的關係資料庫選擇了放棄分散式的方案，因為在上個世紀70~80年代，我們的資料庫主要被用來處理企業內的各類資料，面對的使用者不過幾千人，而資料量最多也就是TB級別。

企業級別的資料庫，面對的人數不會很多，最多也就在千人級別，磁碟儲存不夠的情況下，增加磁碟陣列也就能解決。

資訊化、網際網路的浪潮使得資料量大增，從TB到PB，因此對資料庫系統的要求也越來越高。

去掉事務和SQL—-> NoSql—->自身的詬病使得在能夠保留效能和擴充套件性的條件下演化出NewSql

TDDL的演化過程：
TDDL的主要功能就是做資料庫切分的，一個或一組SQL請求提交到TDDL，TDDL進行規則運算後得知SQL應該被分發到哪個機器，直接將SQL轉發到對應機器即可(如下圖)。

升級，三層架構：
Matrix對應資料庫切分場景，對SQL有一定限制，Group對應讀寫分離和高可用場景，對SQL幾乎沒有限制。

AngularJS編寫使用者UI

DRDS的主要功能介紹：
分散式SQL執行引擎
分散式SQL引擎主要的目的就是實現與單機資料庫SQL引擎的完全相容。目前我們的SQL引擎能夠做到與MySQL的SQL引擎全相容，包括各類join和各類複雜函式等。他主要包含SQL解析、優化、執行和合並四個流程，如下圖綠色部分

分散式資料庫系統的吞吐調優。

按需資料庫叢集平滑擴縮

DRDS允許應用按需將新的單機儲存加入或移出叢集，DRDS則能夠保證應用在遷移流程中實現不停機擴容縮容。

小表廣播也是我們在分散式資料庫領域內最常用的工具之一，他的核心目的其實都是一個 – 儘可能讓查詢只發生在單機

上面這是兩張表，如果我想知道買家id等於0的使用者在商城裡面買了哪些商品的話，我們一般會先將這兩個表join起來，然後再用 where 平臺名=”商城” and buyerID = 0 找到符合要求的資料。然而這種join的方式，會導致大量的針對左表的網路IO。如果要取出的資料量比較大，系統的延遲會有明顯的上升。

這時候，為了提升效能，我們就必須要減少跨機join的網路代價。我們比較推薦應用做如下處理，將左表複製到右表的每一個庫上。這樣，join操作就由分散式join一下變回到本地join，系統的效能就有很大的提升了。

強調事務的最終一致性和非同步化。利用這種方式，能夠極大的降低分散式系統中鎖持有的時間，從而極大地提升系統的效能。

這種處理機制是我們分散式事務能夠以極低成本大量執行的最核心法門。在DRDS平臺內，我們將這些方案產品化為了DRDS的分散式事務解決套件。
利用他們，能夠讓你以比較低的成本，實現低延遲，高吞吐的分散式事務場景

阿里分散式中介軟體Cobar：

首先，使用Cobar的核心功能如下：

分散式：
Cobar的分散式主要是通過將表放入不同的庫來實現：
1. Cobar支援將一張表水平拆分成多份分別放入不同的庫來實現表的水平拆分
2. Cobar也支援將不同的表放入不同的庫
3. 多數情況下，使用者會將以上兩種方式混合使用
這裡需要強調的是，Cobar不支援將一張表，例如test表拆分成test_1, test_2, test_3…..放在同一個庫中，必須將拆分後的表分別放入不同的庫來實現分散式。

其次、我們也需要注意Cobar的功能約束：

1) 不支援跨庫情況下的join、分頁、排序、子查詢操作。
2) SET語句執行會被忽略，事務和字符集設定除外。
3) 分庫情況下，insert語句必須包含拆分欄位列名。
4) 分庫情況下，update語句不能更新拆分欄位的值。
5) 不支援SAVEPOINT操作。
6) 暫時只支援MySQL資料節點。
7) 使用JDBC時，不支援rewriteBatchedStatements=true引數設定(預設為false)。
8) 使用JDBC時，不支援useServerPrepStmts=true引數設定(預設為false)。
9) 使用JDBC時，BLOB, BINARY, VARBINARY欄位不能使用setBlob()或setBinaryStream()方法設定引數。

然後，我們來分析一下Cobar邏輯層次圖：

• dataSource：資料來源，表示一個具體的資料庫連線，與物理存在的資料庫schema一一對應。
• dataNode：資料節點，由主、備資料來源，資料來源的HA以及連線池共同組成，可以將一個dataNode理解為一個分庫。
• table：表，包括拆分表（如tb1，tb2）和非拆分表。
• tableRule：路由規則，用於判斷SQL語句被路由到具體哪些datanode執行。
• schema：cobar可以定義包含拆分表的schema（如schema1），也可以定義無拆分表的schema（如schema2）。

Cobar支援的資料庫結構（schema）的層次關係具有較強的靈活性，使用者可以將表自由放置不同的datanode，也可將不同的datasource放置在同一MySQL例項上。在實際應用中，我們需要通過配置檔案（schema.xml）來定義我們需要的資料庫伺服器和表的分佈策略，這點我們將在後面的安裝和配置部分中介紹到。

接著，我們來介紹Cobar的安裝和配置步驟：

下面我們將使用一個最簡單的分庫分表的例子來說明Cobar的基本用法，資料庫schema如下圖（該例項也可參考：Cobar產品首頁）。

1) 系統對外提供的資料庫名是dbtest,並且其中有兩張表tb1和tb2。
2) tb1表的資料被對映到物理資料庫dbtest1的tb1上。
3) tb2表的一部分資料被對映到物理資料庫dbtest2的tb2上，另外一部分資料被對映到物理資料庫dbtest3的tb2上。