产品笔记
悄然扩展的数据库
用户越来越多，是件好事。但现有数据库还能支撑多久，也逐渐成为问题。Authrim 在需要之前就为新账户准备好存储空间，让增长不必从迁移项目开始。
先增加存放位置，再考虑搬迁
Authrim使用的Cloudflare D1对单个数据库有容量上限：免费方案500 MB，付费方案10 GB。随着用户和数据增长，最终会需要新的存放位置。
Authrim从一开始就支持把账户分配到多个数据库，因此扩容时不必搬迁所有已有账户。这里把每个存储单元称为分片（shard）。
已有账户留在原处，为新账户增加存放位置。这就是账户存储扩展的基本方式。
不同数据，增长速度也不同
租户设置（例如OAuth客户端和策略）、账户与个人信息、通过邮箱查找账户位置的索引，在Authrim中分别存储。
用户增加不代表所有数据库都要一起扩容。账户存储与查找索引的记录数量和增长速度不同，只需为有需要的部分增加容量。
关注剩余的账户名额
新账户会被分配到租户可用的分片。系统优先选择运行正常、已分配数量相对目标数量较低的分片。
判断依据不是磁盘使用率，而是距离设置的目标账户数还剩多少名额。例如目标为10万账户时，剩余2万的余量可以作为准备下一处存储的参考。
可用分片余量较小时，系统会分配已准备好的备用分片。多个租户共用的共享型，以及一个租户独享的专用型，都采用这一思路。
共享租户
专用租户
共享与专用混合
日常运维中，不必再重复做什么
配置自动预配后，注册量每次增长时，工作人员不必再手动创建数据库、准备表结构并连接新注册位置。每次增加容量，也不必为已有账户制定搬迁计划。
工作人员主要确认扩容进度、失败情况，以及使用量和费用是否符合预期。权限不足或服务上限仍需人工处理。在这种分工下，Authrim负责准备下一个存放位置。
只看今天的空位还不够
同样剩余2万个名额，每天新增100个账户和每小时新增1万个账户，准备时间完全不同。
Authrim结合当前分配数量与近期注册速度，预测账户存储和查找索引的容量需求。定时任务每分钟运行，分配账户后也会更新账户预测。
计算需求时，会计入正在创建的分片，避免多个流程发现同一次容量不足后，各自重复创建数据库。
从创建到投入使用
备用分片不足时，Authrim通过Cloudflare管理API创建D1，准备表结构、配置Worker访问并分发存储位置。读写检查通过后，才把数据库投入分配。
自动执行需要启用自动预配，并分别配置D1与Workers的API令牌。无法自动执行时，工作人员可通过设置工具继续操作。
创建进度会被保存。临时通信故障可以从该状态重试；权限不足或资源上限则需要先解决原因，再恢复执行。
如果准备速度跟不上、注册名额耗尽，新注册可能需要重试。提前准备的目的就是减少这种等待。
是否搬迁数据，仍由运维人员决定
增加容量与移动已有数据是不同操作。例如，把租户从共享分片迁往专用分片，不仅要新增位置，还要复制已有数据。
运维人员决定是否开始迁移。批准后，由Authrim执行同步、验证与切换。
目前支持的布局变更是共享转专用。尚未实现专用转共享，也不会自动把已有账户重新均匀分布。
删除退役分片同样需要人工批准。容量增长不会自动触发已有数据的移动或删除。
已经验证到什么程度
2026年7月使用20万个测试账户测量时，Core约208 MB，PII约238 MB，Lookup约426 MB，分别不到付费方案单库10 GB上限的5%。实际用量取决于存储的属性与索引。
每个分片的默认目标是10万账户。系统保留准备下一个分片的余量，而不是尽量填满物理容量。
Authrim仍处于pre-1.0阶段，长期、大规模生产运维经验还有待积累。20万个测试账户的容量测量，不等同于数百万人每天使用的生产实绩。
让增长少一些迁移计划
小型服务不需要一开始就准备大型部署。可以从少量分片开始，随着注册增长增加位置。Authrim把所需准备和流程纳入系统。
用户开始增长时，不必先把数据库搬迁列为首要任务。减少这些工作，才能把更多时间投入服务本身。
测量时间为2026年7月30日，使用20万个测试账户。MB采用十进制单位。D1容量上限见Cloudflare文档。