Amazon SimpleDB到底比關系數據庫好在哪兒?
原創【51CTO獨家特稿】大家一定都使用過關系數據庫管理系統（RDBMS），可以說關系數據庫的身影無處不在，也有諸如Oracle，微軟，IBM等數據庫廠商為我們提供了大量的RDBMS產品，縱觀這幾十年，關系數據庫為應用程序的快速發展立下了汗馬功勞，但目前出現了一種由互聯網和社交網絡驅動的新型應用程序，這種應用程序需要充足的擴展能力，以滿足高峰時段大規模訪問和數據處理的要求。
這種應用場景很難使用傳統的關系數據庫滿足要求，因為它不可能為高峰時段提供足夠的硬件資源，如果非要在傳統關系數據庫上承載這類應用，維護工作量也是非常驚人的，并且宕機也是常事，SimpleDB可以解決這些問題，但為了解決這些問題，SimpleDB提出了一些新的設計理念，為了保證你在選擇數據庫時作出正確的抉擇，你應該了解這些新的設計理念。
無范式
范式化是關系數據庫有效組織數據的一個過程，其目的是消除冗余數據，同時確保數據依賴的意義，SimpleDB數據模型不遵守任何形式的范式，相反，它是完全反范式的，SimpleDB的無范式化允許你更靈活地處理你的數據模型，允許在你的數據中使用多值屬性。
我們先來看一個基礎的表格結構，然后分別用RDBMS和SimpleDB數據模型理念進行表結構設計，在這個例子中，我們創建一個簡單的聯系人數據庫。
| ID | First_Name | Last_Name | Phone_Num |
| 101 | John | Smith | 555-845-7854 |
| 101 | John | Smith | 555-854-9885 |
| 101 | John | Smith | 555-695-7485 |
| 102 | Bill | Jones | 555-748-7854 |
| 102 | Bill | Jones | 555-874-8654 |
添加新電話號碼的難易程度按照這種設計，要按電話號碼找一個人是很容易的。
- SELECT * FROM Contact_Info WHERE Phone_Num = '555-854-9885'
但最明顯的問題是名字有重復，這樣的表結構設計效率是很低的，下面分析一下這樣設計的強項和弱項。
| 分析項 | 強項 | 弱項 |
| 存儲效率 | 低 | |
| 按電話號碼檢索的效率 | 高 | |
| 按名字檢索的效率 | 低 | |
| 添加新電話號碼的難易程序 | 容易 |
這樣的設計很簡單，但名字重復了，因此在數據同步方面需要小心謹慎，如果名字未同步，按名字檢索電話號碼時，結果就不準確了。
為了改善這個設計，更合理地組織數據，一個辦法是象下面這樣創建多個電話號碼字段，雖然它通過一個簡單的方法解決了當前的問題，但它限制了最多只能容納三個電話號碼，如果還要增加郵件地址和Twitter賬號，表將會越來越大。
| ID | First_Name | Last_Name | Phone_Num | Phone_Num_2 | Phone_Num_3 |
| 101 | John | Smith | 555-845-7854 | 555-854-9885 | 555-695-7485 |
| 102 | Bill | Jones | 555-748-7854 | 555-874-8654 |
要按電話號碼找一個人是很恐怖的。
- 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'
我們再來分析一下這種數據庫結構設計的強項和弱項。
| 分析項 | 強項 | 弱項 |
| 存儲效率 | 高 | |
| 按電話號碼檢索的效率 | 高 | |
| 按名字檢索的效率 | 高 | |
| 添加新電話號碼的難易程序 | 容易 |
這種設計也很簡單，但電話號碼數量受到了限制，并且按電話號碼檢索會涉及到三個索引。
另一個辦法是使用一個字段存儲所有打電話號碼，用分隔符進行分割。
| ID | First_Name | Last_Name | Phone_Num |
| 101 | John | Smith | 555-845-7854;555-854-9885;555-695-7485 |
| 102 | Bill | Jones | 555-748-7854;555-874-8654 |
這種設計方法的優點是無重復，緊湊，簡潔，可維護性好，容易擴展，但要按電話號碼進行檢索只能使用子串模糊匹配，效率低下。
- SELECT * FROM Contact_Info WHERE Phone_Nums LIKE %555-854-9885%
這種SQL語句會強制執行全表掃描，如果是小表，不會有性能影響，但如果有上百萬行記錄，數據庫的性能將會受到嚴重影響。來看一下這種設計的強項和弱項。
| 分析項 | 強項 | 弱項 |
| 存儲效率 | 高 | |
| 按電話號碼檢索的效率 | 低 | |
| 按名字檢索的效率 | 高 | |
| 添加新電話號碼的難易程序 | 容易 |
為了遵守關系數據庫的范式，有時你必須將數據分解到多個獨立的表中，然后相互用鍵進行關聯，要從多個表中檢索數據，必須使用連接操作。
下面就重新對數據進行范式化設計，首先設計一個Person_Info表。
| ID | First_Name | Last_Name |
| 101 | John | Smith |
| 102 | Bill | Jones |
再設計一個Phone_Info表。
| ID | Phone_Num |
| 101 | 555-845-7854 |
| 101 | 555-854-9885 |
| 101 | 555-695-7485 |
| 102 | 555-748-7854 |
| 102 | 555-874-8654 |
現在連接Person_Info和Phone_Info表就可以檢索電話號碼，也可以檢索郵件地址，除了ID主鍵外，表結構很干凈，無重復數據，給Phone_Num字段加上索引，按電話號碼檢索聯系人的效率就很高了。
- 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'
再來分析一下這種設計的強項和弱項。
| 分析項 | 強項 | 弱項 |
| 存儲效率 | 高 | |
| 按電話號碼檢索的效率 | 高 | |
| 按名字檢索的效率 | 高 | |
| 添加新電話號碼的難易程序 | 容易 |
雖然這是一個高效的關系模型，但在SimpleDB中沒有連接命令，使用兩個表會強制實施全表掃描，下面我們就來看看如何使用SimpleDB的數據模型來實現。
#p#
無連接
SimpleDB不支持連接的概念，相反，它為一個屬性提供了存儲多值的功能，從而避免了檢索所有值需要的連接操作。
| ID | |||
| 101 | First_Name=John | Last_Name=Smith | Phone_Num =555-845-7854 Phone_Num =555-854-9885 Phone_Num =555-695-7485 |
| 102 | First_Name=Bill | Last_Name=Jones | Phone_Num =555-748-7854 Phone_Num =555-874-8654 |
在SimpleDB表中，每條記錄保存為一個屬性/值對形式的條目，這里的區別是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'
我們再來分析一下這種設計的強項和弱項。
| 分析項 | 強項 | 弱項 |
| 存儲效率 | 高 | |
| 按電話號碼檢索的效率 | 高 | |
| 按名字檢索的效率 | 高 | |
| 添加新電話號碼的難易程序 | 容易 |
無模式
SimpleDB也是無模式的，你不能創建、修改、升級或維護模式，這也是習慣了傳統關系數據庫的人難以理解的地方，但這正是SimpleDB可無限擴展的關鍵之處，你可以按你喜好的模型存儲任意類型的屬性/值數據，存儲數據時無需擔心模式的變化。
我們在前面的基礎上再添加一個郵件地址字段，在傳統關系數據庫中，要么在聯系人信息表中增加一個字段，要么在電話表中增加一個字段，要么增加一個Email_Info表。
| ID | Email_Addr |
| 101 | john@abc.ccc |
| 102 | bill@def.ccc |
使用傳統的關系數據庫方法，我們需要連接三個表才能提取需要的數據。
- 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'
分析一下這種設計方法的強項和弱項。
| 分析項 | 強項 | 弱項 |
| 存儲效率 | 高 | |
| 按電話號碼檢索的效率 | 高 | |
| 按名字檢索的效率 | 高 | |
| 添加新電話號碼的難易程序 | 容易 | |
| 可擴充能力 | 強 | 定義新表，需要兩個連接 |
我們忽略join和left outer join的區別，實際上這里應該使用left outer join，除非所有聯系人只有一個電話號碼和郵件地址，這個例子只是為了證明必須修改Contact_Info模式。
| ID | |||
| 101 | First_Name=John | Last_Name=Smith | Phone_Num =555-845-7854 Phone_Num =555-854-9885 Phone_Num =555-695-7485 Email_Addr =john@abc.ccc |
| 102 | First_Name=Bill | Last_Name=Jones |
Phone_Num =555-748-7854 Phone_Num =555-874-8654 Email_Addr =john@def.ccc |
可能你要問為什么Email_Addr沒有屬于它自己的列，在SimpleDB中，表是沒有列的概念的，SimpleDB數據的表格視圖只是為了增強可讀性而設計的，并非表現的是它的數據結構，SimpleDB中唯一的結構就是由項目名和屬性/值對組成的，下面是更恰當的SimpleDB數據結構表現形式。
| ID | Attribute/Value pairs |
| 101 |
First_Name=John Last_Name=Smith Phone_Num =555-845-7854 Phone_Num =555-854-9885 Phone_Num =555-695-7485 Email_Addr =john@abc.ccc |
| 102 |
First_Name=Bill Last_Name=Jones Phone_Num =555-748-7854 Phone_Num =555-874-8654Email_Addr =john@def.ccc |
按郵件地址檢索聯系人的查詢語句如下：
- SELECT * FROM Contact_Info WHERE Email_Addr = 'john@def.ccc'
我們再來分析一下這種設計的強行和弱項。
| 分析項 | 強項 | 弱項 |
| 存儲效率 | 高 | |
| 按電話號碼檢索的效率 | 高 | |
| 按名字檢索的效率 | 高 | |
| 添加新電話號碼的難易程序 | 容易 | |
| 可擴充能力 | 強 |
#p#
更簡單的SQL
SQL在傳統關系數據庫中廣泛用于訪問和操作數據，經過多年的發展，SQL已經可以在數據庫上做很多事情了，SimpleDB不支持完整的SQL語言，相反，它使用與SQL類似的查詢語言檢索數據，但語句更加精煉和簡單，簡化了查詢數據的整個過程，它和傳統SQL的***不同就是SimpleDB支持的SQL支持SimpleDB的多值屬性，使得查詢更加簡單，特別是查詢多值屬性時更是如此。
SimpleDB SQL語法很簡單，總結如下：
- select output_list
- from domain_name
- [where expression]
- [sort_instructions]
- [limit limit]
只有字符串
SimpleDB使用非常簡單的數據模型，所有數據都存儲為UTF-8字符串，簡化了文本數據的存儲，SimpleDB可以更容易索引你的數據，使得檢索數據的速度更快，如果你需要存儲或檢索其它類型的數據，如數字和日期型數據，必須將這些數據編碼成字符串類型，由于SimpleDB沒有模式的概念，在存儲到SimpleDB之前，確保數據編碼的正確性就是開發人員的責任了。
只有字符串會在查詢和排序方面帶來的影響，仔細看一下下面的Sample_Qty表：
| ID | |
| 101 | Quantity = 1.0 |
| 102 | Quantity = 1.00 |
| 103 | Quantity = 10 |
| 104 | Quantity = 25 |
| 105 | Quantity = 100 |
嘗試執行下面的SQL語句：
- SELECT * FROM Sample_Qty WHERE Quantity= '1'
它不會返回任何結果，選擇按Quantity排序的所有記錄，返回的結果是101，102，103，105，104。日期問題就好解決了，可以將日期保存為ISO 8601格式。
最終一致性
SimpleDB可以被看作是一個寫少讀多的模型，更新只在中央數據庫上執行，但讀可以在多個只讀從數據庫上執行。
SimpleDB會在多個地方存儲每個域，無論是寫入還是更新域內的數據，首先要向你的應用程序返回一個成功狀態代碼，然后再更新所有數據副本，這些變化傳播到所有存儲節點可能需要一些時間，但最終所有節點上的數據都會保持一致性。
SimpleDB提供了最終一致性保證，這意味著從SimpleDB檢索的數據可能會因時間不同而有所不同，主要原因是SimpleDB是一個分布式系統，所有的信息是跨多個物理服務器存儲的，并有可能是跨多個數據中心的，這樣做可以保證有足夠的擴展能力，也為數據安全提供充分的保障，但代價就是對數據的操作需要一定時間才能傳播到整個分布式SimpleDB系統，因此在最終一致前，檢索到的數據可能是過期的。
Amazon已經聲明實現最終一致性現在已經只需要數秒時間，但這個時間是與網絡，SimpleDB負載等因素緊密相關的，使用一個中間層緩存可以有效解決一致性問題，最終一致性也是SimpleDB與傳統RDBMS的重要不同點。為了實現大規模擴展，在應用程序設計時就要做出取舍。
雖然最終一致性是SimpleDB的常規模型，Amazon也推出了多個一致性讀取擴展，使用GetAttributes或SELECT時，可以選擇ConsistentRead = true，強制讀取***的值，這個參數告訴SimpleDB直接從主數據庫讀取數據，而不是從從數據庫讀取數據。
此外，Amazon也發布了帶有條件的PUT和DELETE，只有當一個特定屬性有一個特定的值或不存在某個特定的值時，才在數據庫上執行PUT或DELETE。
擴展性
關系數據庫是圍繞實體和實體之間的關系設計的，要提供高可擴展性，在硬件上需要的投入很大，SimpleDB是圍繞數據分區設計的，將數據分布在多個節點上，天生就具有很好的擴展能力，SimpleDB提供了數據自動分區和復制功能，同時保證了數據的快速訪問和可靠性，你可以按需擴展Amazon提供給你的資源，應付大規模訪問請求不再是問題。
SimpleDB擴展性最吸引人的是它是按使用量付費的。
低維護
維護傳統關系數據庫正常運行是一個艱巨的任務，應用程序是動態的，總是存在各種修改或增加新的功能，這些都可能導致需要修改數據庫模式，無疑增加了維護和調整成本，SimpleDB是由Amazon托管和維護的，你的任務就是存儲和檢索數據，簡化的數據結構和無模式都有助于讓你的應用程序更加靈活，適應變化的能力更強，SimpleDB自動索引所有數據，確保你的查詢更快。
SimpleDB模型的優點
與傳統關系數據庫相比，SimpleDB有以下優點：
◆與關系數據庫相比，減少了維護工作量；
◆自動索引所有數據，提高查詢性能；
◆靈活修改存儲的數據，無需擔心模式的變化；
◆由Amazon提供自動的故障轉移能力；
◆跨多個節點復制你的數據，安全性有保障；
◆可無限擴展，無需擔心硬件資源不夠用；
◆使用簡單的API簡化了數據存儲和查詢操作；
◆無傳統RDBMS中的對象-關系映射，允許你的結構化數據直接映射到你的底層應用程序代碼，減少應用程序開發周期。
SimpleDB模型的缺點
當然SimpleDB與傳統關系數據庫相比，它也是有缺點的：
◆那些需要數據立即一致性的應用程序不能采用SimpleDB；
◆使用SimpleDB需要開發團隊成員熟悉有別于RDBMS的存儲模型；
◆因為關系不象關系數據庫中定義的那么明確，需要在應用程序代碼中實現對數據的約束；
◆如果你的應用程序需要存儲非字符串數據類型的數據，存儲之前需要先編碼；
◆SimpleDB存儲多個屬性的方法需要習慣了RDBMS的開發人員適應它。
原文名：Amazon SimpleDB versus RDBMS
【編輯推薦】
