湖北北大青鸟:一位男程序员写给老婆的计算机课程SQL vs NoSQL

　　湖北北大青鸟武汉宏鹏光谷校区：网上有很多计算机入门课程，下面是一位男程序员写给他老婆的计算机课程之SQL vs NoSQL，相信能够带给大家一些启发。

       男主角：Wuvist(新浪微博)，真名翁伟，自称胖程序员一个，幸好已婚。学习.NET出身，现常用Python做服务器端开发，曾任新加坡某创业公司主程。公司被Techcrunch blog过后，觉得新加坡生活太过安逸，终于在去年辞职只身回家乡汕头创业，活跃于珠三角技术沙龙，热衷于与其他技术宅分享。

　　女主角：Katze，Wuvist的老婆，女程序员，在某跨国投行任Unix系统管理员，常被Wuvist嘲笑技术太差。

　　在几乎所有的web应用中，数据库都是核心的一环。

　　Web应用往往都是“Database driven”，业务、数据都是由数据库完成，而前端页面是演示、修改数据的一个“壳”。因此很多web框架，都会标榜自己能够兼容多少多少数据库，做CRUD多么多么容易。一般上，提到数据库的时候，指的都是关系型数据库;但关系型数据库并非的一种数据库类型。关系型数据库，一开始便是设计为通用，并有ACID支持的。

　　Atomicity 原子性、 Consistency 一致性、Isolation 隔绝性、Durability 持久性

　　杀手欧阳盆栽说：“每件事都有它的代价”。上述四个特性，都是有代价的。对于严谨的商业应用，如银行、交易系统;为求业务的安，他们不得不，或者说，能够并且愿意付出这些代价。

　　回到12306，后端数据库传说使用的是Oracle，而站出来说吐槽12306的行家往往都会提到 redis \ mysql 这样的替代。有些菜鸟“ED”看到这些吐槽就出来喷了，说这些行家不懂神马业务安性的重要，这帮做互联网的弱爆了，票务是必须使用 Oracle才能搞定云云。好像还有人专门去喷了Fenng，这实在是太讽刺了。Fenng实际上是Orcale ACE Director http://www.hudong.com/wiki/%E5%86%AF%E5%A4%A7%E8%BE%89，国内屈指可数的Oracle。很多人，特别是弱“ED”、“教授”，沉寂在自己所在的领域，然后就以为“悟”了;实际上，是把自己变成了井底之蛙。

　　知识的广博、面性非常重要。在某个领域，通用的东西成熟之后，往往就会有专用的解决方案出现。而专用的解决方案多了之后，又会有新的通用解决方案出现。

　　天下大势，分久必合，合久必分。

　　计算机，早有很多专用系统，如王安打字机;个人电脑通用之后，这些专用设备就湮灭了;而iPad、手机的涌现，则又是专用系统。是的，传统上需要去购买 Orcale、DB2 等巨贵无比的数据库系统，去满足业务需求;不是因为它们把问题解决到了致，而是因为没有别的选择。时代已经变了，井底之蛙若把Oracle当成是王道，那只能被时代淘汰。关系型数据库作为通用解决方案，是非常非常好的;它是一把神刀。

　　但是，它有以下问题：

　　===== ED总是要写烂SQL ====

　　先. 还是那句话，有的人纵然神刀在手，亦无法成为刀中之神。关系型数据库提供的SQL能力，是高度抽象的，封装了无数层的。写SQL的人，太多太多根本不了解SQL背后所执行的事情;烂“ED”都是如此。

　　这甚至造就了一个职业：DBA。DBA去负责数据库微调、优化，听起来很，但实质上，就是给滥用SQL的“ED”擦屁股而已。

　　对于庞大的企业来说，管理者是知道大部分ED都弱爆了，他不期望也不需要ED去了解数据库，他只需要ED去完成基本的业务功能，然后让DBA去给ED擦屁股。

　　大部分的ED，并没有意识到这一点;他们拼命去追求方便快捷的“搞定”;滥用SQL的各种功能;甚至，他们把分享SQL的复杂使用当成是乐事。

　　ED所努力的，是把自己变笨，把活尽可能的都交给神奇的数据库去解决;数据库怎么解决的，他们不关心;这实质上，是在削弱自己工作的技术含量，自我贬值而已。

　　工程师如果能够把数据库给用好了，哪里还有DBA什么事?

　　DBA所谓的数据库优化，往往就是把工程师不负责任写下的2B SQL查询找出来，然后改写为文艺方式罢了。

　　不要滥用数据库，一点都不难。

　　===== 通用数据库性能有限 =====

　　其次，关系型数据库作为通用解决方案，它提供了太多的东西，它做了太多的事，而所有的事情，都有它的代价，直接而言，就是牺牲性能了。

　　所以，DBA的另一个职责，则是把数据库的各种参数调配好，让其能够发挥高的性能。

　　从这个意义上去说，DBA的工作就不是给ED擦屁股了。

　　但，这样的微调，是有限的。DBA拚了命去把鸡蛋竖立起来，考虑了桌面摩擦、空气流动、手指颤抖等等因素，鸡蛋虽然可以竖立一会，但终究还是会倒下去;这也就是微调的限。

　　在某些场景下，是可以用手的：把业务中没有用到的数据库功能都去掉;甚至，去掉完整的ACID支持。

　　这样一来，数据库的性能就可以有数量级的改善了。

　　===== 关键在于灵活性 ====

　　后，上面两点，其实都是跟性能相关的;关系型数据库即便作为通用方案，它的性能有限，但也能够满足绝大多数应用场景了。关系型数据库的软肋，是在灵活性上。

　　数据库有表、而表有结构;而表的结构，在应用上线之后，很难修改。

　　这同样造就了一些专业学问：严密的业务分析、设计数据库结构、如何在数据库上线之后修改结构等等。

　　这些问题或者说学问之所以存在，是植根于关系型数据库表结构不灵活的前提之上。

　　再次”Think out of the box“，如果数据库可以做到灵活、随时修改的表结构呢?

　　====== NoSQL ======

　　关系型数据库的三个问题，被NoSQL部解决了。

　　(同样的，所有事情都有它的代价;NoSQL在解决SQL固有问题的同时，也引入了新的问题;另一方面，NoSQL解决的也不是SQL的这三个问题。)

　　ED要写烂SQL?没有关系，彻底不让他们写SQL好了。

　　数据库支持功能太多?砍功能还不容易么?

　　Schema不灵活?那就schema-less好了。

　　目前，NoSQL的实现方案很多，MongoDB、Redis、Carssendra等等等等;每一个都可以非常不同，是专用解决方案：有自己独有的特性，去解决特定场景的特定问题。

　　(当然，像MongoDB，已经很有NoSQL通用解决方案的意味了。)

　　普通程序员用SQL，文艺程序员用NoSQL，2B程序员把NoSQL当SQL用。

　　普通程序员在从SQL切换去NoSQL时，会受固有的SQL知识限制，总有把NoSQL当成SQL去用的冲动，但这是非常2B的行为。

　　从微观的角度讲，原来SQL查询中所支持的各种神奇joining / groupby都不见了;拼命的想要去找在NoSQL数据库环境下同样的神奇工具。

　　这彻底违背了使用NoSQL的初衷：为了就是不让你滥用SQL的这些神奇功能。

　　滥用SQL会造成严重的性能问题，而在性能问题浮现之后，需要耗费更大的力气去纠正。

　　是的，信用卡透支购物很方便;但付账单的时候就傻逼了;所以，换成无法透支的借记卡。

　　固然没有了透支的便利，会有不方便，但彻底杜绝了还不起账单，被收取高额利息的问题。

　　要透支的便利?ED，请先去掌握好理财技能，彻底了解透支的影响，然后我们再来谈便利。

　　从宏观的角度讲，会有人企图去给NoSQL做封装，让NoSQL表现得跟SQL一样;甚至，去把NoSQL去掉的那些SQL功能加回去。

　　SQL已经是一个非常非常成熟的方案，它所能够解决的问题范畴里面，几乎没有办法做得比SQL更好。

　　在NoSQL的基础上，去试图模拟SQL，只能成为SQL的蹩脚模拟;还不如直接用回SQL。

　　在网路编程里面也有类似的例子，TCP跟UDP。可以把SQL看成是TCP，它是可靠、神奇的。UDP虽然不可靠，但是会比TCP更快。要做视频、语音通讯，UDP是更好的选择。但要去做“不丢包、不失帧”的可靠视频通讯，选择在UDP的基础上添加确认、重发机制模拟TCP，那就是2B了。不是天才，没法做得比TCP更好，直接用TCP就好。

        学习更多计算机技术，可以直接致电：17740513250   湖北北大青鸟武汉宏鹏光谷校区,祝你成功！