搜索 - 论坛

@老虎会游泳，我写了一些脚本，利用去年隔壁 v2 论坛千万帖子数据，在机械硬盘上，测试了 SQLite 并发能力：

更新

[08-30 22:38]：全文索引加上主帖内容，写请求从 800 RPS 掉到 700 了。。

结果

（读写请求，用两个 wrk 同时进行。末尾附上运行过程）

700 写请求/秒：新增用户信息/帖子数据/回帖数据 + 全文索引 （新增帖子/回帖时。效果） + 计算该帖总回复数（新增帖子/回帖时）。
1. 测试时，按创建用户/帖子/回复的时间顺序，并发请求。
4000 读请求/秒：读取某个帖子及其所有回帖的所有数据，以 json 形式响应。
1. 仅请求已完结的帖子。（所有回复已添加进服务端数据库）
2. 以帖子点击数，作为概率，加权随机不放回地抽取，服务端数据库里，已完结的帖子。（一般点击数越高，回帖数量也越多）

环境

CPU：i7-4790（看 gb6 跑分，论单核，和 i5-8250u 差不多。是 i3-12100 的 57%）
内存：16 GB，DDR3，1600 MHz
系统：Ubuntu 24.04
服务端：Python 3.12，FastAPI，双进程（2 workers），运行时总共 100 MB 内存左右
测试时服务端数据库
- 大小：5.0 GB
- 用户数：32.8 W
- 帖子数：79.7 W
- 回帖数：1062.3 W
硬盘

缺点

断电可能丢失少量数据

操作系统崩溃/断电时，可能会损失少量数据。但可以维持原子性、一致性。
落盘几千个事务时，会卡 0.5 秒

几千个事务后，会在一个事务强制将预写日志，刷新回数据库。（否则日志无限增长，读取速度下降）

但该事务需要等待：
1. 在此事务前的所有读事务完成。（否则隔离性有问题，会不可重复读）
2. 将以往几千个事务脏页数据，大量随机写回数据库。（测试时需要 0.5 秒左右）
因此：
1. 不能持续开着一个数据库连接，惰性获取数据进行响应。（如全文搜索后，按用户下拉速度，流式响应游标结果）
2. 回写数据库时，后续写请求会被阻塞。
改进方向：
1. SQLite 官方有个开发了 7 年的 WAL2 分支，可在写满一个 WAL 后，立即转向第二个。
  只要第一个 WAL 所有读事务完毕，就可立即全部写回数据库（大大延长了读事务持续时间，但还是不能无限），且此时不会阻塞后续写事务。
  但该分支一直未被合并回主分支，可能有不稳定的风险。
写事务串行，需最快速度完成

本质上，SQLite 的并行写事务数仍是 1，因此每个写请求都需要尽可能快处理，否则后续写请求都会被拖慢，降低 RPS。

改进方向：
1. SQLite 官方有个开发了 9 年的 begin-concurrent 分支，允许多个事务，同时写入不同的页面。
  若提交时，读取/写入过的页号被其他事务修改过，回滚重来。（类似 redis 的事务）
  同上，该分支一直未被合并回主分支，可能有不稳定的风险。
FastAPI 服务端，需要读写请求分离

一个 worker 专心处理写请求，其他 workers 处理读请求。

原因：
1. SQLite 只支持 1 个并行写事务，且自带的阻塞重试机制效率低下，需要外部互斥锁保证，任何时刻只有一个写请求在进行。
2. Python 的 GIL 很慢，不能使用多线程。
3. 多进程方案，可以使用 redis 锁来实现。但需要使用异步，等待获得写请求锁期间，去处理读请求。（否则绝大部分 workers 都阻塞在等写锁时）
4. 然而，Python 的事件循环，是公平调度。在等 redis 锁时，会先去完成本次调度的其他几十个读请求。下一轮循环，才拿到锁。
  但实际上，可能处理第二个读请求时，redis 就上锁成功。导致其他 workers 的写请求，也要被迫额外等待几十个读请求完成。。
5. 我还没完美实现，基于优先级的事件循环调度。。（为啥就没个包干这种事啊。。nodejs、PHP 好像也不支持。。）

测试过程

写请求

$ wrk -s test.lua --latency -t1 -d30 -c100 http://127.0.0.1:8081 -- write
[22:24:42]  INFO  启动写入脚本
Running 30s test @ http://127.0.0.1:8081
  1 threads and 100 connections
  Thread Stats   Avg      Stdev     Max   +/- Stdev
    Latency   221.29ms  237.46ms   1.98s    79.97%
    Req/Sec     1.25k   684.68     2.37k    51.41%
  Latency Distribution
     50%   66.50ms
     75%  382.95ms
     90%  622.55ms
     99%  806.51ms
  20453 requests in 30.06s, 4.90MB read
  Socket errors: connect 0, read 0, write 0, timeout 5
Requests/sec:    680.47
Transfer/sec:    167.06KB

读请求

$ wrk -s test.lua --latency -t1 -d30 -c100 http://127.0.0.1:8080
[22:24:43]  INFO  启动读取脚本
Running 30s test @ http://127.0.0.1:8080
  1 threads and 100 connections
  Thread Stats   Avg      Stdev     Max   +/- Stdev
    Latency    22.74ms   12.94ms 369.21ms   98.69%
    Req/Sec     4.24k   429.51     4.64k    90.88%
  Latency Distribution
     50%   21.47ms
     75%   22.67ms
     90%   24.43ms
     99%   70.82ms
  126055 requests in 30.03s, 193.80MB read
Requests/sec:   4197.77
Transfer/sec:      6.45MB