敏感文档全文检索方案重构咨询：安全与性能优化需求

我经手过好几个大型敏感文档检索系统的重构项目，太懂你的痛点了——把明文敏感内容存在MySQL里绝对是致命的安全隐患，Sphinx在百万级文档规模下频繁出问题也完全在预料之中。结合你们把文档安全和加密放在首位的需求，给你一套端到端的重构方案：

• 全程无明文敏感数据落地：整个流程里绝对不能让纯文本出现在任何可被直接访问的持久化存储（比如原来的MySQL）
• 加密贯穿全链路：从上传、文本提取、索引构建到最终存储，所有涉及敏感数据的环节都要加密
• 检索引擎优先选原生支持加密+高可用的方案：彻底替换Sphinx，解决稳定性问题

完全替换原来的流程，每一步都紧扣安全：

1. 文档上传即加密

   • 用户上传文档后，应用层直接用AES-256-GCM对称加密算法加密原始文档，加密密钥存在独立的密钥管理服务（KMS）中，绝对不能硬编码在应用代码里
   • 加密后的文档直接存入加密S3桶（保留原S3存储，但要把S3的服务器端加密改成用自定义KMS密钥，而非默认的SSE-S3，强化密钥控制权）

2. 内存流式处理，跳过MySQL存储

   • 彻底砍掉MySQL存纯文本的环节：从S3下载加密文档到内存，用KMS密钥解密后，直接调用文本提取工具（比如Apache Tika、PyMuPDF）在内存里提取文本
   • 提取的纯文本绝不落地，直接传给检索引擎构建索引，全程只在内存中短暂存在

3. 替代Sphinx的检索引擎选型
   根据安全和性能需求，推荐以下几个成熟方案：

   • Elasticsearch（加密增强版）：
     • 原生支持静态索引加密（用KMS密钥加密磁盘上的索引文件），传输层强制TLS，还能开启字段级加密，完美解决安全问题
     • 高可用集群方案成熟，百万级文档的索引和检索性能比Sphinx稳定太多，运维工具链也更完善
     • 注意：一定要禁用自动创建索引，开启RBAC权限控制，只允许应用服务的IP访问ES集群
   • OpenSearch：
     • 作为Elasticsearch的合规分叉版，原生支持更多安全特性（比如节点间加密、静态加密、细粒度权限），适合对合规要求极高的场景
   • Solr：
     • 同样支持全链路加密和索引加密，如果你团队有Solr运维经验，它的稳定性也能轻松支撑百万级文档规模

4. 元数据安全存储

   • 把原来MySQL里的非敏感元数据（比如文档ID、上传时间、所属用户ID）迁移到加密的数据库（比如加密版PostgreSQL，或者开启透明数据加密的MySQL），但元数据里绝对不能包含任何敏感内容
   • 用文档ID作为唯一标识关联检索引擎和S3存储，避免泄露敏感信息

• 密钥全生命周期管理：所有加密密钥（文档加密密钥、索引加密密钥）都存在独立的KMS服务，应用通过API动态获取密钥，绝不本地存储密钥；密钥定期轮换，过期密钥及时销毁
• 最小权限原则：检索引擎集群只开放应用服务的访问IP，S3桶只授权给文本提取服务，KMS只给应用和处理服务分配必要权限
• 全链路审计日志：开启上传、解密、提取、索引、检索的所有操作日志，日志加密存储，定期做安全审计
• 文档销毁闭环：用户删除文档时，同时删除S3里的加密文档、检索引擎里的对应索引条目，必要时销毁该文档的专属加密密钥（如果KMS支持）

• 索引分片与副本配置：百万级文档建议设置5-10个索引分片，副本数至少2个，既保证检索性能，又避免单点故障
• 异步批量索引：用消息队列（比如Kafka、RabbitMQ）做文档上传的异步处理，避免同步请求阻塞；积累一定数量的文档后批量构建索引，提升索引效率
• SSD存储+缓存优化：检索引擎的索引依然存在SSD上，开启字段缓存（比如ES的fielddata缓存），提升高频检索的响应速度
• 检索语句优化：优先用前缀查询、短语查询等高效方式，避免全索引扫描；针对文档类型配置合适的分词器（比如中文用IK分词器，英文用Lucene标准分词器）

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