NoSQL和传统SQL数据库的比较

举报
fengfeng 发表于 2017/04/13 17:01:17 2017/04/13
【摘要】 NoSQL出现的目的就是为了解决高并发读写的问题,而高并发应用往往需要分布式的数据库来实现高性能和高可靠性,所以NoSQL的关键字就是concurrency和scalability。

NoSQL出现的目的就是为了解决高并发读写的问题,而高并发应用往往需要分布式的数据库来实现高性能和高可靠性,所以NoSQL的关键字就是concurrency和scalability。NoSQL(非关系式数据库)和传统SQL数据库的比较如下:

1、高并发读写:传统SQL数据库为了实现ACID(atomicity, consistency, isolation, durability),往往需要频繁应用文件锁,这使得其在现代的web2.0应用中越来越捉襟见肘。例如SNS网站每一个点击都是一条/多条查询,对数据库写的并发要求也非常高,而传统数据库无法很好地应对这种需求。SNS中大部分需求并不要求ACID,比如Like/Unlike投票等等。
web2.0网站要根据用户个性化信息来实时生成动态页面和提供动态信息,所以基本上无法仅仅使用动态页面静态化技术,因此数据库并发负载非常高,往往要达到每秒上万次读写请求。关系数据库应付上万次SQL查询还勉强顶得住,但是应付上万次SQL写数据请求,硬盘IO就已经无法承受了。例如对于普通的BBS网站,往往也存在对高并发写请求的需求,例如网站的实时统计在线用户状态,记录热门帖子的点击次数,投票计数等,因此这是一个相当普遍的需求。
NoSQL吸取了教训,比如有些NoSQL采用了eventually consistency的概念,延迟达到一致性,在没有Update操作一段时间后,数据库将最终是consistency的,显然这样的数据库将能更好的支持高并发读写。

2、高可扩展性:在基于web的架构当中,数据库是最难进行横向扩展的,当一个应用系统的用户量和访问量与日俱增的时候,你的数据库却没有办法像web server和app server那样简单的通过添加更多的硬件和服务节点来扩展性能和负载能力。对于很多需要提供24小时不间断服务的网站来说,对数据库系统进行升级和扩展是非常痛苦的事情,往往需要停机维护和数据迁移,为什么数据库不能通过不断的添加服务器节点来实现扩展呢?
其次,SQL数据库是基于schema的(schema:架构,包含表、视图、过程等),这对时时刻刻更新着的web2.0应用开发者来说是个噩梦:随时随地有新的应用出现,旧的数据库无法适应新的应用,只能不停地更新schema,或者做补丁表,如此一来要么schema越发混乱,要么就是数据库频繁升级而耗时耗力耗钱。
NoSQL一般就没有schema这种概念,大部分NoSQL都直接保存json类的Row,比如一个记录可以是{ id = 1, name = Bob, phone = 38492839 },这样扩展升级非常方便,比如需要地址信息直接加入 address=blahblah 即可。

3、处理海量数据(海量数据的高效率存储和访问):传统SQL很难进行分布式应用,即使可以也往往代价高昂。而NoSQL则很好地解决了这个问题:他们一般都直接从分布式系统中吸取了Map/Reduce方法,从而很容易就可以处理规模急速增加的问题。
类似Facebook,twitter,Friendfeed这样的SNS网站,每天用户产生海量的用户动态,以Friendfeed为例,一个月就达到了2.5亿条用户动态,对于关系数据库来说,在一张2.5亿条记录的表里面进行SQL查询,效率是极其低下乃至不可忍受的。再例如大型web网站的用户登录系统,例如腾讯,盛大,动辄数以亿计的帐号,关系数据库也很难应付。
Web网站对传统关系式DB的需求要求不同:
SQL并非适用于所有的程序代码,对于那些繁重的重复操作的数据,SQL值得花钱。但是当数据库结构非常简单时,SQL可能没有太大用处。关系数据库提供了无可比拟的功能集合,而且在数据完整性上也发挥绝对稳定,但是,企业的具体需求可能没有那么多。以Adobe的ConnectNow为例,当用户在线时它会不通过数据库而制作三份会话数据,在离线后删除。因此并不需要数据库,因为具体所需要的数据是在内存中的。

Web网站的减弱的关系式DB需求:
1、数据库事务一致性需求
很多web实时系统并不要求严格的数据库事务,对读一致性的要求很低,有些场合对写一致性要求也不高。因此数据库事务管理成了数据库高负载下一个沉重的负担。
2、数据库的写实时性和读实时性需求
对关系数据库来说,插入一条数据之后立刻查询,是肯定可以读出来这条数据的,但是对于很多web应用来说,并不要求这么高的实时性,比方说发一条消息之后,过几秒乃至十几秒之后,订阅者才看到这条动态是完全可以接受的。
3、对复杂的SQL查询,特别是多表关联查询的需求
任何大数据量的web系统,都非常忌讳多个大表的关联查询,以及复杂的数据分析类型的复杂SQL报表查询,特别是SNS类型的网站,从需求以及产品设计角度,就避免了这种情况的产生。往往更多的只是单表的主键查询,以及单表的简单条件分页查询,SQL的功能被极大的弱化了。

作者 |潘建颖

转载请注明出处:华为云博客 https://portal.hwclouds.com/blogs

【版权声明】本文为华为云社区用户原创内容,转载时必须标注文章的来源(华为云社区)、文章链接、文章作者等基本信息, 否则作者和本社区有权追究责任。如果您发现本社区中有涉嫌抄袭的内容,欢迎发送邮件进行举报,并提供相关证据,一经查实,本社区将立刻删除涉嫌侵权内容,举报邮箱: cloudbbs@huaweicloud.com
  • 点赞
  • 收藏
  • 关注作者

评论(0

0/1000
抱歉,系统识别当前为高风险访问,暂不支持该操作

全部回复

上滑加载中

设置昵称

在此一键设置昵称,即可参与社区互动!

*长度不超过10个汉字或20个英文字符,设置后3个月内不可修改。

*长度不超过10个汉字或20个英文字符,设置后3个月内不可修改。