NoSQL: 克服RDBMS的性能瓶颈
随着社交网或云计算的应用中出现的海量数据,分布式数据储存和处理成为大型网站的框架基础, 传统RDBMS越来越成为系统维持高性能高可用性的瓶颈。开发人员开始积极寻找 关系数据库本质上不适合解决的某些问题的替代品方案。
1998年第一次使用NoSQL来描述没有SQL的数据库。 2009年这个词重新成为热点,并在旧金山举办了NoSQL研讨会, 来“讨论如何推翻效率缓慢,开销昂贵的关系数据库的专政,发展更高效,更便宜的方法来管理数据” (计算机世界杂志)。谷歌的Bigtable和亚马逊的Dynamo对NoSQL影响深远,Bigtable 通常被称为列存储(如HyperTable,HBase),而Dynamo是键值存储的代表 。受Dynamo和Bigtable的影响,许多Web2.0初创公司放弃Oracle和MySQL而建立了自己的数据存储方式,以满足系统对海量数据的处理要求。比如Apache的开源软件Cassandra, 最初是Facebook为新的搜索功能而开发的,它在50G大型数据库上的写操作比MySQL快2500倍(参见[LM09])。 Twitter 和Digg 使用Cassandra存储数据。
主流RDBMS(IBM的DB2,微软的SQL Server 和甲骨文的Oracle)系统架构都可以追溯到上世纪70年代的R系统(R System)。而RDBMS的理论基础是Edgar F:Codd在1970年的论文”大型共享数据存储的关系模型“. 30多年来硬件特性 ,用户需求和数据库市场发生了巨大变化 。 在硬件方面, 处理器速度,内存和磁盘大小对程序的限制发生了根本改变。然而,硬盘和内存之间的带宽增量变化相对缓慢的多。 在用户需求和数据处理方面,许多新兴产业带来的新兴业务的性质不同于传统的银行和电子商务,对事务处理的要求也不一样。比如社交网站的数据没有很高的交易价值, 数据流巨大而且关联度低,、没有很高的数据完整性的需求。同时随着网络渗入到社会生活的各个角落,两类趋势越来越主导系统构架的要求, 1。持续增长的数据量(存储)2。在较短的时间内处理更大量的数据。 对这类可扩展性第一优先的系统而言,维护这类系统的可扩展性比实现更多的功能更为重要。
虽然RDBMS引入了许多改良的新功能,包括共享磁盘架构,支持用户定义的数据类型等等, 但是当今的关系数据库管理系统依然保留着系统R的系统特征(Michael Stonebraker): 比如以磁盘为主体的存储和索引结构,基于锁定的并发控制机制, 和基于日志的恢复机制。没有一种RDBMS发生革命性的变化来充分适应硬件特性 ,用户需求和数据市场的变化; RDBMS不再是解决数据层的唯一选择。
和传统RDBMS相比,NoSQL数据存储具有如下的几大优点:
-
避免数据处理中不必要的复杂度
关系数据库提供数据处理的各种功能和严格的数据一致性。但这种丰富的功能和实现,以及关系数据库管理系统的ACID属性,可能对特定的应用程序和使用情况并不需要。事实是,Facebook状态更新, 微博论坛的留言并不严格需要ACID。
-
高通量
一些NoSQL数据库比传统的RDBMS提供了更高的数据吞吐量。 关系数据库在数据读取上花费大量计算资源,严重影响了系统的可扩展性。相反,NoSQL数据库不提供或避免复杂的读操作。
-
横向扩展和低端硬件上运行
大多数的NoSQL数据库的设计很好地实现了水平扩展,而不是依赖于高端的硬件设置。 服务器的添加和删除不会造成分片的RDBMS集群上遇到的问题。实践和研究表明,低端设备的分布式存储可以比许多现有的高端数据库更可靠,是一种经济的可扩展性优先的数据库解决方案。
-
避免昂贵的ORM
ORM是昂贵的。EBay内部选择开发自己的ORM来提高整个系统的可扩展性。和RDBMS的数据结构相比,大多数NoSQL数据库的数据结构简单(如键/值存储或文档库), 或更接近某种面向对象的编程语言。因此NsSQL没有必要进行昂贵的对象 – 关系映射转换 。
-
避免刚性架构设计
语义Web (Semantic Web) / Web 3.0 将在更大的规模上推动半结构化数据(Semi-structured data)的应用。传统RDBMS不能有效处理半结构化数据。 现在很多成功的应用程序都连接到云服务器,因此,无论是开发桌面上或在Web上运行的应用程序,分布式存储是构架时必须考虑的选择。
NoSQL数据库在某种程度上解决了传统关系数据库面临的难题 1。向上扩展数据的陷阱 2。单台服务器的性能局限 3。刚性架构设计。但是NoSQL不是解决一切问题的灵丹妙药。NoSQL这个词本身就充满语义学上的歧义:NoSQL是理解成 “不是SQL“ 还是 ”对SQL说不“? 有的作者声称,从解决问题的范畴来看, NoSQL与SQL无关,应该被命名为类“NoACID”。NoSQL并不是新鲜事物, 非关系数据库的存储系统已经存在几十年。比如基于对象的数据库(Object Database),Lotus Notes也可以看作支持分布文档存储和复制功能的早期尝试。相对RDBMS而言, NoSQL作为一个数据管理平台还不是非常完善, 缺乏对即席查询和数据修复的支持,对导出数据的支持程度也各不相同。在性能与可扩展性方面,只有一部NoSQL数据库提供自动横向扩展的支持。
NoSQL 分类
分类 | NoSQL 数据库 |
Key-value Stores | Redis Scalaris Tokyo Tyrant Voldemort Memcache |
Document Stores | SimpleDB CouchDB MongoDB Terrastore PNUTS |
Extensible Record Stores | HBase BigTable HyperTable Cassandra PNUTS |
Table 2.2.: Classifications – Categorization by Ken North (cf. [Nor09]
| 性能 | 可扩展性 | 灵活性 | 复杂度 | 功能 |
键-值 库 | 高 | 高 | 高 | 无 | 不定(无) |
表列 库 | 高 | 高 | 中等 | 低 | 少量 |
文档库 | 高 | 不定(高) | 高 | 低 | 不定(低) |
图数据库 | 不定 | 不定 | 高 | 高 | 图论 |
关系数据库 | 不定 | 不定 | 低 | 中等 | 关系代数 |
NoSQL的发展比较快,功能和实现都有重叠,其分类的界限也相对模糊。按照NoSQL支持的数据模型,可以分为键-值库,文档库和可扩展记录库三类。键-值库数据结构简单,提供了高性能的可扩展性,在另一方面也限制了其应用。可扩展记录库提供了可变长的记录集,这些记录集可以通过多个节点在纵向和横向上进行划分(横向用主键划分,纵向分组在不同节点上)。文档存储类型中的文档是一个多重索引的对象模型,这种对象拥有可变长数量的属性,有些系统还允许对象进一步聚合成多重索引的域(domain )。这类系统支持基于多个属性约束的查询。
无论是简单的键-值模型还是文档,和RDBMS数据模型的最大区别是数据的自我封闭性(Self-Contained).数据本身就是语义上的一个完整独立的存在,不需要引用其他数据。这和关系数据库不同,RDBMS表格之间的关联性保证了复杂的数据操作的一致性。而对NoSQL而言, 数据的自我封闭性更好的支持数据的不变性(Immutability) 和信息的局域化(Local data is king), 进而在系统架构上更好的支持了系统的可用性和可扩展性。
同时, BigTable,Hadoop,SimpleDB , Memcached 和 CouchDB 等许多NoSQL只提供了基于关键词的查询。 这是系统设计上一个很重要的限制,保证了系统获得更高的性能,同时数据可以被分割到不同节点上而不影响查询功能。
转载于:https://blog.51cto.com/6927843/1172105