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

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

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

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

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

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

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

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

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

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

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

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

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

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

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