顶级大厂Quora如何优化数据库性能?

2023-11-30 05:01

本文主要是介绍顶级大厂Quora如何优化数据库性能?,希望对大家解决编程问题提供一定的参考价值,需要的开发者们随着小编来一起学习吧!

Quora 的流量涉及大量阅读而非写入,一直致力于优化读和数据量而非写。

0 数据库负载的主要部分

  • 读取
  • 数据量
  • 写入

1 优化读取

1.1 不同类型的读需要不同优化

① 复杂查询,如连接、聚合等

在查询计数已成为问题的情况下,它们在另一个表中构建了计数,以便它们可以直接读取计数值而非计算计数。

② 大型扫描

他们使用 LIMIT 改变它或使用分页

③ 模式与查询之间不匹配

若:

  • 无很好的索引
  • 或索引没有足够的列
  • 或索引中的列顺序对查询来说不是最佳

则查询可能很慢,可能对数据库造成很大负载。

这种情况下,通常会修改索引以对查询进行优化。 有时查询也可修改以对索引进行优化。如:

  • 删除 select 子句中不必要的列(特别是索引中不存在的列)
  • 删除 order by 子句,改为在客户端上排序(MySQL CPU 一般比客户端 CPU 更宝贵)
  • 若该查询提供的功能不再重要,可完全删除查询

1.2 高 QPS 查询

即使使用了优化的 SQL 和良好的模式,高 QPS查询也给数据库带来很大负载。有时可能表示缓存效率低下(甚至没缓存)。

① 低效的缓存是否导致了高 QPS 查询?

缓存通常用于减少数据库 QPS。缓存键的选择可以极大地影响缓存的效率:

  • 若缓存键过于具体或狭窄,可能导致数据库出现高 QPS
  • 若缓存键太宽泛,每次查询都会从数据库中拉取大量数据
② 对用户语言表的查询

我们有一个表跟踪用户使用的语言信息。通常会查询数据库以查看用户 U 是否使用语言 L。使用(uid,language_id)作为缓存键看起来合理。如缓存未命中,将为该 uid 和 language_id 查询数据库表。

因此,将缓存键更改为仅使用 uid 确实有意义,缓存值将是有关用户使用的所有语言的信息。

以上述方式更改缓存键,会增加从库表中每次查询获取的数据量,但它将 QPS 减少超过 90%。大多数用户只使用一或几种语言。 因此,大多数情况,新的查询并没有拉取比以前更多的数据,这是一个显然的优化!

③ 查询 A2A(ask to answer)表

这里我们处理 3 个实体间的关系,即用户(谁提问或关注问题)、问题和回答者,这比 2 个实体之间的关系更不常见。

通常产品逻辑是查询:

  • 用户已请求过的所有回答者,使用缓存键 (question_id, user_id)
  • 请求过相同回答者回答一个问题的所有用户,使用缓存键 (question_id, answerer_id)

综上,A2A 表的 QPS 非常高,这意味着上述缓存效果并不明显。上述两个缓存都在使用 2 个实体作为缓存键question_id 和 user_id(可以是提问者或回答者)。

潜在缓存键数量巨大,因为它是问题数和用户数的乘积,其中只有很少的组合实际上在表中有数据。所以它可看作一个稀疏的数据集,有2维。

大多数问题的 A2A 请求数量相对较少,但有少数问题的 A2A 数量要多得多。因此,添加额外缓存,该缓存包含问题的 A2A,最多限制为 N 个,以便我们捕获大多数问题。 该缓存的键只是 question_id。 如缓存列表大小小于N,我们知道缓存是完整的。 否则,缓存不完整,我们不会使用缓存。

这额外缓存帮助显著减少 A2A 表上的 QPS(在 50% 到 66% 的范围内)。 还对产品逻辑进行了其他更改,以提高效率,但 QPS 的减少大部分来自额外缓存。

1.3 一维数据集中的稀疏数据

Quora 在缓存方面经常遇到的另一个问题是:稀疏一维数据集。如可能需要查询数据库,看某问题是否需重定向到另一问题(如同一个问题被重新发布,就可能发生这种情况)。

绝大多问题不需要重定向,所以 Quora 只会获取几个“重定向”,而大量“不重定向”。

当他们只是缓存了 question_id ,缓存中就会填满不用,只有几个重定向。 这在缓存中占用大量空间,且由于“重定向”数量如此稀疏,也会导致大量缓存未命中。

相反,他们开始缓存范围。 如 question id 123–127的任一问题都没重定向,那么他们会将该范围缓存为所有问题均为 No,而不是缓存每个单独的 question id。

这大大降低此类查询的数据库负载,QPS 下降 90%。

2 优化表占用空间

由于以下几个原因,表大小很重要:

  • 存储更多数据的成本更高
  • 随表增长,适应数据库缓冲池的数据百分比会变小,即IO会逐渐增加,性能会逐渐下降
  • 备份和恢复时间会随表大小线性增长。虽然备份是从 MySQL 副本完成的,但我们也会从副本读数据。在备份期间,MySQL副本性能略有下降
  • 随表增长,备份大小也在增长,导致备份存储成本随时间增长

显然,对不需要永久存储的数据,制定最佳保留策略有助减少表大小 —— 使用 MyRocks 减少表大小

  • 有一些表对于表所有者来说无法接受任何数据的删除。为此研究使用 MyRocks 来减小空间使用
  • MySQL 中的表可能使用更复杂的模式和查询。 所以他们希望谨慎使用 MyRocks。 作为分片项目的一部分,已对 MySQL 中最大的表进行分片,这是在 MySQL 在 Quora 的分片中记录
  • 此表是基于自增列范围进行分片的,与基于时间的分片接近,因为自增列值随时间增加
  • 大多数查询访问最近的分片。 包含 18 个月以上旧数据的较旧分片对日常业务相对不太关键

因此,他们决定按如下方式将较旧的分片移至 MyRocks。 有个工具可将 MySQL 表从一个 MySQL 主服务器移动到另一个主服务器。 每个分片实际上是一个 MySQL 表。 他们能够使用该工具按如下方式将包含旧数据的 MySQL 分片转换为 MyRocks 分片:

  • 在 MyRocks 主服务器上使用相同的模式创建一个新的空表,但使用 RocksDB 存储引擎
  • 使用该工具复制数据并从 MySQL 主服务器重放binlog(二进制日志)到 MyRocks 主服务器。 (该工具已被修改为跳过在目标主机上创建表,因为它已经在前一步中创建过。)
  • 执行阴影读取测试以验证 MyRocks 分片返回的结果与 MySQL 分片的结果相同。
  • 将流量切换到 MyRocks 分片。 (这类似于我们在将 MySQL 表从一个 MySQL 主服务器移动到另一个 MySQL 主服务器时执行的切换。 源主机上的表被重命名以停止新写入,然后在重放赶上后,该表的流量会切换到目标主机。)
  • 对于非键值存储表使用 MyRocks 是我们的一个重大举措。 根据表的不同,空间使用量的减少也有差异。 对于上面提到的第一个表,我们看到每个已移动的分片使用的空间减少了 80% 以上! 对于第二个表,我们看到每个已移动的分片使用的空间只减少了约 50-60%

3 优化写入

有时复制延迟警报,因为 MySQL复制默认情况下会在副本上串行重放主服务器上的并发写。在主服务器上并行写入而在副本上串行重放写入并不适合扩展写入,特别是如果他们使用带多核 CPU 的机器。

MySQL 提供两种方法实现这点,如下所述。两种方法中都需使用 slave_parallel_workers 配置并行度。

  1. slave_parallel_type=LOGICAL_CLOCK(从 MySQL 8.0.26 开始为 replica_parallel_type)
  • MySQL 5.7开始可用。即使所有表都在同一逻辑数据库中,它也可以在副本上并行执行写。
  1. slave_parallel_type=DATABASE(从 MySQL 8.0.26 开始为 replica_parallel_type)
  • 这需要表位于多个逻辑数据库中才能并行执行写
  • 增强存储在 zk 中的数据库配置,以跟踪表所在的逻辑数据库。将此信息保存在 zk 而非代码库或静态配置中,允许动态更改现有表的逻辑数据库。大多数表都位于默认逻辑数据库,因此只需要为不在默认逻辑数据库中的表保留此信息
  • MySQL alter table 语句可用于更改表的逻辑数据库,如 alter table <logical_db1>.table rename <logical_db2>.mytable。 它不复制数据,只是将底层 ibd 文件从一个目录移动到另一个目录,速度很快。移动表后,我们还会在 zk 更新数据库配置,以便应用程序可找到该表
  • 他们将一个表移动到其自己的逻辑数据库并启用并行复制。有助减少包含该表的 MySQL 副本上的复制延迟。

4 结论

学习了世界级大厂如何使用各种技术的组合来优化数据库中的读取、写入和空间使用。你们公司如何优化的呢?欢迎和我一起交流。

参考:

  • https://www.percona.com/blog/scaling-mysql-a-good-problem-to-have

    本文由博客一文多发平台 OpenWrite 发布!

这篇关于顶级大厂Quora如何优化数据库性能?的文章就介绍到这儿,希望我们推荐的文章对编程师们有所帮助!



http://www.chinasem.cn/article/435719

相关文章

MySQL索引的优化之LIKE模糊查询功能实现

《MySQL索引的优化之LIKE模糊查询功能实现》:本文主要介绍MySQL索引的优化之LIKE模糊查询功能实现,本文通过示例代码给大家介绍的非常详细,感兴趣的朋友一起看看吧... 目录一、前缀匹配优化二、后缀匹配优化三、中间匹配优化四、覆盖索引优化五、减少查询范围六、避免通配符开头七、使用外部搜索引擎八、分

数据库面试必备之MySQL中的乐观锁与悲观锁

《数据库面试必备之MySQL中的乐观锁与悲观锁》:本文主要介绍数据库面试必备之MySQL中乐观锁与悲观锁的相关资料,乐观锁适用于读多写少的场景,通过版本号检查避免冲突,而悲观锁适用于写多读少且对数... 目录一、引言二、乐观锁(一)原理(二)应用场景(三)示例代码三、悲观锁(一)原理(二)应用场景(三)示例

Node.js 数据库 CRUD 项目示例详解(完美解决方案)

《Node.js数据库CRUD项目示例详解(完美解决方案)》:本文主要介绍Node.js数据库CRUD项目示例详解(完美解决方案),本文给大家介绍的非常详细,对大家的学习或工作具有一定的参考... 目录项目结构1. 初始化项目2. 配置数据库连接 (config/db.js)3. 创建模型 (models/

Python通过模块化开发优化代码的技巧分享

《Python通过模块化开发优化代码的技巧分享》模块化开发就是把代码拆成一个个“零件”,该封装封装,该拆分拆分,下面小编就来和大家简单聊聊python如何用模块化开发进行代码优化吧... 目录什么是模块化开发如何拆分代码改进版:拆分成模块让模块更强大:使用 __init__.py你一定会遇到的问题模www.

Spring Security基于数据库的ABAC属性权限模型实战开发教程

《SpringSecurity基于数据库的ABAC属性权限模型实战开发教程》:本文主要介绍SpringSecurity基于数据库的ABAC属性权限模型实战开发教程,本文给大家介绍的非常详细,对大... 目录1. 前言2. 权限决策依据RBACABAC综合对比3. 数据库表结构说明4. 实战开始5. MyBA

SpringBoot首笔交易慢问题排查与优化方案

《SpringBoot首笔交易慢问题排查与优化方案》在我们的微服务项目中,遇到这样的问题:应用启动后,第一笔交易响应耗时高达4、5秒,而后续请求均能在毫秒级完成,这不仅触发监控告警,也极大影响了用户体... 目录问题背景排查步骤1. 日志分析2. 性能工具定位优化方案:提前预热各种资源1. Flowable

Ubuntu中远程连接Mysql数据库的详细图文教程

《Ubuntu中远程连接Mysql数据库的详细图文教程》Ubuntu是一个以桌面应用为主的Linux发行版操作系统,这篇文章主要为大家详细介绍了Ubuntu中远程连接Mysql数据库的详细图文教程,有... 目录1、版本2、检查有没有mysql2.1 查询是否安装了Mysql包2.2 查看Mysql版本2.

Oracle数据库常见字段类型大全以及超详细解析

《Oracle数据库常见字段类型大全以及超详细解析》在Oracle数据库中查询特定表的字段个数通常需要使用SQL语句来完成,:本文主要介绍Oracle数据库常见字段类型大全以及超详细解析,文中通过... 目录前言一、字符类型(Character)1、CHAR:定长字符数据类型2、VARCHAR2:变长字符数

Win11安装PostgreSQL数据库的两种方式详细步骤

《Win11安装PostgreSQL数据库的两种方式详细步骤》PostgreSQL是备受业界青睐的关系型数据库,尤其是在地理空间和移动领域,:本文主要介绍Win11安装PostgreSQL数据库的... 目录一、exe文件安装 (推荐)下载安装包1. 选择操作系统2. 跳转到EDB(PostgreSQL 的

SpringBoot3实现Gzip压缩优化的技术指南

《SpringBoot3实现Gzip压缩优化的技术指南》随着Web应用的用户量和数据量增加,网络带宽和页面加载速度逐渐成为瓶颈,为了减少数据传输量,提高用户体验,我们可以使用Gzip压缩HTTP响应,... 目录1、简述2、配置2.1 添加依赖2.2 配置 Gzip 压缩3、服务端应用4、前端应用4.1 N