實際上通過三道隔離層來實現(xiàn)，通過MySQL，一個用戶無論是Java開發(fā)者，PHP開發(fā)者，他在使用的時候RDC的時候沒有任何障礙，他原來代碼訪問的時候，要填自己的IP端口，現(xiàn)在所有人填的IP端口是3307，IP，或者地址是W.RDC。新浪.COM.CN，所有人填的都是這個。當然用戶密碼是分配的，這個根本每個人都不一樣。所有人面向都是同一個中間層，而這個中間層又因為支持SQL協(xié)議，導致用戶使用起來沒有任何障礙，他不知道自己使用的是RDC，以為自己使用的是MySQL，整個語法完全跟MySQL一樣進行調用，用戶使用起來完全沒有障礙，不需要改一行代碼。
在這種情況下RDC如何實現(xiàn)隔離性呢？有三個步驟，第一個步驟叫做SQL預判，如果他認為你的SQL執(zhí)行成本有害于系統(tǒng)的話，他在RDC就屏蔽掉，攔截掉。我們都知道標準MySQL是從1千，標準就是從1萬，你會得到1萬零5，你在一個過大的表上，而且沒有索引的字段上做查詢，你這條搜索被攔截了，這種語句在的RDC上肯定過不去。
也就是說SQL預判可以把我們認為不健康的SQL攔在外面，我們攔的標準是什么？攔哪些SQL語句，比如常見的都攔，攔截的標準是什么？我們會看你帶不帶這樣的語句，語句里面索引是不是加的合適等等，這些選項都會作為我們打分機制，白就通過，黑就攔截，這是第一步。第二步我們都知道黑白這個東西還是過于簡單了，假如說，比如說我現(xiàn)在60分及格，但現(xiàn)在用戶SQL語句都是61分，62分，雖然都及格了，這樣的SQL語句到后端仍然給SAE數(shù)據(jù)庫進行造成傷害，不光對單獨SQL數(shù)據(jù)有一個黑和白，還需要對一個時間趨勢判斷。
實際上SQL在這行也傳播性發(fā)明一個單詞叫“并發(fā)式執(zhí)行時間和來做這個事情”。我們都知道買SQL自身是支持并發(fā)控制，對于一個用戶，我可以限制這個用戶最高并發(fā)是多少，這個SQL自己就支持，但這里面有一個問題。SAE想達到一個什么效果呢？對于好的用戶給最大的并發(fā)，對于不好的用戶給不好，懲罰性的并發(fā)。什么叫好的用戶，你表結果非常合理，思路也非常健康，這種用戶對于SAE來說是好用戶，我們贊賞你，希望你在SQL上運行。哪些不好像剛才那種語句，不好的用戶，不好的語句，我們希望給這種用戶少的并發(fā)。我們怎么來天然區(qū)分這件事？
因為每個用匯在SQL，我們并不事先知道是好是壞，我們提出并發(fā)執(zhí)行時間和，當前并發(fā)SQL語句執(zhí)行時間的和。我在這塊舉個例子，比如說我現(xiàn)在設定當前并發(fā)執(zhí)行時間1萬秒用戶A每條執(zhí)行時間是100秒，用戶A獲得并是100，100×100就是10000，用戶B如果執(zhí)行時間是1萬秒，正好進入SAE之后就繞過去了，第二進都進不來，因為并發(fā)時間和已經(jīng)被消耗光了，1萬×1等于1萬，換成A獲得并發(fā)就是100，用戶B獲得的就是并發(fā)就是1，從技術層面天然驅動用戶，你要更改自己的表結構，你要優(yōu)化自己的數(shù)據(jù)庫，你要寫好的SQL減少對SAE傷害，這就是并發(fā)執(zhí)行時間和的作用。
還有最后防護線就是慢查詢的時間配額，我們規(guī)定你的數(shù)據(jù)庫不能在一定時間之內慢查詢超過多少情況，一旦超過會給你短暫禁用。實際上通過這些措施來綜合的保障了，當我很多很多用戶同時跑在MySQL里面，能夠保證絕大部分用戶健康穩(wěn)定的運行。我們都說RDC很美好，確實RDC，我們所有開發(fā)者數(shù)據(jù)庫都是有RDC來提供的，但是RDC是不是能解決一切？并不是，RDC不能解決的一個很重要的問題就我們的擴展性問題。擴展性，實際上分成兩種，一種水平擴展，一種垂直擴展，垂直擴展不多說，因為一般都跟業(yè)務相關的。
那么水平擴展RDC目前不支持，我們希望用戶分庫分表有自己管，但是RDC天然不做分庫分表。目前有的數(shù)據(jù)庫是支持水平擴展的，比如我聽過百度介紹他們數(shù)據(jù)庫系統(tǒng)，可以指定一個，包括微軟(微博)云計算分布式數(shù)據(jù)庫系統(tǒng)可以指定做分庫分表，但是這里面有一個問題，這個Scalability不叫動態(tài)擴展性，是靜態(tài)擴展性，用戶不知道分庫分表概念，他只需要往里面寫就行了。靜態(tài)就像亞馬遜，我事先數(shù)據(jù)量有多大，有幾個億，事先分成16個庫，每個庫里面512個表，事先有一個預估，這就是靜態(tài)的擴展性。一旦我超過這個預估怎么辦？這時候就需要去遷，拆表，工作量也非常大。
所以，從動態(tài)擴展性來講，用戶毫不知情來講還沒有達到這種程度。實際上除了RDC之外，除了那些靜態(tài)擴展性關系型數(shù)據(jù)庫之外，用戶更需要動態(tài)擴性，根本不需要分什么庫，分什么表，分什么節(jié)點，他需要你往里面執(zhí)行。實際上RDC在這塊目標，為什么要做NoSQL服務，也是希望能夠給用戶提供完全動態(tài)的NoSQL服務。
我們都說關系型數(shù)據(jù)庫的缺點主要在于擴展性，為了彌補這些擴展性，所以SAE開發(fā)一系列NoSQL服務，來彌補和引導用戶，你可以把一些適當不那么可靠性要求不那么高的數(shù)據(jù)，遷到我們NoSQL里面去。SAE里面NoSQL包含什么東西，有RDC，Storage等。SAE一開始Memcache非常簡單，但是有一個問題在什么地方？第一不能擴展，用戶原來說我起一個512的Memcache后來覺得不夠，需要擴充1個億，就需要重啟，后來重啟不夠。另外一個可靠性非常低，如果這臺機器宕了，所有數(shù)據(jù)就穿透了。針對這個缺點就開發(fā)了MemcacheX，即使當中有一臺機器宕機只應該到用戶N分之一T，里面有獨立的統(tǒng)計信息，獨立LRU量，又構建在一個共享的存儲上面去。
同時，MemcacheX還有一個很重要的特性就是connection LRU，MemcacheX在訪問量特別大的時候容易造成connection堵塞，容易造成新的connection進不來，這是在極大訪問量情況下才出現(xiàn)，我們設置了connection LRU，新的替代掉老的，不會造成訪問量的堵塞。這是MemcacheX架構圖，底層是集群，客戶端進行訪問。我們來看KVDB，實際上是一個非可持久化存儲。KVDB就是在SAE上可持續(xù)化的存儲，第一個就是為什么說又一個NoSQL DB，我個人覺得NoSQL DB有點太多了，各個公司都在搞，亂七八糟的東西太多了，我們一開始做之前，SAE有必要參與這個，有必要也攪這個局嗎，后來發(fā)現(xiàn)現(xiàn)有東西滿足不了我們這個要求。
我們KVDB都有什么要求？第一存儲引擎是可換的，因為存儲引擎很依賴于，因為數(shù)據(jù)庫原理是苦定的，幾十年前都已經(jīng)穩(wěn)定好了，這是大部分。變化就是硬件，原來是什么什么傳統(tǒng)硬盤，現(xiàn)在變成什么Flash，過去存儲引擎工作比較好，沒準就變成利用FDD引擎工作比較好。所以，我們要求KVDB存儲引擎可以變，我并不依賴某一個特定存儲引擎。另外任意模塊水平擴展，大多數(shù)人都支持讀寫分離，第四要支持前綴查找，很多開發(fā)者在SAE都需要功能，雖然看似簡單，一個需求就把很多存儲給Pass掉了。
推薦閱讀
時至今日，“Big data”(大數(shù)據(jù))時代的來臨已經(jīng)毋庸置疑，尤其是在電信、金融等行業(yè)，幾乎已經(jīng)到了“數(shù)據(jù)就是業(yè)務本身”的地步。這種趨勢已經(jīng)讓很多相信數(shù)據(jù)之力量的企業(yè)做出改變。恰逢此時，為了讓更多的人了解和使>>>詳細閱讀
地址：http://www.sdlzkt.com/a/kandian/20120305/36930.html
網(wǎng)友點評
精彩導讀
科技快報
品牌展示