能否使用NoSQL数据库实现Elasticsearch的基础功能？

你描述的这套逻辑本质是最简版的倒排索引实现，可以实现Elasticsearch最基础的全文模糊匹配能力，小流量、低复杂度的场景下完全可用。

• 简单文本匹配：查询时将用户输入的搜索词切为相同规则的n-gram，到NoSQL表中查询每个n-gram对应的文档列表，取交集即可得到命中的所有文档
• 基础模糊查询：只要生成n-gram时覆盖了前后缀拆分规则，就能实现类似ES的基础通配符匹配、前后缀搜索效果

这套方案只实现了ES能力的极小一部分，生产级场景下的核心缺失点如下：

• 没有相关性排序能力：ES默认通过BM25算法计算文档匹配度，返回结果按得分排序。你的方案只能拿到命中的文档列表，要实现排序需要额外存储每个n-gram在对应文档中的出现频率、位置、文档长度等元数据，查询时自行计算得分，复杂度会大幅提升
• 无原生分布式支持：ES天生支持分布式分片、副本、水平扩容、高可用，你自行基于NoSQL实现的话，数据分片、一致性保障、故障转移都需要自己开发维护
• 缺失大量高阶能力：短语匹配、搜索结果高亮、聚合统计、地理空间查询、自动补全、分词定制这些ES开箱即用的能力，你都需要额外实现，工作量极大
• 性能与存储成本差距大：ES对倒排索引做了大量底层优化，比如FST索引压缩、段合并、多层级缓存机制，自行用NoSQL存储n-gram的话，数据量超过10万级之后查询延迟、存储占用都会远高于ES
• 数据一致性难保障：更新或删除文档时，你需要遍历删除所有旧n-gram关联的文档记录，再插入新的n-gram映射，整个过程没有原子性保障，很容易出现数据不一致，ES的文档更新逻辑已经做了事务优化，不存在这个问题

如果你的需求只是小流量、小数据量的简单模糊搜索，不需要相关性排序、高阶查询能力，这套方案开发成本很低，可以直接用。如果是生产环境的中大型搜索场景，直接用Elasticsearch的投入产出比会高很多。

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