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

关键词：互联网、关系型数据库 

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

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

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

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

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

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

　　能够看到，互联网应用与传统应用的异同点在于，互联网应用对于数据库的着重点在于从总体上进行把握，对数据的操做相对来讲比较“粗糙”。而传统应用因为其自身缘由，只须要考虑更为“精细化”的操做，例如连表查询，表与表的关系，关系表仍是实体表等等。 

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

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

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

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

　　但就算是互联网中，SQL语句并不是是不重要的，不要由于本身处在互联网，不熟悉SQL语句当作是一种“炫耀”，这是扎马步式的基本功。最简单的例子，若是不重要，像阿里同样的互联网公司，照样在研究关系型数据库（参见：阿里巴巴数据库内核月报： http://mysql.taobao.org/monthly/）。 

　　最后，《三体》一书中，智子锁死了人类的基础物理学，致使人类在科技面前彻底停滞。 

 

 

这是一个能给程序员加buff的公众号