面向海量天文數(shù)據(jù)的分布式MySQL錐形檢索研究*

楊 超，梁 波,2，戴 偉,2，衛(wèi)守林,2，鄧 輝，王 鋒

(1. 昆明理工大學信息工程與自動化學院，云南 昆明 650500；2. 昆明理工大學云南省計算機技術應用 重點實驗室，云南 昆明 650500；3. 廣州大學天體物理中心， 廣東 廣州 510006)

近年來，隨著大型天文觀測裝置的性能不斷提升，以及獲取天文觀測數(shù)據(jù)的能力空前加強，天文觀測數(shù)據(jù)呈現(xiàn)指數(shù)式增長。如我國自主設計研發(fā)的大天區(qū)面積多目標光纖光譜天文望遠鏡(Large Sky Area Multi-object Fiber Spectro-scopic Telescope, LAMOST， 又叫郭守敬望遠鏡)每晚采集的光譜數(shù)據(jù)達到20 GB[1]；魯賓天文臺(Vera C. Rubin Observatory)的大口徑全天巡視望遠鏡(Large Synoptic Survey Telescope, LSST)每晚采集的原始觀測數(shù)據(jù)多達15 TB；平方公里陣列(Square Kilometre Array, SKA)是國內(nèi)外共同協(xié)作的大科學裝置，是世界上最大的射電望遠鏡[2]，預計每年產(chǎn)出數(shù)據(jù)約300 PB。在大數(shù)據(jù)時代背景下，探索海量天文數(shù)據(jù)如何高效、可擴展的檢索成為天文科學觀測領域亟待解決的難題。

科學檢索傳統(tǒng)上依賴于關系型數(shù)據(jù)庫，對于非海量的結構化數(shù)據(jù)，通過建立數(shù)據(jù)索引機制能夠取得較好的檢索效率。但是，隨著天文觀測逐漸從光學覆蓋到全波段，傳統(tǒng)數(shù)據(jù)庫無法適應數(shù)據(jù)雪崩式增長帶來的沖擊。NoSQL系統(tǒng)通常使用鍵值存儲格式，同一鍵下的所有數(shù)據(jù)值存儲在一起并可以快速訪問。文[3]提出了AstroSpark天文檢索系統(tǒng)，文[4]實現(xiàn)了基于分布式陣列數(shù)據(jù)庫的FASTDB系統(tǒng)，它們具有低延遲、可擴展、高性價比等優(yōu)點。但是，由于采用了底層存儲格式，它們?nèi)狈﹃P系模型的高級功能，并且損害了ACID(Atomicity, Consistency, Isolation, Durability)屬性[5]。近年來，NoSQL演變到NewSQL，NewSQL系統(tǒng)本質(zhì)上是一個數(shù)據(jù)庫管理系統(tǒng)(Database Management System, DBMS)，可以為結構化查詢語言(Structured Query Language, SQL)、索引和架構提供支持，它不僅可以支持事務的ACID屬性，而且具有與NoSQL相同的可伸縮性。它的基本體系結構是并行的數(shù)據(jù)庫管理系統(tǒng)，在查詢負載方面的性能優(yōu)于MapReduce框架[6]。分布式關系數(shù)據(jù)庫結合傳統(tǒng)關系數(shù)據(jù)庫、分布式集群以及分布式事務來實現(xiàn)，不僅和傳統(tǒng)數(shù)據(jù)庫具有高度兼容性，還可以更好地支持結構化查詢語言和事務處理[7]。

但是，即使在性能強大的分布式關系數(shù)據(jù)庫中，由于各大天文巡天項目發(fā)布的星表的數(shù)據(jù)量越來越大，直接檢索方式無法滿足當前天文數(shù)據(jù)的檢索需求，所以大規(guī)模星表數(shù)據(jù)集的檢索訪問需要有效的球面索引，目前應用廣泛的偽球面索引方法有層次化三角形網(wǎng)格(Hierarchical Triangular Mesh, HTM)，HEALPix(Hierarchical Equal Area isoLatitude Pixelisation)及Q3C (Quad Tree Cube)等。在建立適合的球面索引之后，可以通過錐形檢索實現(xiàn)大規(guī)模星表數(shù)據(jù)集的檢索。作為天文領域的一種特殊檢索方式[8]，錐形檢索定義天區(qū)中的赤經(jīng)(Right Ascension, RA)、 赤緯(Declination, Dec)和角距離(SR)的位置信息，通常是以(Tra，Tdec)為圓心、角距離為半徑的錐形區(qū)域，錐形檢索就是對這個錐形相關天體的信息查詢，即查詢目標星體r(Sra，Sdec)。本文整合動態(tài)索引工具到分布式MySQL數(shù)據(jù)集群，使分布式關系型數(shù)據(jù)庫能夠建立偽球面索引，從而實現(xiàn)高效的錐形檢索。

1 數(shù)據(jù)庫中間件

數(shù)據(jù)庫中間件可以封裝底層數(shù)據(jù)，實現(xiàn)與單數(shù)據(jù)庫一樣的數(shù)據(jù)操作方式。目前有兩種典型的數(shù)據(jù)庫中間件模式，分別是服務端代理(數(shù)據(jù)庫代理)和客戶端代理(數(shù)據(jù)源代理)。服務端代理方式是通過代理服務器管理多個數(shù)據(jù)庫實例，客戶端通過數(shù)據(jù)源與代理服務器建立連接，客戶端所有的SQL操作由代理分發(fā)給底層數(shù)據(jù)庫，得到的結果也同樣經(jīng)過代理整合返回給客戶端?？蛻舳舜矸绞绞莾?nèi)部管理多個普通數(shù)據(jù)源，客戶端的SQL通過數(shù)據(jù)源代理進行解析、改寫等操作，然后分發(fā)給普通數(shù)據(jù)源執(zhí)行，得到結果也由代理整合并返回客戶端[9]。從SQL處理過程分析，數(shù)據(jù)庫中間件可以解析客戶端發(fā)送的事務請求，在進行解析、優(yōu)化和路由分析時，拆分為數(shù)據(jù)庫可以執(zhí)行的線程任務，按照預先設置的分庫分表規(guī)則發(fā)送到多個數(shù)據(jù)庫服務端，可以有效緩解單機數(shù)據(jù)庫的負載壓力，起到削峰的作用。為了數(shù)據(jù)庫中間件能夠支持高可用，可添加配置中心和監(jiān)控服務形成簡單的高可用架構。通過監(jiān)控服務監(jiān)測集群狀態(tài)，如有變更，推送變更信息到配置中心，數(shù)據(jù)庫代理Proxy拉取配置中心的變更信息，從而更新數(shù)據(jù)庫配置，數(shù)據(jù)庫中間件框架如圖1。

圖1 數(shù)據(jù)庫中間件框架Fig.1 Database middleware architecture

為了降低錐形檢索服務的負載和開銷，可采用主從讀寫分離分布、分庫分表的方式，實現(xiàn)數(shù)據(jù)庫的橫向擴展，提高錐形檢索效率和并發(fā)量。

1.1 分庫分表

分庫分表是數(shù)據(jù)庫中間件的核心功能。常用的切分方法有垂直切分和水平切分，在分布式領域，常用水平分庫分表的方式解決單一數(shù)據(jù)庫的瓶頸，緩解單機數(shù)據(jù)庫的訪問壓力。使用關系型數(shù)據(jù)庫MySQL來水平劃分，根據(jù)水平分表規(guī)則將全局關系的N表劃分為若干個不相交的子集(N1，N2，N3， ...，Nn)，以滿足完整性、重構性以及不相交性，分別表示為[10]

Ifa∈Nis satisfied,then it can be proven that:a∈Ni,i=1,2,...,n，

(1)

N1∪N2∪...∪Nj,j=1,2,...,n，

(2)

Ni,Nj∈N,thenNi∩Nj=φ.

(3)

1.2 讀寫分離

由于數(shù)據(jù)庫讀取操作的比例遠遠大于寫入操作，常使用一主多從的分布方式，主節(jié)點負責寫操作，從節(jié)點負責讀操作，通過讀寫分離，將負載均衡到多個節(jié)點。使用讀寫分離機制需要維護好數(shù)據(jù)一致性問題，常用的數(shù)據(jù)同步方式除了主從復制，還有Paxos，Raft，Term和ZAB等協(xié)議算法[11]。MySQL中常使用MySQL Proxy作為讀寫分離的中間層，通過內(nèi)嵌式Lua解析器定義查詢處理等[12]。

2 動態(tài)索引工具插件

動態(tài)索引工具[13]是開源的MySQL/MariaDB數(shù)據(jù)庫插件，由C++庫、Perl腳本和SQL存儲過程編譯而成，采用離散化二維空間的方法，并使用像素化方法將其映射到一維空間。然后為每個像素標記一個唯一的索引ID，如果只按照窮舉的方式進行檢索，時間復雜度為O(n)。在進行錐形檢索時，需要建立偽球面索引降低檢索的時間復雜度，而大多數(shù)索引基于樹結構。B-Tree[14]索引方法可以將時間復雜度減少到log2N，但是由于B-Tree的深度隨著數(shù)據(jù)量的增加而增加，因此難以應用于海量數(shù)據(jù)的索引?；贐+樹的索引方法是數(shù)據(jù)庫系統(tǒng)中最常用的動態(tài)索引結構，也是動態(tài)索引工具通過MySQL建立偽球面索引使用的方法。

動態(tài)索引工具使用目前應用最廣泛的幾種偽球面索引方法中的分層三角網(wǎng)格和HEALPix。分層三角網(wǎng)格作為天區(qū)劃分的經(jīng)典索引方式，最早應用于斯隆數(shù)字巡天(Sloan Digital Sky Survey, SDSS)數(shù)據(jù)。HEALPix用等面積的四邊形區(qū)塊劃分替換三角形劃分方式[15]，但是它們同樣具有四叉樹式的層次遞歸規(guī)律。目前，與HEALPix相關的偽球面索引和高效錐形檢索等在海量天文數(shù)據(jù)檢索中得到廣泛應用[16]。

本文使用動態(tài)索引工具預先建立HEALPix Nest索引，然后通過DIF_Circle(RA,DEC,SR)函數(shù)實現(xiàn)錐形檢索，其中，RA為赤經(jīng)，DEC為赤緯，SR為角距離。 動態(tài)索引工具使用healpix_

base工具包計算HEALPix Nest中與圓錐相交的像素，然后，通過MySQL數(shù)據(jù)庫查找對應像素，返回結果集。

3 設計與實現(xiàn)

為了實現(xiàn)海量天文大數(shù)據(jù)的高效錐形檢索，本文設計了基于數(shù)據(jù)庫中間件、MySQL數(shù)據(jù)庫和動態(tài)索引工具的方案。圖2是設計的主體框架。在圖2框架中，錐形檢索服務不是直接訪問底層數(shù)據(jù)庫，而是先通過代理服務器按照預先設定的策略，將錐形檢索命令定向轉發(fā)到數(shù)據(jù)庫中間件，經(jīng)過中間件的解析、路由、改寫、執(zhí)行以及結果集合并，其中，底層通過DBI/DBD-MySQL模塊和MySQL數(shù)據(jù)庫進行通信，可以通過MySQL數(shù)據(jù)庫函數(shù)調(diào)用。

圖2 框架設計Fig.2 Framework design

4 試驗及討論

為了驗證本文分布式錐形檢索框架的優(yōu)勢，本文進行了單機關系型數(shù)據(jù)庫MySQL與分布式架構的錐形檢索對比試驗。

4.1 測試環(huán)境

分布式測試平臺是由中科曙光(Sugon)服務器組成的集群，服務器處理器Intel(R)Xeon(R)CPU E7-4807，內(nèi)存16 G，存儲為2 × 256 GB的固態(tài)驅動器(Solid State Disk, SSD)，服務器間通過千兆網(wǎng)絡連接，操作系統(tǒng)是Ubuntu 18.04.4 LTS。一臺服務器搭建中間件系統(tǒng)，另外3臺搭建MySQL 5.7.31和DIF 0.5.5。單機測試環(huán)境與分布式測試平臺服務器配置相同。

4.2 測試數(shù)據(jù)

本測試使用蓋亞(Gaia)數(shù)據(jù)集第2版的源數(shù)據(jù)表，表中包含基本的源參數(shù)。如表1，過濾原數(shù)據(jù)集中和錐形檢索無關的數(shù)據(jù)列，從中提取source_id，ra和dec 3列數(shù)據(jù)作為測試數(shù)據(jù)，然后通過動態(tài)索引工具建立HEALPix Nest索引。

表1 數(shù)據(jù)集描述Table 1 Description of dataset

動態(tài)索引工具和大圓公式的錐形檢索對比如表2，試驗在分布式測試環(huán)境下進行，其中檢索中心為(0，50)，檢索半徑為1°。第1種， 動態(tài)索引工具的SQL模板表示以赤經(jīng)、赤緯(RA，DEC)為中心，SR為角距離進行錐形檢索。第2種，首先建立赤緯索引，然后進行(DEC-SR，DEC+SR)的范圍過濾，最后利用大圓公式計算球面角距離小于SR的集合，從而實現(xiàn)錐形檢索的目的，其中角距離SR為度(degree，deg)。大圓公式是兩點赤道坐標為p1(RA，DEC)和p2(ra，dec)，求它們的球面角距離d，公式為[17]

d=arccos[sin(DEC)sin(dec)+cos(DEC)cos(dec)cos(RA-ra)].

(4)

表2 動態(tài)索引工具與大圓公式對比Table 2 Comparison between DIF and Great-circle formula

由表2可知，兩種方式的結果集數(shù)量(Count)與兩結果集的交集(Intersect)數(shù)量一致，可以確定動態(tài)索引工具實現(xiàn)方式和優(yōu)化的大圓公式的結果一致，此外， 動態(tài)索引工具查詢方式的效率更高。

4.3 測試結果及分析

為了測試數(shù)據(jù)庫節(jié)點數(shù)量以及HEALPix Nest的索引級別對檢索效率的影響，從而確定數(shù)據(jù)庫節(jié)點數(shù)量和索引級別的選用，我們進行了以下對比實驗。根據(jù)圖3，數(shù)據(jù)庫節(jié)點分別為1，3，15，30，60和100時錐形檢索的對比，試驗的檢索中心為(40，0)，橫軸為檢索半徑SR從30到240，豎軸為檢索時間。為了消除緩存機制對實驗的干擾，試驗過程中通過set global query_cache_size=0或者set global query_cache_type=0臨時關閉緩存。對比發(fā)現(xiàn)，在節(jié)點由1增加到30的過程中，檢索時間呈遞減趨勢，然而，當節(jié)點繼續(xù)增加到60甚至100時，檢索時間呈遞增趨勢。所以，本文選擇30節(jié)點為試驗測試節(jié)點數(shù)量。

圖3 數(shù)據(jù)庫節(jié)點的對比Fig.3 Comparison for database nodes

為了對比HEALPix Nest各個索引等級對錐形檢索效率的影響，選擇在30節(jié)點下進行以(40，0)為中心、60′為檢索半徑的錐形檢索試驗，結果如圖4。

圖4 索引等級對比Fig.4 Comparison for index level

文[18]進行了索引等級與檢索效率之間的對比實驗，得出索引等級為12時方案最佳，并指出對于不同密度的數(shù)據(jù)集可能有不同的選擇。文[19]對比了HTM，HEALPix索引在Solaris，Windows和Windows Server數(shù)據(jù)庫服務器的性能，提高索引等級可提高性能，但是索引等級并不是越大越好，還得考慮索引粒度過細造成的性能退化以及硬件輸入輸出吞吐量等因素。本文結合文[18-19]及圖4的結果，選擇索引等級12為本數(shù)據(jù)樣本的最佳方案，不至于粒度過大影響檢索結果的正確率，也不至于索引等級過高造成檢索效率下降。

由圖3的對比，選擇30個節(jié)點和單機通過Jmeter工具進行壓力測試，測試采用500個并發(fā)，對系統(tǒng)進行以(40，0)為中心、查詢半徑為60、索引等級為12的錐形檢索，檢索性能指標對比如表3，中央處理器性能對比如圖5。

表3 檢索性能指標對比Table 3 Comparison of retrieval performance indicators

圖5 中央處理器性能對比Fig.5 Comparison for CPU performance

錐形檢索屬于數(shù)據(jù)密集型計算，十分消耗中央處理器資源。由表3可知，數(shù)據(jù)庫中間件的分布式方案不僅可以有效加速錐形檢索效率，而且還具有更大的吞吐量。在圖5中，MySQL單機進行錐形檢索查詢的中央處理器占用率達到90%以上，本文中間件框架下的分布式檢索的中央處理器占用率在50%左右。本文提出的面向海量天文數(shù)據(jù)的數(shù)據(jù)庫中間件分布式解決方案，能夠有效提高錐形檢索的效率，為未來巡天項目的錐形檢索提供參考。

5 結束語

日益增長的海量天文數(shù)據(jù)始終面臨著數(shù)據(jù)存儲和高效檢索的問題，本文提出了一種通過數(shù)據(jù)庫中間件和動態(tài)索引工具，來擴展MySQL數(shù)據(jù)庫系統(tǒng)的方案。主要通過數(shù)據(jù)庫中間件實現(xiàn)MySQL數(shù)據(jù)庫的分庫分表，緩解海量天文數(shù)據(jù)存儲、檢索的壓力。為了進一步加快天文數(shù)據(jù)的檢索，引入了動態(tài)索引工具整合MySQL數(shù)據(jù)庫，使方案能夠滿足對海量天文數(shù)據(jù)進行高效錐形檢索的需求。通過測試，本文的分布式檢索方案選擇索引等級為12時，能夠對海量天文數(shù)據(jù)進行高效的錐形檢索，不僅可以緩解錐形檢索帶來的負載壓力，還能有效保證數(shù)據(jù)的安全性、數(shù)據(jù)庫的高可用性。未來的研究工作是對比不同的索引算法(HTM，HEALPix和Q3C等)是否同樣適用于本文的架構方案，以及列式數(shù)據(jù)庫或者向量引擎對錐形檢索的影響。另外動態(tài)索引工具適用于mariaDB和MySQL，需對比兩者的檢索性能。最后， 動態(tài)索引工具的算法是否可以利用圖形處理器加速，以及如何改進錐形檢索的算法，需要進一步的試驗和探索。

致謝：感謝國家天文臺-阿里云天文大數(shù)據(jù)聯(lián)合研究中心對本項工作的支持。