如何为多租户应用的大体积文档实现全文检索功能

原生 Redis 不内置全文检索能力，你调研的检索能力实际来自 RediSearch 模块，它对大文本的支持完全可以覆盖你的需求：

• 单 TEXT 类型字段默认支持最大长度为 1MB，换算为中文约 50 万字，按常规 A4 纸单页 2000 字的排版标准，最多可支持 250 页的文本，远高于你提到的 20 页上限
• 你的单客户千份文档的规模完全在 RediSearch 的负载能力范围内：单客户总文本量按 1000 份 * 20 页 * 2000 字计算仅 4000 万字，存储占用不到 80MB，即使租户规模扩大 10 倍也不会出现性能瓶颈
• 多租户场景可以给所有文档新增 tenant_id 标签字段，检索时先通过 tenant_id 过滤再做全文匹配，既避免跨租户数据泄漏，也能提升检索效率

如果你的业务后续有更复杂的检索需求，可以根据技术栈和场景选择以下方案：

• Elasticsearch/OpenSearch：是工业级全文检索的首选方案，单文本长度无明确上限，支持关键词高亮、同义词扩展、分面搜索、语义向量检索等能力，可直接对接大模型搭建 RAG 系统。千份级文档属于极低负载，单机部署即可跑通，多租户可选择索引隔离或字段过滤两种方案。缺点是组件较重，内存占用高于 RediSearch，需要单独维护部署。
• PostgreSQL 内置全文检索：如果你的业务数据原本就存储在 PostgreSQL 中，不想额外引入新的技术栈，可以直接使用其内置的全文检索能力。给 content 字段创建 GIN 索引后，最大支持 1GB 的文本字段，千份级文档的检索延迟完全满足常规业务需求，多租户过滤逻辑和普通 SQL 查询一致，开发成本极低。缺点是复杂检索场景的优化空间不如专用检索引擎，不适合检索需求快速迭代的场景。
• SQLite FTS5 扩展：如果是低并发、轻量级的端侧或小型应用，使用 SQLite 的 FTS5 全文检索扩展即可满足需求，无需单独部署服务，本地文件存储的架构足够支撑单租户万份级大文本的检索需求。

如果仅需要基础关键词检索、对延迟要求高且已有 Redis 技术栈，直接选择 RediSearch 即可。如果后续有扩展检索能力的规划，优先选择 Elasticsearch/OpenSearch。如果不想新增技术栈，PostgreSQL 内置全文检索完全可以支撑你当前的业务规模。

内容的提问来源于stack exchange，提问作者ppavlov