天天看点

数据库架构演进

来源于金松同学的资料分享整理,在此感谢。

一、单个数据库

数据库架构演进

1、最早单个数据库

2、单个数据库太大了、太乱了,要拆一下,分库分表,用阿里巴巴的mycat中间件来做 MYCAT 分库分表中间件

3、分库,有按照业务领域拆的,也有按照地域拆分的

二、分库分表

数据库架构演进

1、分表,把User表拆分成两张表,存入两个数据库

2、解决单数据库瓶颈问题

数据库架构演进

1、缺点是:交易里面有一个userId联系用户信息,还要有一个productId联系产品信息,在单个数据库里可以通过外键很方便的连接,但这里就不好做了。

2、这个只适合微服务

数据库架构演进

1、缺点是:华北的同学访问其他的数据库就比较慢甚至不能访问

2、因此需要有读写分离

三、读写分离

数据库架构演进

1、每个数据库都放相同的数据,包含所有领域和所有地区

2、但是我们总共有三个拷贝,不能全都支持读写,这样太复杂了

3、两个读,一个读写,这样“读”的性能就解决了

4、但“写”的问题还没解决

5、因此与区域相结合去解决“写”的问题

数据库架构演进

1、所有的数据库都能读,但是写只能就近写,写完之后再同步到其他数据库

2、数据库结构调整好了,但是访问还是慢怎么办?

3、因此需要加上缓存

四、加入缓存

数据库架构演进

1、80%的访问都在20%的数据上,著名的28原则,因此可将这些高频数据放入缓存。

2、缓存放在比如Redis,Memcached的集群里面

3、关系型数据库啥都好,就是慢,NoSQL缓存就是解决这个慢的问题

4、Memcached性能比Redis略强,但不支持持久化,Redis支持持久化,Redis还支持更多的数据结构

5、加入缓存变快了,但我们希望更快,因此开始考虑添加搜索引擎

五、加入搜索引擎

数据库架构演进

1、把业务数据做成搜索引擎的Document,让搜索引擎给索引起来,这样“读”起来更快

2、同样数据存在这么多地方,又是数据库、又是NoSQL集群,又是搜索引擎集群的。因此后台会运行Map-Reduce来进行数据分析和同步