阿里分布式数据库服务(DRDS)【学习笔记】

关系型数据库服务(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上。

参考文档：
http://hualong.iteye.com/blog/2102798

国内关于mysql分布式中间有
360公司的Atlas：http://www.guokr.com/blog/475765/
淘宝的tddl：http://www.guokr.com/blog/475765/
京东的蓝海豚：http://cio.zdnet.com.cn/cio/2014/0731/3028990.shtml?fromrss=rss
网易的DDB：-RUESzjI7ALpo-mDWXW9uQv-0PCjmJrl9QH6ijP1ycFTXyz3plcrWgXOV80snuIVcMkLYNNKJA3EujCPTG”>http://wenku.baidu.com/link?url=TiILF6KxWQBUu1bj2n8mA1E--RUESzjI7ALpo-mDWXW9uQv-0PCjmJrl9QH6ijP1ycFTXyz3plcrWgXOV80snuIVcMkLYNNKJA3EujCPTG