|
|
6c2381ad2c
|
perf(提交列表): 越早的页越慢，最后一页要等 1.2 秒
Deploy / deploy (push) Has been cancelled
翻页用的是 LIMIT n OFFSET m，而 Postgres 对 OFFSET 没有捷径：前 m 行必须真的
产出再丢掉，丢弃又发生在 join 之后，每一行都白回了一次表。生产快照（10.4 万条
公开提交）实测最后一页 1258ms、碰了 95347 个 buffer。最早那几页平时没人翻，
数据页从来不在缓存里，全是冷读，所以感受上比新的几页慢得多。
改成两步：先只 select create_time / id 数到第 m 行拿游标——这两列正好是部分索引
的全部内容，跳过 m 行走 Index Only Scan，Heap Fetches 为 0，纯在索引页里数数；
再拿这一行做 keyset 回查，只回表取 limit 行。同一页降到约 9ms、885 个 buffer，
端到端 HTTP 10.7ms。代价变成 O(m) 个索引条目而不是堆页，按快照密度外推，
涨到 100 万条时最深一页仍在几十毫秒量级。
接口签名和前端都没动，页码跳转照旧。offset 为 0、以及按题号筛选时（条件在
problem 表上，第一步得跟着 join，index-only 就没了）退回普通 offset。
部分索引从 (create_time) 换成 (create_time, id)：create_time 由
new Date().toISOString() 生成，只有毫秒精度，不是全序，游标用 <= 回查时同毫秒的
上一页末行会重复出现在下一页页首。加 id 之后两步走同一个顺序。索引 2.3MB → 6.9MB。
索引两列都建成默认 ASC，靠 Index Only Scan Backward 反着扫。别照着 ORDER BY
写成 (create_time DESC, id DESC)：ORDER BY 的 DESC 默认 NULLS FIRST，索引的 DESC
默认 NULLS LAST，规划器认为出不了序，会退化成 external merge sort（5.2MB 落盘），
比不加索引还糟。这一条已写进 schema.ts 和迁移文件的注释。
正确性：在快照上把新旧写法返回的 id 序列逐页比对，14 个 offset × 4 个 limit
共 56 组全部一致，含末尾残页与越界。
比赛提交列表暂不改：单场比赛撑死几千条，offset 不构成问题。
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
|
2026-08-27 11:13:38 -06:00 |
|
|
|
bb4b5825c3
|
feat(迁移): 0000 改成可执行，空库能自举
0000_crazy_gateway.sql 原本是 drizzle-kit pull 的产物，整份被 /* */ 包着、
可执行语句 0 条，所以任何新库的结构都只能先手工 psql 灌一遍 schema.sql 再打基线。
现在它的内容由 docs/specs/schema.sql（2026-08-07 的生产 pg_dump --schema-only）
机械转换而来：去掉 psql 专有指令 12 条、去掉 7 张 Django 遗留表及其索引外键 41 条，
保留 212 条语句、顺序不动。转换脚本入库在 docs/spikes/。
不含 Django 那 7 张表，是因为 meta/0000_snapshot.json 从来就没有它们（pull 当时
tablesFilter 滤掉了），不建它们才和快照一致；0002 那串 DROP ... IF EXISTS 在新库上
空转、在生产库上真删，两边跑同一串迁移落点相同。
改 0000 对生产库没有影响：migrator 只比 created_at、从不校验 hash，而生产库那行
baseline-0000-faked 早把它挡在门外了。
migrate.ts 配套：空库直接从 0000 建起（并自建 drizzle 记账表——原来这步由 drizzle 的
migrate() 顺手做掉）；自举时不触发破坏性闸门，因为空库上没有数据可丢，拦下来只会逼
每个新环境都带一次 OJ2_ALLOW_DESTRUCTIVE，把这道闸训练成习惯动作。「有表但没基线」
仍然 exit 3。
验证：空库自举出来的结构，和「灌 schema.sql + 打基线 + 跑迁移」这条老路子跑出来的
结构，pg_dump --schema-only 逐字节一致（734 行，零差异）。
转换时踩到两个坑，都写进注释了：注释里不能出现 statement-breakpoint 的字面量
（readMigrationFiles 纯文本切分，会把注释从中间切开）；过滤 Django 对象要看
public.X 形式的对象引用，不能扫语句字样——user 表有一列叫 auth_token。
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
|
2026-08-26 09:54:31 -06:00 |
|
|
|
2e871cb5b0
|
refactor(迁移): 换掉 drizzle 的执行器，一条迁移一个事务
drizzle 的 migrate()（pg-core/dialect.js）把所有待执行的迁移塞进同一个
session.transaction()，两个后果：第 3 条失败会把第 1、2 条一起回滚，和 Django
migrate 的逐条提交语义不一样；以及 CREATE INDEX CONCURRENTLY 一律跑不了，
没有任何开关。
现在自己按 journal 逐条执行，一条一个事务。文件第一行写 `-- oj2:no-transaction`
的迁移走裸执行（简单查询协议——扩展协议会把语句包进隐式事务块，CONCURRENTLY
照样被拒），代价是没有回滚，所以这类迁移一个文件只放一条语句。
记账行的写法和 drizzle 完全一致（hash = 整文件 sha256，created_at = journal 的
when），migrator 又只比 created_at、不校验 hash，两套执行器可以互换。
顺带：日志和报错说得出迁移文件名了（readMigrationFiles 不返回 tag，自己读一遍
journal），失败时打印的是 Postgres 那句话而不是 postgres.js 的内部堆栈，
新增退出码 5。
实跑验证（本机 Docker，生产 schema 灌进探针库）：CONCURRENTLY 带标记成功、
indisvalid = t，去掉标记复现 "cannot run inside a transaction block"；
0003 成功 + 0004 失败时，0003 留下、0004 的首条合法语句没留下。
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
|
2026-08-26 09:54:01 -06:00 |
|
|
|
eabb61189c
|
fix(数据库): 索引方向被 .op() 吞掉，schema.ts 和真实库对不上
根因不是 .desc()，是 opclass。drizzle-kit 的 CreatePgIndexConvertor 里那个
三元一旦走进 opclass 分支就回不到方向分支，而 pull 给每一列都挂了 .op(...)，
于是"写了 .desc() 却生成不出 DESC"每次都会重演。实测确认：不写 .op() 时
多列混合方向能正常生成，所以原先"多列混合方向的索引别指望 generate"这条
自我限制不成立。
announcement_list_idx 和 contest_create_time_idx 两条真实索引踩在这上面：
生产库里它们带 DESC（schema.sql:1636、:1685），schema.ts 却会生成成全 ASC。
contest_create_time_idx 的 opclass 还串了位（contest_id 标 timestamptz_ops、
create_time 标 int4_ops），那条 SQL 真拿去执行 Postgres 会直接拒绝。
改快照而不是生成迁移：generate 想 drop + recreate，但重建出来的和生产库里
那两条完全等价（DESC 默认就是 NULLS FIRST），执行它只是在 12.3 万行的表上
白挨一次锁。手法和当初处理 problem_tag_name_ci_unique 的 opclass 一致。
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
|
2026-08-26 09:53:05 -06:00 |
|
|
|
586c88f629
|
build(数据库): 改用 drizzle migration，加提交列表索引、清掉 Django 残留
Deploy / deploy (push) Has been cancelled
一条线上的三件事：让 drizzle 的迁移机制真正可用 → 用它加索引 → 用它清掉
不再需要的 Django 表，最后接进部署和 CI。
## 1. 让 drizzle-kit generate 可用
原本以为不能用：只加一个索引，generate 却吐出一堆噪音，其中 5 条
`DROP SEQUENCE auth_*/django_*` 打到生产库上会直接搞坏旧后端。
逐个查下来全是 `pull` 出的基线自己不能 round-trip，都是可修的：
- **快照里的 Django 序列**：tablesFilter 只过滤表、不过滤它们的序列。
已从 0000_snapshot.json 清掉。
- **bigint 上限精度**：pull 生成的 `maxValue: 9223372036854775807` 是 JS
number 字面量，round-trip 成 ...776000，每次 generate 都多出 10 条
ALTER COLUMN。改成字符串。
- **表达式索引的 opclass**：problem_tag_name_ci_unique 在快照里带
opclass，drizzle 自己序列化不出来，导致每次 drop + recreate。已去掉。
改完 `generate` 是干净的 no-op。
两个改不掉、只能绕的写进了 CLAUDE.md：索引 `.desc()` 生成 SQL 时会被丢
（单列索引不写方向即可，Postgres 用 Index Scan Backward 服务 ORDER BY
DESC，实测同样 0.08ms）；migrator 把所有语句包一个事务，
CREATE INDEX CONCURRENTLY 跑不了。
最容易吃亏的是 drizzle 没有 --fake-initial：对已有数据的库直接 migrate
会从 0000 跑起、撞表回滚，**而且 exit 1 但一个错误都不打印**。
## 2. 0001 提交列表索引
`WHERE contest_id IS NULL ORDER BY create_time DESC LIMIT n` 用不上现有的
contest_create_time_idx (contest_id, create_time DESC) —— Postgres 不把
`IS NULL` 当成能吃掉首列、从而继承第二列有序性的等值条件。把
enable_seqscan / enable_bitmapscan 全关掉逼它用也不肯，宁可走单列
contest_id 索引再全量排序。于是每翻一页都 Parallel Seq Scan 扫完整张表。
换成部分索引后谓词由索引自己保证，索引序就是查询要的排序序。生产快照
（12.3 万条提交）实测首页取 10 行：61.8ms / 读 18936 blocks →
0.22ms / 读 34 blocks。端到端 94ms → 6ms。
真正要命的不是单次 61ms，是每个请求都要把 169MB 的表刷一遍
shared_buffers —— 一节课几十个学生同时开提交列表，磁盘和缓存直接被打穿。
## 3. 0002 删掉 Django 残留
确认旧 Django 后端不再使用、也不再作为回滚路径。删前核实过：没有任何
OJ2 保留的表引用这 7 张，3 条外键全在它们内部（所以不用 CASCADE，真有
漏网的会报错而不是被悄悄级联掉）；5 个序列都由各自的表 owned，随
DROP TABLE 一并消失；数据全是 Django 自身元数据。tablesFilter 随之移除。
**回滚路径就此作废** —— CLAUDE.md 开头和 runbook 的「回滚保证」「七、回滚」
都改了。这条迁移已在本机 dev 库和生产快照副本上跑通，**生产库尚未执行**。
## 4. migrate 接进部署与 CI
deploy.sh 在构建之后、起栈之前跑 `oj2-api migrate`，失败就中止部署（旧
容器原样还在跑）。CI 走的也是 deploy.sh，所以不用给 GitHub 配数据库凭据，
也不用把生产库对外开放。
迁移文件**不内嵌进二进制**，随镜像装在 /usr/local/share/oj2/migrations。
这样 drizzle 的 migrate() 能原样用 —— 靠 _journal.json 自动发现，新增迁移
不用改任何代码，和 Django 扫 migrations/ 是一回事。内嵌就得为每条迁移
手写一行 import，那是迟早会漏的账。（CLAUDE.md 里「单二进制不能读文件」
那条讲的是 node_modules 和 import.meta.dir 推路径，按显式绝对路径读一个
数据目录不在此列。）
三道闸门，都是写完测出来才补上的：
- **破坏性迁移拦截**：DROP TABLE / DROP COLUMN / DROP SCHEMA /
ALTER COLUMN ... TYPE / TRUNCATE 命中就退出 4，需要
`OJ2_ALLOW_DESTRUCTIVE=1` 显式放行。DROP INDEX / DROP CONSTRAINT 不算，
拦了只会让人习惯性带上放行开关。扫描前先剥注释，避免误报。
- **基线缺失**：退出 3 并直接打印该敲的 SQL。注意判的是
`max(created_at) < 0` 而不是「表不存在」—— 表存在而为空（上次迁移失败
留下的）同样是没基线。
- **迁移目录读不到**：这是最可能犯的错（Dockerfile 漏拷），原本是 drizzle
的堆栈，现在直接说该检查哪一行。
另外发现 0000_crazy_gateway.sql 是 pull 的产物，**整份被 /* */ 包着，
可执行语句 0 条**，所以这个库根本不能靠迁移自举建表。原先写的「空库就从
0000 建」跑起来会炸在一个和真实原因毫不相干的 unterminated /* comment 上。
现在如实说明：结构只能来自 docs/specs/schema.sql 或生产 dump。
验证：镜像内编译（ARTIFACTS=build）出的真实镜像跑完五种场景 —— 拦截、
放行、幂等、无基线、漏拷目录，全部符合预期；dev 形态同样五种场景全过。
tsc / 路由遮蔽 / deploy.sh 语法 / generate no-op 都通过。
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
|
2026-08-26 07:56:30 -06:00 |
|
|
|
0f0a5cb65a
|
fix(阶段1): 修正 problem 主键与展示编号映射
|
2026-08-06 21:11:44 -06:00 |
|
|
|
f635737453
|
feat(阶段1): drizzle schema 从本地库生成并剪掉 Django 框架表
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
|
2026-08-06 20:45:51 -06:00 |
|
