时至今日，“Big data”(大数据)时代的来临已经毋庸置疑，尤其是在电信、金融等行业，几乎已经到了“数据就是业务本身”的地步。这种趋势已经让很多相信数据之力量的企业做出改变。恰逢此时，为了让更多的人了解和使用分析大数据，CSDN(微博)独家承办的大数据技术大会于今日在北京中旅大厦召开。本次大会汇集Hadoop、NoSQL、数据分析与挖掘、数据仓库、商业智能以及开源云计算架构等诸多热点话题。包括百度、淘宝、新浪等业界知名专家与参会者齐聚一堂，共同探讨大数据浪潮下的行业应对法则以及大数据时代的抉择。
时至今日，“Big data”(大数据)时代的来临已经毋庸置疑，尤其是在电信、金融等行业，几乎已经到了“数据就是业务本身”的地步。这种趋势已经让很多相信数据之力量的企业做出改变。恰逢此时，为了让更多的人了解和使用分析大数据，CSDN(微博)独家承办的大数据技术大会于今日在北京中旅大厦召开。本次大会汇集Hadoop、NoSQL、数据分析与挖掘、数据仓库、商业智能以及开源云计算架构等诸多热点话题。包括百度、淘宝、新浪等业界知名专家与参会者齐聚一堂，共同探讨大数据浪潮下的行业应对法则以及大数据时代的抉择。
新浪云计算高级技术经理丛磊
新浪云计算高级技术经理丛磊表示2011年新浪SAE平台注册用户已达50000，应用超过100000，日均PV达到1亿，活跃开发者达到10000名。
丛磊还介绍了新浪自己开发的的KVDB，KVDB用来支持公有云计算平台上的海量key-value存储。KV DB支持的存储容量很大，对每个用户支持100G的存储空间，可支持1000000000条记录，用户可以用KV DB存放简单数据，如好友关系等。KVDB具备存储引擎可替换、任意模块水平扩展、支持读写分离、支持前缀查找、支持secondary index、支持认证、支持重平衡和无缝迁移等优势。
以下为文字实录
大家好，很高兴在这里跟大家分享关于SAE在NoSQL上一个话题。如果大家对SAE有一些看法，和意见，也可以关注新浪官方微博。另外，SAEJava平台，已经在内测了，大家有兴趣也可以通过官方微博去申请测试渠道，加入我们测试，大家一起来提高SAE。今天先简单向大家汇报一下SAE发展，这张图就是SAE发展的一个，相对于一个里程碑，从09年8月份SAE云计算小组成立，当时还非常小只有几个人，09年11月份SAE发布了一个版本，到今年正好2年，到2010年SAE发布一个重量级云存储产品微盘。今年5月份也有很大的事开放注册，目前任何人去使用SAE不需要什么邀请码，审批流程，只要有新浪帐号就可以使用。
现在SAE开通了支付，SAE也划归为新浪云计算，还有一些第三方站点，互联网的咨询类站点也跑到SAE上。那么，在SAE产品主要有计算类服务，存储类服务，还有一个是云应用商店跟云服务商店CDN。关于云应用商店和云服务商店，应用商店大家都听说过，比如App Store，但是我们所知道App Store要不就是基于苹果IOS，要不就是Android上的，SAE如果做并不是OS，我们OS是互联网，互联网上的App Store，你现在在SAE上只需要花30秒时间就可以开通一个自己的团购网站，可以开通一个论坛，相册网站，维基百科类网站，做互联网上App Store。
反过来说什么是服务商店？我们作为一个开发者，你开发的东西并不一定都有界面，有的人开发东西，比如我是苹果语言开发商，我开发这个东西非常有价值但并没有界面，这种东西你开发者是想把他的API卖给用户的，这个时候实际上可以借助SAE分装商店，进行整个统计，日志，报表流程，你把你API架构在其上面进行销售，这是一个服务的概念。
来看一下现在SAE发展的三个指标，一个是注册用户，目前SAE注册用户大部分都是开发者，虽然数目不多，但是质量很高。尤其目前SAE做开发者认证，如果大家使用SAE的话应该听说过，任何一个人只要通过了开发者的认真都可以获取到相当多的云，相当于SAE给真正开发者免费的钱让他在SAE上开发应用。另外一个应用数，应用数目前是10万，日均PV不止1亿，应该有好几个亿。
我们也看了一下SAE上面跑的这些应用和服务来讲可靠不可靠？这是Q3的一个宕机时长45分钟，宕机次数4次，总体时间56.05。看一下活跃开发者1万多名，刚才提到开发者认证，实际上SAE还是将更多的精力关注在能够创造价值核心开发者上面，这主要是指外部开发者，包括移动互联网领域。当然还有SAE跟PHP官方合作，如果大家是爱好者登录PHP，目前PHP在大陆唯一官方网站就是SAE提供的，这说明二者之间合作也在加强，这块我们跟官方合作也会加强。
最后一个是应用商店，都有哪些应用，这块就是一个列表，不多说了，weibo，HDwik，团购等等。从这一页开始今天关于技术类的话题，我们今天题目是在HCE上MySQL，我今天先讲SQL，我个人从06年毕业之后，07年就开始做云计算方面开发。当时我们是看着亚马逊(微博)长大的一批人，亚马逊认为SQL不重要，这里是指亚马逊云计算，因为他觉得他可以推出自己的产品，这个产品是叫HDB，他的目的，我不知道他的目的，一个目的因为他想推出自己的HDB，另外因为SQL不具备可扩展性，也不具备其他云计算的特性，他想把用户导向导入到SQL里面去，后来尝试是失败的，亚马逊被迫推出RDS。
换句话说你妄想用自己一个NoSQL去改变开发者对MySQL的习惯，只要你的NoSQL，你需要用户去改代码，有实际成本，那么NoSQL就不会完全替代SQL作用。所以SAE从09年推出的时候，一定要支持SQL，那么怎么来支持MySQL呢？我们在云计算上做MySQL最重要的问题就是隔离性问题，因为使用MySQL人水平不一样，我们在HCE上确实有一些开发者，连索引都不知道是什么，就建了几千几亿的表。我们做公有云计算，如果这样的人特别多势必影响到我们分布式数据库服务，实际上SQL，或者MySQL对SAE来讲最大挑战就是隔离性。如何一个人好的坏的，黑客也好，他的烂使用不应该影响到其他人的使用，怎么做到？就是通过虚拟机来做这个事。
现在虚拟机技术，应该说还是比较成熟。比如我可以把VCPO绑定到VPO上，当然网络隔离大家都能做，实际磁盘IO隔离有一些虚拟化也可以做到，我就一个虚拟机起一个SQL，用户A需要SQL就成立一个虚拟机来实现，这种方案还是不错的。最重要一个问题，这个方案成本太大了，SAE很穷，没有钱，冲不起。我举个例子，现在在SAE从目前虚拟化来说，一个物理机最多也就3万台，3万多台需要1千台物理机。我告诉大家一个秘密，SAE到目前也没有1千台物理机，这个成本对SAE是不可承担的，我们一定要减少成本来做隔离。
怎么减少成本？一个虚拟机一个SQL不行，我就多个SQL一个虚拟机，大家不同instance也是可以，我们之前也讨论过，其实这个方案实施起来也有最大一个问题，维护起来特别麻烦。你想想那么多端口，都有自己的主和从，如果用管理人员来管理就会疯掉，可能开发人员还好，开发人员开发东西很少，但是管理人员运维成本非常大，SAE怎么来做，SAE提出一个很疯狂观念，让所有用户跑到一个SQL里面行不行，貌似是一个很不好的任务，但是SAE自己研发一套产品来实现这个技术，就是RDC，是国内唯一面对公有云，就是让所有用户，或者说一部分用户跑在一个instance，而不互相影响。
实际上通过三道隔离层来实现，通过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掉了。
另外还要支持secondary index，还有要支持认证。最后一定要支持重平衡，随着时间运转系统内势必不均衡，有的节点弱，有的节点冷，有的磁盘占用空间比较满，有的磁盘占用空间比较空，势必要有一个重新平衡，重新利用机器的过程，这个特性也是我们一定需要的。我们来看一下KVDB的架构图，其实这个架构推有点像，大体上有点像GLS，Client在发起一个绘画的时候，都会从Meta上取一个东西，我影射到哪个，拿到一个信息之后，就会根据Meta Server进行读写操作，数据流传输跟后端存储节点去进行，有主有从可以进行同步。
Meta Server并不是一个，而是一组机器。那么Meta Server如何保持影射之间的一致性？我们采用的方式就是变种的一致性，当某一个Meta Server出现一定时间，他自己肯定知道出现一段时间没有跟后端进行同步成功，这时候会发起一个操作，把自己下线，就是把自己服务端口给封掉。这里有一个风险，后端挂掉是不是会导致所有的Meta Server都挂掉了全部下线，这样导致服务不可用的。我们在这块假如协议，我能不能自己把自己给宕了，如果能就宕了，如果不能就继续提供服务，这样保证即使出现故障的时候，仍然保持有二分之一的机器能够服务。当一个系统里面，我们主要处理两个纬度。
这种逻辑很简单，缺乏一个很有理论高度平衡，SAE怎么来做这个事，基于一个数学理论，实际上就两个概念，第一个概念叫数学期望，第二就军方差。我们以磁盘利用率为例子，比如现在所有系统里面磁盘利用率，数学期望是50%的话，这个时候表示什么呢？就表示我们所有系统里面磁盘大概利用率，基本上都是属于一半。军方差表什么意思？是所有系统磁盘里面有效率，或者说利用率，离50%的偏差程度。换句话说，我们怎么来判断重平衡，如果我这个系统里边，不管你以什么指标为准，如果军方差很小，数学期望很高，这时候做的不是平衡而是扩容。反过来如果系统里面数学期望很小，军方差很高，就表示你所有点离中心离散度已经非常高了，这时候做的不是扩容，而是重平衡。
所以，我们以这个为方式就设立一个SAE上用来重平衡的概念，当然我们这个公式不是这么简单，因为时间关系不多说了。重平衡如果做无缝迁移？我们从客户端来写，从A迁到B，以写B端成功为主。从A去读，也人觉得你写到A，再写到B，如果A没有成功，会不会读不出来，这可能会发生这就是我们一个他想保证一个最终一致性，这个暂时可能读不出来，但是一定会读出来。
这是KVDB使用的一些问题，不多说了，还有一个服务。下面介绍一下Rank，排行榜，这个排行榜服务应用场景就是有这种，比如游戏网站，游戏下载周排行，月排行都会用到。Rank，第一个需求是top rank，我往里面放一些东西，我希望是最大的，比如top100 top1000，还有一个all rank，我要知道在里面每一个排行，我玩游戏想知道分数最高100个用户是谁，这叫top rank，还有我给你一个用户，告诉我在FaceBook用户里面用户排名是多少，这就是all rank，这块今天不讨论了。
目前主要解决是top rank的问题，all rank也在开发。实际上这个Rank服务还是比较简单，到后端主从，实际上一个Rank配一个ERBT，他一部分是key到一个value，还有如何从rank而去查value，关键如何从value去查Rank，这块也可以通过扩展，不仅仅包括服务节点，红黑部分，还包括所有子节点数，通过这个信息我们就可以通过topn来得到，就像我这个表里所说到，PPT可以下载，大家回去看。
那么Rank可靠性如何来保证？首先是一个in-memory master slave sync，因为从事任何时刻热备才能够顶替主的服务。另外他会每隔2分钟，1分钟把自己的数据，变化的数据宕到硬盘上。主从之间我们bin-log，这是一个问题。比如我主跟从互相in-memory，比如从突然宕机24个小时，这时候从要起来追主所有数据，这时候怎么来做，我们每次去同步的时候都去对比主从之间这个表的值，如果发现这个不一样就去统计这一小块的数字，这就减少主从之间量，虽然表面上是一个全部，实际上量会得到一个控制。
NoSQL还有一个Counter应用场景。从SAE来讲，对于开发者如何来选型SAE的NoSQL首先是速度，其次像容量，可靠性。我们反过来看容量，肯定是有限制的，虽然SAE是动态去扩容量，今天是10兆明天不够变成20兆，200兆，一个T就是可以，但是有一个上限，超过一个上限往里放，容量最大KVDB，可以限往里面去放，MySQL也比较大，目前支持512个表，每个表里面最多1千万条记录。可靠性上来讲，很显然MySQL占第一位，甚至会考虑WLAN的方式部署数据，反过来MySQL数据是最低的，一旦出现问题你不可恢复，需要从其他数据里面重新加入。
最后是SAE，在SAE官方微博有招聘信息，大家就兴趣可以加入SAE。如果大家对今天演讲内容有问题可以在微博上与我进行沟通，谢谢大家。
