全部产品
云市场

简介

更新时间:2019-11-15 15:19:02

一. SearchIndex解决哪些用户问题?

1. HBase不支持复杂查询

HBase作为海量在线存储引擎,被广泛应用于推荐、风控、物联网、画像、表单等大数据场景。Phoenix作为HBase的SQL层,极大降低了用户使用门槛,并且实现了二级索引、加盐表、动态列等大量实用功能。HBase底层存储基于LSM,LSM能将业务的随机写转为顺序写,能有效提升写吞吐,但是其查询只适合于Rowkey的前缀匹配,查询模式单一;Phoenix二级索引,底层是跟原表关联的索引表,同样也是前缀匹配,一个表可以有多个索引,这样可以增加查询模式,但是索引数目不能太多,否则写放大的问题会比较严重。

对于更加复杂的查询场景,比如表单、日志查询里面的模糊查找,用户画像里面的随机条件组合等等,HBase + Phoenix的组合就不能支持。该问题是基于LSM的NoSQL数据库的通用问题,除了HBase,Cassandra、LevelDB、RocksDB、MongoDB引擎等都有相同的问题。

如果用户选择强行在OLTP数据库上做复杂查询,会导致在线库写性能严重下降,影响在线业务,甚至引发故障,做过在线业务的用户都深有感受。当然用户也可以选择在备库上做复杂查询,不过前面提到在线库本身的查询能力往往有限,满足不了在线复杂查询的相应要求。

2. 双写遇到的问题

为了解决问题1,用户自然会想到借助检索引擎,比如ES、Solr、Lucene等来解决该问题。不少用户选择的是双写的方式,也就是每一条记录同时写在线库和检索引擎,该方式看起来简单,但实际使用过程中问题很多。我们了解到的case,把这套方案解决较好的客户往往都是要投入月级别的时间和大量人力。下面以双写HBase和Solr为例,举几个用户遇到比较多的问题。

  1. 一致性难以保证双写很难保证在线库跟检索引擎的一致性。比如,两个链接并发双写,并且有修改的操作,那么很难保证HBase中同一字段的写入顺序跟Solr中同一个doc的修改顺序一致,那HBase和Solr中数据就出现了不一致,而且出现问题很难排查;另外,在线库往往只需要保存最近一段时间的数据,超过TTL的数据会被自动清理掉,而Solr中同样会有这个需求。但是HBase是按照KV做TTL的,Solr是按照doc,那两者在做数据清理的时候同样会出现不一致。不一致的场景有很多,这里就不一一介绍了。
  2. 写入性能下降相同配置下,HBase的吞吐要比Solr高很多,这源于软件设计的出发点不同,优化的方向不同等诸多因素。如果双写,那势必会导致Solr的写吞吐限制了HBase的写吞吐。
  3. 历史数据的同步双写只是解决了新数据的问题,对于历史数据则不适用,用户需要自己解决历史数据批量同步问题。特别是,对于不能停机的场景,在历史数据rebuild过程中,如何解决跟新数据跟历史数据相互覆盖的问题,也是十分棘手的问题。
  4. 冗余存储空间检索引擎专门解决索引问题,其数据存储格式要比在线库要更复杂,一份在线库的数据在检索引擎中可能需要存储多份,比如原始数据存储,倒排索引存储,为提升聚合和排序的列存DocValue的存储。那么,势必有存储冗余的问题,如何降成本也是一大挑战。
  5. 稳定性双写要求HBase和Solr同时保证稳定性,如果Solr出现故障,写流程会被block住,对在线业务造成影响。

3. HBase + Solr易用性不足

阿里云HBase Solr全文检索引擎,采用在系统层做数据转换和同步的方式一站式解决了用户使用双引擎遇到的大部分问题。但是,试用过的用户会有一个体会,就是使用太灵活了,步骤也比较繁琐,容易出问题,如果不是资深玩家难以驾驭。下面举几个用户痛点:

  1. 使用门槛高用户需要同时理解HBase、Solr、Indexer(数据同步服务),同时操作HBase Shell,Indexer命令行,Solr界面三个途径才能把流程走通。

  2. Schemaless的HBase跟强Schema的Solr数据类型难以保证对齐首先,用户要自己定义从HBase column到Solr field的映射;其次,用户要自己保证实际写入到HBase中的类型正确。比如HBase中一个列对应Solr中一个long类型,因为HBase API并不检查用户实际写入的数值是否合法,导致写入HBase成功,但是同步到Solr是通不过的。这就要求用户要自己基于HBase API写一套类型检查系统,费时费力。

  3. HBase + Solr对于数据冗余存储的问题解决不友好用户需要自己决定Solr中是否开启stored,docValued选项,对于只开启indexed选项的Field,用户可以通过回读HBase的方式来拿到最终结果数据,而对于开启了stored或者docValued的Field,直接从Solr中返回结果性能会更好。这套优化的逻辑需要用户自己管理和实现。

二. SearchIndex架构

framework

SearchIndex是阿里云HBase SQL(Phoenix)基于HBase + Solr双引擎的新的索引实现,其架构如上图所示。Phoenix层将SQL(DDL、DML)语句转化为对HBase和Solr的具体操作,SearchService负责索引同步,一致性,元数据管理等。

SearchIndex解决了前面提到的所有问题,用户只需要几分钟,几条SQL语句就可以跑通整个流程;Phoenix强类型直接映射Solr类型,并支持分词、Array等复杂类型;自适应回查的优化策略更好解决了数据冗余存储问题。相比于HBase Solr全文检索引擎,大大提高了易用性,并且覆盖绝大部分的场景和需求。但目前SearchIndex还不能完全取代HBase + Solr,对于资深玩家,比较喜欢直接写HBase API和Solr API带来的灵活性,仍然可以选择使用HBase Solr全文检索引擎的方式。