【51CTO獨(dú)家特稿】大家一定都使用過關(guān)系數(shù)據(jù)庫管理系統(tǒng)（RDBMS），可以說關(guān)系數(shù)據(jù)庫的身影無處不在，也有諸如Oracle，微軟，IBM等數(shù)據(jù)庫廠商為我們提供了大量的RDBMS產(chǎn)品，縱觀這幾十年，關(guān)系數(shù)據(jù)庫為應(yīng)用程序的快速發(fā)展立下了汗馬功勞，但目前出現(xiàn)了一種由互聯(lián)網(wǎng)和社交網(wǎng)絡(luò)驅(qū)動的新型應(yīng)用程序，這種應(yīng)用程序需要充足的擴(kuò)展能力，以滿足高峰時段大規(guī)模訪問和數(shù)據(jù)處理的要求。

這種應(yīng)用場景很難使用傳統(tǒng)的關(guān)系數(shù)據(jù)庫滿足要求，因?yàn)樗豢赡転楦叻鍟r段提供足夠的硬件資源，如果非要在傳統(tǒng)關(guān)系數(shù)據(jù)庫上承載這類應(yīng)用，維護(hù)工作量也是非常驚人的，并且宕機(jī)也是常事，SimpleDB可以解決這些問題，但為了解決這些問題，SimpleDB提出了一些新的設(shè)計(jì)理念，為了保證你在選擇數(shù)據(jù)庫時作出正確的抉擇，你應(yīng)該了解這些新的設(shè)計(jì)理念。

[[12139]]

無范式

范式化是關(guān)系數(shù)據(jù)庫有效組織數(shù)據(jù)的一個過程，其目的是消除冗余數(shù)據(jù)，同時確保數(shù)據(jù)依賴的意義，SimpleDB數(shù)據(jù)模型不遵守任何形式的范式，相反，它是完全反范式的，SimpleDB的無范式化允許你更靈活地處理你的數(shù)據(jù)模型，允許在你的數(shù)據(jù)中使用多值屬性。

我們先來看一個基礎(chǔ)的表格結(jié)構(gòu)，然后分別用RDBMS和SimpleDB數(shù)據(jù)模型理念進(jìn)行表結(jié)構(gòu)設(shè)計(jì)，在這個例子中，我們創(chuàng)建一個簡單的聯(lián)系人數(shù)據(jù)庫。

添加新電話號碼的難易程度按照這種設(shè)計(jì)，要按電話號碼找一個人是很容易的。

SELECT * FROM Contact_Info WHERE Phone_Num = '555-854-9885' 

但最明顯的問題是名字有重復(fù)，這樣的表結(jié)構(gòu)設(shè)計(jì)效率是很低的，下面分析一下這樣設(shè)計(jì)的強(qiáng)項(xiàng)和弱項(xiàng)。

這樣的設(shè)計(jì)很簡單，但名字重復(fù)了，因此在數(shù)據(jù)同步方面需要小心謹(jǐn)慎，如果名字未同步，按名字檢索電話號碼時，結(jié)果就不準(zhǔn)確了。

為了改善這個設(shè)計(jì)，更合理地組織數(shù)據(jù)，一個辦法是象下面這樣創(chuàng)建多個電話號碼字段，雖然它通過一個簡單的方法解決了當(dāng)前的問題，但它限制了最多只能容納三個電話號碼，如果還要增加郵件地址和Twitter賬號，表將會越來越大。

要按電話號碼找一個人是很恐怖的。

SELECT * FROM Contact_Info WHERE Phone_Num_1 = '555-854-9885' 
OR Phone_Num_2 = '555-854-9885' 
OR Phone_Num_3 = '555-854-9885' 

我們再來分析一下這種數(shù)據(jù)庫結(jié)構(gòu)設(shè)計(jì)的強(qiáng)項(xiàng)和弱項(xiàng)。

這種設(shè)計(jì)也很簡單，但電話號碼數(shù)量受到了限制，并且按電話號碼檢索會涉及到三個索引。

另一個辦法是使用一個字段存儲所有打電話號碼，用分隔符進(jìn)行分割。

這種設(shè)計(jì)方法的優(yōu)點(diǎn)是無重復(fù)，緊湊，簡潔，可維護(hù)性好，容易擴(kuò)展，但要按電話號碼進(jìn)行檢索只能使用子串模糊匹配，效率低下。

SELECT * FROM Contact_Info WHERE Phone_Nums LIKE %555-854-9885% 

這種SQL語句會強(qiáng)制執(zhí)行全表掃描，如果是小表，不會有性能影響，但如果有上百萬行記錄，數(shù)據(jù)庫的性能將會受到嚴(yán)重影響。來看一下這種設(shè)計(jì)的強(qiáng)項(xiàng)和弱項(xiàng)。

為了遵守關(guān)系數(shù)據(jù)庫的范式，有時你必須將數(shù)據(jù)分解到多個獨(dú)立的表中，然后相互用鍵進(jìn)行關(guān)聯(lián)，要從多個表中檢索數(shù)據(jù)，必須使用連接操作。

下面就重新對數(shù)據(jù)進(jìn)行范式化設(shè)計(jì)，首先設(shè)計(jì)一個Person_Info表。

再設(shè)計(jì)一個Phone_Info表。

現(xiàn)在連接Person_Info和Phone_Info表就可以檢索電話號碼，也可以檢索郵件地址，除了ID主鍵外，表結(jié)構(gòu)很干凈，無重復(fù)數(shù)據(jù)，給Phone_Num字段加上索引，按電話號碼檢索聯(lián)系人的效率就很高了。

SELECT First_Name, Last_Name, Phone_num, Person_Info.ID  
FROM Person_Info JOIN Phone_Info  
ON Person_Info.ID = Phone_Info.ID  
WHERE Phone_Num = '555-854-9885' 

再來分析一下這種設(shè)計(jì)的強(qiáng)項(xiàng)和弱項(xiàng)。

雖然這是一個高效的關(guān)系模型，但在SimpleDB中沒有連接命令，使用兩個表會強(qiáng)制實(shí)施全表掃描，下面我們就來看看如何使用SimpleDB的數(shù)據(jù)模型來實(shí)現(xiàn)。

#p#

無連接

SimpleDB不支持連接的概念，相反，它為一個屬性提供了存儲多值的功能，從而避免了檢索所有值需要的連接操作。

在SimpleDB表中，每條記錄保存為一個屬性/值對形式的條目，這里的區(qū)別是Phone_Num字段有多個值，和使用分隔符的字段不同，SimpleDB可以索引所有的值，因此檢索任何一個值的效率都很高。

SELECT * FROM Contact_Info WHERE Phone_Num = '555-854-9885' 

SELECT操作是非常高效的，甚至可以象下面這樣多次使用Phone_Num：

SELECT * FROM Contact_Info WHERE Phone_Num = '555-854-9885' 
OR Phone_Num = '555-748-7854' 

我們再來分析一下這種設(shè)計(jì)的強(qiáng)項(xiàng)和弱項(xiàng)。

無模式

SimpleDB也是無模式的，你不能創(chuàng)建、修改、升級或維護(hù)模式，這也是習(xí)慣了傳統(tǒng)關(guān)系數(shù)據(jù)庫的人難以理解的地方，但這正是SimpleDB可無限擴(kuò)展的關(guān)鍵之處，你可以按你喜好的模型存儲任意類型的屬性/值數(shù)據(jù)，存儲數(shù)據(jù)時無需擔(dān)心模式的變化。

我們在前面的基礎(chǔ)上再添加一個郵件地址字段，在傳統(tǒng)關(guān)系數(shù)據(jù)庫中，要么在聯(lián)系人信息表中增加一個字段，要么在電話表中增加一個字段，要么增加一個Email_Info表。

使用傳統(tǒng)的關(guān)系數(shù)據(jù)庫方法，我們需要連接三個表才能提取需要的數(shù)據(jù)。

SELECT First_Name, Last_Name, Phone_num, Person_Info.ID, Email_Addr  
FROM Person_Info JOIN Phone_Info JOIN Email_Info  
ON Person_Info.ID = Phone_Info.ID  
AND Person_Info.ID = Email_Info.ID  
WHERE Phone_Num = '555-854-9885' 

分析一下這種設(shè)計(jì)方法的強(qiáng)項(xiàng)和弱項(xiàng)。

我們忽略join和left outer join的區(qū)別，實(shí)際上這里應(yīng)該使用left outer join，除非所有聯(lián)系人只有一個電話號碼和郵件地址，這個例子只是為了證明必須修改Contact_Info模式。

可能你要問為什么Email_Addr沒有屬于它自己的列，在SimpleDB中，表是沒有列的概念的，SimpleDB數(shù)據(jù)的表格視圖只是為了增強(qiáng)可讀性而設(shè)計(jì)的，并非表現(xiàn)的是它的數(shù)據(jù)結(jié)構(gòu)，SimpleDB中唯一的結(jié)構(gòu)就是由項(xiàng)目名和屬性/值對組成的，下面是更恰當(dāng)?shù)腟impleDB數(shù)據(jù)結(jié)構(gòu)表現(xiàn)形式。

按郵件地址檢索聯(lián)系人的查詢語句如下：

SELECT * FROM Contact_Info WHERE Email_Addr = 'john@def.ccc' 

我們再來分析一下這種設(shè)計(jì)的強(qiáng)行和弱項(xiàng)。

#p#

更簡單的SQL

SQL在傳統(tǒng)關(guān)系數(shù)據(jù)庫中廣泛用于訪問和操作數(shù)據(jù)，經(jīng)過多年的發(fā)展，SQL已經(jīng)可以在數(shù)據(jù)庫上做很多事情了，SimpleDB不支持完整的SQL語言，相反，它使用與SQL類似的查詢語言檢索數(shù)據(jù)，但語句更加精煉和簡單，簡化了查詢數(shù)據(jù)的整個過程，它和傳統(tǒng)SQL的***不同就是SimpleDB支持的SQL支持SimpleDB的多值屬性，使得查詢更加簡單，特別是查詢多值屬性時更是如此。

SimpleDB SQL語法很簡單，總結(jié)如下：

select output_list  
from domain_name  
[where expression]  
[sort_instructions]  
[limit limit] 

只有字符串

SimpleDB使用非常簡單的數(shù)據(jù)模型，所有數(shù)據(jù)都存儲為UTF-8字符串，簡化了文本數(shù)據(jù)的存儲，SimpleDB可以更容易索引你的數(shù)據(jù)，使得檢索數(shù)據(jù)的速度更快，如果你需要存儲或檢索其它類型的數(shù)據(jù)，如數(shù)字和日期型數(shù)據(jù)，必須將這些數(shù)據(jù)編碼成字符串類型，由于SimpleDB沒有模式的概念，在存儲到SimpleDB之前，確保數(shù)據(jù)編碼的正確性就是開發(fā)人員的責(zé)任了。

只有字符串會在查詢和排序方面帶來的影響，仔細(xì)看一下下面的Sample_Qty表：

嘗試執(zhí)行下面的SQL語句：

SELECT * FROM Sample_Qty WHERE Quantity= '1' 

它不會返回任何結(jié)果，選擇按Quantity排序的所有記錄，返回的結(jié)果是101，102，103，105，104。日期問題就好解決了，可以將日期保存為ISO 8601格式。

最終一致性

SimpleDB可以被看作是一個寫少讀多的模型，更新只在中央數(shù)據(jù)庫上執(zhí)行，但讀可以在多個只讀從數(shù)據(jù)庫上執(zhí)行。

SimpleDB會在多個地方存儲每個域，無論是寫入還是更新域內(nèi)的數(shù)據(jù)，首先要向你的應(yīng)用程序返回一個成功狀態(tài)代碼，然后再更新所有數(shù)據(jù)副本，這些變化傳播到所有存儲節(jié)點(diǎn)可能需要一些時間，但最終所有節(jié)點(diǎn)上的數(shù)據(jù)都會保持一致性。

SimpleDB提供了最終一致性保證，這意味著從SimpleDB檢索的數(shù)據(jù)可能會因時間不同而有所不同，主要原因是SimpleDB是一個分布式系統(tǒng)，所有的信息是跨多個物理服務(wù)器存儲的，并有可能是跨多個數(shù)據(jù)中心的，這樣做可以保證有足夠的擴(kuò)展能力，也為數(shù)據(jù)安全提供充分的保障，但代價(jià)就是對數(shù)據(jù)的操作需要一定時間才能傳播到整個分布式SimpleDB系統(tǒng)，因此在最終一致前，檢索到的數(shù)據(jù)可能是過期的。

Amazon已經(jīng)聲明實(shí)現(xiàn)最終一致性現(xiàn)在已經(jīng)只需要數(shù)秒時間，但這個時間是與網(wǎng)絡(luò)，SimpleDB負(fù)載等因素緊密相關(guān)的，使用一個中間層緩存可以有效解決一致性問題，最終一致性也是SimpleDB與傳統(tǒng)RDBMS的重要不同點(diǎn)。為了實(shí)現(xiàn)大規(guī)模擴(kuò)展，在應(yīng)用程序設(shè)計(jì)時就要做出取舍。

雖然最終一致性是SimpleDB的常規(guī)模型，Amazon也推出了多個一致性讀取擴(kuò)展，使用GetAttributes或SELECT時，可以選擇ConsistentRead = true，強(qiáng)制讀取***的值，這個參數(shù)告訴SimpleDB直接從主數(shù)據(jù)庫讀取數(shù)據(jù)，而不是從從數(shù)據(jù)庫讀取數(shù)據(jù)。

此外，Amazon也發(fā)布了帶有條件的PUT和DELETE，只有當(dāng)一個特定屬性有一個特定的值或不存在某個特定的值時，才在數(shù)據(jù)庫上執(zhí)行PUT或DELETE。

擴(kuò)展性

關(guān)系數(shù)據(jù)庫是圍繞實(shí)體和實(shí)體之間的關(guān)系設(shè)計(jì)的，要提供高可擴(kuò)展性，在硬件上需要的投入很大，SimpleDB是圍繞數(shù)據(jù)分區(qū)設(shè)計(jì)的，將數(shù)據(jù)分布在多個節(jié)點(diǎn)上，天生就具有很好的擴(kuò)展能力，SimpleDB提供了數(shù)據(jù)自動分區(qū)和復(fù)制功能，同時保證了數(shù)據(jù)的快速訪問和可靠性，你可以按需擴(kuò)展Amazon提供給你的資源，應(yīng)付大規(guī)模訪問請求不再是問題。

SimpleDB擴(kuò)展性最吸引人的是它是按使用量付費(fèi)的。

低維護(hù)

維護(hù)傳統(tǒng)關(guān)系數(shù)據(jù)庫正常運(yùn)行是一個艱巨的任務(wù)，應(yīng)用程序是動態(tài)的，總是存在各種修改或增加新的功能，這些都可能導(dǎo)致需要修改數(shù)據(jù)庫模式，無疑增加了維護(hù)和調(diào)整成本，SimpleDB是由Amazon托管和維護(hù)的，你的任務(wù)就是存儲和檢索數(shù)據(jù)，簡化的數(shù)據(jù)結(jié)構(gòu)和無模式都有助于讓你的應(yīng)用程序更加靈活，適應(yīng)變化的能力更強(qiáng)，SimpleDB自動索引所有數(shù)據(jù)，確保你的查詢更快。

SimpleDB模型的優(yōu)點(diǎn)

與傳統(tǒng)關(guān)系數(shù)據(jù)庫相比，SimpleDB有以下優(yōu)點(diǎn)：

◆與關(guān)系數(shù)據(jù)庫相比，減少了維護(hù)工作量；

◆自動索引所有數(shù)據(jù)，提高查詢性能；

◆靈活修改存儲的數(shù)據(jù)，無需擔(dān)心模式的變化；

◆由Amazon提供自動的故障轉(zhuǎn)移能力；

◆跨多個節(jié)點(diǎn)復(fù)制你的數(shù)據(jù)，安全性有保障；

◆可無限擴(kuò)展，無需擔(dān)心硬件資源不夠用；

◆使用簡單的API簡化了數(shù)據(jù)存儲和查詢操作；

◆無傳統(tǒng)RDBMS中的對象-關(guān)系映射，允許你的結(jié)構(gòu)化數(shù)據(jù)直接映射到你的底層應(yīng)用程序代碼，減少應(yīng)用程序開發(fā)周期。

SimpleDB模型的缺點(diǎn)

當(dāng)然SimpleDB與傳統(tǒng)關(guān)系數(shù)據(jù)庫相比，它也是有缺點(diǎn)的：

◆那些需要數(shù)據(jù)立即一致性的應(yīng)用程序不能采用SimpleDB；

◆使用SimpleDB需要開發(fā)團(tuán)隊(duì)成員熟悉有別于RDBMS的存儲模型；

◆因?yàn)殛P(guān)系不象關(guān)系數(shù)據(jù)庫中定義的那么明確，需要在應(yīng)用程序代碼中實(shí)現(xiàn)對數(shù)據(jù)的約束；

◆如果你的應(yīng)用程序需要存儲非字符串?dāng)?shù)據(jù)類型的數(shù)據(jù)，存儲之前需要先編碼；

◆SimpleDB存儲多個屬性的方法需要習(xí)慣了RDBMS的開發(fā)人員適應(yīng)它。

原文名：Amazon SimpleDB versus RDBMS

【編輯推薦】

1. 用NoSQL來替代MySQL在Digg中的原因
2. MongoDB CEO談NoSQL的大數(shù)據(jù)量處理能力
3. 51CTO專訪蓋國強(qiáng)：NoSQL很火 但還需市場檢驗(yàn)
4. 詳解NoSQL數(shù)據(jù)庫使用實(shí)例
5. 云計(jì)算時代NoSQL當(dāng)?shù)?關(guān)系數(shù)據(jù)庫日薄西山