時至今日，“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。如果大家對今天演講內容有問題可以在微博上與我進行溝通，謝謝大家。
京公網安備 11010502049343號