为了实如今线库的复杂查询，你还在双写吗？

1、在线库不支持在线复杂查询

作在线业务的开发者常常会碰到这样的难题：在线数据库上面运行稍微复杂点的查询，在线业务就挂了！不论是单机数据库如MySQL、PG，仍是分布式数据库，HBase、MongoDB、Cassandra都有这个问题。下面，本文就以HBase为例对该问题进行说明，其余库原理相似。

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

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

有开发者选择在备库上作复杂查询，不过前面提到在线库自己的查询能力每每有限，要么很慢，要么就查不出来，知足不了在线复杂查询的实时性要求。

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中返回结果性能会更好。这套优化的逻辑须要用户本身管理和实现。

4、SearchIndex灵活易用一体化在线库引擎

SearchIndex是阿里云HBase SQL（Phoenix）基于HBase + Solr双引擎的新的索引实现，其架构如上图所示。Phoenix层将SQL（DDL、DML）语句转化为对HBase和Solr的具体操做，SearchService负责索引同步，一致性，元数据管理等。SearchService内部会统一管理HBase中TimeStamp和Solr中DocVersion的对应关系，来实现最终一致性。简单来讲，Solr一行数据的DocVersion等于当前已被同步的HBase对应行各个column的TimeStamp最大值，在解决乱序时，若是前面新的cell已经被同步了，老的cell则被直接丢掉便可。而对于TTL问题，咱们实现了基于行的HBase Compaction机制，来保证一致性。

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

SearchIndex是针对阿里云公共云客户定制开发的一体化云原生在线NoSQL数据库引擎，具备低成本、灵活、易用、稳定等特色，已经被用于物流巴枪、线下支付表单、电商表单、医药实验日志等行业和场景，用户数据量已达数百亿规模，经历过双十一的考验。用户第一步能够只购买HBase实例，全文服务和SQL服务能够后续单独开通，单独升级管理。欢迎感兴趣的开发者共同交流。

---

本文做者：明朔

阅读原文

本文为云栖社区原创内容，未经容许不得转载。