SF1R是一个分布式的存储搜索一体化海量数据引擎。SF1R来自于iZENECloud团队多年的 研发成果，并且已经在商业网站上经受住了严苛的考验。2014年，iZENECloud团队把SF1R 开放给社区，采用Apache License 2，希望共同改进和维护。

Note

SF1R的全称是Search Formula 1 Revolution，SF1R是iZENECloud团队给搜索引擎项目使用的内部代号。

SF1R是一个存在多年的项目，完全基于C++语言开发，最新的master分支已经可以用 C++ 11编译。SF1R在早期开发时，参考了流行的Lucene的索引设计，并进行了若干改进， 这里边包括实时索引，以及更好的压缩手段如PForDelta以及NewPFor。然而在使用过程 中，我们发现Lucene这种完全基于文件的索引应对高并发和低延迟方面不具有优势，鉴于 绝大多数大规模搜索引擎的索引均完全放置于内存中，iZENECloud团队又给SF1R添加了 两种索引Zambezi和Suffix，这2种索引均是业界最佳的设计，大大提升了SF1R的性能， 在后边将分别提到。iZENECloud团队在根据需求不断调整SF1R的过程中，给SF1R添加了众 多的功能，包括各种数据挖掘特性，以及集成了推荐引擎，使之成为一个庞大的搜索，存储， 推荐，挖掘一体化引擎，项目也因此变得臃肿不堪。因此，在2014年，iZENECloud团队针对 老版本的SF1R进行了大量裁剪，把不需要的数据挖掘，以及推荐引擎都从项目里删除，只留下 搜索和存储，这就是SF1R-Lite项目，感兴趣的朋友可以从提交历史里恢复这些裁剪。

社区目前绝大多数应用都已经采用Lucene，以及基于Lucene的一系列搜索解决方案比如Solr 和ElasticSearch，这些搜索方案经过十多年很多人的改进，在通用化方面已经非常优秀。那么 基于此，为什么还要再采用新的搜索方案呢？ 这里边有3个原因：首先，基于Java的搜索方案， 在面临高压力场景时，由于GC的存在而时常有延迟抖动发生，SF1R在实际应用中，可以做到跑满 全部CPU（例如16核），并且7*24不间歇的运转而没有上述抖动；其次，SF1R采用的2种内存索引， 在性能上远高于常规方案，更能满足对性能要求苛刻的应用，在实际应用中，SF1R曾经在单一节点 上部署和索引了上亿文档，仍然提供快速响应；第三，SF1R是一个完整的服务端引擎，可以方便的 对索引和其他功能进行扩展。相比Lucene社区的庞大代码仓库，SF1R的项目要精简得多，因此更加 便于针对特定场景进行修改和维护，这从SF1R支持3种索引结构就可以看出，此外，针对广告检索， SF1R也可以方便扩充第4种索引，这些都是传统搜索解决方案Lucene不具备的。

Zambezi索引来自于 Zambezi 项目，索引的原理可以参考相关的论文，这是传统倒排索引结构里的最佳设计之一，因为它可以做到在 提供实时搜索的功能下不损失查询性能，因此非常适合作为Twitter或者微博搜索服务。在引入Zambezi 到SF1R的过程中，iZENECloud团队又进行了若干改进，这里边包含：原始Zambezi索引完全为Twitter 类查询服务，因此，对于不常见的词（比如在少于128个文档里出现），原始设计进行了剪枝，既无法在 索引中搜索到。iZENECloud团队的改进去掉了这种限制；此外，iZENECloud团队还引入了一些最新的索引 压缩技术并且加以改进，比如 SIMD intersection ，使之具备最高速的解压方案。

Suffix索引采用了罕见的Succinct Self Index结构，基础设施是Suffix Array和Wavelet Tree， 具备完全不同于倒排索引的结构，相关的原理可以参见SF1R的技术报告。Suffix索引具备远高于传统索引的查询性能，缺点是构建的时候需要占用大量内存，并且无法支持增量。

您可能感兴趣的文章: