引言

所谓搜索引擎，就是能够搜索任何文本的全文检索，全文检索要经过索引化才行。本文不是说 Google 或者 Bing 那些搜索引擎，而是针对你自己所产生的数据来进行检索。都是搜索 Google 或者 Bing 这类可以参考一下但是搜索你自己的数据。

Zinc 源来

我当初想找个简单的日志索引工具，不过当下的都用不起（消耗资源太大了），而且都老态龙钟超过十年的搜索技术，—— 结论就是找不到合适的。

我需求是：

• 占资源低
• 磁盘搜索（On-disk ）而不是内存搜索（In-memory）
• 简单安装和运维
• 无约束索引（Schema-less indexes）
• 有浏览数据的 GUI

当下没有一款符合以上需求。关于选型我看过很多，在这篇博客的后面列出一个清单，其中包括我所关注的一些主要产品，以及一些由个人作为爱好/副业项目创建的项目，希望能使用它们或在它们的基础上搞事情。一开始我是没打算直接开撸一个新项目的，就是想看看现有的能否“拿来主义”，后来发现不行，于是自己干吧。

我也看过来自 Grafana 实验室的 Loki，相当不错，但是没有全文检索，除非要 Grafana。

我试着扩展 typesense、sonic 和 toshi，写了一些东西，但没成功。

综上所述，Zinc 走起~

Zinc 啥玩意?

Zinc 就是搞全文搜索的搜索引擎。Go 写的，开源。 Zinc 没有从头开始建立索引引擎，而是建立在 bluge 之上，这个 bluge 肯定好我才会用。Zinc 特点如下。

• 无约束索引（Schema-less indexes）
• 占资源低
• 简单易用的 GUI，轻量级
• 内建认证
• 为编程有简单的 API
• 兼容 Elasticsearch 的 API（Ingestion 摄入 - 单一记录和批量 API），方便 Elasticsearch 迁移过来

RoadMap 是：

• 高可用
• 分布式读写
• 地理搜索
• 内存索引存储
• S3 的索引存储
• 你给建议我（Github 下单）

如果你不懂现今主流的搜索项目，那我跟你说说，就是这个最牛最多人用的 Elasticsearch。

下列所有的搜索引擎都基于倒排索引的索引方法。Lucene 是最早流行的库（第一版 1999 年发布），当时就引入了这种索引方法，一直到 Elasticsearch 也是。并发扬光大。

Elasticsearch/OpenSearch 科普

Elasticsearch 是创建于2000年底的搜索引擎，由 Elastic（2012年成立）开发和推广该产品。Elastic 还提供托管 Elasticsearch 服务。

Elasticsearch 满足了不同客户的各种搜索需求。在我个人经验中，大多数技术公司使用 Elasticsearch 来存储和搜索他们的日志。许多 SaaS 的日志服务都用 Elasticsearch 来做，如 greylog、logdna、loggly、logz.io 等。

2021年1月，elastic 将 Elasticsearch 的许可从 Apache 2.0 改为 SSPL（一种非 OSI 批准的开源许可）。因此 AWS、logz.io 和其他人创建了最后一个可用的 Apache 2.0开源版本 Elasticsearch 的分支（版本7.10.2）。

OpenSearch 是开源的（Apache 2.0），也是作为一个托管服务提供的（Amazon OpenSearch）。

Elasticsearch/OpenSearch 固然是一个优秀的软件，它能很好地为你的数据做全文索引的工作。当我第一次使用时，我觉得能够为自己的数据做全文搜索，那真的很棒，而且不用担心像 SQL 中的 WHERE 子句。

我越来越喜欢它了，我也曾向我的许多客户推荐过 Elasticsearch——然而我也清楚了它的资源要求。它是相当重的。它至少需要0.5GB 的内存才能启动，而且由于 JVM 可能需要几 GB 的内存才能正常运行。我不太喜欢用 Java 构建的东西，主要是因为 JVM 太吃资源了。此外，为了用上它你还要学习许多配置参数。

我最主要的一个需求是在几千 GB 日志中快速搜索，包括全文搜索。我对 logdna、papertrail、logrhythm、logz.io 等这些日志服务进行选型，对于个人项目来说收费不便宜。亚马逊的 Cloudwatch 不错，跟 logdna 一样即用即付的。我也在寻找合适的托管开源方案。

除了 Elasticsearch/OpenSearch 还有谁?——我发现有这两类的搜索引擎。

搜索引擎的类型

有一种搜索起来特别快的（内存型搜索），另外一种是为了大数据搜索的，放在磁盘或闪存上的（On-disk 搜索。其实也不慢）。

类型 1 - 内存型搜索

这类搜索索引存储在内存中，肯定快到没朋友。Algolia、Meilisearch 和 typsesnse 就是此类佼佼者。常见的例子有即时搜索，例如你敲键盘输入的时候。在一些数据量少的场景，不是几千 GB，当然在几百万记录以下都算，你可以可以使用内存搜索了，一般都在 50ms 以下的响应时间，够快了吧？

日志搜索不建议使用内存搜索，内存都放不下，当然也不一定，看怎么样的算法和场景。

类型 2 - 磁盘型搜索

Elasticsearch/OpenSearch、manticore、sphinx 属于此类。对于海量数据（达几个 TB），除了磁盘也没其他好地方呆了。空间打了，检索时间也变长了，虽然没内存型那么快，但也足够可用了。优化好的可以在 100ms 内搜索几千 GB——足够应付大部分应用程序。

下面我们继续深入每一类的搜索引擎，先讲讲内存搜索。

类型 1 - 内存型搜索

Algolia

神奇的搜索服务，有很多流行的使用案例和大量的用户。Algolia 只作为一种服务提供，你不能在你自己的服务器上托管 Algolia。定价是基于记录数量和搜索量的，存储大量的数据对大多数情况下来说成本过高。Algolia 有很多连接器，调试变得简单。Algolia 还创建了一个名为 instantsearch.js 的 Javascript 库，使其更容易在 Web 开发中实现 UI。

Typesense

Typesense 是开源 C++ 搜索引擎，占资源低。可以用 Docker 部署那就很爽，也可以在 kubernetes 的 HA 模式中安装。设置 typesense 超级容易，而且性能很好。它使用 raft 进行高可用。Typesense 还提供了一个全面管理的云服务。

Meilisearch

Meilisearch 是开源 Rust 搜索引擎，以 Algolia 为灵感。Meilisearch 跟 Typesense 挺像，但目前还没有高可用模式。

类型 2 - 磁盘型搜索

Elasticsearch/OpenSearch

基于 Apache Lucene，Java 写就，天生集群高可用，可达 100 个集群节点。

Apache Solr

同样基于 Apache Lucene，功能跟 Elasticsearch 差不多，通过 Apache Tika 来提取文档，如 .doc 和 .pdf，并对其进行索引。在最初的日子里，需要一个严格的模式，但现在不需要了。因此如果你正在寻找索引文件（.doc, xls, pdf, …），那么 Apache Solr 是最佳选择。为可靠的操作还提供了 HA 的模式。

Sphinx

Sphinx 是开源 C++ 搜索引擎，部分开源（GPL 2），旧版本 v2 开源，v3 闭源了。

Manticore

Manticore 是开源 C++ 搜索引擎（GPL 2），其特色在于最初使用 SQL 搜索，基于 HTTP 或 MySQL 协议传输 SQL。通过同步复制提供 HA 模式。

Sonic

Sonic 是开源 Rust 搜索引擎（MPL），其特色在于不存储被索引的整个文档。当搜索时它返回文件的 ID，通过 ID 来从另一个数据存储中获取整个文件。这就需要至少多一个数据存储来保存实际数据。这可能不是一个好的方案，取决于你的使用情况。如果你已经有另一个数据库，如 MySQL/Postgres/DynamoDB，那么 sonic 配合很好的，但是如果你想直接将数据输入 sonic，那就不行。

Sonic 没有提供 http 接口，取而代之的是一个 sonic 协议，可用来与 sonic 交互。客户端库可用于多种语言。

Quickwit

Quickwit 基于tantivy，继承了 tantivy 的优点（高性能）和缺点（严格的模式要求）。数据存储在 S3上，将存储和计算解耦，这一点很不错。

个人项目

这些都是个人爱好的小项目，看起来主要是为了学习而问世的。

• Toshi 基于 tantivy，前面说过
• Bayard 基于 tantivy，类似于 Toshi
• Blast 基于 bleve，分布式的
• Riot，不维护了

索引库

另外谈谈索引库。这些都是库，不能直接使用，或者使用里面的核心功能。

• Java，毫无疑问王者是 Lucene，直接使用或者使用 Elasticsearch/Solr 都可以，不强制要求严格模式。
• Rust，Tantivy 索引库很快，需要严格模式，但某些程序对于严格模式却不太好。
• Go，Bleve 很流行。而 Bluge，Bleve 作者 Marty 的后继产品，如果开始新项目，那么应从 Bluge 开始。Bluge 使用起来非常简单，有如基于磁盘和内存的索引这些不错的功能，而这些功能是其他软件所缺乏的。再加上非常低的资源要求，Bluge 对于大多数应用程序来说是一个非常好的选择。
• C++，Pisa/Xapian

结论

1. 不同使用场景有不同的搜索引擎
2. 推荐使用 Zinc