高性能架构模式

存储高性能

关系型数据库

读写分离
一主多从，一主一从
主从复制延迟解决方案
1.写操作后的读操作指定发给数据库主服务器
2.读从机失败后再读一次主机
3.关键业务读写操作全部指向主机，非关键业务采用读写分离

分库分表
业务分库
join操作问题，事务问题，成本问题(分库后还需要备份机)
单库可以支持10W用户量级的业务

分表
垂直拆分
引入的复杂性体现在表操作的数量要增量原来一次操作现在需要多次

水平拆分
单表超过5000W行就必须分表
分表后需要路由，某条数据具体属于哪个切分后的子表，常见路由算法
1.范围路由，1-1W放到A表，1W-2W放到B表，分段一般在100W-2000W之间
2.Hash路由，分布均匀，但扩充新表很麻烦需要重分布
3.配置路由，增加一个路由表，由user_id找到对应的table_id，但会多一次查询甚至可能成为瓶颈

join操作，查询多个表后在业务或中间件层做合并
count操作，多个表count相加，增加记录数表
oderby操作，分别查询每个子表再进行汇总排序

实现方式
程序代码封装，TDDL
中间件封装，mysql-proxy，MySQL Router，奇虎360的Atlas

 

NoSql

1. 关系型数据库存储的是行记录，无法存储数据结构
2. 关系数据库的schema扩展很不方便
3. 关系数据库再大数据场景下I/O较高
4. 关系数据库的全文搜索功能比较弱

常见的NoSQL方案有

• KV存储，解决关系数据库无法存储数据结构的问题，如Redis
• 文档数据库，解决关系数据库强schema约束的问题，如MongoDB
• 列式数据库，解决关系数据库大数据场景下的I/O问题，如HBase
• 全文搜索引擎，解决关系数据库的全文搜索性能问题，如ElasticSearch

 

K-V存储

Redis不支持完整的ACID事务，只能保证隔离性和一致性
Redis的RDB持久化会丢数据，AOF最好的aways也会丢一条数据

 

文档数据库

为了解决关系数据库schema带来的问题，文档数据库应用而生，其特点是no-schema
可以存储和读取任意的数据，目前大部分文档数据库的数据格式是JSON
优势
1.新增字段简单
2.历史数据不会出错
3.可以很容易存储复杂数据
文档数据库的特点适合电商和游戏业务，因为冰箱和笔记本电脑的属性差异非常大
文档数据库缺点是不支持事务，无法实现join操作
电商网站中，可以用关系数据库存储商品库存信息，订单基础信息，用文档数据库存储商品详细信息

 

列式数据库

列式数据库是按照列来存储数据的数据库，与之对应的传统关系数据库被称为行式数据库
优势
1.业务同时读取多个列时效果高，因为这些列都是按行存储在一起的，一次磁盘操作就可以读取出来
2.能够一次性完成对一行中的多个列的写操作，保证了针对行数据写操作的元咨询和一致性
行存储压缩比为3:1或5:1，列数据库压缩比率为8:1到30:1

全文搜索引擎

数据库的缺陷
全文搜素的条件可以随意排列组合，如果通过索引来满足，则索引数量会非常多
全文搜索的模糊匹配方式，索引无法满足，只能用like查询，而like查询是整表扫描效率低

基本原理
倒排索引，建立单词到文档的索引

与数据库结合
为了让全文搜索引擎支持关系型数据库的全文搜索，需要做一些转换操作，即将关系型数据库转换为文档数据
ElasticSearch是分布式的文档存储方式，它能存储和检索复杂的数据结构--序列化成为JSON文档，以实时的方式
在ElasticSearch中，每个字段的所有数据都是默认被索引的，即每个字段都有为了快速检索设置的专用倒排序，而且不像其他多数的数据库，它能在相同的查询中使用所有倒排索引，并以惊人的速度返回结果

转自https://blog.csdn.net/hixiaoxiaoniao/article/details/86742664