CKB Explorer性能优化记录

[ShiningRay]

本周我进行了ckb explorer的服务器迁移工作。原本以为这个事情花不了多久，实际却出现了很多预想不到的情况，结果让我搞了好几天，每天都搞到凌晨。

首先，测试网ckb explorer数据库dump出来有250多G之巨，下载和导入便用了半天（6小时以上）的时间。
在部署了ckb explorer的服务器端应用并在线复核的时候，各种奇怪的性能问题便出现了。
比如区块同步进程启动之后几乎不跑。某些页面链接无法加载成功等等。
最初我认为是数据库服务器的配置不足，首先将数据库的配置和磁盘iops提升到了一个比较高的水平，然而问题依旧存在。
之后我将原有的sentry-raven gem升级到了最新的sentry-rails，新版本的sentry支持性能统计，可以分析出很多东西。
同时我也在访问了一些页面，并且观察rails的日志，发现有些请求的处理时间长达十几分钟，甚至个别超过了1个小时。经过sentry的数据收集之后，发现大量的时间花费在了一些数据库的查询上。
这时候定位就越来越清晰了，是因为数据库表过大，一些查询未能有效使用索引产生了一些不恰当的扫描导致时间过程。

我从Sentry中找到了几个较慢的事务： Api::V1::BlockTransactionsController#show 和 Api::V1::AddressTransactionsController#show 以及在NodeProcessor 的同步进程，从其中分别找出了有

SELECT "ckb_transactions"."id", "ckb_transactions"."tx_hash", "ckb_transactions"."block_id", "ckb_transactions"."block_number", "ckb_transactions"."block_timestamp", "ckb_transactions"."is_cellbase", "ckb_transactions"."updated_at", "ckb_transactions"."updated_at" AS collection_cache_key_timestamp FROM "ckb_transactions" WHERE "ckb_transactions"."block_id" = $1 ORDER BY "ckb_transactions"."id" ASC LIMIT $2 OFFSET $3

和

SELECT "cell_outputs"."id", "cell_outputs"."address_id", "cell_outputs"."type_hash", "cell_outputs"."cell_type", "cell_outputs"."type_script_id" FROM "cell_outputs" WHERE "cell_outputs"."block_id" = 5085591 AND "cell_outputs"."cell_type" IN (3, 6, 7) ORDER BY "cell_outputs"."id" ASC

等非常缓慢的 SQL 查询。

这些长时间的查询集中在 ckb_transactions 表和 cell_outputs 表，这两个表分别有 16,454,581 条 和 51,241,776 条记录，12GB和15GB数据。

我通过对这两个SQL进行 explain，可以发现postgres都采用了主键索引进行全局扫描，并没有使用最佳的索引去查找，如：

                                               QUERY PLAN
--------------------------------------------------------------------------------------------------------
 Limit  (cost=0.56..291358.44 rows=10 width=78)
   ->  Index Scan using cell_outputs_pkey on cell_outputs  (cost=0.56..114095744.14 rows=3916 width=78)
         Filter: ((block_id = '5085591'::numeric) AND (cell_type = ANY ('{3,6,7}'::integer[])))

实际上，在 ckb_transactions 上存在有 index_ckb_transactions_on_block_id_and_block_timestamp 索引可以缩小搜索范围，然而却没有被使用。前面的SQL如果去掉 order by id ，pg才会使用 index_ckb_transactions_on_block_id_and_block_timestamp 而不是 id 。
另外一个 cell_outputs 也是类似的情况。

根据我对MySQL的了解，这种情况可以使用 index hint 来强制 MySQL 采用特定索引进行查询。
原先的postgres是nervos的运维同学通过ECS自建的，使用的是pg 12。而我选择了AWS的RDS，版本是13。
由于对postgres不熟，我查询了相关资料，发现postgres并不支持在查询中指定要使用的索引，索引的选择全部由postgres内置的智能判断算法决定。

为了能强制postgres使用正确的索引，对于 ckb_transactions 的查询，我在where条件中将 index_ckb_transactions_on_block_id_and_block_timestamp 涉及的两个字段 block_id 和 block_timestamp 全部加上了

SELECT "ckb_transactions"."id", "ckb_transactions"."tx_hash", "ckb_transactions"."block_id", "ckb_transactions"."block_number", "ckb_transactions"."block_timestamp", "ckb_transactions"."is_cellbase", "ckb_transactions"."updated_at", "ckb_transactions"."updated_at" AS collection_cache_key_timestamp FROM "ckb_transactions" WHERE "ckb_transactions"."block_id" = $1 AND "ckb_transactions"."block_timestamp” = $2 ORDER BY "ckb_transactions"."id" ASC LIMIT $3 OFFSET $4

问题便得到了解决。
explain也显示了使用了正确的索引：

                                                          QUERY PLAN
------------------------------------------------------------------------------------------------------------------------------
 Sort  (cost=1696.72..1697.77 rows=419 width=109)
   Sort Key: id
   ->  Bitmap Heap Scan on ckb_transactions  (cost=16.86..1678.47 rows=419 width=109)
         Recheck Cond: ((block_id = '5085591'::bigint) AND (block_timestamp = '1650258764224'::numeric))
         ->  Bitmap Index Scan on index_ckb_transactions_on_block_id_and_block_timestamp  (cost=0.00..16.75 rows=419 width=0)
               Index Cond: ((block_id = '5085591'::bigint) AND (block_timestamp = '1650258764224'::numeric))
(6 rows)

而在接口和区块同步进程中，我将原本在数据库端进行排序的查询，改成一次性将相关数据全部读取过来，并且在应用层进行排序

如 cell_outputs.limit(10).order(:id)
改成了

cell_outputs[0..9].sort{|a, b| a.id <=> b.id}

Rails 中 .find_each 这个方法是内置了一个 id 的游标进行分段的记录遍历。为了满足索引的需求，改成了 to_a.each。

在这些地方去掉了order by id之后，pg便可以正确使用相关索引减少查询范围，提升了性能。

虽然这可能导致网络通信的增加和本地计算量和内存占用，但是可以未来也可以通过一些方式，分散到不同的服务器上进行计算，减轻数据库的压力。

目前看来效果不错，但是由于对pg不了解，我不太理解为什么原来的 ckb explorer 则没有类似问题，希望有对pg熟悉的大佬指点指点

[Keith-CY]

@shaojunda 了解之前这两个查询是如何规避了性能问题的吗

[shaojunda]

以之前在 Explorer 的经验是不要轻易动现在的索引，目前的索引是优化过一轮的结果，除非非常自信或数据充足。有时候你改完了觉得跑两次是快了，结果上线就发现改过的地方变的更慢了。

Postgres 也可以手动指定索引，需要加一个插件，但是指定后未必有它智能判断的好。之前也指定过后来改回去了。

这两个 SQL 目前的样子应该已经是处理过的了，因为在目前的 Production 环境似乎没有特别慢。

还有一种可能是索引和 DB 缓存热起来之后会有改善，可以再跑一段时间看看。 至于是不是 DB 版本的问题我这里也无法确认，但感觉应该不至于。如果担心是版本问题可以先统一使用 12 的版本。