第01章：为什么需要自建搜索引擎

当所有人都说”用Elasticsearch”时，我们选择回到第一性原理

📝 TL;DR (核心要点速览)
– 核心问题：外部搜索服务复杂、昂贵、依赖性强
– 关键认知：80%的搜索需求只需要20%的功能
– 技术真相：数据库+简单分词就能满足大部分需求
– 实际应用：中小型项目的最佳平衡点

1. 现状：被复杂化的搜索系统

打开任何一个技术论坛，搜索问题的标准答案总是：”用Elasticsearch”。但很少有人停下来思考：我们真的需要这么复杂的解决方案吗？

1.1 现代搜索系统的复杂性膨胀

Elasticsearch的问题：

学习曲线：陡峭 → 3个月才能熟练使用
运维成本：高 → JVM调优、集群管理、分片配置
硬件需求：大 → 8GB内存只是起步价
调试难度：大 → 分布式系统问题定位复杂

Algolia的问题：

成本高昂：$0.50/千次记录 → 万级数据月费数百元
依赖外部：网络延迟、数据安全、服务可用性
定制受限：API有限，无法深度定制算法

传统数据库LIKE的问题：

性能糟糕：O(n)查询 → 百万数据秒级响应
功能缺失：无权重、无相关性、无容错
体验差劲：无自动补全、无拼写纠错

1.2 认知误区：功能越多越好？

我们陷入的思维陷阱：
– “别人都在用，我也应该用”
– “功能越多越专业”
– “免费的MySQL太简单，不如用专业的”

但真相是：
– 大部分应用只需要基础文本搜索
– 复杂功能往往带来维护噩梦
– 简单方案更可靠、更可控

2. 本质思考：搜索的核心需求

2.1 真实的使用场景分析

中小型应用的搜索需求：

用户搜索商品：标题匹配 + 类别过滤
用户搜索文章：内容关键词 + 相关度排序
用户搜索用户：姓名匹配 + 活跃度排序

这些场景的核心特点：
– 数据量：几千到几十万记录
– 查询频率：每秒几次到几十次
– 功能需求：关键词搜索 + 基础排序
– 性能要求：毫秒级响应即可

2.2 搜索的本质原理

搜索引擎的核心逻辑：
1. 分词：将文本拆分成可搜索的单元
2. 索引：建立从词到文档的映射
3. 查询：用户输入词，返回相关文档
4. 排序：按相关性对结果排序

关键洞察：
– 这些步骤都可以用SQL实现
– 数据库的JOIN和聚合功能足够强大
– 复杂度主要在算法，不在技术栈

3. 简洁方案的可行性

3.1 数据库搜索的技术可行性

MySQL的优势：

成熟稳定：几十年验证，无隐藏坑
生态完善：工具、文档、社区支持
运维简单：备份、监控、调优都成熟
成本低廉：硬件要求低，云服务便宜

关键技术点：
– FULLTEXT索引支持基础全文搜索
– 复杂JOIN可以实现复杂查询逻辑
– 聚合函数可以计算相关性得分
– 事务支持保证数据一致性

3.2 简洁架构的核心优势

开发效率：

开发时间：1周 vs 1个月（Elasticsearch）
学习成本：SQL基础 vs 分布式系统专业知识
调试难度：单机数据库 vs 分布式集群

运维效率：

部署简单：单机部署 vs 集群部署
监控容易：数据库监控 vs 分布式监控
备份简单：mysqldump vs 分片备份
故障恢复：重启即可 vs 复杂故障转移

4. 权衡的艺术：什么时候用简单方案

4.1 适用场景判断

适合简单搜索方案的场景：

数据量：100万记录以下
并发：每秒100次查询以下
功能：基础关键词搜索 + 相关性排序
团队：中小团队，资源有限

需要专业搜索方案的场景：

数据量：千万级以上
并发：每秒千次以上
功能：复杂的语义搜索、实时分析
团队：大团队，有专门的搜索工程师

4.2 渐进式演进策略

第一阶段：数据库原生搜索
– 快速验证搜索需求
– 积累搜索算法经验
– 了解用户真实使用模式

第二阶段：搜索优化
– 添加缓存层提升性能
– 优化权重算法提升准确性
– 添加高级搜索功能

第三阶段：专业方案（如需要）
– 数据量或复杂度超出数据库能力
– 有专门的搜索团队维护
– 业务需要高级搜索功能

5. 实际案例：成功的简洁搜索系统

5.1 案例分析

中小型电商网站：

商品数量：10万SKU
日均搜索：5万次
技术方案：MySQL + 自研搜索算法
性能表现：平均响应时间 < 100ms
维护成本：1名开发人员兼职维护

内容管理系统：

文章数量：50万篇
搜索频率：每秒10次
技术方案：PostgreSQL + 全文搜索
准确率：用户满意度95%
扩展性：支持多语言搜索

5.2 成功关键因素

技术因素：
– 合理的数据库设计
– 有效的分词策略
– 简单但有效的权重算法
– 适当的缓存策略

业务因素：
– 明确搜索需求边界
– 持续的用户反馈收集
– 渐进式功能迭代
– 性能监控和优化

6. 本章总结

6.1 核心认知转变

从复杂到简洁：
– 不盲目追求”专业”方案
– 重视实际效果而非技术复杂度
– 选择适合业务规模的技术栈
– 关注长期维护成本

从跟风到独立思考：
– 质疑标准答案的适用性
– 理解技术选择的权衡因素
– 基于第一性原理做决策
– 构建自己的技术判断力

6.2 下章预告

下一章我们将深入搜索引擎的核心技术：Tokenization的艺术。你将学到：

• 四种核心分词策略的实现原理
• 如何用PHP实现完整的Tokenizer系统
• 分词质量对搜索效果的决定性影响
• 内存使用与性能的平衡艺术

思考题：你当前的项目中，搜索功能真的需要Elasticsearch吗？重新评估你的技术选择。

上一篇 → 系列首页 | 下一篇 → 第02章：搜索引擎核心原理