一家视频托管服务的工程团队将其 SQLite FTS5 索引更换为 OpenSearch 集群，将零结果查询率从 12% 降低至 1.4%，并将搜索点击率提升了 9%，同时将延迟保持在 28ms 以下。
为什么这次切换变得迫在眉睫
SQLite 的全文搜索扩展 (FTS5) 非常有吸引力：它与其余数据存储在同一个文件中，没有许可成本，并且对于精确的标记（token）匹配可以立即返回结果。然而，平台的日志显示，有百分之十几的用户搜索完全没有返回任何结果。拼写错误，例如 “intersteller” 或 “avengrs endgame” —— 这些都是人们在移动端键盘上容易犯的拼写错误 —— 是主要的罪魁祸首。
使用三元组（trigrams，即三个字符的片段）进行快速修复将空搜索率降低到了 7%，但带来了两个问题。首先，索引体积膨胀到原来的三倍以上，增加了存储成本并减慢了更新速度。其次，相关性受损；模糊匹配返回了大量无关视频的杂乱结果，不仅没有引导用户，反而让用户感到困惑。
团队得出结论，需要一个具有原生纠错能力（typo-tolerance）和复杂相关性评分机制的专用搜索引擎。
构建 OpenSearch 流水线
将 SQLite 作为事实来源 (Source of Truth)
OpenSearch 作为可丢弃的只读副本。所有的视频元数据都保留在 SQLite 中；搜索索引可以在不面临数据丢失风险的情况下重新构建。当 OpenSearch 集群宕机时，应用程序会自动回退到原始的 FTS5 引擎。
使用 “should” 查询实现分层相关性
查询不再仅仅依赖模糊匹配，而是结合了三个子句：
- 精确短语匹配 (Exact phrase match) – 最高权重，奖励那些正确输入标题的用户。
- 所有词项均存在 (All terms present) – 中等权重，捕捉那些每个单词都出现但顺序不一定一致的查询。
- 模糊匹配 (Fuzzy match) – 低权重，作为拼写错误词项的安全网。
这种层级结构在保持精确查询准确性的同时，也为拼写错误提供了宽容的兜底方案。
调整模糊匹配设置
将前缀长度 (prefix length) 设置为 1，强制要求每个词项的首字符在触发模糊逻辑之前必须匹配。这一规则保证了搜索速度，并防止了可能导致内存过载的候选词项爆炸。团队还限制了词项扩展 (term expansions) 的最大数量，这是防止资源失控的另一道防线。
同步策略
三个互补的过程确保 OpenSearch 索引与 SQLite 保持一致：
- 用于同步新数据的 cron 作业。
- 每晚差异扫描 (Nightly diff pass) – 扫描增量更新中遗漏的不匹配项。
- 每周全量重建 (Weekly full rebuild) – 在索引别名 (index alias) 后运行，然后通过单次操作切换别名，从而保证零停机时间。
两周后的可衡量影响
- 零结果查询从 12% 降至 1.4%。
- 搜索点击转化率提升了 9%。
- 中位延迟保持在 28ms 以下，完全符合平台的用户体验目标。
注意事项与反思
这种迁移并非“即插即用”式的升级。团队强调，绝不能用搜索引擎取代主数据库；SQLite 仍然是所有视频元数据的权威存储。
总结
通过专用搜索引擎增加纠错能力，将用户旅程中明显的“死胡同”转变为流畅、快速的体验。该案例研究表明，一种严谨的架构——将关系型存储作为事实来源、实现相关性分层并保护模糊逻辑——可以在不牺牲稳定性的情况下带来显著的收益。