《Amazon SimpleDB到底比关系数据库好在哪儿》由会员分享，可在线阅读，更多相关《Amazon SimpleDB到底比关系数据库好在哪儿（9页珍藏版）》请在金锄头文库上搜索。
1、Amazon SimpleDB 到底比关系数据库好在哪儿?(1)大家一定都使用过关系数据库管理系统（RDBMS），可以说关系数据库的身影无处不在，也有诸如 Oracle，微软，IBM 等数据库厂商为我们提供了大量的 RDBMS 产品，纵观这几十年，关系数据库为应用程序的快速发展立下了汗马功劳，但目前出现了一种由互联网和社交网络驱动的新型应用程序，这种应用程序需要充足的扩展能力，以满足高峰时段大规模访问和数据处理的要求。这种应用场景很难使用传统的关系数据库满足要求，因为它不可能为高峰时段提供足够的硬件资源，如果非要在传统关系数据库上承载这类应用，维护工作量也是非常惊人的，并且宕机也是常事，Sim
2、pleDB 可以解决这些问题，但为了解决这些问题，SimpleDB 提出了一些新的设计理念，为了保证你在选择数据库时作出正确的抉择，你应该了解这些新的设计理念。无范式范式化是关系数据库有效组织数据的一个过程，其目的是消除冗余数据，同时确保数据依赖的意义，SimpleDB 数据模型不遵守任何形式的范式，相反，它是完全反范式的，SimpleDB 的无范式化允许你更灵活地处理你的数据模型，允许在你的数据中使用多值属性。我们先来看一个基础的表格结构，然后分别用 RDBMS 和 SimpleDB 数据模型理念进行表结构设计，在这个例子中，我们创建一个简单的联系人数据库。ID First_Name Las
3、t_Name Phone_Num101 John Smith 555-845-7854101 John Smith 555-854-9885101 John Smith 555-695-7485102 Bill Jones 555-748-7854102 Bill Jones 555-874-8654添加新电话号码的难易程度按照这种设计，要按电话号码找一个人是很容易的。1. SELECT * FROM Contact_Info WHERE Phone_Num = 555-854-9885 但最明显的问题是名字有重复，这样的表结构设计效率是很低的，下面分析一下这样设计的强项和弱项。分析项 强项
4、弱项存储效率 低按电话号码检索的效率 高 按名字检索的效率 低添加新电话号码的难易程序 容易 这样的设计很简单，但名字重复了，因此在数据同步方面需要小心谨慎，如果名字未同步，按名字检索电话号码时，结果就不准确了。为了改善这个设计，更合理地组织数据，一个办法是象下面这样创建多个电话号码字段，虽然它通过一个简单的方法解决了当前的问题，但它限制了最多只能容纳三个电话号码，如果还要增加邮件地址和 Twitter 账号，表将会越来越大。ID First_Name Last_Name Phone_Num Phone_Num_2 Phone_Num_3101 John Smith 555-845-7854
5、555-854-9885 555-695-7485102 Bill Jones 555-748-7854 555-874-8654 要按电话号码找一个人是很恐怖的。1. SELECT * FROM Contact_Info WHERE Phone_Num_1 = 555-854-9885 2. OR Phone_Num_2 = 555-854-9885 3. OR Phone_Num_3 = 555-854-9885 我们再来分析一下这种数据库结构设计的强项和弱项。分析项 强项 弱项存储效率 高 按电话号码检索的效率 高 按名字检索的效率 高 添加新电话号码的难易程序 容易 这种设计也很简单，
6、但电话号码数量受到了限制，并且按电话号码检索会涉及到三个索引。另一个办法是使用一个字段存储所有打电话号码，用分隔符进行分割。 ID First_Name Last_Name Phone_Num101 John Smith 555-845-7854;555-854-9885;555-695-7485102 Bill Jones 555-748-7854;555-874-8654这种设计方法的优点是无重复，紧凑，简洁，可维护性好，容易扩展，但要按电话号码进行检索只能使用子串模糊匹配，效率低下。1. SELECT * FROM Contact_Info WHERE Phone_Nums LIKE %
7、555-854-9885% 这种 SQL 语句会强制执行全表扫描，如果是小表，不会有性能影响，但如果有上百万行记录，数据库的性能将会受到严重影响。来看一下这种设计的强项和弱项。分析项 强项 弱项存储效率 高 按电话号码检索的效率 低按名字检索的效率 高 添加新电话号码的难易程序 容易 为了遵守关系数据库的范式，有时你必须将数据分解到多个独立的表中，然后相互用键进行关联，要从多个表中检索数据，必须使用连接操作。下面就重新对数据进行范式化设计，首先设计一个 Person_Info 表。ID First_Name Last_Name101 John Smith102 Bill Jones再设计一个
8、Phone_Info 表。ID Phone_Num101 555-845-7854101 555-854-9885101 555-695-7485102 555-748-7854102 555-874-8654现在连接 Person_Info 和 Phone_Info 表就可以检索电话号码，也可以检索邮件地址，除了 ID 主键外，表结构很干净，无重复数据，给 Phone_Num 字段加上索引，按电话号码检索联系人的效率就很高了。1. SELECT First_Name, Last_Name, Phone_num, Person_Info.ID 2. FROM Person_Info JOIN
9、Phone_Info 3. ON Person_Info.ID = Phone_Info.ID 4. WHERE Phone_Num = 555-854-9885 再来分析一下这种设计的强项和弱项。分析项 强项 弱项存储效率 高 按电话号码检索的效率 高 按名字检索的效率 高 添加新电话号码的难易程序 容易 虽然这是一个高效的关系模型，但在 SimpleDB 中没有连接命令，使用两个表会强制实施全表扫描，下面我们就来看看如何使用 SimpleDB 的数据模型来实现。无连接SimpleDB 不支持连接的概念，相反，它为一个属性提供了存储多值的功能，从而避免了检索所有值需要的连接操作。ID 101
10、 First_Name=John Last_Name=SmithPhone_Num =555-845-7854 Phone_Num =555-854-9885 Phone_Num =555-695-7485102 First_Name=Bill Last_Name=Jones Phone_Num =555-748-7854 Phone_Num =555-874-8654在 SimpleDB 表中，每条记录保存为一个属性/值对形式的条目，这里的区别是Phone_Num 字段有多个值，和使用分隔符的字段不同，SimpleDB 可以索引所有的值，因此检索任何一个值的效率都很高。1. SELECT *
11、 FROM Contact_Info WHERE Phone_Num = 555-854-9885 SELECT 操作是非常高效的，甚至可以象下面这样多次使用 Phone_Num：1. SELECT * FROM Contact_Info WHERE Phone_Num = 555-854-9885 2. OR Phone_Num = 555-748-7854 我们再来分析一下这种设计的强项和弱项。分析项 强项 弱项存储效率 高 按电话号码检索的效率 高 按名字检索的效率 高 添加新电话号码的难易程序 容易 无模式SimpleDB 也是无模式的，你不能创建、修改、升级或维护模式，这也是习惯了传
12、统关系数据库的人难以理解的地方，但这正是 SimpleDB 可无限扩展的关键之处，你可以按你喜好的模型存储任意类型的属性/值数据，存储数据时无需担心模式的变化。我们在前面的基础上再添加一个邮件地址字段，在传统关系数据库中，要么在联系人信息表中增加一个字段，要么在电话表中增加一个字段，要么增加一个 Email_Info 表。ID Email_Addr101 johnabc.ccc102 billdef.ccc使用传统的关系数据库方法，我们需要连接三个表才能提取需要的数据。1. SELECT First_Name, Last_Name, Phone_num, Person_Info.ID, Ema
13、il_Addr 2. FROM Person_Info JOIN Phone_Info JOIN Email_Info 3. ON Person_Info.ID = Phone_Info.ID 4. AND Person_Info.ID = Email_Info.ID 5. WHERE Phone_Num = 555-854-9885 分析一下这种设计方法的强项和弱项。分析项 强项 弱项存储效率 高 按电话号码检索的效率 高 按名字检索的效率 高 添加新电话号码的难易程序 容易 可扩充能力 强 定义新表，需要两个 连接我们忽略 join 和 left outer join 的区别，实际上这里应
14、该使用 left outer join，除非所有联系人只有一个电话号码和邮件地址，这个例子只是为了证明必须修改 Contact_Info 模式。 ID 101 First_Name=John Last_Name=SmithPhone_Num =555-845-7854 Phone_Num =555-854-9885 Phone_Num =555-695-7485 Email_Addr =johnabc.ccc 102 First_Name=Bill Last_Name=JonesPhone_Num =555-748-7854Phone_Num =555-874-8654 Email_Addr
15、=johndef.ccc可能你要问为什么 Email_Addr 没有属于它自己的列，在 SimpleDB 中，表是没有列的概念的，SimpleDB 数据的表格视图只是为了增强可读性而设计的，并非表现的是它的数据结构，SimpleDB 中唯一的结构就是由项目名和属性/值对组成的，下面是更恰当的SimpleDB 数据结构表现形式。ID Attribute/Value pairs101First_Name=JohnLast_Name=Smith Phone_Num =555-845-7854 Phone_Num =555-854-9885 Phone_Num =555-695-7485 Email_
16、Addr =johnabc.ccc102First_Name=BillLast_Name=Jones Phone_Num =555-748-7854 Phone_Num =555-874-8654 Email_Addr =johndef.ccc按邮件地址检索联系人的查询语句如下：1. SELECT * FROM Contact_Info WHERE Email_Addr = johndef.ccc 我们再来分析一下这种设计的强行和弱项。分析项 强项 弱项存储效率 高 按电话号码检索的效率 高 按名字检索的效率 高 添加新电话号码的难易程序 容易 可扩充能力 强 更简单的 SQLSQL 在传统关系数据库中广泛用于访问和操作数据，经过多年的发展，SQL 已经可以在数据库上做很多事情了，SimpleDB 不支持完整的 SQL 语言，相反，它使用与 SQL 类似的查询语言
