Sql-Or-NoSql，看完这一篇你就懂了，mongodb缓存原理

这种结构也被成为自描述的结构。

以关系型数据库的方式做存储的架构演进

首先，我们看一下使用关系型数据库的方式，企业一个系统发展的几个阶段的架构演进（由于本文写的是Sql与NoSql，因此只以存储方式作为切入点，不会涉及类似MQ、ZK这些中间件内容）：

阶段一：企业刚发展的阶段，最简单，一个应用服务器配一个关系型数据库，每次读写数据库。

阶段二：无论是使用MySQL还是Oracle还是别的关系型数据库，数据库通常不会先成为性能瓶颈，通常随着企业规模的扩大，一台应用服务器扛不住上游过来的流量且一台应用服务器会产生单点故障的问题，因此加应用服务器并且在流量入口使用Nginx做一层负载均衡，保证把流量均匀打到应用服务器上。

阶段三：随着企业规模的继续扩大，此时由于读写都在同一个数据库上，数据库性能出现一定的瓶颈，此时简单地做一层读写分离，每次写主库，读备库，主备库之间通过binlog同步数据，就能很大程度上解决这个阶段的数据库性能问题

阶段四：企业发展越来越好了，业务越来越大了，做了读写分离数据库压力还是越来越大，这时候怎么办呢，一台数据库扛不住，那我们就分几台吧，做分库分表，对表做垂直拆分，对库做水平拆分。以扩数据库为例，扩出两台数据库，以一定的单号（例如交易单号），以一定的规则（例如取模），交

《一线大厂Java面试题解析+后端开发学习笔记+最新架构讲解视频+实战项目源码讲义》

【docs.qq.com/doc/DSmxTbFJ1cmN1R2dB】 完整内容开源分享

易单号对2取模为0的丢到数据库1去，交易单号对2取模为1的丢到数据库2去，通过这样的方式将写数据库的流量均分到两台数据库上。一般分库分表会使用Shard的方式，通过一个中间件，便于连接管理、数据监控且客户端无需感知数据库ip

关系型数据库的优点

上面的方式，看似可以解决问题（实际上确实也能解决很多问题），正常对关系型数据库做一下读写分离 + 分库分表，支撑个1W+的读写QPS还是问题不大的。但是受限于关系型数据库本身，这套架构方案依然有着明显的不足，下面对利用关系型数据库方式做存储的方案的优点先进行一下分析，后一部分再分析一下缺点，对某个技术的优缺点的充分理解是技术选型的前提。

• 易理解

因为行 + 列的二维表逻辑是非常贴近逻辑世界的一个概念，关系模型相对网状、层次等其他模型更加容易被理解

• 操作方便

通用的SQL语言使得操作关系型数据库非常方便，支持join等复杂查询

• 数据一致性

支持ACID特性，可以维护数据之间的一致性，这是使用数据库非常重要的一个理由之一，例如同银行转账，张三转给李四100元钱，张三扣100元，李四加100元，而且必须同时成功或者同时失败，否则就会造成用户的资损

• 数据稳定

数据持久化到磁盘，没有丢失数据风险，支持海量数据存储

• 服务稳定

最常用的关系型数据库产品MySql、Oracle服务器性能卓越，服务稳定，通常很少出现宕机异常

关系型数据库的缺点

紧接着的，我们看一下关系型数据库的缺点，也是比较明显的。

• 高并发下IO压力大

数据按行存储，即使只针对其中某一列进行运算，也会将整行数据从存储设备中读入内存，导致IO较高

• 为维护索引付出的代价大