elasticsearch in查询_Sonic：用Rust编写的Elasticsearch的极简替代品

本文是对Sonic的创建者Valerian Saliou的采访，也可以帮助我们对Sonic有一个比较全面的了解。
原文 ： https:// notamonadtutorial.com/s onic-a-minimalist-alternative-to-elasticsearch-written-in-rust-7f3612ecb47b
Sonic源码： https:// github.com/valeriansali ou/sonic
本文只是重点摘要

什么是Sonic？
Sonic是一个开源搜索索引服务器，用Rust编写。它构建简单，高性能且轻量级。 Sonic接受用户查询，并返回标识符。这些标识符指的是关系数据库中的实际文档（例如，在我们的案例中：消息，文章，CRM联系人等）。 Sonic不存储文档，这使得整个系统在存储方面简单而有效，因为从Sonic获取搜索结果的应用程序必须从另一个数据库（例如，MongoDB，MySQL等）提取实际结果数据，因为搜索结果返回的是ID）。为什么要创造一个除Solr、ElasticSearch之外的新选择？
我（sonic作者）经营一家名为Crisp的公司，为100,000名用户提供客户支持软件。用户想要搜索他们的消息，我们的一些用户有很多消息。事实证明，使用传统的开源搜索索引软件（例如Elasticsearch等）对我们的免费增值商业模型来说太贵了，因为这些系统很重，因此需要巨大的服务器CPU和RAM。
作为开发人员和系统管理员，我非常喜欢Redis的简单性和速度。在计算机软件中，简单性通常提供速度，这在规模上是一件好事。我将Sonic打造成“可搜索的Redis”：简单的功能，简单的网络协议。你为什么决定使用Rust？使用Rust创建Sonic是一种什么样的体验？
Rust使整个开发体验更加顺畅。语言的约束（例如，借用检查器，没有NULL值的事实）保证在生产中运行项目时不会遇到某些类型的错误（例如，NULL指针异常和分段错误，这些是在C，C ++或Go等编程语言中不可避免; 是人就会犯错误）。
我过去已经构建了其他Rust项目来大规模支持Crisp基础架构，例如Bloom，Vigil和Constellation（它们也已经在GitHub上开源）。 Rust对我来说不是什么新鲜事;总的来说，我喜欢使用这种语言。我2年前的第一个Rust项目有点粗糙，因为你必须花很多时间借助借助检查器“无缘无故”阻挡你。一旦你了解它的工作机制，你就会变得更有效率，并且Rust借用检查器错误也会逐渐变得更加罕见。
总的来说，我可以说在Rust中编写Sonic的经历非常棒。我爱Rust。它也使我成为一个更好的程序员。（同感）什么是Sonic Channel？这个功能的灵感是来自Redis吗？
Sonic Channel用于通过网络与Sonic通信的协议。由于当今大多数应用程序基础结构都通过网络分布在多台计算机上，因此需要一种基于TCP的协议来将新文本数据推送到索引并查询索引。出于性能原因，我不想像Elasticsearch那样编写基于HTTP的协议。
在发布Sonic之后，我从社区中获得了很多贡献，为最流行的编程语言构建Sonic Channel库（集成）：Go，Python，Ruby，Java，PHP和JavaScript（仅在NodeJS上运行）。这使开发人员能够以他们喜欢的编程语言从他们的应用程序中推送数据并搜索Sonic中的项目。它使整个Sonic集成过程更容易调用REST API，更简洁。您使用哪些数据结构来支持创建索引和自动完成？
索引存储在LSM（Log-Structured Merge-tree）中，底层使用了RocksDB。为了自动完成，Sonic使用FST (Finite-State Transducer，有穷状态转换器），BurntSushi在他的博客上的一篇文章中详细解释了这一点。
FST存储在磁盘上，用于每个Sonic（集合，存储桶）对，并且是内存映射的，这意味着实际的FST数据不会加载到RAM中，但访问速度仍然很快。我正在使用的Rust FST实现的缺点是任何构建的FST都是不可变的。如果Sonic存储桶中出现一个新的词，则需要将其推送到FST，因此需要重新构建新的FST。 Sonic定期为变异的FST运行合并任务，并在磁盘上添加或删除它们的词。
FST结构不仅用于自动完成，还用于拼写错误校正（例如，它能够将“Englich”校正为“English”）。它使用Levenshtein自动机来实现这一点（给定最大Levenshtein距离相对于单词的长度;即，单词越长，允许的拼写错误越多）。你为什么选择RocksDB作为存储？
RocksDB（来自Facebook）建立在LevelDB（来自Google）上。
它非常擅长在巨大的密钥空间保持性能稳定，并通过压缩旧数据来最小化磁盘使用（它具有分层数据存储架构，旧数据处于较低级别，可以通过较高但较慢的比率进行压缩或压缩）。
RocksDB改进了LevelDB，并且非常易于配置。这意味着Sonic用户可以通过Sonic配置调整RocksDB的内部结构，以便在服务器硬件的情况下充分利用其设置。Sonic现在有什么文档？
我写了一篇博文，总结了Sonic的工作原理。后续还打算写大量的文档来解释Sonic的内部工作原理，这个可以在GitHub issues上跟踪。
总的来说，阅读Sonic代码应该有助于理解它的运作方式。我花了很多时间注释我的代码并使其尽可能清晰。为什么要用jemalloc ？
jemalloc是一个最初为FreeBSD编写的内存分配器。它专为现代CPU架构而设计，在管理多核架构上的内存方面要好得多。但它在单核架构上没有任何好处，但在单CPU的情况下已被证明与旧的分配器一样好。所以在最坏的情况下，它与传统的分配器一样好，最多可以在多核CPU上提供更好的性能并减少内存碎片。
Rust先前使用jemalloc作为其默认分配器，并且最近由于性能以外的原因而移至系统分配器。你之前写过数据库吗？如果别人想构建Sonic这样的工具，你有什么建议？
我已经构建了大量的服务器软件，但我从未编写过数据库。数据库可能很难，因为它们涉及大量的锁定策略以防止竞争条件，因此数据库开发人员必须一丝不苟。锁是很难正确的;生产中的锁更难：编写死锁的代码很容易，同时找到发生死锁的原因是痛苦的。
自己创造新事物的最佳方式是了解其他人过去是如何做到的。所以我建议大家可以先看看Snoic的源码实现。Sonic现在状态如何？还有什么想改进的？
是的，看起来Sonic到目前为止工作得很好。搜索很快，用户很高兴。
我们的Sonic实例索引了5亿个对象（消息，文章，联系人）。压缩索引为20GB，负载下的CPU使用率为1 Intel Xeon核心的10％。 Sonic在最差的情况下使用~200MB的RAM用于如此大的索引，而在冷启动时使用20MB的RAM。搜索延迟低于1毫秒。