一、业务数据库不擅长【找最像的十条】

这一节要解决的问题，可以用两句话划开：

• 业务数据库擅长【准确地找到某一条】——按主键、按订单号，一次命中。
• 它不擅长【从一百万条里挑出最像的十条】。

后一件事就是搜索。搜索引擎就是为它造的。

这一类的排名（DB-Engines 2026 年 10 月，搜索分类共 30 个系统）：

• Elasticsearch 94.11——第一名，放在全部数据库里也能排到第 12。
• Splunk 69.25（偏日志与安全分析）、Apache Solr 32.41（老牌，结构化检索强）。
• OpenSearch 22.72（开源分支，唯一在涨）、Algolia 6.45（托管式）、Azure AI Search 6.33。

注意它是全类别第 12 名——这不是一个小众品类。 搜索被单独拆成一个类别，本身就说明它是一块够大的独立需求。

二、倒排索引：为什么它能快那么多

Elasticsearch 为什么能比数据库快那么多？答案只有一句： 它把索引反着建。

• 数据库里是一行一行存——想知道哪行包含这个词，得逐行看。
• 它里面是一个词对应一串文档编号——查一个词，直接把那张名单拿出来。

这套结构叫【倒排索引】。 代价也很清楚：写入的时候要多干一份建索引的活。

所以它天生适合写少读多的场景—— 日志、商品、文章，写进去一次，被搜上千次。 反过来，如果是高频写入又要求立刻可查，倒排索引的维护成本就会变成负担。

顺带解释了一个现象：搜索为什么能容忍错别字。 因为词被拆开、建了索引之后，模糊匹配就成了一次近邻查找—— 而这在【一行一行扫】的结构里是做不到的。

三、ELK：四块拼成一个系统

一个完整的数据分析系统，通常由四块拼成：

• Elasticsearch——存数据、建索引、执行查询与统计。
• Logstash——从各处收数据、转换格式再送进去。
• Kibana——把结果画成图表和仪表盘。
• Beats——装在机器上的轻量采集器。

四块的分工可以记成一句话：Beats 采、Logstash 送、Elasticsearch 存和算、Kibana 画。 这四块合起来的名字叫 ELK，是日志分析最经典的搭配。

它 2026 年的定位还在往前走——从【搜索和日志】长成了【向量检索】。 也就是把文字、图片变成一串数字向量，再按【相似度】找，而不是按关键字匹配。 今天几乎所有【让 AI 先查资料再回答】的系统，底下都有一层它在撑着。

所以它今天的角色，更像 AI 的记忆库，而不只是一个搜索框。

四、要不要走开源分支：Elasticsearch 与 OpenSearch

用这一类系统绕不开一个选择：官方的，还是开源分支的。

• 许可证：Elasticsearch 是 SSPL／ELv2；OpenSearch 是 Apache 2.0。
• 治理方：一个是 Elastic 公司；一个是 Linux 基金会。
• 新部署占比：53% 对 42%。
• 100 GB 月成本：1200 美元以上 对 800 美元以上。
• 索引速度（1 TB）：Elasticsearch 快 15%~20%。
• 密集向量检索：OpenSearch 快 10%~12%。
• 堆内存占用：Elasticsearch 少 5%~8%。

分岔点是 2021 年：Elastic 把许可证从 Apache 2.0 改成了 SSPL， 于是 AWS 拿最后一个开源版本分了出去，成了 OpenSearch。 一个把它当商业产品经营，一个交给基金会管——路线从此不同。

成本这项最直观：同样 100 GB，每月差 400 美元，一年差 4800 美元（约 3.4 万元）。 所以选择不只是技术偏好，也是一道许可证和预算题。

最后一条纪律，比选哪个更重要： 搜索库不进主流程。 业务数据以数据库为准，搜索库只是同步过去的副本； 同步是单向的，丢了能重建。 把它当唯一数据源，是这条路上最常见的翻车方式。

五、动手 Demo：搜索为什么不能直接用数据库

两个分支的成本差和新部署份额，都可以直接算出来：

diff = (1200 - 800) * 12
print("  100 GB 每月：Elasticsearch 1200 美元、OpenSearch 800 美元")
print("  一年差 %d 美元，约 %.1f 万元" % (diff, diff * 7.1 / 10000))
print("  新部署占比 53%% + 42%% = 95%%，剩下 %d%% 是其他方案" % (100 - 95))

实跑输出：

--------------------------------------------------------------------
搜索为什么不能直接用数据库
--------------------------------------------------------------------
  业务数据库擅长【准确地找到某一条】，
  但它不擅长【从一百万条里挑出最像的十条】。
  搜索引擎就是为后一件事造的。先看这一类的排名
  （DB-Engines 2026 年 10 月，搜索引擎分类共 30 个系统）：

  系统                得分      定位
  ------------------------------------------------------------
  Elasticsearch       94.11     第一名，也是全部数据库里第 12
  Splunk              69.25     偏日志与安全分析
  Apache Solr         32.41     老牌，结构化检索强
  OpenSearch          22.72     开源分支，唯一在涨
  Algolia             6.45      托管式，前端即搜即得
  Azure AI Search     6.33      云厂商自带
  ------------------------------------------------------------
  Elasticsearch 为什么能比数据库快那么多？
  因为它的索引是反着建的——数据库里是【一行一行存】，
  它是【一个词对应一串文档编号】。
  查一个词，不用扫全表，直接把那张名单拿出来就行。
  这套结构叫【倒排索引】，代价是写入时要多干一份建索引的活。

  一个完整的数据分析系统，通常由四块拼成：

  组件              负责什么
  -------------------------------------------------
  Elasticsearch     存数据、建索引、执行查询与统计
  Logstash          从各处收数据、转换格式再送进去
  Kibana            把结果画成图表和仪表盘
  Beats             装在机器上的轻量采集器
  -------------------------------------------------
  这四块合起来的名字叫 ELK，是日志分析最经典的搭配。

  它 2026 年的定位还在往前走——从【搜索和日志】长成了【向量检索】，
  也就是把文字、图片变成一串数字向量，再按【相似度】找。
  今天几乎所有【让 AI 先查资料再回答】的系统，底下都有一层它在撑着。

  另一个绕不开的选择是它的开源分支：

  对比项               Elasticsearch     OpenSearch
  ----------------------------------------------------
  许可证               SSPL／ELv2        Apache 2.0
  治理方               Elastic 公司      Linux 基金会
  新部署占比           53%               42%
  100 GB 月成本        1200 美元以上     800 美元以上
  索引速度（1 TB）     快 15%~20%        略慢
  密集向量检索         略慢              快 10%~12%
  堆内存占用           少 5%~8%          略多
  ----------------------------------------------------
  分岔点是 2021 年：Elastic 把许可证从 Apache 2.0 改成了 SSPL，
  于是 AWS 拿最后一个开源版本分了出去，成了 OpenSearch。
  一个把它当商业产品经营，一个交给基金会管——路线从此不同。

  最后一条纪律，比选哪个更重要：
  搜索库【不进主流程】。业务数据以数据库为准，
  搜索库只是同步过去的副本；同步是单向的，丢了能重建。
  把它当唯一数据源，是这条路线上最常见的翻车方式。

4800 美元这个差额看起来不大，但它随数据量线性放大。 1 TB 就是 48000 美元，10 TB 就是 48 万美元—— 这时候许可证就不只是法务问题了。 另外注意最后一行：两个分支加起来占 95%， 说明这个市场的竞争基本只在这两者之间发生。

30 秒实验

1. 在你常用的网站里故意搜一个错别字，看它能不能给出纠正后的结果——那就是你在用一个搜索引擎。
2. 想一下你项目里所有【按关键词搜】的功能，看它现在是靠数据库的什么子句实现的。
3. 找一台你有的服务器，看它有没有装采集器类的组件在后台跑——那多半就是 ELK 的前半段。

常见误区

1. 错误：有了 Elasticsearch 就不需要数据库了。——纠正：它不进主流程；业务数据以数据库为准，搜索库只是同步过去的副本，丢了能重建。把它当唯一数据源是这条路上最常见的翻车方式。
2. 错误：Elasticsearch 快是因为它代码写得好。——纠正：快在索引结构；它建的是倒排索引（一个词对应一串文档编号），查一个词不用扫全表，代价是写入时要多干一份建索引的活。
3. 错误：OpenSearch 是 Elasticsearch 的旧版本。——纠正：它是分出去的开源分支；2021 年 Elastic 把许可证从 Apache 2.0 改成 SSPL，AWS 拿最后一个开源版本分了出去，此后两者的许可证和治理方都不同。

• ☐ 下一节（9-1 应对威胁的安全措施：非法访问、恶意攻击）

相关笔记

• Web应用后端的构成元素 —— 回看四层结构，这一节是给数据库那一层加了个搭档
• 应对威胁的安全措施 —— 下一章登场：全书最后一章，从威胁的分类与代价讲起
• 实测Web服务器的负载 —— 搜索节点的负载特征和业务节点完全不同
• 是否使用数据库 —— 第七章的第一个检查项，在这里有了另一种答案
• 大数据-收集和分析大量数据 —— 分析型系统在数据库那一侧怎么讲
• 并行处理的动向 —— 大数据的处理为什么靠并行
• 🕸️ Web技术原理 · 索引