实际上通过三道隔离层来实现，通过MySQL，一个用户无论是Java开发者，PHP开发者，他在使用的时候RDC的时候没有任何障碍，他原来代码访问的时候，要填自己的IP端口，现在所有人填的IP端口是3307，IP，或者地址是W.RDC。新浪.COM.CN，所有人填的都是这个。当然用户密码是分配的，这个根本每个人都不一样。所有人面向都是同一个中间层，而这个中间层又因为支持SQL协议，导致用户使用起来没有任何障碍，他不知道自己使用的是RDC，以为自己使用的是MySQL，整个语法完全跟MySQL一样进行调用，用户使用起来完全没有障碍，不需要改一行代码。
在这种情况下RDC如何实现隔离性呢？有三个步骤，第一个步骤叫做SQL预判，如果他认为你的SQL执行成本有害于系统的话，他在RDC就屏蔽掉，拦截掉。我们都知道标准MySQL是从1千，标准就是从1万，你会得到1万零5，你在一个过大的表上，而且没有索引的字段上做查询，你这条搜索被拦截了，这种语句在的RDC上肯定过不去。
也就是说SQL预判可以把我们认为不健康的SQL拦在外面，我们拦的标准是什么？拦哪些SQL语句，比如常见的都拦，拦截的标准是什么？我们会看你带不带这样的语句，语句里面索引是不是加的合适等等，这些选项都会作为我们打分机制，白就通过，黑就拦截，这是第一步。第二步我们都知道黑白这个东西还是过于简单了，假如说，比如说我现在60分及格，但现在用户SQL语句都是61分，62分，虽然都及格了，这样的SQL语句到后端仍然给SAE数据库进行造成伤害，不光对单独SQL数据有一个黑和白，还需要对一个时间趋势判断。
实际上SQL在这行也传播性发明一个单词叫“并发式执行时间和来做这个事情”。我们都知道买SQL自身是支持并发控制，对于一个用户，我可以限制这个用户最高并发是多少，这个SQL自己就支持，但这里面有一个问题。SAE想达到一个什么效果呢？对于好的用户给最大的并发，对于不好的用户给不好，惩罚性的并发。什么叫好的用户，你表结果非常合理，思路也非常健康，这种用户对于SAE来说是好用户，我们赞赏你，希望你在SQL上运行。哪些不好像刚才那种语句，不好的用户，不好的语句，我们希望给这种用户少的并发。我们怎么来天然区分这件事？
因为每个用汇在SQL，我们并不事先知道是好是坏，我们提出并发执行时间和，当前并发SQL语句执行时间的和。我在这块举个例子，比如说我现在设定当前并发执行时间1万秒用户A每条执行时间是100秒，用户A获得并是100，100×100就是10000，用户B如果执行时间是1万秒，正好进入SAE之后就绕过去了，第二进都进不来，因为并发时间和已经被消耗光了，1万×1等于1万，换成A获得并发就是100，用户B获得的就是并发就是1，从技术层面天然驱动用户，你要更改自己的表结构，你要优化自己的数据库，你要写好的SQL减少对SAE伤害，这就是并发执行时间和的作用。
还有最后防护线就是慢查询的时间配额，我们规定你的数据库不能在一定时间之内慢查询超过多少情况，一旦超过会给你短暂禁用。实际上通过这些措施来综合的保障了，当我很多很多用户同时跑在MySQL里面，能够保证绝大部分用户健康稳定的运行。我们都说RDC很美好，确实RDC，我们所有开发者数据库都是有RDC来提供的，但是RDC是不是能解决一切？并不是，RDC不能解决的一个很重要的问题就我们的扩展性问题。扩展性，实际上分成两种，一种水平扩展，一种垂直扩展，垂直扩展不多说，因为一般都跟业务相关的。
那么水平扩展RDC目前不支持，我们希望用户分库分表有自己管，但是RDC天然不做分库分表。目前有的数据库是支持水平扩展的，比如我听过百度介绍他们数据库系统，可以指定一个，包括微软(微博)云计算分布式数据库系统可以指定做分库分表，但是这里面有一个问题，这个Scalability不叫动态扩展性，是静态扩展性，用户不知道分库分表概念，他只需要往里面写就行了。静态就像亚马逊，我事先数据量有多大，有几个亿，事先分成16个库，每个库里面512个表，事先有一个预估，这就是静态的扩展性。一旦我超过这个预估怎么办？这时候就需要去迁，拆表，工作量也非常大。
所以，从动态扩展性来讲，用户毫不知情来讲还没有达到这种程度。实际上除了RDC之外，除了那些静态扩展性关系型数据库之外，用户更需要动态扩性，根本不需要分什么库，分什么表，分什么节点，他需要你往里面执行。实际上RDC在这块目标，为什么要做NoSQL服务，也是希望能够给用户提供完全动态的NoSQL服务。
我们都说关系型数据库的缺点主要在于扩展性，为了弥补这些扩展性，所以SAE开发一系列NoSQL服务，来弥补和引导用户，你可以把一些适当不那么可靠性要求不那么高的数据，迁到我们NoSQL里面去。SAE里面NoSQL包含什么东西，有RDC，Storage等。SAE一开始Memcache非常简单，但是有一个问题在什么地方？第一不能扩展，用户原来说我起一个512的Memcache后来觉得不够，需要扩充1个亿，就需要重启，后来重启不够。另外一个可靠性非常低，如果这台机器宕了，所有数据就穿透了。针对这个缺点就开发了MemcacheX，即使当中有一台机器宕机只应该到用户N分之一T，里面有独立的统计信息，独立LRU量，又构建在一个共享的存储上面去。
同时，MemcacheX还有一个很重要的特性就是connection LRU，MemcacheX在访问量特别大的时候容易造成connection堵塞，容易造成新的connection进不来，这是在极大访问量情况下才出现，我们设置了connection LRU，新的替代掉老的，不会造成访问量的堵塞。这是MemcacheX架构图，底层是集群，客户端进行访问。我们来看KVDB，实际上是一个非可持久化存储。KVDB就是在SAE上可持续化的存储，第一个就是为什么说又一个NoSQL DB，我个人觉得NoSQL DB有点太多了，各个公司都在搞，乱七八糟的东西太多了，我们一开始做之前，SAE有必要参与这个，有必要也搅这个局吗，后来发现现有东西满足不了我们这个要求。
我们KVDB都有什么要求？第一存储引擎是可换的，因为存储引擎很依赖于，因为数据库原理是苦定的，几十年前都已经稳定好了，这是大部分。变化就是硬件，原来是什么什么传统硬盘，现在变成什么Flash，过去存储引擎工作比较好，没准就变成利用FDD引擎工作比较好。所以，我们要求KVDB存储引擎可以变，我并不依赖某一个特定存储引擎。另外任意模块水平扩展，大多数人都支持读写分离，第四要支持前缀查找，很多开发者在SAE都需要功能，虽然看似简单，一个需求就把很多存储给Pass掉了。
推荐阅读
时至今日，“Big data”(大数据)时代的来临已经毋庸置疑，尤其是在电信、金融等行业，几乎已经到了“数据就是业务本身”的地步。这种趋势已经让很多相信数据之力量的企业做出改变。恰逢此时，为了让更多的人了解和使>>>详细阅读
地址：http://www.lgo100.com/a/kandian/20120305/36930.html
网友点评
精彩导读
科技快报
品牌展示