讓貝殼性能提升3-4?倍，OceanBase是如何做到的？

為了能給大家提供更高品質、高效率的智能居住服務，貝殼一直積極探索，只為尋找能夠更好提高平臺性能的服務器。

比如在貝殼家居等業務場景中，需要在用戶下單后將訂單信息與維度表中商品信息的相關信息進行實時關聯，但由于維表數據量較大，并且 Flink 實時查詢 QPS 較高，傳統數據庫MySQL 難以支撐，因此貝殼采用 HBase 作為維表。

但隨著使用的深入，貝殼發現，HBase雖然具有較好的查詢性能，但也存在難以解決的痛點。

首先，HBase 不支持二級索引。

在許多應用場景中，Flink 任務關聯維度表時，除了需要基于主鍵字段進行關聯外，還需要其他非主鍵字段進行關聯。但是HBase 只支持行鍵（Row Key）作為單一索引，本身并不直接支持二級索引。Apache Phoenix 等項目對 HBase 的基礎上進行擴展，能夠實現類似于二級索引的功能，但是需要更多的開發和維護成本。

其次，HBase 依賴較多，部署復雜，成本高。

HBase 是構建在 Hadoop 生態系統之上的，它依賴于分布式文件系統 HDFS 用于數據的持久化存儲，依賴 ZooKeeper 來完成選舉、節點管理、集群元數據維護等，因此在生產環境中部署 HBase 之前，需要先部署和配置 Hadoop、ZooKeeper 等組件，涉及組件多，部署較復雜，運維成本較高，硬件成本也較高，特別是在一些特殊場景下需要分別為其部署獨立的 HBase 集群。

為了解決以上兩個關鍵問題，貝殼將目光投向了分布式數據庫OceanBase，而OceanBase也不負眾望地解決了這些業務痛點。

首先，OceanBase 原生支持二級索引功能，可以直接在維表上創建額外的索引，提升維表的查詢性能。

其次，OceanBase 只有 OBServer 一個角色，不依賴任何外部組件，天然具備高可用能力，部署非常簡單。并且OceanBase自帶的周邊工具也可以快速安裝，比如通過 OCP（OceanBase Cloud Platform）白屏化安裝或通過 OBD（OceanBase Deployer）命令行安裝集群，運維很方便。

再者，OceanBase成本更低。在部署資源消耗方面，HBase 方案機器成本大概是 OceanBase 的 2 倍。因為 HBase 為了保證高可用, 采用了雙 HRegionServer，而 HBase 又是基于三副本的 Hadoop 存儲數據, 所以一份數據通常需要六副本。在集群規模不大時，使用 Zookeeper、Hadoop 會帶來大量額外的機器冗余，但是使用 OceanBase 存儲數據只需要三副本，成本降低一半。

最終在 OceanBase 的加持下，貝殼的性能提升了3-4倍，硬件成本節省了一半，運維成本也得到大幅降低。

事實上，除了在實時維表服務上實現“降本增效”，在實時字典服務方面，OceanBase也展現出了更好的服務性能。

根據測試統計數據，在批量讀、批量寫、吞吐量上，OceanBase相比于HBase都有明顯優勢。HBase 要保證 key 不重復和 value 自增，只能通過單條數據寫入，寫數據成為了整個數據流程的瓶頸。通過數據庫本身的特性，使用 OceanBase 時不需要關注 key 重復和 value 自增的問題，通過 SQL 批量寫入數據，從而能提供更大的寫吞吐。

與此同時，在數據量壓測對比下，面對12萬~24萬數據量，HBase 的處理時間是1.27秒，隨著時間積累，延遲也越來越大；而OceanBase 是在數據量28萬~56萬，且加到了7個實時任務的情況下，才開始出現延遲，數據處理時間1.1秒。

可以看出，在相同環境下，OceanBase 綜合性能要優于 HBase，且具有更低的硬件成本和運維成本，因此貝殼選擇上線OceanBase也就不足為奇了。