YunTable

-云計算時代的數(shù)據(jù)庫目錄云計算時代的數(shù)據(jù)庫YunTable的簡介和設(shè)計NoSQL產(chǎn)品之間的比較YunTable的使用場景YunTable今后的規(guī)劃云計算時代的數(shù)據(jù)庫云計算時代的需求低延遲的讀寫速度：應(yīng)用快速地反應(yīng)能極大地提升用戶的滿意度；支撐海量的數(shù)據(jù)和流量：對于搜索這樣大型應(yīng)用而言，需要利用PB級別的數(shù)據(jù)和能應(yīng)對百萬級的流量；大規(guī)模集群的管理：系統(tǒng)管理員希望分布式應(yīng)用能更簡單的部署和管理；龐大運(yùn)營成本的考量：IT經(jīng)理和CFO們都希望在硬件成本、軟件成本和人力成本上面能夠有大幅度地降低；關(guān)系型數(shù)據(jù)庫的限制擴(kuò)展困難：由于存在類似Join這樣多表查詢機(jī)制，使得數(shù)據(jù)庫在擴(kuò)展方面很艱難；讀寫慢：這種情況主要發(fā)生在數(shù)據(jù)量達(dá)到一定規(guī)模時由于關(guān)系型數(shù)據(jù)庫的內(nèi)部邏輯非常復(fù)雜，使得其很容易發(fā)生死鎖等的并發(fā)問題，而這將導(dǎo)致其讀寫速度下滑嚴(yán)重；成本高：企業(yè)級數(shù)據(jù)庫的License價格很驚人，并且隨著系統(tǒng)的規(guī)模，而不斷上升；有限的支撐容量：現(xiàn)有關(guān)系型解決方案還無法支撐Google這樣海量的數(shù)據(jù)存儲；NoSQL數(shù)據(jù)庫業(yè)界為了解決前面提到的幾個需求，推出了多款新類型的數(shù)據(jù)庫，并且由于它們在設(shè)計上和傳統(tǒng)的SQL數(shù)據(jù)庫相比有很大的不同，所以被統(tǒng)稱為“NoSQL”。在設(shè)計上，NoSQL非常關(guān)注對數(shù)據(jù)高并發(fā)地讀寫和對海量數(shù)據(jù)的存儲等。在我看來，它與關(guān)系型數(shù)據(jù)庫相比，在架構(gòu)和數(shù)據(jù)模型方面做了“減法”，而在擴(kuò)展和并發(fā)等方面做了“加法”。主要產(chǎn)品有：BigTable、HBase、Redis、Cassandra和MongoDB等。NoSQL數(shù)據(jù)庫的優(yōu)勢簡單的擴(kuò)展：典型例子是Cassandra，由于其架構(gòu)是類似于經(jīng)典的P2P，能輕松地添加新的節(jié)點(diǎn)來擴(kuò)展這個集群；并發(fā)的讀寫：主要例子有Redis，由于其邏輯簡單，而且純內(nèi)存操作，使得其性能非常出色；低廉的成本：這是大多數(shù)分布式數(shù)據(jù)庫共有的特點(diǎn)，因?yàn)橹饕情_源軟件，沒有昂貴的License成本。NoSQL數(shù)據(jù)庫的不足之處不提供對SQL的支持：如果不支持SQL這樣的工業(yè)標(biāo)準(zhǔn)，將會對用戶產(chǎn)生一定的學(xué)習(xí)和應(yīng)用遷移成本；支持的特性不夠豐富：現(xiàn)有產(chǎn)品所提供的功能都比較有限，大多數(shù)NoSQL數(shù)據(jù)庫都不支持事務(wù)，也不像MSSQLServer那樣能提供各種強(qiáng)大的附加功能；現(xiàn)有產(chǎn)品的不夠成熟：大多數(shù)產(chǎn)品都還處于初創(chuàng)期，和關(guān)系型數(shù)據(jù)庫幾十年的完善不可同日而語；YunTable的簡介和設(shè)計YunTable的簡介在研發(fā)YunEngine的時候，發(fā)現(xiàn)在業(yè)界還缺乏一款在架構(gòu)上非常簡潔，并可適應(yīng)多種云計算場景的NoSQL數(shù)據(jù)庫，所以在那時就開始進(jìn)行研發(fā)YunTable了。YunTable的目標(biāo)不是做一個類似BigTable這樣比較大而全的數(shù)據(jù)庫，而主要是做一個精簡版的分布式Key-Value數(shù)據(jù)庫，上層的云計算應(yīng)用將會根據(jù)其自身的需求去利用YunTable或者做修改，從而使YunTable能適應(yīng)云計算各種場景，并且非常易用。現(xiàn)在已經(jīng)在10月初正式開源，并發(fā)布其0.8版，項目地址。YunTable的設(shè)計首先，從設(shè)計角度而言，YunTable主要從BigTable中借鑒了很多優(yōu)秀的設(shè)計，并進(jìn)行簡化，總體而言，主要有下面這三大特色:在數(shù)據(jù)模型方面基于Key-Value；在分布式架構(gòu)方面采用了Single-Master的設(shè)計；在存儲方面利用了SSTable的格式；其次，在結(jié)構(gòu)方面，YunTable主要有兩大模塊組成：Master節(jié)點(diǎn)：作用是管理整個YunTable集群，在集群中只存在一個。Region節(jié)點(diǎn)：作用是存儲數(shù)據(jù)，在集群中會有多個。Key-Value

Key-value這種數(shù)據(jù)模型在結(jié)構(gòu)方面和傳統(tǒng)的關(guān)系型相比較簡單，有點(diǎn)類似常見的HashTable，一個Key對應(yīng)一個Value，但是其能提供非常快的查詢速度、大的數(shù)據(jù)存放量和高并發(fā)地操作，并非常適合通過主鍵（Key）來對數(shù)據(jù)進(jìn)行查詢和修改等操作，雖然不支持復(fù)雜的操作，但是可以通過上層的開發(fā)來彌補(bǔ)這個缺陷。Single-Master在分布式的設(shè)計上面，選擇了在語義和實(shí)現(xiàn)上都非常簡單明了的SingleMaster模式來管理整個集群。一般來說，一個Master節(jié)點(diǎn)能管理上千個Region節(jié)點(diǎn)，為了能管理這樣大的集群，所以Master節(jié)點(diǎn)只負(fù)責(zé)Region節(jié)點(diǎn)之間數(shù)據(jù)的分布，實(shí)際數(shù)據(jù)的處理則與Master無關(guān)，而由Client端和Region節(jié)點(diǎn)之間進(jìn)行交互來完成。為了避免Master出現(xiàn)單點(diǎn)失敗的情況，YunTable將在今后版本中引入Shadow-Master這種機(jī)制。SSTable簡單而言，SSTable是一個用于存儲已排序Key-Value對的文件格式，并且是不可變動的（Immutable），也就是寫了之后，只能將其更新附加在其之后，而不能直接進(jìn)行修改，這樣是為了讓系統(tǒng)能執(zhí)行Disk所擅長的順序訪問，而不是隨機(jī)訪問。在內(nèi)部格式方面，SSTable文件主要有Index和DataBlock這兩部分組成。在實(shí)際運(yùn)行時，系統(tǒng)常會把Index載入內(nèi)存，以確保查詢的效率。YunTable的架構(gòu)如何適應(yīng)不同的云計算環(huán)境云計算主要常見的有兩類場景：需要低延遲和高并發(fā)的讀寫能力（類似OLTP）。海量數(shù)據(jù)的存儲和操作（類似OLAP）。那么YunTable是如何適應(yīng)這兩種環(huán)境？首先，堅持Key-Value、Single-Master和SSTable這樣經(jīng)典和通用的設(shè)計。其次，在數(shù)據(jù)存儲方面，加入Hotness這個機(jī)制，主要是通過設(shè)置Hotness值來決定之前為了完成查詢而讀取到內(nèi)存中的DataBlock的生存時間，假設(shè)如果是低延遲的情況，那么將Hotness值設(shè)置長一點(diǎn)，如果是海量數(shù)據(jù)，則相反。NoSQL產(chǎn)品之間的比較主要的NoSQL數(shù)據(jù)庫BigTable/HBase：在數(shù)據(jù)模型上面屬于Column-Family，采用了SingleMaster的分布式架構(gòu)，主要為了存儲海量的數(shù)據(jù)，不強(qiáng)調(diào)低延遲。Cassandra：在數(shù)據(jù)模型方面繼承BigTable，也是Column-Family，采用Dynamo的機(jī)制，其分布式架構(gòu)類似P2P。Redis：是Key-Value的，對List和Set這些操作有原生的支持，由于數(shù)據(jù)集都是放置于內(nèi)存中，所以讀寫速度非常快，但是對分布式支持非常有限。MongoDB：是DocumentDB，提供功能相對而言，比較完善，在分布式方面，有ReplicaSets這樣的新一代Master/SlaveReplication機(jī)制。NoSQL數(shù)據(jù)庫之間的比較YunTableBigTable/

HBaseCassandraRedisMongoDB設(shè)計理念簡潔，通過設(shè)置來應(yīng)對不同場景海量存儲和處理簡單和有效的擴(kuò)展高并發(fā)全面數(shù)據(jù)模型Key-ValueColumn-FamilyColumn-FamilyKey-ValueDocument分布式Single-MasterSingle-MasterP2PM/S備份ReplicaSets特色簡潔和Hotness支撐海量數(shù)據(jù)采用Dynamo和P2PList、Set的處理全面不足現(xiàn)在還處于開發(fā)階段不適應(yīng)低延遲應(yīng)用Dynamo機(jī)制受到質(zhì)疑分布式方面支持有限在性能和擴(kuò)展方面沒優(yōu)勢YunTable的使用場景具體場景PaaS平臺：由于PaaS平臺的需求比較復(fù)雜，所以需要對其后臺的數(shù)據(jù)庫進(jìn)行很多定制化，而YunTable由于其架構(gòu)簡單，所以非常適合，這方面的例子有YunEngine。Key-Value的數(shù)據(jù)存儲：YunTable現(xiàn)在已提供名為YunCli的命令行，通過這個命令行能