5.5.2. Facet技术优势

1. 与ES对比

lsql的facet：

• lsql可以针对万亿规模的数据进行秒级的统计。
• lsql的facet并非采用将数据加载到内存的方式，而是使用非常少量的内存
• 磁盘采用近顺序读的策略，吞吐量高.
• lsql在索引合并与查询中并不需要不断的重构内存，在数据实时入库下，边入边算的性能也会比开源方案性能好。

开源ES的统计：

• 目前开源的实现只能针对10亿规模以下数据的秒级统计
• 采用docvalues 需要将映射加载到内存，需要大量的内存
• docvalues采用随机读写，磁盘在随机读写的吞吐量上相对于顺序读写相差一个数量级
• 每次commit 造成的小索引合并，都要重构docvalues内存映射，对CPU与磁盘的消耗太大。

2. 与Solr对比

​ Facet这个词取自Solr，相对于Solr这个竞品，LSQL在facet上具有如下技术优势，也是实现在万亿级别能够进行秒级统计的技术基础。

(1) 在读取数据上，Solr需要一条一条的从磁盘随机读取，而lsql是一批一批的顺序读取，而磁盘的顺序读写的性能要远远高于随即读取。

(2) 在null值的处理上，如果null值占比很高，Solr针对null值也要进行一次判断，如果null值可以直接跳过的话会大幅度提升计算速度。而lsql则不需要对null值进行计算。

(3) 在异构策略上，因实际项目中考虑项目的经济性，往往将SSD硬盘、SATA硬盘等多重硬盘混合在一起使用。这这种策略下，通常将随即读写较多的索引部分存储在固态硬盘上，而将数据和备份存储在相对比较廉价的SATA盘上。因存储机制的不同Solr的统计实现是从SATA盘上获取数据而再进行统计的，lsql是从固态硬盘上读取，两种盘的性能截然不同。

(4) 在内存上，Solr是将一个列的值或者ord全部构建在内存里，内存消耗大,因现实项目预算不可能提供几百tb规模的内存，故百亿以上根本不可能。而lsql则没有这种问题，lsql仅消耗少量内存来计算，不像Solr那样过分依赖内存。

(5) 在实时数据导入上，Solr会因数据的实时变动而不断的对内存映射进行重建，重建开销太大了，所以通常来说Solr在统计模式下只能处理静态索引。而lsql这种方法，数据可以实时导入，而且还能同时进行facet统计。

(6) 在存储上，Solr需要同时创建索引和存储部分才能进行统计，null值也必须占用空间，而新技术仅使用索引部分，存储体积比原先能减少至少三分之二，且null不占存储。

(7) 在计算上，万亿场景针对每个分组，用户可以接受只要告诉用户这个分组的数据条数超过xxx(如5000条)即可，不必全部计算。Solr必须要将每个分组的数据全部计算完毕才能返回，很多计算是浪费掉的，而lsql则支持这样的操作，不用将每个组全部条数据都计算出来，达到设定的条数后，就可以直接开始计算下一组的数据。

(8) 在检索上，万亿场景没必要将匹配到的数据全部返回，用户大部分情况下看不了那么多，往往用户会设定一个阈值，系统只需要返回匹配到的前一万条即可。Solr的检索必须要检索到全部的记录才行，即使匹配了上万亿，也要全部检索出来，Solr不会对是否已经达到了匹配条数而进行判断，而lsql可以通过设定一个期望返回的数据条数，如10000。在检索过程中达到期望值后直接中断返回。除此之外，lsql是先查最近几天的，如果最近几天的数据能满足达到10000条的要求，则后续几天的数据就可以不必进行检索，而直接返回了。而往往最近几天的数据是存储在固态上的，返回很快，通过这种方式减少计算量，重而提升整体响应时间。

(9) 在大范围扫描上，Solr对像1 ，2，以及大范围的range扫描这样的查询会直接查挂，系统会直接崩掉。而lsql技术则不会，对此有较好的处理，不会查挂。

(10) 在任务管控上，Solr针对一个已经发出去的请求无法撤销，即使SQL写错了也不行，必须执行完毕。而lsql每个查询都有超时时间的限制，如果超过配置时间没有执行完成，会自动杀掉。可以看每个查询的执行进度，也可以直接kill掉。