NoSQL非关系型数据库的发展及应用初探

《NoSQL非关系型数据库的发展及应用初探》由会员上传分享，免费在线阅读，更多相关内容在行业资料-天天文库。

1、万方数据30福建电脑2010年第7期NoSQL非关系型数据库的发展及应用初探黄贤立(淮阴师范学院计算机科学与技术学院江苏淮安223300)【摘要】：随着Web2．0技术的发展，网络环境下的数据库应用出现了一些新的变化。NoSQL是在这种新变化之下产生的一种非关系型数据库产品的总称。文章分析了NoSQL的起源与发展。通过与传统关系型数据库产品的对比，指出了NoSQL的优缺点。讨论了其应用-gr-景-。【关键词】：NoSQL；数据库；并发；Key／VMuel、NoSQL的起源与发展NoSQL的发展最早可以追溯到19

2、91年BerkeleyDB第一版的发布。BerkelevDB是一个Key／ValRe(键，值)类型的Hush数据库。这种类型的数据库适用于数据类型相对简单，但需要极高的插入和读取速度的嵌人式场合『11。NoSQL得到真正的快速发展开始于2007年．从2007年到现在．先后出现了十多种比较流行的NoSQL产品．从2009年开始，国内的NoSOL领域也开始活跃起来，豆瓣的BeansDB，人人网的Nucbar开源NoSQL产品以及盛大创新院的TCDatabase纷纷发布。NoSQL能够得到快速的发展．其主要背景在于W

3、eb2．O技术在网络中的广泛应用。在Web2．0环境下，用户对于数据库高并发读写的需求、对海量数据的高效率存储和访问的需求、对数据库的高可扩展性和高可用性的需求等．都对传统关系型数据库带来很大的困难。典型的例子是北京奥运会的订票方案．由于最早实施的是网站、电话申请。先到先得的原则。在开始订票的当天．数以百万计的用户同时涌入奥运会官方票务网站。大量的并发请求使得该网站在短短几分钟内死机．一直到当天晚上才恢复工作。而北京奥组委不得不紧急调整了预售方式，改为在规定时间内申请．之后进行摇号的方式发售，这才解决了这一问题

4、。2、传统关系型数据库在Web2．O环境下存在的问题通过上述例子可以看出。传统的关系型数据库难以适合现在的Web2．0环境下可能出现的众多并发读写请求．特别是超大规模和高并发的SNS类型的Web2．0纯动态网站更是力不从心。可以看出．传统关系型数据库面临的挑战主要有以下几点ftl：(1)对数据库高并发读写的需求Web2．0网站要根据用户个性化信息来实时生成动态页面和提供动态信息．无法使用动态页面静态化技术．因此数据库的并发负载非常高．往往要达到每秒上万次的读写请求。此时的磁盘I，0根本无法承受如此之多的读写请求

5、。(2)对海量数据的高效率存储和访问的需求类似Facebook、Twitter和Ffiendfeed这样的SNS网站，每天用户产生海量的用户动态，以FfiendFeed为例，一个月就达到了2．5亿条用户动态．对于关系型数据库来说，在一张2．5亿条记录的表里面进行SQL查询，效率是极其低下的。再例如大型Web网站的用户登录系统，如腾讯、盛大。动辄数以亿计的帐号。关系数据库也难以应付。(3)对数据库的高扩展性和高可用性的需求在基于Web的架构中，数据库是最难进行横向扩展的．当用户量和访问量增加时．数据库没有办法像W

6、ebServer那样简单的通过添加更多的硬件和服务结点来扩展性能和负载能力．对于很多需要24小时不问断服务的网站来说．对数据库系统的升级和扩展往往需要停机维护．3、NoSQL和关系型数据库的区别珥(1)横向和纵向扩展能力关系型数据库通常部署在一台服务器上，通过增加处理器、内存和硬盘来升级。部署在多台服务器上的关系型数据库通过是依赖互相复制来保持数据同步。NoSQL数据库可以部署在单服务器上．但更多的部署是成云状分布。在NoSQL的模式一文中p1．作者详细介绍了NoSQL数据库的部署、数据分区、数据复制等问题的解

7、决方案。(2)列，ke3，／value存储．数组(Tuples)存储关系型数据库通常是由表或视图里的字段构成(固定的结构．用各种操作相互关联)。NoSQL数据库通常存储的是一对键值或数组(Tuples)，其结构不周定，只是一个有顺序的数据队列。(3)数据的内存和硬盘使用关系型数据库通常是驻留在一个硬盘内或一个网络存储空间里。SOL查询或存储过程操作会把数据集提取到内存空间里。一些(并不是全部)NoSQL数据库可以直接在硬盘上操作，也可以通过内存来加快速度。4、NoSQL存在的不足与传统的关系型数据库相比．NoS

8、QL非关系型数据库在Web2．0的高并发实时环境下有着一定的优势．但也存在着一些问题．主要体现在阁：(1)NoSQL很难实现数据的完整性由于在NoSQL项目中很难实现数据的完整性．而在企业应用中数据完整性又必不可少。因此，目前的NoSQL项目很难以企业中普及开来。需要注意的是，这一不足在Web2．0的很多应用中并不重要．因为很多Web实时系统并不要求严格的数据库事务．对读一致性要求很低