网站建设市场多大,免费网站制作平台推荐,建网站系统平台,外贸都用什么网站一、在线库不支持在线复杂查询
做在线业务的开发者经常会碰到这样的难题#xff1a;在线数据库上面运行稍微复杂点的查询#xff0c;在线业务就挂了#xff01;不管是单机数据库如MySQL、PG#xff0c;还是分布式数据库#xff0c;HBase、MongoDB、Cassandra都有这个问题…一、在线库不支持在线复杂查询
做在线业务的开发者经常会碰到这样的难题在线数据库上面运行稍微复杂点的查询在线业务就挂了不管是单机数据库如MySQL、PG还是分布式数据库HBase、MongoDB、Cassandra都有这个问题。下面本文就以HBase为例对该问题进行说明其他库原理类似。
HBase作为海量在线存储引擎被广泛应用于推荐、风控、物联网、画像、表单等大数据场景。Phoenix作为HBase的SQL层极大降低了用户使用门槛并且实现了二级索引、加盐表、动态列等大量实用功能。HBase底层存储基于LSMLSM能将业务的随机写转为顺序写能有效提升写吞吐但是其查询只适合于Rowkey的前缀匹配查询模式单一Phoenix二级索引底层是跟原表关联的索引表同样也是前缀匹配一个表可以有多个索引这样可以增加查询模式但是索引数目不能太多否则写放大的问题会比较严重。
对于更加复杂的查询场景比如表单、日志查询里面的模糊查找用户画像里面的随机条件组合等等HBase Phoenix的组合就不能支持。该问题是基于LSM的NoSQL在线数据库的通用问题除了HBaseCassandra、LevelDB、RocksDB、MongoDB引擎等都有相同的问题。
有开发者选择在备库上做复杂查询不过前面提到在线库本身的查询能力往往有限要么很慢要么就查不出来满足不了在线复杂查询的实时性要求。
二、双写遇到的问题 为了解决问题1用户自然会想到借助检索引擎比如ES、Solr、Lucene等来解决该问题。不少用户选择的是双写的方式也就是每一条记录同时写在线库和检索引擎该方式看起来简单但实际使用过程中问题很多。我们了解到的case把这套方案解决较好的客户往往都是要投入月级别的时间和大量人力。下面以双写HBase和Solr为例举几个用户遇到比较多的问题。
一致性难以保证 双写很难保证在线库跟检索引擎的一致性。比如两个链接并发双写并且有修改的操作那么很难保证HBase中同一字段的写入顺序跟Solr中同一个doc的修改顺序一致那HBase和Solr中数据就出现了不一致而且出现问题很难排查另外在线库往往只需要保存最近一段时间的数据超过TTL的数据会被自动清理掉而Solr中同样会有这个需求。但是HBase是按照KV做TTL的Solr是按照doc那两者在做数据清理的时候同样会出现不一致。不一致的场景有很多这里就不一一介绍了。写入性能下降 相同配置下HBase的吞吐要比Solr高很多这源于软件设计的出发点不同优化的方向不同等诸多因素。如果双写那势必会导致Solr的写吞吐限制了HBase的写吞吐。历史数据的同步 双写只是解决了新数据的问题对于历史数据则不适用用户需要自己解决历史数据批量同步问题。特别是对于不能停机的场景在历史数据rebuild过程中如何解决跟新数据跟历史数据相互覆盖的问题也是十分棘手的问题。冗余存储空间 检索引擎专门解决索引问题其数据存储格式要比在线库要更复杂一份在线库的数据在检索引擎中可能需要存储多份比如原始数据存储倒排索引存储为提升聚合和排序的列存DocValue的存储。那么势必有存储冗余的问题如何降成本也是一大挑战。稳定性 双写要求HBase和Solr同时保证稳定性如果Solr出现故障写流程会被block住对在线业务造成影响。
三、HBase Solr易用性不足
阿里云HBase Solr全文检索引擎采用在系统层做数据转换和同步的方式一站式解决了用户使用双引擎遇到的大部分问题。但是试用过的用户会有一个体会就是使用太灵活了步骤也比较繁琐容易出问题如果不是资深玩家难以驾驭。下面举几个用户痛点
使用门槛高 用户需要同时理解HBase、Solr、Indexer数据同步服务同时操作HBase ShellIndexer命令行Solr界面三个途径才能把流程走通。Schemaless的HBase跟强Schema的Solr数据类型难以保证对齐 首先用户要自己定义从HBase column到Solr field的映射其次用户要自己保证实际写入到HBase中的类型正确。比如HBase中一个列对应Solr中一个long类型因为HBase API并不检查用户实际写入的数值是否合法导致写入HBase成功但是同步到Solr是通不过的。这就要求用户要自己基于HBase API写一套类型检查系统费时费力。HBase Solr对于数据冗余存储的问题解决不友好 用户需要自己决定Solr中是否开启storeddocValued选项对于只开启indexed选项的Field用户可以通过回读HBase的方式来拿到最终结果数据而对于开启了stored或者docValued的Field直接从Solr中返回结果性能会更好。这套优化的逻辑需要用户自己管理和实现。
四、SearchIndex灵活易用一体化在线库引擎 SearchIndex是阿里云HBase SQLPhoenix基于HBase Solr双引擎的新的索引实现其架构如上图所示。Phoenix层将SQLDDL、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服务可以后续单独开通单独升级管理。欢迎感兴趣的开发者共同交流。
原文链接 本文为云栖社区原创内容未经允许不得转载。
