搜索引擎漫谈以及 Zinc 简介

Posted sp42a

tags:

篇首语:本文由小常识网(cha138.com)小编为大家整理,主要介绍了搜索引擎漫谈以及 Zinc 简介相关的知识,希望对你有一定的参考价值。

引言

所谓搜索引擎,就是能够搜索任何文本的全文检索,全文检索要经过索引化才行。本文不是说 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

以上是关于搜索引擎漫谈以及 Zinc 简介的主要内容,如果未能解决你的问题,请参考以下文章

搜索引擎漫谈以及 Zinc 简介

漫谈ElasticSearch关于ES性能调优几件必须知道的事(转)

ElasticSearch01_简介安装es以及kibana详解倒排索引检索es基本信息增删改查文档

ElasticSearch01_简介安装es以及kibana详解倒排索引检索es基本信息增删改查文档

ElasticSearch入门简介

Zinc 的概念与存储