数据持久层

关系数据库

关系数据库是以关系模型为基数而建立的数据库，它最终可以通过二维表格的结构来表达。关系数据库有明确的 schema 关系以及对于事务的支持。保证了强一致性。

数据库范式

设计数据库，是有套路可循的。这些套路就叫做范式。

• 第一范式（1NF）：要求每个属性值都是不可再分的。
• 第二范式（2NF）：要求去除局部依赖。即表中的属性完全依赖于主键。
• 第三范式（3NF）：要求去除非主属性的传递依赖。即主属性必须直接依赖于主键，而不能传递依赖于主键。

一般按照这三个范式来设计就够了，再细分就有点过渡解耦了。这对于程序员的理解、数据模型的建立、联表操作的 IO 性能，都是不利的。

NoSQL

关系型数据库对一些量大且非结构化的数据，缺乏特别好的解决方法。更多的时候只能在传统关系数据库的基础上，使用数据库的 Sharding 和 Partition 这样的操作。

Web 2.0 时代的到来，产生了海量、不定结构、弱关联关系、高可用性和低一致性的数据特点，让关系数据库力不从心。而 NoSQL 则具有更好的横向扩展性、海量数据支持、已维护和廉价等优势。

关系书库云服务的崛起将传统的数据库管理工作自动化了。

针对上文所提到的数据问题，有两个层次的解决方案：

• 出现更适合业务的非关系数据库，如 NoSQL。
• 把关系数据库搬到云上，从而让企业从数据库管理工作中解脱出来。如 RDS。

NoSQL 数据库分类

• 键值数据库 Redis
• 列式数据库 Redshift
• 文档数据库 MongoDB
• 对象数据库 S3

对于数据来说，磁盘的读写本身，往往不是最慢的。最慢的是寻址操作。

数据库的演进趋势

从纵向提升单台设备的性能到横向提升设备的数量

NoSQL 技术往往具备很强的横向扩展能力。

趋势出现的原因：单台设备性能的提升是非常有限、且极其昂贵的。所以横向扩展更多设备成了更好的选择。

从结构化数据到非结构化数据

在关系数据库中，每一行数据都有严格的表结构定义，我们把这类数据叫做结构化数据。而这个确定的结构就是 schema。结构化的数据具备最佳的查询、检验和关联能力。
而在 NoSQL 数据库中，虽然数据也被分成了一列一列，但是列的数量、类似等是不固定的。我们可以把它们叫做半结构化的数据。
而在 S3 这类数据库中，数据就已经是非结构化数据了。

趋势出现的原因：虽然结构化数据容易使用简单直白的代码逻辑去处理，但是我们现实中遇到的绝大多数数据都是非结构化的。