meilisearch -- 为什么我放弃了 Elasticsearch 转投 Meilisearch？
前言：苦 Elasticsearch 久矣？
在日常项目开发中，一提到“全文搜索”，我们往往会习惯性地掏出 Elasticsearch（简称 ES）。但对于大多数中小型应用来说，ES 可能太“重”了。
试想一下：在一个只有 20 万篇文档的业余项目里运行 ES，每月要烧掉 120 多美元。与之相伴的，是令人心力交瘁的日常运维：调优 JVM 内存、处理节点变黄的健康告警、应对索引损坏，以及维护多达数百行的 YAML 配置。
直到有一天，只需花一个下午将搜索后端替换为 Meilisearch，奇迹发生了：
- 延迟暴降：搜索 P99 延迟从 180ms 降至 12ms。
- 成本跳水：服务器费用断崖式降至每月 14 美元。
- 配置极简：配置文件被精简到了区区 30 行左右。
- 极速检索：极其优秀的开箱即用体验和极简的 API 设计。
这篇博客，我们就来深度对比这两款搜索引擎的差异，并重点揭秘 Meilisearch 那些被吹爆的“神仙功能”在真实的中文业务场景下，到底表现如何。
核心揭秘：Meilisearch 究竟是什么？
Meilisearch 是一个由 Rust 编写的开源搜索引擎。它的核心设计哲学非常明确：克制。它压根不想成为下一个大而全的 ES，而是将所有精力死磕在一个场景上——为用户的应用内搜索框提供极致体验。
为了实现这个目标，它做了几个非常关键的设计取舍，但对于国内开发者来说，我们需要辩证地看待这些“杀手锏”：
1. 基于内存映射的极速响应 底层使用 LMDB（一种高性能嵌入式键值存储），只要热数据能塞进内存，查询就不需要经过磁盘 I/O 的漫长等待。这是它快如闪电的根本原因。
2. 默认自带拼写容错 官方极力推崇它的 Typo tolerance（拼写容错）。它通过底层的 BK-tree 自动计算输入词的编辑距离。英文环境下体验堪称魔法：apple 错打成 aple，编辑距离为 1，引擎瞬间纠错并返回正确结果。 但在纯中文搜索中，这个机制往往会帮倒忙：
- 字与字母的降维打击： 英文的错误在字母，中文的错误在输入法的“拼音”。在计算机眼中，“苹果”和“平果”是完全不同的 Unicode 字符，编辑距离为 1。
- 极高的误杀率： 如果你盲目开启 1 个字符的中文容错，搜索“苹果”不仅会匹配出同音错字“平果”，还会荒唐地匹配出“芒果”、“坚果”、“糖果”等毫无关联的词。准确率会瞬间崩溃。
- 正确的解法： 在 Meilisearch 中处理中文，不要过度迷信原生的汉字容错。你必须打一套组合拳：首先利用内置的 Jieba 进行中文分词；其次，在写入数据时进行“拼音化”预处理（将中文转成拼音存入专门的
pinyin字段），让引擎在拼音字段上计算编辑距离（pimguo匹配pingguo）；最后，辅以完善的同义词库。
3. 基于规则的级联排名 舍弃了复杂的机器学习模型和 TF-IDF 算法，采用一套确定的规则（如错别字距离、词汇匹配度、属性优先级）来决定结果排序。这在绝大多数基础的业务场景下异常精准，且极其容易调试。
4. 极简的架构模型 单一进程，完全由 REST API 驱动。写入是异步排队执行，查询则是同步秒回。没有分片，没有节点拓扑等复杂概念。
巅峰对决：Meilisearch vs Elasticsearch
到底该怎么选？我们把它们的差异摊开来看：
| 核心维度 | Elasticsearch (ES) | Meilisearch |
|---|---|---|
| 产品定位 | 通用、分布式的大数据分析与搜索引擎。 | 专为“应用内前端搜索框”打造的轻量级引擎。 |
| 典型场景 | 日志聚合、超大规模复杂检索、全栈数据分析。 | SaaS 产品、电商商品搜索、文档站、知识库。 |
| 运维与配置 | 极重。需管理集群状态、分配分片、维护映射等。 | 极轻。单节点运行，配置极少，对小团队极其友好。 |
| 排序与算法 | 基于文本相关性（如 BM25），支持复杂的自定义打分。 | 采用预设的规则级联排序。不支持复杂数学公式算分。 |
| 架构与扩展 | 原生分布式，支持 PB 级别数据的横向扩展。 | 单机架构。高度依赖物理内存（RAM），数据量受限。 |
| 高级功能 | 拥有强大无比的聚合（Aggregations）功能。 | 仅提供基础的分面搜索（Faceted search），足够覆盖 90% 需求。 |
避坑指南：什么时候千万别用 Meilisearch？
如果你中了以下任何一条，请老老实实留在 ES 的怀抱：
- 你需要复杂的自定义打分：比如需要根据“评分 × 销量 + 近期转化率”来动态计算产品排名，Meilisearch 难以招架。
- 你的数据量远大于服务器内存：当海量数据把内存撑爆，触发频繁的系统分页缓存置换时，它的查询延迟会惨不忍睹。
- 你强依赖分布式高可用：它目前依然是一个单机系统，没有原生的多机复制和分片功能，如果业务对单点故障零容忍，请慎重。
- 主打语义/向量检索：虽然它加入了混合搜索，但纯向量检索的成熟度仍不及专门的向量数据库（如 Qdrant）。
写在最后
工程界过度设计是常态。“我们大多数人，其实只是在做一个普通的食谱应用而已。”
如果你只是需要一个快如闪电、体验极佳的前端搜索框，Meilisearch 绝对应该成为你的默认首选。它不仅能为你省下大笔的服务器账单，还能省下大把用来填坑的运维时间。看清它在中文处理上的局限，做一点点前置的拼音化处理，你就能用极低的成本，换来用户体验的巨大飞跃。