云計(jì)算時(shí)代的數(shù)據(jù)庫

YunTable

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

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

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