从需求出发看关系模型与非关系模型

Question

关系模型：简单来说，关系模型就是针对数据之间的"关系"进行的一种抽象。它将一切事物都抽象为关系，并通过集合运算的方式规定关系之间的运算过程，因此更为严谨。

层次模型：按照层次结构的形式组织数据库数据的数据模型，用树形结构来表示各类实体以及实体间的联系，是数据库系统最早出现的数据模型。

关系模型与层次模型的差别：关系模型存取路径对用户透明，不需要关心层次结构，只需要关注于核心的查询逻辑即可。

互联网之前

在web2.0蓬勃发展之前，使用数据库的主要应用场景是个大企业，金融机构在使用，他们面临的主要问题是：如何高效简单的满足用户的需求，并且能够随着用户需求的变化而快速的进行响应。而对业务量上面的要求却并不夸张，大部分情况下，每天数据库也只需要处理不算特别多的用户请求。此时关注的是开发效率。

数据库存储领域，以提升工作效率为首要目标进行设计的特性如下：

1. 关系模型，关系模型的主要目的是"隔离数据库的存储路径，让用户只关心查询的逻辑"。
2. 事务和一致性的原理和实现机制。
3. 约束。

需求：解决关系模型与前端业务开发模型不匹配问题。

方案：ORMapping转换，数据库层面支持（Oracle）

互联网时代

互联网行业的发展对数据存储提出的新要求：

1. 大量的用户
2. 单个用户的数据的价值非常低
3. 数据量比较大，部分数据增长较快
4. 用户的业务逻辑相对的比较简单

问题：互联网应用的实际需求与传统数据库之间出现了不匹配的情况。

解决方法

方案 1、 MySQL 切分

优点：数据库切分的最大优势，是对之前的架构冲击不大，因为切分逻辑是很简单可以写出来的，而既然之前能够接受mysql所提供的安全性标准，那么水平的扩展更多的mysql，安全性标准基本没有发生变化，不需要担心架构和人才出现不匹配的情况，该踩的坑都大部分都踩过，社区比较大，问题能够快速得到解决。

缺点： 1、最大的问题就是业务要做重构，原来在单个数据库时多条更新事务操作，在数据库切分后，不可能以单机事务那样的成本做到。 2、运维和管理难度上升，机器增多，故障率上升，扩容也成问题。 3、关系模型成了累赘，原来两个表的join，现在变成了两个库的join，延迟增加，性能降低。

方案 2、NoSQL

优点：这类产品的基本特征是，只实现了简单的key-value接口，主要关注于数据的自动运维，以及利用新的引擎实现来达到写的优化，从而降低成本。比较有特色的nosql系统是cassandra，hbase，mongodb等。

缺点：大部分情况下，开发效率比自动的数据运维重要的多，在这种情况下盲目的使用原始的层次模型接口来完成功能，可能会极大的降低生产效率。

方案 3、newSQL

主要思路：关系代数模型与扩展性无关，只需要做适当的权衡，将关系代数模型在分布式环境下进行重构。此领域比较有特色的想法是基于内存的数据库实现，他们假定未来的数据库主要依托于更大的内存和网络进行构建，这样，数据库就成功的规避了慢速磁盘设备对系统造成的影响，让延迟下降到可以接受的程度。比较具有代表性的是 voltdb，mysql cluster 等。