NOSQL系統(tǒng)一般都會(huì)宣傳一個(gè)特性，那就是性能好，然后為什么呢？關(guān)系型數(shù)據(jù)庫(kù)發(fā)展了這么多年，各種優(yōu)化工作已經(jīng)做得很深了，NOSQL系統(tǒng)一般都是吸收關(guān)系型數(shù)據(jù)庫(kù)的技術(shù)，那么，到底是什么因素束縛了關(guān)系型數(shù)據(jù)庫(kù)的性能呢？我們從系統(tǒng)設(shè)計(jì)的角度看這個(gè)問(wèn)題。

1. 索引支持

關(guān)系型數(shù)據(jù)庫(kù)創(chuàng)立之初沒(méi)有想到今天的互聯(lián)網(wǎng)應(yīng)用對(duì)可擴(kuò)展性提出如此高的要求，因此，設(shè)計(jì)時(shí)主要考慮的是簡(jiǎn)化用戶(hù)的工作，SQL語(yǔ)言的產(chǎn)生促成數(shù)據(jù)庫(kù)接口的標(biāo)準(zhǔn)化，從而形成了Oracle這樣的數(shù)據(jù)庫(kù)公司并帶動(dòng)了上下游產(chǎn)業(yè)鏈的發(fā)展。關(guān)系型數(shù)據(jù)庫(kù)在單機(jī)存儲(chǔ)引擎支持索引，比如Mysql的 Innodb存儲(chǔ)引擎需要支持索引，而NOSQL系統(tǒng)的單機(jī)存儲(chǔ)引擎是純粹的，只需要支持基于主鍵的隨機(jī)讀取和范圍查詢(xún)。NOSQL系統(tǒng)在系統(tǒng)層面提供對(duì)索引的支持，比如有一個(gè)用戶(hù)表，主鍵為user_id，每個(gè)用戶(hù)有很多屬性，包括用戶(hù)名，照片ID(photo_id)，照片URL，在NOSQL系統(tǒng)中如果需要對(duì)photo_id建立索引，可以維護(hù)一張分布式表，表的主鍵為形成的二元組。關(guān)系型數(shù)據(jù)庫(kù)由于需要在單機(jī)存儲(chǔ)引擎層面支持索引，大大降低了系統(tǒng)的可擴(kuò)展性，使得單機(jī)存儲(chǔ)引擎的設(shè)計(jì)變得很復(fù)雜。

2. 事務(wù)并發(fā)處理

關(guān)系型數(shù)據(jù)庫(kù)有一整套的關(guān)于事務(wù)并發(fā)處理的理論，比如鎖的粒度是表級(jí)，頁(yè)級(jí)還是行級(jí)，多版本并發(fā)控制機(jī)制MVCC，事務(wù)的隔離級(jí)別，死鎖檢測(cè)，回滾，等等。然而，互聯(lián)網(wǎng)應(yīng)用大多數(shù)的特點(diǎn)都是多讀少些，比如讀和寫(xiě)的比例是10 : 1，并且很少有復(fù)雜事務(wù)需求，因此，一般可以采用更為簡(jiǎn)單的copy-on-write技術(shù)：?jiǎn)尉€(xiàn)程寫(xiě)，多線(xiàn)程讀，寫(xiě)的時(shí)候執(zhí)行copy-on- write，寫(xiě)不影響讀服務(wù)。NOSQL系統(tǒng)這樣的假設(shè)簡(jiǎn)化了系統(tǒng)的設(shè)計(jì)，減少了很多操作的overhead，提高了性能。

3. 動(dòng)態(tài)還是靜態(tài)的數(shù)據(jù)結(jié)構(gòu)

關(guān)系型數(shù)據(jù)庫(kù)的存儲(chǔ)引擎總是一顆磁盤(pán)B+樹(shù)，為了提高性能，可能需要有insert buffer聚合寫(xiě)，query cache緩存讀，經(jīng)常需要實(shí)現(xiàn)類(lèi)似Linux page cache的緩存管理機(jī)制。數(shù)據(jù)庫(kù)中的讀和寫(xiě)是互相影響的，寫(xiě)操作也因?yàn)闀r(shí)不時(shí)需要將數(shù)據(jù)flush到磁盤(pán)而性能不高。簡(jiǎn)而言之，關(guān)系型數(shù)據(jù)庫(kù)存儲(chǔ)引擎的數(shù)據(jù)結(jié)構(gòu)是通用的動(dòng)態(tài)更新的B+樹(shù)。然而，在NOSQL系統(tǒng)中，比如Bigtable中采用SSTable + MemTable的數(shù)據(jù)結(jié)構(gòu)，數(shù)據(jù)先寫(xiě)入到內(nèi)存的MemTable，達(dá)到一定大小或者超過(guò)一定時(shí)間才會(huì)dump到磁盤(pán)生成SSTable文件，SSTable是只讀的。如果說(shuō)關(guān)系型數(shù)據(jù)庫(kù)存儲(chǔ)引擎的數(shù)據(jù)結(jié)構(gòu)是一顆動(dòng)態(tài)的B+樹(shù)，那么SSTable就是一個(gè)排好序的有序數(shù)組。很明顯，實(shí)現(xiàn)一個(gè)有序數(shù)據(jù)比實(shí)現(xiàn)一個(gè)動(dòng)態(tài)B+樹(shù)且包含復(fù)雜的并發(fā)控制機(jī)制要簡(jiǎn)單高效地多。

4. Join操作

關(guān)系型數(shù)據(jù)庫(kù)需要在存儲(chǔ)引擎層面支持Join，而NOSQL系統(tǒng)一般根據(jù)應(yīng)用來(lái)決定Join實(shí)現(xiàn)的方式。舉個(gè)例子，有兩張表：用戶(hù)表和商品表，每個(gè)用戶(hù)下可能有若干個(gè)商品，用戶(hù)表的主鍵為，用戶(hù)和商品的關(guān)聯(lián)屬性存放在用戶(hù)表中，商品表的主鍵為item_id，商品屬性包括商品名，商品URL，等等。假設(shè)應(yīng)用需要查詢(xún)一個(gè)用戶(hù)的所有商品并顯示商品的詳細(xì)信息，普通的做法是先從用戶(hù)表查找指定用戶(hù)的所有item_id，然后對(duì)每個(gè)item_id去商品表查詢(xún)?cè)敿?xì)信息，即執(zhí)行一次數(shù)據(jù)庫(kù)Join操作，這必然帶來(lái)了很多的磁盤(pán)隨機(jī)讀，并且由于Join帶來(lái)的隨機(jī)讀的局部性不好，緩存的效果往往也是有限的。在NOSQL系統(tǒng)中，我們往往可以將用戶(hù)表和商品表集成到一張寬表中，這樣雖然冗余存儲(chǔ)了商品的詳細(xì)信息，卻換來(lái)了查詢(xún)的高效。

關(guān)系型數(shù)據(jù)庫(kù)的性能瓶頸往往不在SQL語(yǔ)句解析上，而是在于需要支持完備的SQL特性?；ヂ?lián)網(wǎng)公司面臨的問(wèn)題是應(yīng)用對(duì)性能和可擴(kuò)展性要求很高，并且DBA和開(kāi)發(fā)工程師水平比較高，可以通過(guò)犧牲一些接口友好性來(lái)?yè)Q取更好的性能。NOSQL系統(tǒng)的一些設(shè)計(jì)，比如通過(guò)寬表實(shí)現(xiàn)Join操作，互聯(lián)網(wǎng)公司的DBA和開(kāi)發(fā)工程師也做過(guò)，NOSQL系統(tǒng)只是加強(qiáng)了這種約束。從長(zhǎng)遠(yuǎn)來(lái)看，可以總結(jié)一套約束集合，并且定義一個(gè)SQL子集，只需要支持這個(gè)SQL子集就可以在不犧牲可擴(kuò)展性的前提下支持比如90%以上的互聯(lián)網(wǎng)應(yīng)用。我想，NOSQL技術(shù)發(fā)展到這一步的時(shí)候就算是比較成熟了，這也是我們最終想做的事情。我們?cè)谠O(shè)計(jì)和使用NOSQL系統(tǒng)的時(shí)候也可以適當(dāng)轉(zhuǎn)化一下思維，如下：

1) 更大的數(shù)據(jù)量。很多人在使用Mysql的過(guò)程遇到記錄條數(shù)超過(guò)一定值，比如2000W的時(shí)候，數(shù)據(jù)庫(kù)性能開(kāi)始下降，這個(gè)值的得出往往需要經(jīng)過(guò)大量的測(cè)試。然而，大多數(shù)的NOSQL系統(tǒng)可擴(kuò)展性都比較好，能夠支持更大的數(shù)據(jù)量，因此也可以采用一些空間換時(shí)間的做法，比如通過(guò)寬表的方式實(shí)現(xiàn)Join。

2) 性能預(yù)估更加容易。關(guān)系型數(shù)據(jù)庫(kù)由于復(fù)雜的并發(fā)控制，insert buffer及類(lèi)似page cache的讀寫(xiě)優(yōu)化機(jī)制，性能估算相對(duì)較難，很多時(shí)候需要憑借經(jīng)驗(yàn)或者經(jīng)過(guò)測(cè)試才能得出系統(tǒng)的性能。然后，NOSQL系統(tǒng)由于存儲(chǔ)引擎實(shí)現(xiàn)，并發(fā)控制機(jī)制等相對(duì)簡(jiǎn)單，可以通過(guò)硬件的性能指標(biāo)在系統(tǒng)設(shè)計(jì)之處大致預(yù)估系統(tǒng)的性能，性能預(yù)估可操作性相對(duì)更強(qiáng)。