SQL到NoSQL的思维转变

标签: 转载文章 | 发表时间:2013-04-16 22:09 | 作者:人月神话
出处:http://blog.sina.com.cn/cmmi
本文链接地址:  http://www.nosqlnotes.net/archives/140

NOSQL系统一般都会宣传一个特性,那就是性能好,然后为什么呢?关系型数据库发展了这么多年,各种优化工作已经做得很深了,NOSQL系统一般都是吸收关系型数据库的技术,然后,到底是什么因素束缚了关系型数据库的性能呢?我们从系统设计的角度看这个问题。

1, 索引支持。关系型数据库创立之初没有想到今天的互联网应用对可扩展性提出如此高的要求,因此,设计时主要考虑的是简化用户的工作,SQL语言的产生促成数据库接口的标准化,从而形成了Oracle这样的数据库公司并带动了上下游产业链的发展。关系型数据库在单机存储引擎支持索引,比如Mysql的Innodb存储引擎需要支持索引,而NOSQL系统的单机存储引擎是纯粹的,只需要支持基于主键的随机读取和范围查询。NOSQL系统在系统层面提供对索引的支持,比如有一个用户表,主键为user_id,每个用户有很多属性,包括用户名,照片ID(photo_id),照片URL,在NOSQL系统中如果需要对photo_id建立索引,可以维护一张分布式表,表的主键为形成的二元组。关系型数据库由于需要在单机存储引擎层面支持索引,大大降低了系统的可扩展性,使得单机存储引擎的设计变得很复杂。

2, 事务并发处理。关系型数据库有一整套的关于事务并发处理的理论,比如锁的粒度是表级,页级还是行级,多版本并发控制机制MVCC,事务的隔离级别,死锁检测,回滚,等等。然而,互联网应用大多数的特点都是多读少些,比如读和写的比例是10 : 1,并且很少有复杂事务需求,因此,一般可以采用更为简单的copy-on-write技术:单线程写,多线程读,写的时候执行copy-on-write,写不影响读服务。NOSQL系统这样的假设简化了系统的设计,减少了很多操作的overhead,提高了性能。

3, 动态还是静态的数据结构。关系型数据库的存储引擎总是一颗磁盘B+树,为了提高性能,可能需要有insert buffer聚合写,query cache缓存读,经常需要实现类似Linux page cache的缓存管理机制。数据库中的读和写是互相影响的,写操作也因为时不时需要将数据flush到磁盘而性能不高。简而言之,关系型数据库存储引擎的数据结构是通用的动态更新的B+树,然而,在NOSQL系统中,比如Bigtable中采用SSTable + MemTable的数据结构,数据先写入到内存的MemTable,达到一定大小或者超过一定时间才会dump到磁盘生成SSTable文件,SSTable是只读的。如果说关系型数据库存储引擎的数据结构是一颗动态的B+树,那么SSTable就是一个排好序的有序数组。很明显,实现一个有序数组比实现一个动态B+树且包含复杂的并发控制机制要简单高效地多。

4, Join操作。关系型数据库需要在存储引擎层面支持Join,而NOSQL系统一般根据应用来决定Join实现的方式。举个例子,有两张表:用户表和商品表,每个用户下可能有若干个商品,用户表的主键为,用户和商品的关联属性存放在用户表中,商品表的主键为item_id,商品属性包括商品名,商品URL,等等。假设应用需要查询一个用户的所有商品并显示商品的详细信息,普通的做法是先从用户表查找指定用户的所有item_id,然后对每个item_id去商品表查询详细信息,即执行一次数据库Join操作,这必然带来了很多的磁盘随机读,并且由于Join带来的随机读的局部性不好,缓存的效果往往也是有限的。在NOSQL系统中,我们往往可以将用户表和商品表集成到一张宽表中,这样虽然冗余存储了商品的详细信息,却换来了查询的高效。

关系型数据库的性能瓶颈往往不在SQL语句解析上,而是在于需要支持完备的SQL特性。互联网公司面临的问题是应用对性能和可扩展性要求很高,并且DBA和开发工程师水平比较高,可以通过牺牲一些接口友好性来换取更好的性能。NOSQL系统的一些设计,比如通过宽表实现Join操作,互联网公司的DBA和开发工程师也做过,NOSQL系统只是加强了这种约束。从长远来看,可以总结一套约束集合,并且定义一个SQL子集,只需要支持这个SQL子集就可以在不牺牲可扩展性的前提下支持比如90%以上的互联网应用。我想,NOSQL技术发展到这一步的时候就算是比较成熟了,这也是我们最终想做的事情。我们在设计和使用NOSQL系统的时候也可以适当转化一下思维,如下:

1, 更大的数据量。很多人在使用Mysql的过程遇到记录条数超过一定值,比如2000W的时候,数据库性能开始下降,这个值的得出往往需要经过大量的测试。然而,大多数的NOSQL系统可扩展性都比较好,能够支持更大的数据量,因此也可以采用一些空间换时间的做法,比如通过宽表的方式实现Join。

2, 性能预估更加容易。关系型数据库由于复杂的并发控制,insert buffer及类似page cache的读写优化机制,性能估算相对较难,很多时候需要凭借经验或者经过测试才能得出系统的性能。然后,NOSQL系统由于存储引擎实现,并发控制机制等相对简单,可以通过硬件的性能指标在系统设计之处大致预估系统的性能,性能预估可操作性相对更强。

原文评论:

我个人感觉NoSQL是使用MySQL作为数据库的一个自然的演化..

1. 数据规模与访问规模不断的扩大的过程中,,业务必然会不断的牺牲掉表连接(Decouple),,以及不断的牺牲掉表上的很多复杂特性(ACID)(主要针对Web 应用).
2. 这样慢慢的数据就变成了单纯的基于主键的查询,,只不过可能是多个字段,,但是由于MySQL本身对于ddl的限制(或者说较弱的在线DDL处理能力), 后面就出现两个不同方向的演化.
a. 每条记录演化成简单的Key/Value/Timestamp. 也就是走KV Engine的道路来提高整个系统的可扩展性并降低复杂度.
b. 使得系统可以动态的增加新的列(no-schema,比如MongoDB,CouchDB,Cassandra,BigTable). 以把开发以及DBA从复杂的数据迁移/DDL中解放出来.
3. 由于数据之间的耦合性都去掉了,,后面使用Consistent Hash 以及其它的Replication,Failure Detector来解决解耦之后的业务数据就成为了新的话题..

以上这三步走完,,差不多就是我们现在看到的NoSQL的主要景象了.

  青春就应该这样绽放   游戏测试:三国时期谁是你最好的兄弟!!   你不得不信的星座秘密

相关 [sql nosql 思维] 推荐:

SQL到NoSQL的思维转变

- - 人月神话的BLOG
本文链接地址:  http://www.nosqlnotes.net/archives/140. NOSQL系统一般都会宣传一个特性,那就是性能好,然后为什么呢. 关系型数据库发展了这么多年,各种优化工作已经做得很深了,NOSQL系统一般都是吸收关系型数据库的技术,然后,到底是什么因素束缚了关系型数据库的性能呢.

NoSQL再次败北——我坚持使用SQL的原因

- - 外刊IT评论
【编者按】NoSQL拥有可扩展性和超高吞吐量的能力,然而这却没有发挥实际的优势,同时它不具备关系数据库所有的智能操作,虽然具有无模式存储的优势,却无形中增加了代码的复杂度. 更多的应用证明使用NoSQL如此困难,它仅能成为SQL系统的构件而不是替代品. 这是我第二次为新项目深入调研NoSQL,也是第二次决定放弃NoSQL.

排名前十的SQL和NoSQL数据库

- - 外刊IT评论
本排名根据 DB Engines的排行榜得来,该排行榜从人气上分析了市场上200个不同的数据库,这里一览Top 10. Oracle、MySQL及Microsoft SQL Server一直以绝对的优势霸占着排行榜的前三名,以独特的优势瓜分了市场上最多的用户. 许可机制:Proprietary. Oracle是重要商业项目的首选,同时也是市场上最古老的主流数据库产品.

一般认为NoSQL数据库在性能方面要优于传统的SQL数据库。但是有两个SQL的解…

- _li_ming_ - 《Ourlinux》杂志
一般认为NoSQL数据库在性能方面要优于传统的SQL数据库. 但是有两个SQL的解决方案宣布:对于大型系统的高可扩展性需求,SQL仍然是可行的解决方案. 这两个SQL解决方案分别是MySQL加NoSQL层插件和支持SQL的VoltDB数据库. Yoshinori Matsunobu是Sun/Oracle的前雇员,从事MySQL的研发工作,目前是DeNA的首席数据库和基础设施架构师,他以插件的方式为MySQL/InnoDB提供解决方案,可以在一台2.53GHZ、8核CPU、32G内存的Nehalem服务器上把每秒的查询数量(qps)提升到750,000以上.

Oracle MySQL Or NoSQL续

- - Sky.Jian 朝阳的天空
接前面一篇,这里再将之前在“中国系统架构师大会”5周年的时候发布的纪念册“IT架构实录”上的一篇文章发出来,也算是前面博文中PPT的一个文字版解读吧. Oracle,MySQL 还是 NoSQL. 随着阿里系的“去IOE”运动在社区的宣传声越来越大,国内正在掀起一股“去xxx”的技术潮. 不仅仅是互联网企业,包括运营商以及金融机构都已经开始加入到这个潮流之中.

NoSQL开篇——为什么要使用NoSQL

- Foxiang - 博客园新闻频道
  NoSQL在2010年风生水起,大大小小的Web站点在追求高性能高可靠性方面,不由自主都选择了NoSQL技术作为优先考虑的方面. 今年伊始,InfoQ中文站有幸邀请到凤凰网的孙立先生,为大家分享他之于NoSQL方面的经验和体会.   非常荣幸能受邀在InfoQ开辟这样一个关于NoSQL的专栏,InfoQ是我非常尊重的一家技术媒体,同时我也希望借助InfoQ,在国内推动NoSQL的发展,希望跟我一样有兴趣的朋友加入进来.

8种nosql对比

- - 谁主沉浮
虽然SQL数据库是非常有用的工具,但经历了15年的一支独秀之后垄断即将被打破. 这只是时间问题:被迫使用关系数据库,但最终发现不能适应需求的情况不胜枚举. 但是 NoSQL数据库之间的不同,远超过两 SQL数据库之间的差别. 这意味着软件架构师更应该在项目开始时就选择好一个适合的 NoSQL数据库.

Oracle 发布 NoSQL 数据库

- 冷月 - 博客园新闻频道
  Oracle 作为全球最大的关系型数据库提供商,在其产品链条中,也加入了 NoSQL 数据库这一环,而且这个新的数据库名字很霸气,就叫 NoSQL Database,想起了当年新浪微博更换 weibo.com 域名之时的一个笑话:. 原来有三家人做面包,张三家的面包叫三张牌面包,李四家的牌子叫李四牌面包,王五家出品的是王五牌面包,而突然有一天,张三家的面包改名了,叫面包牌面包.

NoSQL 数据建模技术

- - 博客 - 伯乐在线
全文译自墙外文章“ NoSQL Data Modeling Techniques”,译得不好,还请见谅. 这篇文章看完之后,你可能会对NoSQL的数据结构会有些感觉. 我的感觉是,关系型数据库想把一致性,完整性,索引,CRUD都干好,NoSQL只干某一种事,但是牺牲了很多别的东西. 总体来说,我觉得NoSQL更适合做Cache.

Nosql Redis ttserver Flare memcache比较

- - 小彰
随着互联网web2.0网站的兴起,非关系型的数据库现在成了一个极其热门的新领域,非关系数据库产品的发展非常迅速. 而传统的关系数据库在应付 web2.0网站,特别是超大规模和高并发的SNS类型的web2.0纯动态网站已经显得力不从心,暴露了很多难以克服的问题,例如:. 1、High performance - 对数据库高并发读写的需求.