架构学习（三）-关系型数据库、读写分离

一般架构可以大致分为三类，“高性能架构”，“高可用架构”和“高扩展架构”，其实也是刚好对应于评价一个架构的几种方式。

在讲存储之前，存储肯定会用到数据库，数据库有很多种类，但是大致可以分为关系数据库和非关系型数据库。

什么是关系型数据库？

简单来说，关系模型指的就是二维表格模型，而一个关系型数据库就是由二维表及其之间的联系所组成的一个数据组织。

关系模型中常用的概念：

关系：可以理解为一张二维表，每个关系都具有一个关系名，就是通常说的表名

元组：可以理解为二维表中的一行，在数据库中经常被称为记录

属性：可以理解为二维表中的一列，在数据库中经常被称为字段

域：属性的取值范围，也就是数据库中某一列的取值限制

关键字：一组可以唯一标识元组的属性，数据库中常称为主键，由一个或多个列组成

关系模式：指对关系的描述。其格式为：关系名(属性1，属性2， ... ... ，属性N)，在数据库中成为表结构

关系型数据库的优点：

容易理解：二维表结构是非常贴近逻辑世界的一个概念，关系模型相对网状、层次等其他模型来说更容易理解

使用方便：通用的SQL语言使得操作关系型数据库非常方便

易于维护：丰富的完整性(实体完整性、参照完整性和用户定义的完整性)大大减低了数据冗余和数据不一致的概率

关系型数据库的瓶颈？

高并发读写需求

网站的用户并发性非常高，往往达到每秒上万次读写请求，对于传统关系型数据库来说，硬盘I/O是一个很大的瓶颈

海量数据的高效率读写

网站每天产生的数据量是巨大的，对于关系型数据库来说，在一张包含海量数据的表中查询，效率是非常低的

高扩展性和可用性

在基于web的结构当中，数据库是最难进行横向扩展的，当一个应用系统的用户量和访问量与日俱增的时候，数据库却没有办法像web server和app server那样简单的通过添加更多的硬件和服务节点来扩展性能和负载能力。对于很多需要提供24小时不间断服务的网站来说，对数据库系统进行升级和扩展是非常痛苦的事情，往往需要停机维护和数据迁移。

对网站来说，关系型数据库的很多特性不再需要了：

事务一致性

关系型数据库在对事物一致性的维护中有很大的开销，而现在很多web2.0系统对事物的读写一致性都不高

读写实时性

对关系数据库来说，插入一条数据之后立刻查询，是肯定可以读出这条数据的，但是对于很多web应用来说，并不要求这么高的实时性，比如发一条消息之后，过几秒乃至十几秒之后才看到这条动态是完全可以接受的。

复杂SQL，特别是多表关联查询

任何大数据量的web系统，都非常忌讳多个大表的关联查询，以及复杂的数据分析类型的复杂SQL报表查询，特别是SNS类型的网站，从需求以及产品阶级角度，就避免了这种情况的产生。往往更多的只是单表的主键查询，以及单表的简单条件分页查询，SQL的功能极大的弱化了

什么是ACID?

ACID，指数据库事务正确执行的四个基本要素的缩写。包含：原子性（Atomicity）、一致性（Consistency）、隔离性（Isolation）、持久性（Durability）。一个支持事务（Transaction）的数据库，必须要具有这四种特性，否则在事务过程（Transaction processing）当中无法保证数据的正确性，交易过程极可能达不到交易方的要求。

什么是读写分离？

 

就是将原有的读写数据库服务器变成主从集群的形式，一个主机，好多台从机，主机只负责写，从机负责读。数据写到主机中之后，会逐渐复制到从机上。

采用这种操作的原因是，数据库的写操作很耗费时间，以oracle为例，写入10000条数据可能需要3分钟的时间，但是读10000条数据却只需要几秒钟。写的操作很大程度上影响了数据库的效率。

这种方式也会存在一定的问题，那就是复制会耗费一定的时间，少则几秒，多则几十秒，因此会存在，用户刚刚注册了一个账户，在另外一台机子上登录，会发现登不上了，就是因为还没有复制到从机上，针对这种情况也有一些处理办法：比如刚刚插入的一段时间内，只能在主机上读，或者是一些关键的业务，都放在主机上。

 

 

具体的实现方式，比较复杂，以后会慢慢学习。