【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
【编辑推荐】
