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执行在单库上完成，实际采用的方式就是用“空间换效率”的方案，也就是将同一份数据表，冗余存储多份，按照不同的业务使用场景进行拆分，保持拆分维度和使用维度统一，而多份数据之间会实时数据复制以解决数据一致性问题，这就是“异构索引”方案。当然异构索引表不能无限制滥用，过多的异构索引表会影响同步效率，对源数据表造成同步压力。