Amazon SimpleDB到底比关系数据库好在哪儿?

原创
数据库 其他数据库
我们今天要讨论的是Amazon SimpleDB,到底这款数据库产品与之前我们熟悉的传统关系型数据库有什么区别?请听我们为您细细道来。

【51CTO独家特稿】大家一定都使用过关系数据库管理系统(RDBMS),可以说关系数据库的身影无处不在,也有诸如Oracle,微软,IBM等数据库厂商为我们提供了大量的RDBMS产品,纵观这几十年,关系数据库为应用程序的快速发展立下了汗马功劳,但目前出现了一种由互联网和社交网络驱动的新型应用程序,这种应用程序需要充足的扩展能力,以满足高峰时段大规模访问和数据处理的要求。

这种应用场景很难使用传统的关系数据库满足要求,因为它不可能为高峰时段提供足够的硬件资源,如果非要在传统关系数据库上承载这类应用,维护工作量也是非常惊人的,并且宕机也是常事,SimpleDB可以解决这些问题,但为了解决这些问题,SimpleDB提出了一些新的设计理念,为了保证你在选择数据库时作出正确的抉择,你应该了解这些新的设计理念。

[[12139]]

无范式

范式化是关系数据库有效组织数据的一个过程,其目的是消除冗余数据,同时确保数据依赖的意义,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

添加新电话号码的难易程度按照这种设计,要按电话号码找一个人是很容易的。

  1. 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  

要按电话号码找一个人是很恐怖的。

  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' 

我们再来分析一下这种数据库结构设计的强项和弱项。

分析项 强项 弱项
存储效率  
按电话号码检索的效率  
按名字检索的效率  
添加新电话号码的难易程序 容易  

这种设计也很简单,但电话号码数量受到了限制,并且按电话号码检索会涉及到三个索引。

另一个办法是使用一个字段存储所有打电话号码,用分隔符进行分割。

 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

这种设计方法的优点是无重复,紧凑,简洁,可维护性好,容易扩展,但要按电话号码进行检索只能使用子串模糊匹配,效率低下。

  1. 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字段加上索引,按电话号码检索联系人的效率就很高了。

  1. SELECT First_Name, Last_Name, Phone_num, Person_Info.ID  
  2. FROM Person_Info JOIN Phone_Info  
  3. ON Person_Info.ID = Phone_Info.ID  
  4. 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可以索引所有的值,因此检索任何一个值的效率都很高。

  1. SELECT * 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也是无模式的,你不能创建、修改、升级或维护模式,这也是习惯了传统关系数据库的人难以理解的地方,但这正是SimpleDB可无限扩展的关键之处,你可以按你喜好的模型存储任意类型的属性/值数据,存储数据时无需担心模式的变化。

我们在前面的基础上再添加一个邮件地址字段,在传统关系数据库中,要么在联系人信息表中增加一个字段,要么在电话表中增加一个字段,要么增加一个Email_Info表。

 ID Email_Addr
 101 john@abc.ccc
102 bill@def.ccc

使用传统的关系数据库方法,我们需要连接三个表才能提取需要的数据。

  1. SELECT First_Name, Last_Name, Phone_num, Person_Info.ID, Email_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的区别,实际上这里应该使用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-8654

Email_Addr =john@def.ccc

按邮件地址检索联系人的查询语句如下:

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

我们再来分析一下这种设计的强行和弱项。

分析项 强项 弱项
存储效率  
按电话号码检索的效率  
按名字检索的效率  
添加新电话号码的难易程序 容易  
可扩充能力  

#p#

更简单的SQL

SQL在传统关系数据库中广泛用于访问和操作数据,经过多年的发展,SQL已经可以在数据库上做很多事情了,SimpleDB不支持完整的SQL语言,相反,它使用与SQL类似的查询语言检索数据,但语句更加精炼和简单,简化了查询数据的整个过程,它和传统SQL的***不同就是SimpleDB支持的SQL支持SimpleDB的多值属性,使得查询更加简单,特别是查询多值属性时更是如此。

SimpleDB SQL语法很简单,总结如下:

  1. select output_list  
  2. from domain_name  
  3. [where expression]  
  4. [sort_instructions]  
  5. [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语句:

  1. 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

【编辑推荐】

  1. 用NoSQL来替代MySQL在Digg中的原因
  2. MongoDB CEO谈NoSQL的大数据量处理能力
  3. 51CTO专访盖国强:NoSQL很火 但还需市场检验
  4. 详解NoSQL数据库使用实例
  5. 云计算时代NoSQL当道 关系数据库日薄西山
责任编辑:彭凡 来源: 51CTO
相关推荐

2018-08-31 08:51:31

C 语言开发编程

2009-10-29 11:01:52

Amazon RDSMySQL关系数据库

2018-03-07 15:19:07

2022-02-25 10:03:11

对象数据算法

2015-01-08 14:52:29

google云计算分布式计算框架

2020-06-28 07:49:06

WiFi 6WiFi 5网络技术

2015-10-13 15:58:38

Javascript循环变量

2021-05-12 08:47:54

Go数组切片

2011-12-12 13:09:45

云计算

2019-07-23 16:00:36

区块链存储5G

2022-07-01 06:03:08

WiFi 7WiFi 6

2009-02-07 12:23:45

AmazonSimpleDB数据存储

2012-10-25 16:40:11

WOT高效数据中心数据中心

2014-04-17 10:16:50

2023-09-12 11:38:18

2013-12-04 09:33:15

软件成本

2015-08-27 13:45:25

2011-10-11 17:07:12

数据库Internet文件数据库

2012-10-26 15:50:02

Windows 8微软

2009-07-10 09:28:41

NoSQL关系数据库
点赞
收藏

51CTO技术栈公众号