我们有数以百万计的真正敏感的文件（docx，pfd，xlsx等）上传到我们的应用程序客户端。在我们的应用程序中，我们有斯芬克斯全文搜索这些文件。流程如下：
通过应用程序表单上传
来自文档的纯文本抓取器
将文档存储到加密的s3存储桶
将纯文本存储到mysql数据库中
从mysql db明文到存储在ssd上的sphinx索引的索引器
由于安全性和性能问题，我们必须完全重建上面描述的流。mysql数据库中的纯文本是这个解决方案中最大的“禁忌”，但我们必须分析市场上任何可能的解决方案。文档的安全和加密是业务的重中之重。除此之外，狮身人面像本身的问题是在每周的基础上。
任何有过搜索引擎和文档解决方案全文搜索经验的人——我很想听听你的意见。
1条答案
按热度按时间nle07wnf1#
特别是对于sphinx，有xmlpipe（或tsvpipe）索引器方法。在这里，indexer不是读取“数据库”，而是执行脚本并对输出进行索引。
因此，有了这个脚本，就可以下载加密的数据，解密并输出内容。即解密的数据从不直接“存储”。
或者可以用mysql中的本机加密做类似的事情https://dev.mysql.com/doc/refman/8.0/en/encryption-functions.html#function_aes-加密数据可以在数据库中加密，在索引过程中只需“动态”解密。
还要注意的是，虽然搜索索引实际上没有加密，但它是一个“倒排索引”，因此，虽然理论上可以从中重建单词，但它只是原始单词，而不是原始形式的完整文档。如果你愿意牺牲一些准确性的结果，也许可以启用说无故障索引。那就意味着连文件都无法重建。知道每个文档中的单词，但不知道实际的顺序。
或者可以使用dict=crc，它不存储实际的单词，只存储单词的散列版本。这使得重建非常困难（但并非完全不可能）。因为需要计算彩虹表来重建文档。