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
暂无签名
Java 避坑指南：Java 高手笔记代码篇
本迷你书包括 86 个业务开发中常见踩坑点。每一个知识点都相当的实用，是程序员业务开发中的必备避坑指南...
评论