论文阅读——SSD In-Storage Computing for Search Engines

Smart SSD是否适合search engine还未有人探索果。本文总结了searchengine中可能适于Smart SSD的5种应用：intersection,ranked intersection,ranked union,difference and ranked difference.基于Smart SSD实现以上应用比常规的搜索引擎延时上缩短2-3倍，功耗上降低6-10倍。

Abstract

鉴于各大搜索引擎公司（百度、必应、谷歌等）都用SSD取代HDD，本文也聚焦于构建一个纯SSD的系统。
常规的计算体系SSD做纯存储用，CPU做计算，二者通过SATA/SAS连接。
但SSD不仅仅能做存储，SSD部分可以看出包含嵌入式的CPU（通常是个Arm核）、内存DRAM和外存Flash芯片，而且DRAM和Flash内部带宽是host interface的好几倍，bottleneck所在就是hostinterface 的bandwidth。
尽管SSD做计算的缺点之一就是算力不如CPU，但也有两大好处（对于I/O访问密集型以及计算简单型操作）（1）内部带宽更快（2）比CPU的能耗更低
本文是前一篇（SSD In-Storage Computing for Intersection)的进阶版，主要了：
（1）探索了Smart SSD用于搜索引擎的更多应用，除了Intersection还加入了Ranked Intersection,Ranked Union,Difference,Ranked Difference.
(2)从全局、系统的角度进行分析，除了在合成数据集还在真实数据集中进行了测试。

Section II

Part A SSD相关
一个Smart SSD架构包括：NAND Flash阵列、DRAM内存、以及SSD Controller
SSD Controller:
Host Interface Controller:处理从host interface(SATA,SAS,PCIe)发送来的指令并且分发给processoer
Flash Controller：接受由embeded processor发过来的指令+运用FTL实现将闪存的操作虚拟成磁盘的独立扇区完成逻辑到物理地址的映射。
DRAM Controller：DRAM中存的是较为不重要的代码或数据，processor旁的SRAM存的是critical code & data
SSD软件架构和上一篇一样
Part B Search Engine
一个搜索引擎包括以下3部分：
Front-End Web Server：接受用户请求并返回检索结果
Index Server实现对网页内容进行检索，返回最相关的信息的ID
Document Server：根据index server提供的ID返回对应的网页。
本文只聚焦于IndexServer的实现
Part C SSD适用分析
（1）适合I/O intensive 原因：内部bandwidth是host interface的几倍；延时也更低
（2）SSD不适用的地方-CPU intensive & memory intensive：ARM较低的时钟频率比不过CPU，SSD访问DRAM由于cache的限制没有CPU访问DRAM快

与Index Server分析
Step S1:涉及到分词、词干提取等CPU访问密集型
Step S2:键值匹配的I/O操作不熟很密集，在此 也不进行offload
Step S3：倒排索引根据属性值记录索引地址，是I/O intensive的，在此进行Smart SSD 的offload
Step S4:搜索引擎常见操作：词汇取交集、连接、求差异
Step S5:计算相似度并且排列

Section IV 具体实现

搜索引擎基本操作的实现，包括intersection,union,difference,ranked operations
索引格式：（ID,doc freq,position)
Part A Intersection
首先需要从flash中将数据读到DRAM memory里，在在SSD内部执行intersection算法-adaptive algrithm，但在List较短时使用sortmerge algrithm。
在进行intersection是由两种解决方案第一种对device memory的容量有要求，至少是最短List的两倍；第二种采用分块，不论长短一律切块。
Part B Union
访问memory的次数约等于2u*（L1-Lm的长度），取决于list的数目和最终结果的大小
Part C Difference
Difference实现的是找出A中存在B中不存在的结果放入result set中，本文使用binary search，当list较短时切换到linearsearch.
Part D Ranked Operations
搜索引擎能够将最相关的结果返回给用户通过以下两部完成：（1）匹配度计算（2）排列 这会消耗大量的CPU资源因此也放在SSD内实现。
采用BM25算法计算相关性并排序，考虑到SSD资源有限，我们存储的不是实际的document freq而是计算得到的分数（score),并将top-10的结果以堆的形式存放在SRAM中。

Section V 实验分析
简要分析了如何offload任务来权衡性能和功耗。还是涉及到prformance和energy的分析。

Section VI 实验设定
采用的数据集：搜狗提供的数据和querylog。基于此生成实验所需数据集。
比如生成list A/B 切分成2-8部分尽可能贴近真实的检索情况，相关参数还有intersectionratio,list size.
硬件平台：i7+8G memory,SSD:processor=Arm quad-core，400MHz,SAS HBAinterface+interbal bandwidth=2.2GB/s
软件代码用C++写不是Java

Section VII实验结果分析

主要对执行各种操作（Intersection Union,difference以及ranked operation)用Smart SSD实现的latency 和energy。
Part A Intersection
用smart SSD时间加速2.2x功耗降低6.7x（主要得益于内部带宽以及低IO延时，功耗降低得益于数据搬运的少了）
很明显看出主要时间花费在load data以及memory access和computation上。
而Skewnessfactor会增加随机访问的难度；而intersection ratio看起来似乎和performance没什么联系。
list number的增加则会增加latency以及energy而放在SSD里则有效减少了IO上数据传输的时间。

Part B Ranked Intersection
和intersection不同之处在于将S3-S5都交给SSD可以减少数据传输量，只把最后排列后结果返回给CPU，当AB序列长度相当时主要影响因素是intersection ratio

Part C Difference
latency:2.7x
energy:9.7x
对于A-B和B-A shorter A的情况下Smart SSD只适合前者。

Part D Ranked Difference
把排列操作分解到SSD上实现虽然减少了数据移动但增加了ranking的cost，因此只有当结果的规模较大的时候才能显示初Smart SSD的优势。
Part 5 Ranked Union
latency:1.7x
提升效果不高的原因是需要频繁访问memory

Summary

将搜索引擎的基本操作offload给smart SSD完成，不管是涉及到排序与否都有一定时间和energy上的提升，尤其当List较多，list长度较长以及低intersection ratio的情况下。但对于union operation由于需要频繁访问memeory并不十分适合offload。

以上两篇主要是Smart SSD在搜索引擎上的分解，主要了解了SSD里面的架构、评测的指标以及加速的原理。