宅男程序员给老婆的计算机课程之4:SQL vs NoSQL

本文涉及的产品
云原生数据库 PolarDB PostgreSQL 版,标准版 2核4GB 50GB
云原生数据库 PolarDB MySQL 版,通用型 2核8GB 50GB
简介:

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

Wuvist

本文作者:Wuvist

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

【51CTO独家特稿】在几乎所有的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就好。

作业:
1. NoSQL的方案,如MongoDB还解决了SQL的什么问题?

2. NoSQL的应用场景有啥米?

51CTO系列:

  1. 宅男程序员给老婆的计算机课程之0:认清本质
  2. 宅男程序员给老婆的计算机课程之1:认清实际
  3. 宅男程序员给老婆的计算机课程之2:怎么看待牛人
  4. 宅男程序员给老婆的计算机课程之3:架构比较
  5. 宅男程序员给老婆的计算机课程之4:SQL vs NoSQL
  6. 宅男程序员给老婆的计算机课程之5:设计模式
  7. 宅男程序员给老婆的计算机课程之6:模版引擎
  8. 宅男程序员给老婆的计算机课程之7:运维的重要性
  9. 宅男程序员给老婆的计算机课程之8:控制器
  10. 宅男程序员给老婆的计算机课程之9:数据模型
  11. 宅男程序员给老婆的计算机课程之10:做,就对了!
  12. 宅男程序员给老婆的计算机课程之11:域模型

 

本文转自 Wuvist 51CTO博客,原文链接:http://blog.51cto.com/wuvist/847705



相关实践学习
使用PolarDB和ECS搭建门户网站
本场景主要介绍基于PolarDB和ECS实现搭建门户网站。
阿里云数据库产品家族及特性
阿里云智能数据库产品团队一直致力于不断健全产品体系,提升产品性能,打磨产品功能,从而帮助客户实现更加极致的弹性能力、具备更强的扩展能力、并利用云设施进一步降低企业成本。以云原生+分布式为核心技术抓手,打造以自研的在线事务型(OLTP)数据库Polar DB和在线分析型(OLAP)数据库Analytic DB为代表的新一代企业级云原生数据库产品体系, 结合NoSQL数据库、数据库生态工具、云原生智能化数据库管控平台,为阿里巴巴经济体以及各个行业的企业客户和开发者提供从公共云到混合云再到私有云的完整解决方案,提供基于云基础设施进行数据从处理、到存储、再到计算与分析的一体化解决方案。本节课带你了解阿里云数据库产品家族及特性。
相关文章
|
7月前
|
SQL 存储 NoSQL
SQL、NoSQL还是NewSQL
【7月更文挑战第5天】SQL、NoSQL还是NewSQL
120 1
|
4月前
|
SQL 存储 NoSQL
SQL和NoSQL数据库的全面比较
不可否认,已有越来越多开发人员愿意使用NoSQL数据库,并且在不断地壮大着其相应的社区。但是,相对于成熟的SQL社区,该领域的专家和顾问可能需要更多的时间,去解决那些未曾被记录的NoSQL问题。
148 0
|
4月前
|
SQL 监控 数据库
管理系统VS SQL:高效集成的关键技巧与方法
在现代企业信息化建设中,管理系统(如ERP、CRM等)与SQL数据库之间的紧密集成是确保数据流动顺畅、业务逻辑高效执行的关键
|
6月前
|
SQL NoSQL 数据库
开发效率与灵活性:SQL vs NoSQL
【8月更文第24天】随着大数据和实时应用的兴起,数据库技术也在不断发展以适应新的需求。传统的SQL(结构化查询语言)数据库因其成熟的数据管理机制而被广泛使用,而NoSQL(Not Only SQL)数据库则以其灵活性和扩展性赢得了众多开发者的青睐。本文将从开发者的视角出发,探讨这两种数据库类型的优缺点,并通过具体的代码示例来说明它们在实际开发中的应用。
158 1
|
7月前
|
SQL 存储 NoSQL
. NoSQL和SQL的区别、使用场景与选型比较
【7月更文挑战第30天】. NoSQL和SQL的区别、使用场景与选型比较
101 15
|
7月前
|
SQL 存储 设计模式
SQL与NoSQL的比较?
【7月更文挑战第30天】SQL与NoSQL的比较?
45 13
|
6月前
|
SQL 数据库 Java
HQL vs SQL:谁将统治数据库查询的未来?揭秘Hibernate的神秘力量!
【8月更文挑战第31天】Hibernate查询语言(HQL)是一种面向对象的查询语言,它模仿了SQL的语法,但操作对象为持久化类及其属性,而非数据库表和列。HQL具有类型安全、易于维护等优点,支持面向对象的高级特性,内置大量函数,可灵活处理查询结果。下面通过示例对比HQL与SQL,展示HQL在实际应用中的优势。例如,HQL查询“从员工表中筛选年龄大于30岁的员工”只需简单地表示为 `FROM Employee e WHERE e.age > 30`,而在SQL中则需明确指定表名和列名。此外,HQL在处理关联查询时也更为直观易懂。然而,对于某些复杂的数据库操作,SQL仍有其独特优势。
87 0
|
6月前
|
SQL 存储 NoSQL
从SQL到NoSQL:理解不同数据库类型的选择与应用——深入比较数据模型、扩展性、查询语言、一致性和适用场景,为数据存储提供全面决策指南
【8月更文挑战第31天】在信息技术飞速发展的今天,数据库的选择至关重要。传统的SQL数据库因其稳定的事务性和强大的查询能力被广泛应用,而NoSQL数据库则凭借其灵活性和水平扩展性受到关注。本文对比了两种数据库类型的特点,帮助开发者根据应用场景做出合理选择。SQL数据库遵循关系模型,适合处理结构化数据和复杂查询;NoSQL数据库支持多种数据模型,适用于非结构化或半结构化数据。SQL数据库在一致性方面表现优异,但扩展性较差;NoSQL数据库则设计之初便考虑了水平扩展性。SQL使用成熟的SQL语言,NoSQL的查询语言更为灵活。
133 0
|
6月前
|
SQL NoSQL 关系型数据库
性能与扩展性的考量:SQL vs NoSQL
【8月更文第24天】在选择数据库系统时,开发者和架构师面临着一个关键决策:是选择传统的SQL(结构化查询语言)数据库还是现代的NoSQL(非关系型)数据库。这两种类型各有优劣,尤其是在性能和扩展性方面。本文将深入探讨SQL和NoSQL数据库在这两个方面的差异,并通过具体的代码示例来展示它们各自的优势。
200 0
|
6月前
|
SQL 存储 NoSQL
数据模型与应用场景对比:SQL vs NoSQL
【8月更文第24天】随着大数据时代的到来,数据存储技术也在不断演进和发展。传统的SQL(Structured Query Language)数据库和新兴的NoSQL(Not Only SQL)数据库各有优势,在不同的应用场景中发挥着重要作用。本文将从数据模型的角度出发,对比分析SQL和NoSQL数据库的特点,并通过具体的代码示例来说明它们各自适用的场景。
149 0