【作者】

施緯，攜程數據庫研發工程師，主要負責數據庫運維和內核研發。
姜賢富，攜程高級數據庫研發工程師，主要負責攜程數據庫監控運維及工具研發，擁有十年運維經驗。

【概述】

自從2021年OceanBase開源以來，攜程一直致力于其在實際業務場景下的應用實踐，探索新一代分布式數據庫的可能性。隨著攜程業務需求的增長和多樣化，OceanBase的應用范圍也越來越廣，與之對應的，我們積累的實踐經驗也越來越豐富，希望進一步參與到OceanBase開源社區的建設中，推進國產分布式數據庫的發展。其中，攜程和OceanBase共同實現了索引統計功能，本文將介紹此次開源實踐。

【開源共建】

經過2年的探索實踐，攜程已經形成了比較完善的OceanBase應用體系。2021年，我們將OceanBase初步應用于日志庫場景，以評估OceanBase的性能、穩定性及數據壓縮率。與此同時，我們進行了周邊工具的建設，如發布工具，Canal工具等，并完善了標準化的上下線流程，為深化應用打下基礎。隨著使用流程的逐漸成熟，以及生產數據量的不斷增長，我們拓展了OceanBase的使用場景，將其作為歷史冷數據的歸檔庫（見圖1），利用其高壓縮率節省85%的存儲成本。如今，攜程越來越多的業務場景使用OceanBase，如結算業務、推薦業務及其他在線OLTP業務場景，得益于分布式的擴容能力，我們可以更加輕松地應對各種高負載的情況。

圖 1 OceanBase存儲歸檔冷數據

除了體會到分布式數據庫高性能、大容量、靈活擴展等優勢外，我們也面臨運維體系的挑戰。因為我們已經有多年的MySQL使用經驗，形成了相對成熟的MySQL開發和運維流程，所以我們在使用OceanBase時，希望它可以盡量兼容現有的各項開發、運維流程，包括數據庫的上下線、表結構的發布變更、應用的訪問方式、大數據取數等；還能提供超越MySQL的運維潛力。方便我們將OceanBase平滑接入現有的自動化運維系統，同時借助強大的分布式拓展能力進一步提升我們的運維能力。

對此，我們針對OceanBase建立了監控告警系統、慢日志審計系統、數據庫遷移工具等，但在使用過程中，我們發現相比MySQL，OceanBase 4.2.1并不能完全滿足我們的運維工作需求，例如沒有提供類似MySQL的索引統計功能、詳細的表級增刪改查統計功能等。針對這些問題，我們向OceanBase團隊提出了反饋，一方面我們希望OceanBase可以功能更加豐富，完全滿足我們的使用需求，另一方面，希望參與分布式數據庫的建設，為OceanBase社區貢獻一份力量。

基于此，我們很榮幸和OceanBase團隊達成了源碼共建的合作關系，由我們提出需求協作開發并最終并入社區版源碼，目前我們已在OceanBase 4.3中合作完成了索引統計功能（源碼鏈接），下面就該功能的設計和實現進行詳細的介紹。

【需求背景】

OceanBase 4.2.1缺乏針對索引在使用上的監控，例如索引被引用的次數，一段時間內的頻率，讀寫訪問的次數等。這些統計數據對于數據庫的運維是非常重要的，存在很多應用場景：

1. 刪除索引時需要確認索引是否被訪問。用戶一般通過創建索引來加速查詢的過程，然而過多的索引，可能會占用過多的磁盤空間，查詢時的索引選擇和爭用的開銷也會上升，索引走錯的概率也會增大，因此需要清理冗余索引。業務SQL發生變化時也可能需要下線老的索引，索引統計功能可以極大地降低刪除索引的風險。
2. 通過采集各個時間段的索引使用情況，我們可以感知整張表的訪問熱度趨勢。例如圖2中的例子，用戶可以根據圖中趨勢分析出這張表的訪問高峰時段，以及各個不同索引的訪問趨勢，在添加新索引后可以觀察趨勢驗證索引效果，例如圖中idx_b_c索引添加之后idx_b索引就逐漸不再被訪問。
3. 通過采集索引的讀寫訪問次數，可以分析表的訪問模式，以進行進一步的優化。MySQL的索引統計功能就提供了表級別的讀寫統計數據，利用這些數據，用戶可以采集每張表的讀寫訪問趨勢，從而判斷這些表是讀多寫少還是寫多讀少等并根據訪問模式選擇更合適的優化方案，例如使用緩存、優化寫入方式等。
   
   圖 2 索引訪問數據示例

傳統的數據庫MySQL和Oracle都提供了索引監控功能，前者利用performance_shcema中的內存表詳細統計了每個索引被訪問的次數及各種類型語句(增刪改查)的執行次數，攜程就是利用這些數據評估各個表的和索引的訪問情況和負載類型；后者則將索引統計信息定期持久化到磁盤，DBA可以通過特定視圖訪問。

綜上所述，我們認為索引監控功能對于OceanBase也是非常有必要的。

【設計方案】

為同時適應MySQL和Oracle模式下的用戶訪問，OceanBase索引統計功能采用持久化存儲設計，數據存在內部表，兩種模式下的用戶可以通過不同視圖訪問；由于OceanBase是多租戶設計，索引統計功能也需要具備租戶級別的控制和統計能力；另外，為了盡可能降低性能影響，參考Oracle，該功能提供抽樣統計模式選項。

如圖3所示，索引統計采用增量數據寫入內存，定期刷到內部表的方式實現，各個租戶的增量數據、相關配置、定時任務以及內部表都是獨立的。不同的SQL線程在訪問到索引時會更新其租戶下的索引統計數據，各個租戶的定時任務會負責配置的刷新和內部表的更新，用戶可以通過視圖查詢索引信息。

圖 3 索引統計實現

【實現細節】

索引統計功能的主要流程可以抽象為三個階段。

• 數據收集：收集索引使用數據。
• 數據管理：在內存中維護管理索引統計數據。
• 數據上報：將收集到的數據持久化到內部表中。

圖3中的流程就是這三個階段的具體體現。另外，我們在實現的過程中也重點考慮了索引統計對數據庫性能的影響，并進行了相應的優化。

【階段1：數據收集】

考慮到兼容MySQL和Oracle的索引統計功能，收集的數據包括索引的使用次數、上次使用的時間、掃描的行數、各種類型查詢的數量等。OceanBase 支持 SQL / OBKV(TableAPI) 兩種方式對數據進行訪問，數據統計需要考慮 SQL 和 TableAPI 兩種訪問形式。但由于 TableApi 使用與 SQL 模式不同的TableScan算子，ObTableApiScanExecutor 和ObTableScanOp，若在TableScan算子層統計索引使用，那么就需要分別適配 TableAPI 和 SQL 兩種模式的算子；如果在更底層DAS層進行統計，則只能按分區粒度統計，無法獲取表級數據。因此決定在TableScan算子層實現兩種統計方式，在算子關閉時更新內存中的索引使用信息。目前，索引統計會收集索引的訪問次數和訪問時間。

圖 4 索引統計數據收集流程圖

【階段2：數據管理】

各個租戶會維護自身的索引統計數據，具體到內存中，增量數據儲存在多個hashmap中，租戶初始化時會根據自身的內存和CPU資源選擇合適的hashmap數量來保證最優性能。索引數據更新時會隨機選擇hashmap寫入數據，目的是降低并發訪問時的鎖競爭，同時數據采樣也發生在此處，將根據租戶配置的采樣比隨機寫入數據。選擇在寫入時采樣一方面可以減少性能影響和內存占用，另一方面不在數據上報時采樣可以更精確地檢測索引是否被刪除。

【階段3：數據上報】

租戶內存中的增量數據會通過定時任務的方式寫入內部表完成數據上報，該任務使用OceanBaseSharedTimer的方式實現，避免消耗額外的線程資源。上報過程中會對內存中每個hashmap進行全量的遍歷，通過batch insert的方式將增量數據寫入內部表，這個過程還會檢查對應索引表是否已經刪除，hashmap和內部表中的數據將在索引刪除一段時間之后被刪除。

【索引統計性能優化】

在開發和測試過程中，我們發現索引統計信息寫入內存的過程有可能對整體的語句執行主流程產生性能影響。從圖4的流程也可以看到，索引統計發生在整個語句執行的關鍵路徑中，因此這一步的性能優化尤為重要。最開始我們采用單個hashmap進行數據存儲，在數據上報時進行采樣的方式。
由于統計是在TableScan算子關閉時寫入hashmap，每次執行使用索引的語句都會對hashmap進行寫入，在高并發訪問相同的索引場景下，由于需要寫入相同的hash桶，就會產生較多的鎖競爭，從火焰圖可以看到，整個調用棧中鎖等待占用了較長時間。針對這個問題，我們和OceanBase的同學進行討論后決定對hashmap進行分片，使用多個hashmap的方式來減少鎖競爭，并將采樣邏輯移到數據收集階段，減少寫hashmap的次數，這樣一來，索引統計整體的性能影響就降低了很多。當然，用戶也可以動態配置采樣比例或者暫時關閉采樣模式以獲取更為準確的索引統計信息。

圖 5 單Hashmap模式訪問火焰圖

【數據展示】

內部表：__all_index_usage_info
視圖：DBA_INDEX_USAGE, CDB_INDEX_USAGE
內部表用于定時任務內部數據存儲，視圖則是呈現給用戶使用，兼容Oracle的DBA_INDEX_USAGE字段，目前支持索引使用次數和使用時間的展示，后續可以進一步拓展。

圖 6 索引統計視圖示例

【展望未來】

本次開源共建，一方面豐富了OceanBase的功能，使其滿足了我們的使用需求，另一方面也加強了我們團隊的源碼開發能力，為日后進一步的使用和共建打下了基礎。非常感謝OceanBase團隊提供的共建機會和技術支持，我們希望以后可以繼續合作，共同推進國產分布式數據庫的發展，實現共建共贏。

總結

以上是生活随笔為你收集整理的携程OceanBase开源实践——索引统计功能实现的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。