在互联网中关系型数据库是否不再那么重要

关键词:互联网关系型数据库

  强调互联网,这是因为本文所讨论的前提是互联网应用。与“传统”应用不同,互联网中的应用每天面临的是海量的数据、大量的请求以及对系统可靠性和响应速度有着更高的要求。“传统”应用,我姑且浅显地认为是,数据量不大,面对的用户群范围相对较小,自然大量的高并发请求场景几乎不存在。

  在上文对互联网应用和传统应用有了一个大概的认识后,接下来我们来谈一谈,本文的主题关系型数据库在两种类型应用的不同使用方式,以及关系型数据在如今的互联网应用中是否不再是关注的焦点。

  首先,海量的数据。百万级甚至千万级亿级的数据已不可能存储在单一的数据表中,甚至不可能存储在一个数据库中。试想如果将所有的数据存储在单库单表中,一旦发生全表扫描,这对于系统响应速度来讲将是一个灾难。然而在传统应用中,可能单库单表已经足以适用。

  第二,由于产生了海量数据,进而数据在磁盘上的存储被设计成了“分库分表”的模式,利用某种特定的“路由”算法,定位一个数据所处的位置。正是因为“分库分表”的设计,使得关系型数据中的“联表查询”场景失效,所以在互联网应用中,一张表的设计已经几乎不再有“外键”,也就是联表查询几乎已消失。

  第三,大量的请求。这在互联网应用中比较常见,一起突发事件,一个明星的突发新闻,都会造成大量的请求瞬时到达。数据库的承载能力是有限的,一旦所有的访问量在某一时刻同时涌入,这直接会造成数据库宕机,整个系统甚至会因为数据库的原因造成服务不可用。所以在如今的互联网应用中,对数据的读取写入几乎已经不再直接操作数据库,而是在数据库前加入了一道“安全”屏障——缓存。

  第四,服务的可靠性。服务的可靠性,即使系统出现问题,也要保证部分可用,读写分离是一个很好的解决方案,读取和写入操作不再同一个数据库中进行,而是将他们分开。如果此时有大量写操作,要尽量不影响读操作,或者如果如果在写入数据库时造成数据库宕机,此时要尽量不能影响数据库的读操作。此时在互联网应用中通常就会部署一套“主从”数据库,主库写,从库读,这就会衍生出数据同步的问题,或者归纳为数据一致性问题。

  可以看到,互联网应用与传统应用的异同点在于,互联网应用对于数据库的着重点在于从整体上进行把握,对数据的操作相对来说比较“粗糙”。而传统应用由于其自身原因,只需要考虑更为“精细化”的操作,例如连表查询,表与表的关系,关系表还是实体表等等。

  这是否意味着,在互联网中关系型数据库已经不再那么重要了呢?那些课本上的第一范式、第二范式已经过时了呢?

  如果认为互联网中关系型数据库不再强调“精细化”的操作,就是已经过时了,这是一叶障目不见泰山。再总结一下,在互联网中,对于关系型数据库,我们需要设计分库分表、主从库、读写分离、热点数据缓存等等。在传统应用中,对于关系型数据库,我们需要设计出E-R图,需要设计主键、外键,需要写联表查询的SQL语句等等。

  再回顾一下,我们在大学的数据库课程中,在学习数据库时,是否是从第一范式、第二范式开始的?再逐步练习“一个学生学习了哪几门课程”、“一个学生每个课程的分数”、“某门课程按80分、90分以上分类”这类的SQL语句,因为这是基础,这是原理。

  那么回到本文的主题“在互联网中关系型数据库是否不再那么重要”,笔者的观点是,侧重点不同,互联网应用的很大,有的很大很大,有时需要你放弃遵循某些范式,从其他方面去弥补,而从整体上去思考如何进行数据建模,互联网应用更加考验的是“能力”,对数据建模的能力,如何构建更高的可靠性应用。传统应用,更加考验的是一切按照规矩来,“精细化”的操作,对SQL语句的熟悉程度就意味着对数据库的熟悉程度。

  但就算是互联网中,SQL语句并非是不重要的,不要因为自己处在互联网,不熟悉SQL语句当做是一种“炫耀”,这是扎马步式的基本功。最简单的例子,如果不重要,像阿里一样的互联网公司,照样在研究关系型数据库(参见:阿里巴巴数据库内核月报: http://mysql.taobao.org/monthly/)。

  最后,《三体》一书中,智子锁死了人类的基础物理学,导致人类在科技面前完全停滞。

本文参与腾讯云自媒体分享计划,欢迎正在阅读的你也加入,一起分享。

发表于

我来说两句

0 条评论
登录 后参与评论

扫码关注云+社区

领取腾讯云代金券