设备指纹识别系统框架初级调研报告

架构需求

针对设备指纹系统的需求，从技术角度将该系统架构所需要满足的条件进行分解如下：

  1. 满足分布式存储系统AP类型（一致性要求相对较低）；
  2. 海量存储，数十到百亿级数据；
  3. 全文检索（不需要进行分词，若设备指纹组成里面有中文字段值，则需要支持中文检索）；
  4. 检索速度要求至少百毫秒级；
  5. 增加缓存命中（使用高性能可存储大数据量的缓存系统）；
  6. 读比写多的使用场景；
  7. 其他：搜索结果相似度计算可控；有相关辅助分析功能和统计工具等。

技术调研

根据上面分解的需求，将满足基本的要求（全文检索（相似度查询）和分布式（海量数据）存储）的存储系统筛选分类，大致可分为三类：

关系型数据库

以MYSQL为代表的传统关系型数据库也提供了相似度全文检索功能。

MYSQL4.x版本及以上版本替公司全文检索支持，但表的存储引擎必须为MyISAM。mysql5.6版本以下只有myisam存储引擎支持全文索引，mysql5.6以上版本myisam和innodb都支持全文索引: 使用match against。

缺点：

  1. 专业的事要交给专业的技术去做：以MYSQL为代表的关系型数据库的核心功能是存储数据和事务等功能，而并非全文检索；
  2. 检索性能低；
  3. 水平扩展较难，不适合大数据低价值的文档性数据存储；
  4. 全文检索功能很简单，不能满足设备指纹系统需求，如相似度计算可控以及相关的辅助分析功能。

基于此，在后面的框架对比中，关系型数据库将不参加比较。

参考文档：http://www.cnblogs.com/feichexia/archive/2012/06/09/2543049.html。

 

存储型NOSQL
存储型NOSQL有很多，几款主流的NOSQL如下：MongoDB，HBase，redis，Couchbase, Cassandra，SequoiaDB等。各数据库的简单对比可参考：

http://kkovacs.eu/cassandra-vs-mongodb-vs-couchdb-vs-redis

可以看出各数据库有自己的适用场景和特点：

  1. HBase适用于随机数据、实时读取海量数据；
  2. redis适用于数据快速变化，数据库大小可以预见（适合内存存取数据）；
  3. Couchbase适用于有大量数据，但更新不大，需要预先定义查询；
  4. Cassandra适用于写操作较多，读少的场景；
  5. SequoiaDB适用于海量数据存储和实时访问；
  6. MongoDB适用于动态的查询，定义索引而非map/reduce。数据变化快，磁盘不够用，可以使用MongoDB。

 

其中，适合海量数据存储且读写性能较高的有：MongoDB，SequoiaDB，Couchbase，Cassandra；

而直接提供全文检索功能的只有：MongoDB。

（Couchbase和Cassandra有相关的全文检索解决方案，会在后面进行讨论）

下面来分析MongoDB的全文索引方案：

MongoDB直接使用$text,$search即可，实例如下：

db.articles.find({$text:{$search:"coffee"}})
    db.articles.find({$text:{$search:"aa bb cc"}}) #空格代表或操作，aa或bb或cc
    db.articles.find({$text:{$search:"aa bb -cc"}}) #-号为非操作，即不包含cc的
    db.articles.find({$text:{$search: "\"aa\" \"bb\" \"cc\""}}) #加双引号可以提供与关系操作
    相似度查询： 使用{score:{$meta: "textScore"}}

 

分析：

  1. 如mysql一样，MongoDB的全文索引功能很简单，并不能满足复杂的搜索功能；
  2. 而且MongoDB的索引性能比专业的搜索引擎框架（如：es）相比要差一些，参考文档：

           https://blog.quarkslab.com/mongodb-vs-elasticsearch-the-quest-of-the-holy-performances.html

        3. 在网上关于其全文检索方面的信息很少，因此该方案的使用风险太高；

        4. 参考文档https://www.zhihu.com/question/19856707中可以看出，基本上没有人建议使用其自带的全文检索方案。

        5. 其中文检索的支持不好，只有在企业版才有。

 

结论：排除使用存储型NOSQL作为设备指纹系统的存储方案。

关于上面几种数据库的性能对比可以参考：

http://www.csdn.net/article/2013-04-15/2814886-nosql-benchmark?locationNum=16

http://tech.it168.com/a2014/1217/1691/000001691166.shtml

http://tech.it168.com/a2013/0904/1529/000001529489_all.shtml

 

主流全文索引框架

先简单介绍一下这几款框架。

Elasticsearch：使用lucene作为内部引擎，基于restful web接口。相对于lucene，不但包括了全文搜索功能，还扩展了：
1. 分布式实时文件存储，并将每一个字段都编入索引；
2. 实时分析的分布式搜索引擎；
3. 水平扩展，处理PB级别结构和非结构化数据。

   Solr: Solr也是基于lucene，主要功能包括全文检索、命中标示、分面搜索、动态聚类、数据库集成，以及富文本（如Word、PDF）的处理。

Sphinx：使用c++编写，基于sql（内置mysql解决方案）的高性能全文检索引擎，其性能在众多全文检索引擎中也是数一数二的。
由于大多数数据库尚未支持中文全文检索，所以sphinx如果需要中文检索，也得需要一些插件来实现，如：coreseek 和 sfc。

sphinx在使用过程中如果表的数据量很大，新增加的内容在sphinx索引没有重建之前都是搜索不到的。
这时可以通过建立sphinx增量索引，通过定时更新增量索引，合并主索引的方式，来实现伪实时更新。(使用定时任务,定时更新增量索引,例如10分钟一次)

Riak search：riak2.0集成了Apache Solr全文搜索，使用lucene的索引分析器，可以自定义索引分析器，告诉riak如何对文档进行索引。

主流全文检索框架是本次调研的重点，结合架构需求和其他的一些要素，我总结出了以下表格，用于对比分析各框架对设备指纹系统架构的契合度。表格如下：

 

Elasticsearch

Solr

Sphinx

Riak search

编写语言

Java

Java5

c++

Erlang

许可证

Apache

Apache

GNU

Apache 2.0

服务方式

RESTful http

HTTP

提供各类语言的API

HTTP API，

Protocol Buffers 和一个原生 Erlang 界面

存储数据格式

JSON

多种数据格式，如：JSON，XML， CSV

基于sql，

MySQL,PostgreSQL

Key/value存储，值是对象

优点
  1. 基于Lucene；
  2. 接近实时的搜索；
  3. 自身带有分布式协调管理功能；
  4. 使用gateway概念，使得备份更加简单；
  5. 有很多优秀第三方插件，调优方案很多；
  6. 6.       可以定制ranker
  7. 基于Lucene；

强大成熟的开发者社区；

  1. 2.       不考虑建索引的同时进行搜索，速度更快

基于SQL的全文检索引擎，可以结合MySQL,PostgreSQL做全文搜索，可以提供比数据库本身更专业的搜索功能
  1. Erlang一开始就支持分布式、容错应用程序，因此基于此开发的Riak在分布式，容错方面有天生的优势；
  2. 2.       集成了Apache Solr全文搜索

缺点

由于2016年受欢迎程度才超越solr，资料文档方面比solr相对较少

建立索引时，搜索效率下降，实时索引搜索效率不高
  1. 不负责数据存储，使用关系型数据库作为数据存储，在性能上相比nosql存储方案较差；
  2. 2.       sphinx不适合内容更新频繁的网站，不适合做实时索引

社区活跃度低，基于Solr，

Riak 2.0才推出了riak search，全文检索方案并不成熟。

性能

毫秒级，海量数据下，性能影响不大

当单纯的对已有数据进行搜索时，Solr更快，数据量大时，性能下降明显

高速索引 （在新款CPU上，近10 MB/秒）;

高速搜索 (2-4G的文本量中平均查询速度不到0.1秒);

毫秒级

基于Dynamo，读写访问中99.9%的响应时间都在300ms内。

辅助工具

成熟的可视化工具Kibana

 

 

Riak Control

社区活跃度

GitHub star

24770

GitHub star

1075

GitHub star

1213

GitHub star

Riak：2820

Riak Search：141

百度指数对比

ES > solr > sphinx

ES > solr > sphinx

ES > solr > sphinx

未收录

DB-engines流行趋势https://db-engines

.com/en/blog_post

/70

TOP 10 第一名

2016年超过Slor

目前仍处于上升趋势

TOP 10 第二名

缓慢下降趋势

TOP 10 第五名

下降趋势

Top 10 以外

下降趋势

使用案例

见下文

见下文

见下文

见下文

使用案例

Elasticsearch使用案例

  1. 维基百科使用Elasticsearch来进行全文搜做并高亮显示关键词，以及提供search-as-you-type、did-you-mean等搜索建议功能；
  2. 英国卫报使用Elasticsearch来处理访客日志，以便能将公众对不同文章的反应实时地反馈给各位编辑；
  3. StackOverflow将全文搜索与地理位置和相关信息进行结合，以提供more-like-this相关问题的展现；
  4. GitHub使用Elasticsearch来检索超过1300亿行代码；
  5. Elasticsearch使Fog Creek可以在400亿行代码中进行一个月3千万次的查询
  6. 每天，Goldman Sachs使用它来处理5TB数据的索引，还有很多投行使用它来分析股票市场的变动；
  7. 其他：http://blog.csdn.net/lirenzuo/article/details/54845889

      参考文档：http://www.cnblogs.com/chowmin/articles/4629220.html

 

      Solr使用案例

  1. StumbleUpon使用solr根据你的兴趣推荐网页给你，后来由于数据量增加，满足不了需求，改为Elasticsearch；

         2.  百度，必应，知乎上几乎查不到Solr国内的使用案例，参考：

https://yq.aliyun.com/wenzhang/show_197204

         3.       官网上查到的国外使用案例

         

     Sphinx使用案例

         Craigslist.org，Recruitment.aleph-graymatter.com， Tradebit.com，vBulletin.com，Mediawiki Extension，

Boardreader.com，OMBE.com

      Riak search 使用案例

        riak的使用者列表：

        AT&T, Comcast,GitHub, Best Buy, UK National Health Services (NHS),The Weather Channel,and Riot Games.

       但不知道其中对Riak search的使用情况

   调研分析

      下面我将通过加权积分统计的方式来选择出最适合设备指纹的检索框架

  1.  从许可证来看，除了sphinx，其他三个都是apache，网上流传着一句话：没有人因为选择apache下的框架而被解雇，哈哈。

            Sphinx 0分，Elasticsearch 1分， solr 1分，riak search 1分

         2. 从编程语言来看，sphinx使用c++，riak使用Erlang，其他java。C++性能优于java，Erlang是天生的分布式语言。

            Sphinx 0.2分，Elasticsearch  0分,  solr 0分，riak search 0.1分

         3.  从数据存储格式来看，Elasticsearch和solr都支持json格式，sphinx支持sql存储，riak search key/value。

             JSON格式比key/value方案更适合现有系统数据，sql存储方案性能没有nosql方案好。

             Sphinx 0分，Elasticsearch  1分,  solr 1分，riak search  0分

         4.  从服务方式来看，sphinx提供各类语言api，其他都支持http方式，现有系统是http访问方式，因此从系统改造角度来看，直接使用http方式操作更占优。

             Sphinx 0分，Elasticsearch  0.5分,  solr 0.5分，riak search  0.5分

         5. 从辅助工具来看，Elasticsearch有很成熟的辅助工具帮助开发人员进行运维。

             Sphinx 0分，Elasticsearch  1分,  solr 1分，riak search  0.5分

         6. 从百度指数来看，ES > solr > sphinx

            Sphinx 0.1分，Elasticsearch  0.5分,  solr 0.2分，riak search  0分

         7. 从社区活跃度来看（重点）

             Sphinx 0.5分，Elasticsearch  2分,  solr 2.5分，riak search  0.2分

         8. 从db-engines趋势排名来看（重点）

             Sphinx 1分，Elasticsearch  2.5分,  solr 2分，riak search  0.5分

         9. 从各自优缺点来看（重点），Elasticsearch 和solr都直接基于lucene，lucene是目前最流行的全文检索引擎工具， riak2.0才通过集成solr的方式，实现全文检索，Sphinx是基于关系型数据库存储方案。而且，虽然riak search基于Erlang,具有天生的分布式优势，但Elasticsearch本身带有分布式协调管理功能，具备高可扩展性。

             Sphinx 1分，Elasticsearch  3分,  solr 3分，riak search  2分

         10. 从性能上来看（重点），Elasticsearch与solr的性能测试对比比较多，Elasticsearch在大数据量，实时搜索方面明显优于solr，solr只在稳定数据以及数据量不是特别大时性 能优于Elasticsearch，具体参考性能对比图：http://www.cnblogs.com/chowmin/articles/4629220.html。

               Sphinx和riak search相关资料较少，没法直接对比，据说都是百毫秒级，这和Elasticsearch相差不大，但Elasticsearch相对来说有更可靠的成功使用案例，Sphinx和riak search在国内的应用都偏少，在国外的使用也相对较少，使用风险较大。

           Sphinx 2分，Elasticsearch  3分,  solr 1.5分，riak search  1.5分

          11. 从使用案例来看，Elasticsearch的使用案例更具有代表性，尤其在海量数据方面体现得更突出，见上面案例。

           Sphinx 1分，Elasticsearch  2分,  solr 1分，riak search  1分

           积分计算结果：Sphinx  5.8分，Elasticsearch 16.5分， solr 13.7分，riak search 7.3分

           综合分析，从实际应用场景来看，公司现有系统已经使用Elasticsearch方案，从技术熟悉成本来看，更占优势，solr在性能上不适合设备指纹系统架构（海量数据下的高性能索引检索）。sphinx不适合内容更新频繁的网站，不适合做实时索引。riak search使用风险太高，应该做更深层次的调研。

           所以，针对主流的全文检索框架方案可以作如下结论：

    首选方案：Elasticsearch；

    备选方案：riak search，需要做更深层次的调研。

基于主流全文索引框架 + NOSQL的方案

    在分析主流全文索引框架+nosql方案之前，先看一篇论文：

    利用nosql构建高性能全文检索：http://www.doc88.com/p-6983213041839.html；

    这篇文章指出了lucene的缺点，即在实时建立索引的同时，检索性能会下降，数据量大的情况下对性能的影响很大，可以说solr直接继承了这一缺点。同时这篇文章也指出了nosql的存储优势，在lucene+nosql的方案与直接使用lucene方案之间做了性能测试发现，lucene+nosql的方案更优，详细对比见上面链接。

    另外，在上面存储型nosql的调研分析中，我提到了关于Couchbase，和Cassandra的全文检索方案，即：

    Couchbase的全文检索方案：Bleve是Apache 协议下，Couchbase官方基于go语言开发并适用于go语言环境的检索框架。

    Cassandra的全文检索方案：Solandra,基于solr和Cassandra。其他还有好几种。

　 参考文档：http://pimin.net/archives/367

     http://www.open-open.com/doc/view/082d2d0e46a4475a9baae8473f526a59

     可以看出，虽然Bleve虽然只适用于go语言环境，但它的思路也是基于nosql的，而Cassandra的方案比较多，其中Solandra也是基于nosql的，其实Elasticsearch的本质也是lucene + nosql，它本身内部集成了一个nosql数据库。这也是为什么Elasticsearch越来越流行的原因，而且Elasticsearch有很多的第三方river插件，提供了es+mysql，es+mongodb，es+hadoop的方案。因此基于nosql的全文检索框架可能才是真正解决设备指纹系统的技术方案。

    由于网上这方面的资料较少，各种基于nosql方案之间的性能对比基本没有，加上时间太短，我在这儿只是提供了一个方向，后面可以进行更深层次的调研。

调研结果

 方案一：继续使用Elasticsearch+redis的存储方案。通过对Elasticsearch的不断调优以满足实时的需求。根据压力测试结果，可以探讨后面的方案。

 方案二：在现有Elasticsearch框架的基础上，对redis缓存部分进行调优，有以下几个方案：

         1. 通过增加部署redis集群，增加缓存数据，提高缓存命中率；

         2. 用更具高扩展性和高性能的nosql替换redis增加缓存数据，提高缓存命中率（这样就需要调研比redis更优秀的同类缓存数据库）；

         3. 优化缓存机制，比如实时动态替换缓存数据，具体思路如下:

                1. 将缓存未命中，es中命中的数据加入缓存；

                2. 将缓存中长期未命中的数据删除。

             这样就保证了缓存中的数据是热点数据，缓存命中率将得到很大提升。

 方案三：其他基于NOSQL的方案，如：

   1.ES+mongodb，使用mongo-connector；

         2. ES+Hadoop，使用ES-Hadoop；

         3. 使用Cassandra的全文检索方案，如：Solandra。

 

本文调研结果不是最终的采用的方案，随着业务发展以及结合公司环境，最终我们采用了redis+hbase的存储模式，舍弃掉了对全文检索的依赖

posted on 2017-09-01 09:18  青风叶鸣  阅读(264)  评论(0)    收藏  举报

导航