爲了實如今線庫的複雜查詢，你還在雙寫嗎？

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服務能夠後續單獨開通，單獨升級管理。歡迎感興趣的開發者共同交流。

---

本文做者：明朔

閱讀原文

本文爲雲棲社區原創內容，未經容許不得轉載。