Elasticsearch 的诞生:从 Compass 到搜索革命

当 Shay Banon 为妻子开发食谱应用时,他意外发现了一个改变搜索技术的契机...

Elasticsearch 的诞生:从 Compass 到搜索革命

导语

2004年的伦敦,Shay Banon 坐在狭小的公寓里,看着妻子沮丧地翻阅一堆食谱卡片。作为一名厨师,她需要一个更好的方式来管理她的食谱收藏——能够按照食材、烹饪时间、难度来搜索。Banon 是一名软件工程师,他觉得这应该很简单。但现实让他大吃一惊:当时的搜索解决方案要么太复杂(需要学习 Lucene 的内部工作原理),要么功能太弱(简单的 SQL LIKE 查询)。在那一刻,一个想法在他脑海中闪现:搜索不应该这么难。这个为妻子写的私人工具,最终演变成了 Elasticsearch,一个每天为全球数十亿用户提供搜索服务的基础设施,一个市值超过 100 亿美元的商业帝国。这是一个关于爱、代码和分布式系统的传奇故事。


时代背景(Why now)

2000年代中期,搜索技术正处于一个尴尬的境地。

互联网搜索的爆炸

Google 在2004年上市,搜索引擎已经成为互联网的核心入口。用户期望每一次搜索都能在几毫秒内返回相关结果,无论数据量有多大。

企业搜索的困境

但企业内部的搜索完全是另一回事。当时的商业搜索软件(如 Autonomy、Verity、Fast Search)昂贵、复杂、难以部署。它们通常需要:

  • 昂贵的许可费(每 CPU 或每文档计费)
  • 专门的搜索工程师来配置和调优
  • 复杂的硬件架构

中小企业根本无法承受这些成本。

Lucene 的兴起

Apache Lucene 于1999年由 Doug Cutting 创建,是一个开源的搜索库。它提供了强大的全文搜索能力,但使用起来相当复杂:

  • 需要深入理解倒排索引(inverted index)的工作原理
  • 需要自己处理分词、分析、查询解析
  • 没有分布式能力,只能在一台服务器上运行

Lucene 是构建搜索应用的基础,但不是完整的解决方案。

分布式系统的黎明

2000年代,Google 发布了一系列论文,揭示了它们构建分布式系统的秘诀:

  • 2003年:GFS(Google File System)论文
  • 2004年:MapReduce 论文
  • 2006年:Bigtable 论文

这些论文启发了 Hadoop 和其他开源分布式项目。开发者开始意识到,分布式系统不再是超大规模公司的专利,普通开发者也可以构建。

NoSQL 浪潮前夕

2009年 MongoDB 诞生,NoSQL 运动全面爆发。但在2004年,关系型数据库仍然是唯一选择。开发者渴望新的数据存储方案,特别是针对搜索这类特殊场景。

正是在这样的背景下,Shay Banon 开始了他为妻子构建食谱应用的旅程。


产品诞生(Origin Story)

Shay Banon 是以色列人,2000年代初在伦敦工作。他的妻子是一名厨师,正在学习烹饪学校。

“她有很多食谱,写在卡片上、本子上、打印出来的纸上,” Banon 回忆道,“她想找一个更好的方式组织它们——按照食材、烹饪时间、来源分类。我觉得这是一个有趣的编程挑战。”

Banon 首先尝试了 MySQL 的全文搜索功能,但很快发现它远远不够:

  • 不支持复杂的布尔查询
  • 相关性排序很差
  • 性能在数据量增大后急剧下降

然后他转向了 Lucene。Lucene 功能强大,但 API 复杂。为了简化使用,Banon 在 Lucene 之上构建了一层抽象。他把这个项目称为”Compass”(指南针),寓意帮助用户在信息海洋中找到方向。

Compass 在2004年发布,很快在 Java 社区获得了关注。它简化了 Lucene 的使用,提供了 ORM 风格的映射(类似 Hibernate),让开发者可以用声明式的方式定义索引结构。

但 Banon 很快意识到 Compass 的局限。

“Compass 是建立在 Lucene 之上的,” Banon 解释道,“这意味着它继承了 Lucene 的所有限制。最大的问题是,Lucene 不是分布式的。当你的数据量超过单台服务器的内存时,你就遇到了瓶颈。”

2007年,Banon 开始考虑 Compass 的第三个版本。但他意识到,修补现有架构无法解决根本问题。他需要重新思考——从零开始构建一个真正分布式的搜索系统。

“我决定放弃 Compass,” Banon 说,“这是一个痛苦的决定,但我知道这是正确的。分布式系统需要全新的设计。”

2009年,Banon 开始全职投入新项目。他给这个项目起名为”Elasticsearch”——“Elastic”(弹性的)指的是系统的可扩展性,“Search”(搜索)是它唯一的使命。


第一个关键突破(First Breakthrough)

Elasticsearch 的第一个突破,来自于它的分布式架构设计。

Banon 深入研究了分布式系统的原理,特别是 “shared nothing” 架构——每个节点独立工作,不需要共享存储。他设计了一个系统:

自动分片(Sharding)

数据被自动分割成多个分片(shard),分布在集群的各个节点上。开发者不需要手动决定如何分片,Elasticsearch 自动处理。

自动复制(Replication)

每个分片都可以有多个副本,分布在不同的节点上。当某个节点故障时,副本自动接管,确保高可用性。

自动重新平衡(Rebalancing)

当添加或移除节点时,Elasticsearch 自动重新分配分片,保持负载均衡。

RESTful API

Banon 做出了一个关键决定:使用 HTTP 和 JSON 作为通信协议。这意味着:

  • 任何编程语言都可以与 Elasticsearch 通信
  • 开发者可以用浏览器或 curl 测试查询
  • 与 Web 技术栈自然集成

近实时搜索

传统搜索系统需要定期重建索引(“批处理”模式),Elasticsearch 则支持近实时(near real-time)搜索——文档在索引后几秒内就可搜索。

2010年2月8日,Elasticsearch 的第一个公开版本发布。Banon 在博客上写下了那句著名的标题:“You Know, for Search”。

这个看似随意的标题背后,是对复杂企业搜索软件的颠覆性简化。Elasticsearch 不需要昂贵的许可,不需要专门的硬件,不需要搜索工程师——只需要下载、启动、开始索引。

发布后 24 小时内,Elasticsearch 就登上了 Hacker News 首页。开发者们兴奋地讨论这个新工具:

“终于有一个搜索解决方案,既强大又易用。” “分布式搜索,开箱即用。这太棒了。” “Lucene 的潜力被真正释放了。“


扩张阶段(Growth)

2010年至2012年,Elasticsearch 经历了爆发式增长。

早期采用者

GitHub 是最早的大规模用户之一。他们使用 Elasticsearch 为代码仓库、问题、用户资料提供搜索功能。GitHub 的工程博客详细记录了迁移过程,这成为 Elasticsearch 最好的广告。

SoundCloud 使用 Elasticsearch 搜索音乐和音频。 Foursquare 使用 Elasticsearch 搜索地点。 StumbleUpon 使用 Elasticsearch 推荐内容。

这些早期采用者都有一个共同点:数据量大、搜索是核心功能、需要实时更新。

1.0 版本和 Lucene 升级

2014年1月,Elasticsearch 1.0 发布。这是一个里程碑,标志着产品已经成熟到可以承载生产负载。

同时,Elasticsearch 紧跟 Apache Lucene 的更新。Lucene 4.x 带来了重大的性能提升和新功能(如 doc values、更高效的压缩),Elasticsearch 用户自动受益。

Logstash 和 Kibana:ELK 堆栈的形成

2013年,两个重要项目加入 Elasticsearch 生态:

Logstash:由 Jordan Sissel 创建的数据收集管道,可以从各种来源(日志文件、数据库、消息队列)收集数据,处理后发送到 Elasticsearch。

Kibana:由 Rashid Khan 创建的数据可视化工具,可以创建 Elasticsearch 数据的仪表板和图表。

Logstash + Elasticsearch + Kibana 形成了著名的 “ELK 堆栈”(后来 Elastic 公司更名为 “Elastic Stack”)。

ELK 堆栈解决了当时的一个重大痛点:日志分析。

传统上,服务器日志被写入文件,需要手动查看或使用 grep 搜索。随着服务器数量增加,这变得不可能。ELK 堆栈让日志集中化、可搜索、可视化——运维工程师可以实时查看整个基础设施的状态。

日志分析成为 Elasticsearch 的杀手级应用,推动了其在企业市场的普及。


关键竞争(Competition)

Elasticsearch 的崛起,引来了竞争者的关注。

Solr 的挑战

Apache Solr 是 Lucene 之上的另一个开源搜索平台,比 Elasticsearch 早几年发布。Solr 功能丰富,有很长的企业采用历史。

Solr 的优势:

  • 更成熟的功能集(当时)
  • 更多的企业用户
  • 更灵活的部署选项

Elasticsearch 的优势:

  • 原生分布式架构(Solr 的分布式功能后来才添加)
  • 更简单的部署和管理
  • 更好的开发者体验(REST API 对比 XML 配置)

随着时间推移,Elasticsearch 的增长速度明显快于 Solr。分布式架构是决定性的优势——在云计算时代,简单性和可扩展性比功能丰富度更重要。

云搜索服务

AWS 推出了 CloudSearch(后来升级为 Amazon Elasticsearch Service,再后来由于商标问题改为 Amazon OpenSearch Service)。Google 推出了 Search for Retail。这些云厂商试图提供托管搜索服务,与 Elasticsearch 竞争。

Elastic 公司(Elasticsearch 的母公司)的策略是拥抱云,而不是对抗。他们推出了 Elastic Cloud,提供托管 Elasticsearch 服务,支持 AWS、Azure、GCP。这让他们既受益于云计算的浪潮,又保持对技术的控制。

Splunk 的统治

Splunk 是日志分析市场的领导者,成立于 2003 年,2012 年上市。它提供专有的搜索和数据分析平台,价格昂贵但功能强大。

ELK 堆栈成为 Splunk 的开源替代品。对于预算有限的团队,ELK 提供了 80% 的功能,而成本只是 Splunk 的一小部分。

Splunk 和 Elasticsearch 的竞争,本质上是闭源和开源、昂贵和免费、专有和标准化之间的竞争。

Amazon OpenSearch 的分叉

2021年,AWS 宣布从 Elasticsearch 7.10.2 创建分支,推出 OpenSearch。这是因为 Elastic 公司在 2021 年初更改了许可证,从 Apache 2.0 改为 SSPL(Server Side Public License),限制了云厂商的使用。

这场”分叉战争”仍在继续。OpenSearch 获得了 AWS 的资源支持,但 Elasticsearch 拥有品牌、生态和社区的优势。


拐点(Turning Point)

Elasticsearch 的关键转折点出现在2012年至2014年间。

成立 Elastic 公司

2012年,Shay Banon 与其他联合创始人(包括 Uri Boness、Simon Willnauer、Steven Schuurman)正式成立 Elastic 公司,总部设在阿姆斯特丹。

Banon 担任 CTO,Schuurman 担任 CEO。公司获得了第一轮风险投资。

“我们意识到 Elasticsearch 需要一个商业实体来支持其长期发展,” Banon 解释道,“公司可以提供文档、培训、支持服务,同时保持核心代码开源。”

多产品战略

Elastic 公司没有满足于只做搜索。他们开始扩展产品线:

  • Elastic Security(原 Endgame):安全信息和事件管理(SIEM)
  • Elastic Observability:应用性能监控(APM)和基础设施监控
  • Elastic Enterprise Search:企业搜索解决方案,包括 Workplace Search 和 App Search

这个战略转变的背后是洞察:搜索技术可以应用于许多场景——安全日志分析、性能指标监控、企业内部搜索。Elasticsearch 的核心引擎是通用的,只需要不同的界面和集成。

2018 年 IPO

2018年10月,Elastic 在纽交所上市,股票代码 ESTC。发行价 36 美元,首日收盘价 70 美元,市值超过 40 亿美元。

对于一个开源项目来说,这是一个巨大的成功。它证明了开源商业模式的可行性——核心开源吸引用户,商业功能和服务创造收入。


结果(Outcome)

到2024年,Elasticsearch 已经成为搜索和数据分析领域的事实标准。

市场地位:

  • 每天为超过 50% 的财富 500 强公司提供搜索和分析服务
  • GitHub 上超过 68,000 个 star
  • 累计下载量超过 35 亿次
  • 每天处理数十 PB 的数据

用户案例:

  • Netflix:内容搜索、推荐系统、日志分析
  • Uber:实时司机和乘客匹配、定价算法
  • Slack:消息搜索、用户目录
  • Adobe:Creative Cloud 搜索、文档分析
  • Walmart:产品搜索、库存管理

Elastic Stack 生态:

  • Elasticsearch:分布式搜索和分析引擎
  • Kibana:可视化和仪表板
  • Logstash:数据收集和处理
  • Beats:轻量级数据发送器
  • Elastic Agent:统一的数据收集代理

商业产品:

  • Elastic Cloud:托管云服务(SaaS)
  • Elastic Cloud Enterprise:企业私有云
  • Elastic Cloud on Kubernetes:Kubernetes 上的 Elastic
  • Elastic 安全:SIEM 和终端安全
  • Elastic 可观测性:APM、日志、指标、Uptime 监控

技术演进:

  • 向量搜索:支持 AI 和机器学习用例(语义搜索、推荐)
  • 机器学习:内置异常检测、预测、分类
  • frozen tier:低成本存储历史数据
  • 跨集群搜索:跨多个集群统一查询

2024年发展:

  • Elasticsearch 8.x 持续迭代,性能和安全性不断提升
  • 向量数据库功能增强,与 OpenAI、Hugging Face 等 AI 平台集成
  • Elastic 与 OpenSearch 的竞争继续,两者都在快速发展

规律总结(Lessons)

Elasticsearch 的故事,为开源创业和技术产品提供了深刻的启示。

1. 从一个具体的问题开始

Banon 不是为了”改变搜索行业”而创建 Elasticsearch,他只是想为妻子做一个更好的食谱应用。伟大的产品往往始于创始人的个人痛点,因为他们知道什么才是真正重要的。

2. 技术选择决定产品命运

Banon 的几个关键技术决策成就了 Elasticsearch:

  • 原生分布式架构(而非后来添加)
  • HTTP/JSON API(而非专有协议)
  • 近实时搜索(而非批处理)
  • 自动化的运维(自动分片、复制、重新平衡)

这些选择让 Elasticsearch 天生适合云计算时代。

3. 拥抱生态系统

ELK 堆栈的形成不是计划好的,而是自然演化的结果。Elastic 公司明智地拥抱了 Logstash 和 Kibana,将它们整合到产品生态中。有时候,最好的战略是顺势而为,而不是试图控制一切。

4. 开源作为市场策略

Elasticsearch 的核心引擎保持开源(虽然许可证后来有变更),这让它能够快速传播、建立标准、赢得开发者信任。商业功能(如高级安全、机器学习)作为增值服务,为开源用户提供升级路径。

5. 从工具到平台

Elastic 公司的战略演进值得学习:从搜索工具,到日志分析平台,再到完整的安全和可观测性套件。每一次扩展都是基于核心技术的自然延伸,而不是盲目多元化。

6. 云是基础设施的未来

Elastic Cloud 的成功证明了,即使是开源软件,云服务也是最佳商业模式。开发者愿意为便利性付费,而云服务提供了可持续的收入来源。

7. 社区与商业的平衡

2021年的许可证变更显示了开源商业化的挑战。当云厂商(如 AWS)从开源项目中获益而不回馈时,商业实体需要找到平衡。SSPL 是一个有争议的尝试,但它反映了开源世界正在经历的深刻变化。


“我们不是在构建另一个搜索工具,而是在重新定义人们与数据交互的方式。搜索不应该是一个复杂的企业软件,而应该是每个应用的基础能力。”

—— Shay Banon,Elasticsearch 创始人