1万字长文高速你千万级并发架构下如何提高数据库存储性能_并发模式下优化数据库

数据量增加带来的性能问题

============

随着业务的增长，数据库中的数据量也会随着增加，由于最早开发时主要是为了赶进度，数据都是单表存储，因此单表数据量增加之后，导致数据库的查询和写入都造成非常大的性能开销，具体体现在。

• 单表数据量过大，千万级别到上亿级别，这时即使你使用了索引，索引占用的空间也随着数据量的增长而增大，数据库就无法缓存全量的索引信息，那么就需要从磁盘上读取索引数据，就会影响到查询的性能。

• 数据量的增加也占据了磁盘的空间，数据库在备份和恢复的时间变长

• 不同模块的数据，比如用户数据和用户关系数据，全都存储在一个主库中，一旦主库发生故障，所有的模块儿都会受到影响

• 在 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所示。

图2-14

可以很明显的看到，在同样的程序中，Redis的QPS要比Mysql的多了1000。

了解Redis

=======

08年的时候有一个意大利西西里岛的小伙子，笔名antirez（http://invece.org/），创建了一个访客信息网站LLOOGG.COM。如果有自己做过网站的同学应该知道，

有的时候我们需要知道网站的访问情况，比如访客的IP、操作系统、浏览器、使用的搜索关键词、所在地区、访问的网页地址等等。在国内，有很多网站提供了这个功能，比如CNZZ，百度统计，国外也有谷歌的Google Analytics。

也就是说，我们不用自己写代码去实现这个功能，只需要在全局的footer里面嵌入一段JS代码就行了，当页面被访问的时候，就会自动把访客的信息发送到这些网站统计的服务器，然后我们登录后台就可以查看数据了。

LLOOGG.COM提供的就是这种功能，它可以查看最多10000条的最新浏览记录。这样的话，它需要为每一个网站创建一个列表（List），不同网站的访问记录进入到不同的列表。如果列表的长度超过了用户指定的长度，它需要把最早的记录删除（先进先出）。

图2-15

总结

面试难免让人焦虑不安。经历过的人都懂的。但是如果你提前预测面试官要问你的问题并想出得体的回答方式，就会容易很多。

此外，都说“面试造火箭，工作拧螺丝”，那对于准备面试的朋友，你只需懂一个字：刷！

给我刷刷刷刷，使劲儿刷刷刷刷刷！今天既是来谈面试的，那就必须得来整点面试真题，这不花了我整28天，做了份“Java一线大厂高岗面试题解析合集：JAVA基础-中级-高级面试+SSM框架+分布式+性能调优+微服务+并发编程+网络+设计模式+数据结构与算法等”

且除了单纯的刷题，也得需准备一本【JAVA进阶核心知识手册】：JVM、JAVA集合、JAVA多线程并发、JAVA基础、Spring 原理、微服务、Netty与RPC、网络、日志、Zookeeper、Kafka、RabbitMQ、Hbase、MongoDB、Cassandra、设计模式、负载均衡、数据库、一致性算法、JAVA算法、数据结构、加密算法、分布式缓存、Hadoop、Spark、Storm、YARN、机器学习、云计算，用来查漏补缺最好不过。

2-15

总结

面试难免让人焦虑不安。经历过的人都懂的。但是如果你提前预测面试官要问你的问题并想出得体的回答方式，就会容易很多。

此外，都说“面试造火箭，工作拧螺丝”，那对于准备面试的朋友，你只需懂一个字：刷！

给我刷刷刷刷，使劲儿刷刷刷刷刷！今天既是来谈面试的，那就必须得来整点面试真题，这不花了我整28天，做了份“Java一线大厂高岗面试题解析合集：JAVA基础-中级-高级面试+SSM框架+分布式+性能调优+微服务+并发编程+网络+设计模式+数据结构与算法等”

[外链图片转存中…(img-UC42zeK8-1716379494852)]

且除了单纯的刷题，也得需准备一本【JAVA进阶核心知识手册】：JVM、JAVA集合、JAVA多线程并发、JAVA基础、Spring 原理、微服务、Netty与RPC、网络、日志、Zookeeper、Kafka、RabbitMQ、Hbase、MongoDB、Cassandra、设计模式、负载均衡、数据库、一致性算法、JAVA算法、数据结构、加密算法、分布式缓存、Hadoop、Spark、Storm、YARN、机器学习、云计算，用来查漏补缺最好不过。

[外链图片转存中…(img-fvQjBlGh-1716379494852)]