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