DRDS/TDDL
alibaba. Distributed Relational Database Service.
阿里分布式數據庫DRDS的前身是淘寶分布式數據庫層TDDL，大概在2012年的時候，阿里開始嘗試將TDDL這套體系輸出到阿里雲上，也有了一個新的名字：DRDS.
TDDL
Tabao根據自己的業務特點開發了TDDL(Tabao Distributed Data Layer, 外號：頭都大了)。主要解決了分庫分表對應用的透明化以及異構數據庫之間的數據復制，它是一個基於集中式配置的jdbc datasourcce實現，具有主備，讀寫分離，動態數據庫配置等功能。
TDDL並非獨立的中間件，只能算作中間層，是以Jar包方式提供給應用調用。屬於JDBC Shard的思想。
TDDL處於業務層和JDBC層中間。
TDDL其實主要可以划分為3層架構，分別是Matrix層，Group層和Atom層。Matrix層用於實現分庫分表邏輯，底層多個Group實例。而Group和Atom共同組成了動態數據源，Group層實現了數據庫的Master/Slave模式的寫分離邏輯，底層持有多個Atom實例。最后Atom層（持有數據源）實現數據庫ip, port, password, connectionProperties等信息的動態推送，以及持有院子的數據源分離的JBoss數據源。
TDDL社區處於停滯狀態，網上可查資源也較少。
DRDS
DRDS/TDDL是阿里巴巴自主研發的分布式數據庫服務。DRDS脫胎於阿里巴巴開源的Cobar分布式數據庫引擎，吸收了Cobar核心的Cobar-Proxy源碼，實現了一套獨立的類似MySQL-Proxy協議的解析端，能夠對傳入的SQL進行解析和處理，對應用程序屏蔽各種復雜的底層DB拓撲結構，獲得單機數據庫一樣的使用體驗，同時借鑒了淘寶TDDL豐富的分布式數據庫實踐經驗，實現了對分布式Join支持，SUM/MAX/COUNT/AVG等聚合函數支持以及排序等函數支持，通過異構索引、小表廣播等解決分布式數據庫使用場景下衍生出的一系列問題，最終形成了完整的分布式數據庫方案。
DRDS在整個阿里系統中所處的位置：
技術分享：
對於很多應用而言，單機數據庫最終都會碰到單機性能上的天花板，在TPS/QPS/內存容量/磁盤容量等等一系列系統資源上會碰到各類限制。DRDS的主要目標就是幫您解決這方面的各類問題，他主要提供了兩個功能，讀寫分離和數據庫切分:
-
讀寫分離，能夠運行實現一台機器寫入，多台機器讀取，這對於讀多寫少的應用，能夠以極低的成本解決系統的瓶頸。
-
數據庫切分是一個解決系統存儲瓶頸的最終極解決方案，數據庫切分的核心思想其實很簡單，就是分而治之。將數據分散到多台機器，並保證請求能夠平均的分發到這些機器上，就可以以極低的成本來解決業務的各類性能瓶頸。當然切分也是有代價的，最明顯的代價就是，分布式數據庫會對一些原有單機數據的場景進行限制，因為這些操作，在分布式環境下的延遲或效率非常低效，就算是能夠實現出來，也會因為性能問題而無法使用。
其他功能特性
1.分布式MySQL執行引擎
主要目標是實現與單機數據庫SQL引擎的完全兼容，實現SQL的智能下推，能夠智能分析SQL，解析出那些SQL可以直接下發，那些SQL需要進行優化改造，優化成什么樣，以及路由到哪些實例節點上執行，充分發揮數據庫實例的全部能力，減少網絡之間的數據傳輸量，最終對不同實例處理后的少量結果進行聚合計算返回給應用調用方。這就是分布式SQL引擎的智能下推功能。分布式引擎的職責包含SQL解析，優化，執行和合並四個流程。
支持市面上幾乎所有的語言（具有MySQL訪問能力的），兼容90%以上MySQL語法。
案例分析：比如一個簡單的AVG操作，對於一些比較初級的分布式數據庫模型而言，常見做法是把AVG直接下發到所有存儲節點，這樣造成的結果就是語法兼容，語義不兼容，最終拿到的是錯誤結果。而DRDS的智能下推引擎，對SQL的語法做充分的語義兼容性適配，針對AVG操作，只能由引擎將邏輯AVG SQL解析優化為SUM和COUNT的SQL然后進行下推，由底層的數據庫實例節點完成SUM和COUNT計算，充分利用底層節點的計算能力，在引擎層將各個存儲節點的SUM和COUNT結果聚合計算，最終計算出AVG。
2.在線平滑擴容
在線數據擴容的重點在於“在線”兩字，也就是用戶不需要停止業務進行割接操作，直接就可以添加新的RDS節點到集群中，實現無縫的自由擴展。RDRS則將整個擴容過程分為幾個階段，包括全量遷移，增量同步，切換數據庫等幾個步驟。數據會提前進行搬遷，並進行增量並行同步一段時間，因此，我們可以在非常短的時間內（秒級別）完成數據庫的最終擴容切換工作，對業務沒有影響。
3.小表廣播
在一些大的業務表進行了切分后，總會存在一些表的數據量不大，更新量也不大的原始信息表。這些表往往會與我們的切分后大表進行join操作，這種操作物理上就會造成分布式join查詢，效率從整體上會比較地下。針對這種分布式join的場景，開發了OETL專用工具來進行小表廣播，將原信息表的所有數據（包括增量更新）全部自動的廣播到大表的機器上，這樣，就可以讓原來的分布式查詢變成單機本地查詢了。
4.全局唯一ID
DRDS sequence功能的目標只是為了保證數據的全局唯一，雖然基本上是按時間序列獲取的，但並不全局有序。
5.異構索引
解決分布式場景下數據拆分維度和數據查詢使用維度不一致導致的低效問題。
當數據表被拆分為多個分庫分表時，數據在分庫分表的分布規則就固定了。但是通常數據的業務使用場景非常復雜，如果數據的查詢維度和數據拆分分布的規則一直，單條SQL會在一個分庫分表上執行；如果數據的查詢使用維度和數據拆分分布的規格不一致，單條SQL可能在多個分庫分表上執行，出現跨庫查詢，跨庫查詢會增加IO成本，查詢效率必然下降。
解決這個問題的思路還是分布式數據庫的一貫原則，讓SQL執行在單庫上完成，實際采用的方式就是用“空間換效率”的方案，也就是將同一份數據表，冗余存儲多份，按照不同的業務使用場景進行拆分，保持拆分維度和使用維度統一，而多份數據之間會實時數據復制以解決數據一致性問題，這就是“異構索引”方案。當然異構索引表不能無限制濫用，過多的異構索引表會影響同步效率，對源數據表造成同步壓力。