一、在線庫不支持在線復(fù)雜查詢

做在線業(yè)務(wù)的開發(fā)者經(jīng)常會(huì)碰到這樣的難題：在線數(shù)據(jù)庫上面運(yùn)行稍微復(fù)雜點(diǎn)的查詢，在線業(yè)務(wù)就掛了！不管是單機(jī)數(shù)據(jù)庫如MySQL、PG，還是分布式數(shù)據(jù)庫，HBase、MongoDB、Cassandra都有這個(gè)問題。下面，本文就以HBase為例對(duì)該問題進(jìn)行說明，其他庫原理類似。

HBase作為海量在線存儲(chǔ)引擎，被廣泛應(yīng)用于推薦、風(fēng)控、物聯(lián)網(wǎng)、畫像、表單等大數(shù)據(jù)場(chǎng)景。Phoenix作為HBase的SQL層，極大降低了用戶使用門檻，并且實(shí)現(xiàn)了二級(jí)索引、加鹽表、動(dòng)態(tài)列等大量實(shí)用功能。HBase底層存儲(chǔ)基于LSM，LSM能將業(yè)務(wù)的隨機(jī)寫轉(zhuǎn)為順序?qū)?#xff0c;能有效提升寫吞吐，但是其查詢只適合于Rowkey的前綴匹配，查詢模式單一；Phoenix二級(jí)索引，底層是跟原表關(guān)聯(lián)的索引表，同樣也是前綴匹配，一個(gè)表可以有多個(gè)索引，這樣可以增加查詢模式，但是索引數(shù)目不能太多，否則寫放大的問題會(huì)比較嚴(yán)重。

對(duì)于更加復(fù)雜的查詢場(chǎng)景，比如表單、日志查詢里面的模糊查找，用戶畫像里面的隨機(jī)條件組合等等，HBase + Phoenix的組合就不能支持。該問題是基于LSM的NoSQL在線數(shù)據(jù)庫的通用問題，除了HBase，Cassandra、LevelDB、RocksDB、MongoDB引擎等都有相同的問題。

有開發(fā)者選擇在備庫上做復(fù)雜查詢，不過前面提到在線庫本身的查詢能力往往有限，要么很慢，要么就查不出來，滿足不了在線復(fù)雜查詢的實(shí)時(shí)性要求。

二、雙寫遇到的問題

為了解決問題1，用戶自然會(huì)想到借助檢索引擎，比如ES、Solr、Lucene等來解決該問題。不少用戶選擇的是雙寫的方式，也就是每一條記錄同時(shí)寫在線庫和檢索引擎，該方式看起來簡(jiǎn)單，但實(shí)際使用過程中問題很多。我們了解到的case，把這套方案解決較好的客戶往往都是要投入月級(jí)別的時(shí)間和大量人力。下面以雙寫HBase和Solr為例，舉幾個(gè)用戶遇到比較多的問題。

一致性難以保證
雙寫很難保證在線庫跟檢索引擎的一致性。比如，兩個(gè)鏈接并發(fā)雙寫，并且有修改的操作，那么很難保證HBase中同一字段的寫入順序跟Solr中同一個(gè)doc的修改順序一致，那HBase和Solr中數(shù)據(jù)就出現(xiàn)了不一致，而且出現(xiàn)問題很難排查；另外，在線庫往往只需要保存最近一段時(shí)間的數(shù)據(jù)，超過TTL的數(shù)據(jù)會(huì)被自動(dòng)清理掉，而Solr中同樣會(huì)有這個(gè)需求。但是HBase是按照KV做TTL的，Solr是按照doc，那兩者在做數(shù)據(jù)清理的時(shí)候同樣會(huì)出現(xiàn)不一致。不一致的場(chǎng)景有很多，這里就不一一介紹了。

寫入性能下降
相同配置下，HBase的吞吐要比Solr高很多，這源于軟件設(shè)計(jì)的出發(fā)點(diǎn)不同，優(yōu)化的方向不同等諸多因素。如果雙寫，那勢(shì)必會(huì)導(dǎo)致Solr的寫吞吐限制了HBase的寫吞吐。

歷史數(shù)據(jù)的同步
雙寫只是解決了新數(shù)據(jù)的問題，對(duì)于歷史數(shù)據(jù)則不適用，用戶需要自己解決歷史數(shù)據(jù)批量同步問題。特別是，對(duì)于不能停機(jī)的場(chǎng)景，在歷史數(shù)據(jù)rebuild過程中，如何解決跟新數(shù)據(jù)跟歷史數(shù)據(jù)相互覆蓋的問題，也是十分棘手的問題。

冗余存儲(chǔ)空間
檢索引擎專門解決索引問題，其數(shù)據(jù)存儲(chǔ)格式要比在線庫要更復(fù)雜，一份在線庫的數(shù)據(jù)在檢索引擎中可能需要存儲(chǔ)多份，比如原始數(shù)據(jù)存儲(chǔ)，倒排索引存儲(chǔ)，為提升聚合和排序的列存DocValue的存儲(chǔ)。那么，勢(shì)必有存儲(chǔ)冗余的問題，如何降成本也是一大挑戰(zhàn)。

穩(wěn)定性
雙寫要求HBase和Solr同時(shí)保證穩(wěn)定性，如果Solr出現(xiàn)故障，寫流程會(huì)被block住，對(duì)在線業(yè)務(wù)造成影響。

三、HBase + Solr易用性不足

阿里云HBase Solr全文檢索引擎，采用在系統(tǒng)層做數(shù)據(jù)轉(zhuǎn)換和同步的方式一站式解決了用戶使用雙引擎遇到的大部分問題。但是，試用過的用戶會(huì)有一個(gè)體會(huì)，就是使用太靈活了，步驟也比較繁瑣，容易出問題，如果不是資深玩家難以駕馭。下面舉幾個(gè)用戶痛點(diǎn)：

使用門檻高
用戶需要同時(shí)理解HBase、Solr、Indexer（數(shù)據(jù)同步服務(wù)），同時(shí)操作HBase Shell，Indexer命令行，Solr界面三個(gè)途徑才能把流程走通。

Schemaless的HBase跟強(qiáng)Schema的Solr數(shù)據(jù)類型難以保證對(duì)齊
首先，用戶要自己定義從HBase column到Solr field的映射；其次，用戶要自己保證實(shí)際寫入到HBase中的類型正確。比如HBase中一個(gè)列對(duì)應(yīng)Solr中一個(gè)long類型，因?yàn)镠Base API并不檢查用戶實(shí)際寫入的數(shù)值是否合法，導(dǎo)致寫入HBase成功，但是同步到Solr是通不過的。這就要求用戶要自己基于HBase API寫一套類型檢查系統(tǒng)，費(fèi)時(shí)費(fèi)力。

HBase + Solr對(duì)于數(shù)據(jù)冗余存儲(chǔ)的問題解決不友好
用戶需要自己決定Solr中是否開啟stored，docValued選項(xiàng)，對(duì)于只開啟indexed選項(xiàng)的Field，用戶可以通過回讀HBase的方式來拿到最終結(jié)果數(shù)據(jù)，而對(duì)于開啟了stored或者docValued的Field，直接從Solr中返回結(jié)果性能會(huì)更好。這套優(yōu)化的邏輯需要用戶自己管理和實(shí)現(xiàn)。

四、SearchIndex靈活易用一體化在線庫引擎

SearchIndex是阿里云HBase SQL（Phoenix）基于HBase + Solr雙引擎的新的索引實(shí)現(xiàn)，其架構(gòu)如上圖所示。Phoenix層將SQL（DDL、DML）語句轉(zhuǎn)化為對(duì)HBase和Solr的具體操作，SearchService負(fù)責(zé)索引同步，一致性，元數(shù)據(jù)管理等。SearchService內(nèi)部會(huì)統(tǒng)一管理HBase中TimeStamp和Solr中DocVersion的對(duì)應(yīng)關(guān)系，來實(shí)現(xiàn)最終一致性。簡(jiǎn)單來說，Solr一行數(shù)據(jù)的DocVersion等于當(dāng)前已被同步的HBase對(duì)應(yīng)行各個(gè)column的TimeStamp最大值，在解決亂序時(shí)，如果前面新的cell已經(jīng)被同步了，老的cell則被直接丟掉即可。而對(duì)于TTL問題，我們實(shí)現(xiàn)了基于行的HBase Compaction機(jī)制，來保證一致性。

SearchIndex解決了前面提到的所有問題，用戶只需要幾分鐘，幾條SQL語句就可以跑通整個(gè)流程，可參考快速開始文檔；Phoenix強(qiáng)類型直接映射Solr類型，并支持分詞、Array等復(fù)雜類型；自適應(yīng)回查的優(yōu)化策略更好解決了數(shù)據(jù)冗余存儲(chǔ)問題。相比于HBase Solr全文檢索引擎，大大提高了易用性，并且覆蓋絕大部分的場(chǎng)景和需求。但目前SearchIndex還不能完全取代HBase + Solr，對(duì)于資深玩家，比較喜歡直接寫HBase API和Solr API帶來的靈活性，仍然可以選擇使用HBase Solr全文檢索引擎的方式。

SearchIndex是針對(duì)阿里云公共云客戶定制開發(fā)的一體化云原生在線NoSQL數(shù)據(jù)庫引擎，具有低成本、靈活、易用、穩(wěn)定等特點(diǎn)，已經(jīng)被用于物流巴槍、線下支付表單、電商表單、醫(yī)藥實(shí)驗(yàn)日志等行業(yè)和場(chǎng)景，用戶數(shù)據(jù)量已達(dá)數(shù)百億規(guī)模，經(jīng)歷過雙十一的考驗(yàn)。用戶第一步可以只購買HBase實(shí)例，全文服務(wù)和SQL服務(wù)可以后續(xù)單獨(dú)開通，單獨(dú)升級(jí)管理。歡迎感興趣的開發(fā)者共同交流。

原文鏈接
本文為云棲社區(qū)原創(chuàng)內(nèi)容，未經(jīng)允許不得轉(zhuǎn)載。

創(chuàng)作挑戰(zhàn)賽新人創(chuàng)作獎(jiǎng)勵(lì)來咯，堅(jiān)持創(chuàng)作打卡瓜分現(xiàn)金大獎(jiǎng)

總結(jié)

以上是生活随笔為你收集整理的为了实现在线库的复杂查询，你还在双写吗？的全部?jī)?nèi)容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯(cuò)，歡迎將生活随笔推薦給好友。