学习SpringBoot：java高并发实战pdf

结构化数据、非结构化数据与半结构化数据

文章的开始，聊一下结构化数据、非结构化数据与半结构化数据，因为数据特点的不同，将在技术上直接影响存储引擎的选型。

首先是结构化数据，根据定义结构化数据指的是由二维表结构来逻辑表达和实现的数据，严格遵循数据格式与长度规范，也称作为行数据，特点为：数据以行为单位，一行数据表示一个实体的信息，每一行数据的属性是相同的。例如：

因此关系型数据库完美契合结构化数据的特点，关系型数据库也是关系型数据最主要的存储与管理引擎。

非结构化数据，指的是数据结构不规则或不完整，没有任何预定义的数据模型，不方便用二维逻辑表来表现的数据，例如办公文档（Word）、文本、图片、HTML、各类报表、视频音频等。

介于结构化与非结构化数据之间的数据就是半结构化数据了，它是结构化数据的一种形式，虽然不符合二维逻辑这种数据模型结构，但是包含相关标记，用来分割语义元素以及对记录和字段进行分层。常见的半结构化数据有XML和JSON，例如：

<person>
    <name>张三</name>
    <age>18</age>
    <phone>12345</phone>
</person>

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

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

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

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

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

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

阶段四：企业发展越来越好了，业务越来越大了，做了读写分离数据库压力还是越来越大，这时候怎么办呢，一台数据库扛不住，那我们就分几台吧，做分库分表，对表做垂直拆分，对库做水平拆分。以扩数据库为例，扩出两台数据库，以一定的单号（例如交易单号），以一定的规则（例如取模），交易单号对2取模为0的丢到数据库1去，交易单号对2取模为1的丢到数据库2去，通过这样的方式将写数据库的流量均分到两台数据库上。一般分库分表会使用Shard的方式，通过一个中间件，便于连接管理、数据监控且客户端无需感知数据库ip

关系型数据库的优点

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

• 易理解

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

• 操作方便

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

• 数据一致性

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

• 数据稳定

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

• 服务稳定

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

关系型数据库的缺点

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

• 高并发下IO压力大

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

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

为了提供丰富的查询能力，通常热点表都会有多个二级索引，一旦有了二级索引，数据的新增必然伴随着所有二级索引的新增，数据的更新也必然伴随着所有二级索引的更新，这不可避免地降低了关系型数据库的读写能力，且索引越多读写能力越差。有机会的话可以看一下自己公司的数据库，除了数据文件不可避免地占空间外，索引占的空间其实也并不少

• 为维护数据一致性付出的代价大

数据一致性是关系型数据库的核心，但是同样为了维护数据一致性的代价也是非常大的。我们都知道SQL标准为事务定义了不同的隔离级别，从低到高依次是读未提交、读已提交、可重复度、串行化，事务隔离级别月底，可能出现的并发异常越多，但是通常而言能提供的并发能力越强。那么为了保证事务一致性，数据库就需要提供并发控制与故障恢复两种技术，前者用于减少并发异常，后者可以在系统异常的时候保证事务与数据库状态不会被破坏。对于并发控制，其核心思想就是加锁，无论是乐观锁还是悲