谢邀,先回答问题,我的理解——必须要掌握最佳实践。
什么是最佳实践——设计能够恰好的支撑你所做的业务,并且随着业务的演进,设计也能随之演进保障业务。所以你少要知道——你有多少数据(容量评估,是否需要Sharding,及分布策略)?这些数据怎么存?(Schema 怎么设计),怎么查?(SQL 及 Index的应用和优化),哪些东西放在数据库做合适,哪些不合适。这些算是最简单的要求了。下面稍微展开来多啰嗦两句:
单独抛开这一个具体问题不说,了解任何一个所不熟悉的领域首要问题是什么?“要清楚他问题域”,而不是先要知道他具体可以做什么,比如:小的汤勺可以用来炒菜,大的炒勺也可以用来喝汤。具体能做什么只是应用的Pattern,重要的是要了解本质。
好现在回到这个具体的问题上来,数据库的问题域是什么?我想不外乎以下几点,在将数据持久化的同时,还够最大限度的保证吞吐(并发,延时)和一致性(隔离,事务)。弄明白了问题域我们再来看,所要掌握的不外乎是以下几个问题数据怎么存,为什么要这么存,如何不丢数据?
数据怎么查?
数据怎么保证事务(与文件系统的最大区别,目前NewSQL解决的最重要的问题)?
从下往上看(仅限关系数据库),不说物理上的存储,最终落到磁盘上的存储模型是什么?B Tree 为什么用这个而不是链表?或者不是平衡二叉树?再往上来说,这个底层的存储模型如何被组织——table, table space, database 。还有数据库是如何保证数据不丢——WAL Log,一旦崩溃之后如何恢复?(checkpoint)。
知道了数据如何被存储的,那数据怎么被检索到就显而易见的了(树的搜索遍历算法),说到事务,事务的本质其实是并发和锁(一般的关系数据库的实现),锁的粒度关系到一致性的表现和性能,所以MVCC(朴素的理解为copyOnWrite)带来了性能上的提升,数据库的操作说白了就有两种,read write,所有发生的事情都是这些操作的组合(操作有先后,有时序),RR, RW, WR, WW,数据库的性能就是如何最大程度保证两类操作的并发性 。说了这么多,就算抛砖引玉,数据库是比较复杂的技术工程,水很深,要想彻底说清楚三言两语是不可能的。
如果真的想深入的了解数据库,不仅仅只是停留在应用层面,我想不外乎几个方面:并发控制,数据库日志系统恢复技术,查询调度以及优化(逻辑查询计划以及物理查询计划),如何保障高可用和高性能。希望能带来更多的思考。
以上