Sonic : 一个轻量无模式的搜索后端

Sonic 是一个开源的、无模式的搜索后端，能够在某些情况下中替代 Elasticsearch 等全功能的搜索系统。Sonic 能够规范自然语言的搜索查询，提供自动补全功能，并为搜索查询返回最相关的结果。与文档索引相反，Sonic 实现了一个标识符索引，其查询返回了一个可以被外部数据库解析的 ID 列表。Sonic 由 Crisp 的工程师设计，主要用于 Crisp 客服消息服务的搜索。

Sonic 中的索引数据存储在由桶结构组成的集合中。Sonic 可以使用单个桶，也可以通过配置使用多个桶，这样就可以为不同的搜索用例定制不同的索引。搜索查询返回了用于外部数据库解析的对象标识符。这样的设计决策最大限度地减少了磁盘上存储的数据。Sonic 提供了额外的功能，例如查询中的拼写错误更正，查询词自动补全，并对超过八十种语言提供了 Unicode 支持。查询和索引是通过 Sonic Channel 协议完成的，该协议对 Node.js、PHP、Rust、Go 和 Python 等语言都提供了 支持 库 。

Sonic 搜索引擎由一个 倒排索引 组成。要索引的句子被拆分成单词并存储为键值对，单词为键而句子则为索引值对象，在查询匹配时返回该对象。数据存储在 RocksDB 支持的键值数据库中。当从一个索引中添加或删除对象时，将会有一个后台作业专门负责索引的更新，这样搜索时就能够获取最新的索引。Sonic 由 Rust 语言编写，这是一种专注于安全性的现代编程语言，它提供了一个编译的二进制文件，并且没有垃圾收集器，因为垃圾收集器会影响 Sonic 的实时内存管理需求。

根据 Crisp 的联合创始人 Valerian Saliou 所述，Sonic 的灵感来自于 Redis 的轻量级开源设计。Sonic 又被称为“搜索中的 Redis”。为了实现类似的轻量级实现，Sonic 的设计师在决定其新功能时遵循以下标准：

• 这个功能真的需要吗？
• 我们怎样才能让它变得简单？
• 添加该功能后，Sonic 仍然是快速和轻量级的么？
• 这个很棒的功能会让 Sonic 变得很难配置么？

为了满足这些标准，Sonic 的开发者需要做出一些取舍。自然语言处理（NLP）系统工作在词而不是句子的层面，它可以预测词，但不能预测句子中的下一个词。这个决策允许使用 有穷状态转换器（ FST） 图，能够修正输入错误，保持浅显，从而降低了时间和空间的复杂度，也最小化了存储需求。Sonic 对 FST 重建周期进行批处理，这意味着对搜索索引的更新并不是完全实时的，新的索引在下一个构建周期之前可能不会出现。此外，Sonic Protocol Channel 是目前唯一支持与 Sonic 交互的协议，HTTP API 仍然不支持。

用户可以在 Crisp 帮助页面 进行 Sonic 在线测试。更多关于 Sonic 安装和管理的信息请参阅 Sonic Github 页面 。

原文链接：

Sonic: A Lightweight, Schema-Less Search