【51CTO獨家特稿】大家一定都使用過關(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)用程序需要充足的擴展能力，以滿足高峰時段大規(guī)模訪問和數(shù)據(jù)處理的要求。

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

[[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ù)模型理念進行表結(jié)構(gòu)設(shè)計，在這個例子中，我們創(chuàng)建一個簡單的聯(lián)系人數(shù)據(jù)庫。

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

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

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

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

為了改善這個設(shè)計，更合理地組織數(shù)據(jù)，一個辦法是象下面這樣創(chuà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è)計的強項和弱項。

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

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

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

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

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

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

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

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

現(xiàn)在連接Person_Info和Phone_Info表就可以檢索電話號碼，也可以檢索郵件地址，除了ID主鍵外，表結(jié)構(gòu)很干凈，無重復數(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è)計的強項和弱項。

雖然這是一個高效的關(guān)系模型，但在SimpleDB中沒有連接命令，使用兩個表會強制實施全表掃描，下面我們就來看看如何使用SimpleDB的數(shù)據(jù)模型來實現(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è)計的強項和弱項。

無模式

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

我們在前面的基礎(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è)計方法的強項和弱項。

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

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

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

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

我們再來分析一下這種設(shè)計的強行和弱項。

#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ā)人員的責任了。

只有字符串會在查詢和排序方面帶來的影響，仔細看一下下面的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é)點可能需要一些時間，但最終所有節(jié)點上的數(shù)據(jù)都會保持一致性。

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

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

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

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

擴展性

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

SimpleDB擴展性最吸引人的是它是按使用量付費的。

低維護

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

SimpleDB模型的優(yōu)點

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

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

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

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

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

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

◆可無限擴展，無需擔心硬件資源不夠用；

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

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

SimpleDB模型的缺點

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

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

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

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

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

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

原文名：Amazon SimpleDB versus RDBMS

【編輯推薦】

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