1 万字长文高速你千万级并发架构下如何提高数据库存储性能，使用指南
...
数据库读写操作的性能问题
============
如果老板说公司准备在下个月搞一场运营活动，用户数量会快速增加，导致对数据库的读压力增加，假设在 4 核 8G 的机器上运 MySQL 5.7 时，大概可以支撑 500 的 TPS 和 10000 的 QPS，而实际的 QPS 可能是 10W，那怎么解决呢？
首先分析一下这个问题，在绝大部分面向用户的系统中，都是读多写少的模型，比如电商，大部分的时候是在搜索和浏览，比如抖音，大部分是在加载短视频，所以我们需要考虑的问题是，数据库如何扛住查询请求。一般的解决方法是读写分离，
所谓读写分离，就是把同一个数据库分离成两份，一份专门用来做事务操作，另一份专门用来做读操作，如图 2-3 所示。
图 2-3
做了主从复制之后，我们就可以在写入时只写主库，在读数据时只读从库，这样即使写请求会锁表或者锁记录，也不会影响到读请求的执行。同时呢，在读流量比较大的情况下，我们可以部署多个从库共同承担读流量，这就是所说的?一主多从?部署方式，在你的垂直电商项目中就可以通过这种方式来抵御较高的并发读流量。另外，从库也可以当成一个备库来使用，以避免主库故障导致数据丢失。
那么你可能会说，是不是我无限制地增加从库的数量就可以抵抗大量的并发呢？?实际上并不是的。因为随着从库数量增加，从库连接上来的 IO 线程比较多，主库也需要创建同样多的 log dump 线程来处理复制的请求，对于主库资源消耗比较高，同时受限于主库的网络带宽，所以在实际使用中，一般一个主库最多挂 3～5 个从库。
当然，主从复制也有一些缺陷，?除了带来了部署上的复杂度，还有就是会带来一定的主从同步的延迟，这种延迟有时候会对业务产生一定的影响
数据量增加带来的性能问题
============
随着业务的增长，数据库中的数据量也会随着增加，由于最早开发时主要是为了赶进度，数据都是单表存储，因此单表数据量增加之后，导致数据库的查询和写入都造成非常大的性能开销，具体体现在。
单表数据量过大，千万级别到上亿级别，这时即使你使用了索引，索引占用的空间也随着数据量的增长而增大，数据库就无法缓存全量的索引信息，那么就需要从磁盘上读取索引数据，就会影响到查询的性能。
数据量的增加也占据了磁盘的空间，数据库在备份和恢复的时间变长
不同模块的数据，比如用户数据和用户关系数据，全都存储在一个主库中，一旦主库发生故障，所有的模块儿都会受到影响
在 4 核 8G 的云服务器上对 MySQL5.7 做 Benchmark，大概可以支撑 500TPS 和 10000QPS，你可以看到数据库对于写入性能要弱于数据查询的能力，那么随着系统写入请求量的增长，对于写请求的耗时也会增加（更新数据操作需要同步更新索引，数据量较大的情况下更新索引耗时较长）
在这类场景中，解决方案就是对数据进行分片，也就是分库分表的机制，如图 2-4 所示。数据拆分的核心降低单表和单库的数据 IO 压力，从而提升对数据库相关操作的性能。
图 2-4
不同存储设备带来的性能提升
=============
前面我们了解了对于传统关系型数据库的一些优化思路，整体来说，通过优化之后能够提升程序访问数据库的计算性能。但是还是有一些情况，即便是优化之后，使用传统关系型数据库无法解决的，比如。
当数据量达到 TB 级别时，传统关系型数据库基本做了分库分表，单表数据量也是非常大的。
对于一些不适合用关系型数据库存储的数据，传统数据库无法做到，所以数据库本身的特性限制了多样性数据的管理。
所以 nosql 出现了，大家对 nosql 这个概念已经不陌生了，它是指不同于传统关系型数据库的其他数据库系统的一个统称，它不使用 SQL 作为查询语言，并且相对于传统关系型数据库来说，
它提供了更高的性能以及横向扩展能力，非常适合互联网项目中高并发且数据量较大的场景中，如图 25 所示，表示目前比较主流的不同类型的 nosql 数据库。
图 2-5 不同的 NoSql 数据库
这个网站上记录了所有的 Nosql 框架
https://hostingdata.co.uk/nosql-database/
Key-Value 数据库
============
key-value 数据库，典型的代表就是 Redis、Memcached，也是目前业内非常主流的 Nosq 数据库。
之所以在 IO 性能方面比传统关系型数据库高，有两个点
数据基于内存，读写效率高
KV 型数据，时间复杂度为 O(1)，查询速度快
KV 型 NoSql 最大的优点就是高性能，利用 Redis 自带的 BenchMark 做基准测试，TPS 可达达到接近 10W 的级别，性能非常强劲。同样的 Redis 也有所有 KV 型 NoSql 都有的比较明显的缺点：
查询方式单一，只有 KV 的方式，不支持条件查询，多条件查询唯一的做法就是数据冗余，但这会极大的浪费存储空间
内存是有限的，无法支持海量数据存储
同样的，由于 KV 型 NoSql 的存储是基于内存的，会有丢失数据的风险
基于 Key-Value 数据库的特性，这类数据库比较适用于缓存的场景。
读多写少
读取能力强
可以接受数据丢失
这类存储相比于传统的数据库的优势是极高的读写性能，一般对性能有比较高的要求的场景会使用，主要使用场景。
用来做分布式缓存，提升程序处理效率。
用来做会话数据存储
其他功能性特性，比如消息通信、分布式锁、布隆过滤器
微博的 feed 流，早期就是用了 redis 实现。（持续更新并呈现给用户内容的信息流。每个人的朋友圈，微博关注页等等都是一个 Feed 流）
列式数据库
=====
我们最早学习数据库，都是基于以二维表形式存储，每一行代表一条完整的数据。大部分传统的关系型数据库中，都是以行来存储数据。不过最近几年，列式存储也逐步被广泛运用在大数据框架中。
行存储和列存储，是数据库底层数据组织的形式的区别，如图 2-6 所示，数据库表中所有列一次排成一行，以行位单位存储，再配合 B+树或者 SS-Table 作为索引，就能快速通过主键找到相应的行数据。
图 2-6
在实际应用中，大部分的操作都是以实体（Entity）为单位，也就是大部分 CRUD 操作都是针对一整行记录，如果需要保存一行数据，只需要在原来的数据后追加一行数据即可，所以数据的写入非常快。
但是对于查询来说，一个典型的查询操作需要遍历整个表，分组、排序、聚合等，对于行存储来说，这样的操作的优势就不存在了，更惨的是，分析型 SQL 可能不需要用到所有的列，仅仅只需要对某些列进行运算即可，但是那一行中和本次操作无关的列也必须要参与到数据扫描中。
比如，如图 2-7 所示，现在我想统计所有文章的总的点赞数量，作为行存储的系统，数据库会怎么操作呢？
首先需要把所有行的数据加载到内存
然后对 like_num 列做 sum 操作
图 2-7
行式存储对于 OLAP 场景而言，优势就不存在了，所以就引入了列式存储。
OLTP（on-line transaction processing）翻译为联机事务处理， OLAP（On-Line Analytical Processing）翻译为联机分析处理，从字面上来看 OLTP 是做事务处理，OLAP 是做分析处理。从对数据库操作来看，OLTP 主要是对数据的增删改，OLAP 是对数据的查询
如图 2-8 所示，列式存储是将每一列数据组织在一起，它方便对于列的操作，比如前面说的统计 like_num 之和，按列存储之后只需要一次磁盘操作就可以完成三个数据的汇总，所以非常适合 OLAP 的场景。
当查询语句只涉及部分列时，只需要扫描相关列
每一列数据都是相同类型，彼此间的关联性更大，对列数据压缩的效率较高。
但是对于 OLTP 来说不是很友好，因为一行数据的写入需要修改多个列。
图 2-8
列式存储在大数据分析中使用非常多，比如推荐画像（蚂蚁金服的风控）、是空数据（滴滴打车的归集数据）、消息/订单（电信领域、银行领域）不少订单查询底层的存储。 Feeds 流（朋友圈类似的应用）等等。
图 2-9
文档型数据库
======
传统的数据库，所有信息会被分割成离散的数据字段，保存在关系型数据库中，甚至对于一些复杂的场景，还会分散在不同的表结构中。
举个例子，在一个技术论坛中，假设对于用户、文章、文章评论表的关系图如图 2-10 所示。
图 2-10
那用户点一篇文章，里面要显示该文章的创建者、文章详情、文章的评论，那么服务端要做什么呢？
查找文章详情
根据文章中的 uid 查找用户信息
查询该文章的所有评论列表
查询每个评论的创建者名字
这个过程要么就是多次数据库查询，要么就是使用一个复杂关联查询来检索，不管怎么做，都不是很方便。而文档数据库就可以解决这样的问题。
文档数据库是以文档单位，具体的文档形式有很多种，比如（XML、YAML、JSON、BSON）等，文档中存储具体的字段和值，应用可以使用这些字段进行查询和数据筛选。
一般情况下，文档中包含了实体中的全部数据，比如图 2-10 的结构，我们可以直接把一篇文章的基本要素信息构建成一个完整的文档保存到文档数据库中，应用程序只需要发起一次请求就可以获取所有数据。b
Article：{
Creator:{
uid: '',
username: ''
},
Topic: {
title: '',
content: ''
},
Reply: [
{
replyId:,
content:''
},
{
replyId:,
content:''
}
]
}
MongoDB 是目前最流行的 Nosql 数据库，它是一种面向集合、与模式（Schema Free）无关的文档型数据库。它的数据是以“集合”的方式进行分组，每个集合都有单独的名称并可以包含无线数量的文档，这种集合与关系型数据库中的表类似，唯一的区别就是它并没有任何明确的 schema。
在数据库中，schema（发音 “skee-muh” 或者“skee-mah”，中文叫模式）是数据库的组织和结构，schemas?和_schemata_都可以作为复数形式。模式中包含了 schema 对象，可以是表(table)、列(column)、数据类型(data type)、视图(view)、存储过程(stored procedures)、关系(relationships)、主键(primary key)、**外键(**foreign key)等。数据库模式可以用一个可视化的图来表示，它显示了数据库对象及其相互之间的关系
如图 2-11 所示， 将数据存储在类似 JSON 的灵活文档中，这意味着字段可能因具体文档而异，并且数据结构可能随着时间的推移而变化。
图 2-11
MongoDB 没有“数据一致性检查”、“事务”等，不适合存储对数据事务要求较高的场景，只适合放一些非关键性数据，常见应用场景如下：
使用 Mongodb 对应用日志进行记录
存储监控数据，比如应用的埋点信息，可以直接上报存储到 mongoDB 中
MongoDB 可以用来实现 O2O 快递应用，比如快递骑手、快递商家的信息存储在 MongoDB，然后通过 MongoDB 的地理位置查询，方便用来查询附近的商家、骑手等功能。
图形数据库
=====
图形数据库，表示以数据结构“图”作为存储的数据库。
图形数据存储管理两类信息：节点信息和边缘信息。 节点表示实体，边缘表示这些实体之间的关系。 节点和边缘都可以包含一些属性用于提供有关该节点或边缘的信息（类似于表中的列）。
边缘还可以包含一个方向用于指示关系的性质。
图形数据存储的用途是让应用程序有效执行需遍历节点和边缘网络的查询，以及分析实体之间的关系。 如图 2-12 所示，显示了已结构化为图形的组织人员数据。
实体为员工和部门，边缘指示隶属关系以及员工所在的部门。 在此图中，边缘上的箭头表示关系的方向。
图 2-12
使用此结构可以简单直接地执行类似于“查找 Sarah 的直接或间接下属”或“谁与 John 在同一个部门工作？”的查询。 对于包含大量实体和关系的大型图形，可以快速执行复杂的分析。 多个图形数据库提供一种可用于高效遍历关系网络的查询语言。比如：关系、地图、网络拓扑、交通路线等场景。
NewSql
======
NewSql 也是最近几年出来的概念，想必大家或多或少都有听过，NewSql 是 Nosql 发展之后的下一代数据存储方案。
前面我们了解了 Nosql 的优势。
高可用性和可扩展性，自动分区，轻松扩展
不保证强一致性，性能大幅提升
没有关系模型的限制，极其灵活
但是有些优势在某些场景下不是很适合，比如不保证强一致性，对于普通应用来说没有问题，但是对于一些金融级的企业应用来说，
强一致的需求会比较高。另外，Nosql 不支持 SQL 语句，不同的 Nosql 数据库都是有自己独立的 API 来进行数据操作，相对来说比较麻烦和复杂。
所以 NewSql 出现了，简单来说，newSQL 就是在传统关系型数据库上集成了 noSQL 强大的可扩展性，传统的 SQL 架构设计基因中是没有分布式的，而 newSQL 生于云时代，天生就是分布式架构。
NewSQL 的主要特性：
SQL 支持，支持复杂查询和大数据分析。
支持 ACID 事务，支持隔离级别。
弹性伸缩，扩容缩容对于业务层完全透明。
高可用，自动容灾
商用 NewSql
Spanner、F1：谷歌
OceanBase：阿里
TDSQL：腾讯
UDDB：UCloud
总结
==
在 NoSQL 数据库刚刚被应用时，它被认为是可以替代关系型数据库的银弹，在我看来，也许因为以下几个方面的原因：
弥补了传统数据库在性能方面的不足；
数据库变更方便，不需要更改原先的数据结构；
适合互联网项目常见的大数据量的场景；
不过，这种看法是个误区，因为慢慢地我们发现在业务开发的场景下还是需要利用 SQL 语句的强大的查询功能以及传统数据库事务和灵活的索引等功能，NoSQL 只能作为一些场景的补充。
使用 Redis 优化性能问题
=============
Redis 是目前用得非常多的一种 Key-Vlaue 数据库，我们先来通过一个压测数据了解一下 redis 和 mysql 的性能差距。
演示项目： springboot-redis-example
通过 jmeter 工具分别压测这个项目中的两个 url。
http://localhost:8080/city/{id}
http://localhost:8080/city/redis/{id}
其中，基于 mysql 访问的接口，吞吐量数据如下，qps=4735/s。
图 2-13
基于 redis 的压测数据，如图 2-14 所示。
评论