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

2023-11-29 22:42 由公众号-JavaEdge 发表于 #后端开发

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 配置并行度。

slave_parallel_type=LOGICAL_CLOCK(从 MySQL 8.0.26 开始为 replica_parallel_type)

MySQL 5.7开始可用。即使所有表都在同一逻辑数据库中，它也可以在副本上并行执行写。

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 发布！