面向海量天文数据的分布式MySQL锥形检索研究*

杨 超，梁 波,2，戴 伟,2，卫守林,2，邓 辉，王 锋

(1. 昆明理工大学信息工程与自动化学院，云南 昆明 650500；2. 昆明理工大学云南省计算机技术应用 重点实验室，云南 昆明 650500；3. 广州大学天体物理中心， 广东 广州 510006)

近年来，随着大型天文观测装置的性能不断提升，以及获取天文观测数据的能力空前加强，天文观测数据呈现指数式增长。如我国自主设计研发的大天区面积多目标光纤光谱天文望远镜(Large Sky Area Multi-object Fiber Spectro-scopic Telescope, LAMOST， 又叫郭守敬望远镜)每晚采集的光谱数据达到20 GB[1]；鲁宾天文台(Vera C. Rubin Observatory)的大口径全天巡视望远镜(Large Synoptic Survey Telescope, LSST)每晚采集的原始观测数据多达15 TB；平方公里阵列(Square Kilometre Array, SKA)是国内外共同协作的大科学装置，是世界上最大的射电望远镜[2]，预计每年产出数据约300 PB。在大数据时代背景下，探索海量天文数据如何高效、可扩展的检索成为天文科学观测领域亟待解决的难题。

科学检索传统上依赖于关系型数据库，对于非海量的结构化数据，通过建立数据索引机制能够取得较好的检索效率。但是，随着天文观测逐渐从光学覆盖到全波段，传统数据库无法适应数据雪崩式增长带来的冲击。NoSQL系统通常使用键值存储格式，同一键下的所有数据值存储在一起并可以快速访问。文[3]提出了AstroSpark天文检索系统，文[4]实现了基于分布式阵列数据库的FASTDB系统，它们具有低延迟、可扩展、高性价比等优点。但是，由于采用了底层存储格式，它们缺乏关系模型的高级功能，并且损害了ACID(Atomicity, Consistency, Isolation, Durability)属性[5]。近年来，NoSQL演变到NewSQL，NewSQL系统本质上是一个数据库管理系统(Database Management System, DBMS)，可以为结构化查询语言(Structured Query Language, SQL)、索引和架构提供支持，它不仅可以支持事务的ACID属性，而且具有与NoSQL相同的可伸缩性。它的基本体系结构是并行的数据库管理系统，在查询负载方面的性能优于MapReduce框架[6]。分布式关系数据库结合传统关系数据库、分布式集群以及分布式事务来实现，不仅和传统数据库具有高度兼容性，还可以更好地支持结构化查询语言和事务处理[7]。

但是，即使在性能强大的分布式关系数据库中，由于各大天文巡天项目发布的星表的数据量越来越大，直接检索方式无法满足当前天文数据的检索需求，所以大规模星表数据集的检索访问需要有效的球面索引，目前应用广泛的伪球面索引方法有层次化三角形网格(Hierarchical Triangular Mesh, HTM)，HEALPix(Hierarchical Equal Area isoLatitude Pixelisation)及Q3C (Quad Tree Cube)等。在建立适合的球面索引之后，可以通过锥形检索实现大规模星表数据集的检索。作为天文领域的一种特殊检索方式[8]，锥形检索定义天区中的赤经(Right Ascension, RA)、 赤纬(Declination, Dec)和角距离(SR)的位置信息，通常是以(Tra，Tdec)为圆心、角距离为半径的锥形区域，锥形检索就是对这个锥形相关天体的信息查询，即查询目标星体r(Sra，Sdec)。本文整合动态索引工具到分布式MySQL数据集群，使分布式关系型数据库能够建立伪球面索引，从而实现高效的锥形检索。

1 数据库中间件

数据库中间件可以封装底层数据，实现与单数据库一样的数据操作方式。目前有两种典型的数据库中间件模式，分别是服务端代理(数据库代理)和客户端代理(数据源代理)。服务端代理方式是通过代理服务器管理多个数据库实例，客户端通过数据源与代理服务器建立连接，客户端所有的SQL操作由代理分发给底层数据库，得到的结果也同样经过代理整合返回给客户端。客户端代理方式是内部管理多个普通数据源，客户端的SQL通过数据源代理进行解析、改写等操作，然后分发给普通数据源执行，得到结果也由代理整合并返回客户端[9]。从SQL处理过程分析，数据库中间件可以解析客户端发送的事务请求，在进行解析、优化和路由分析时，拆分为数据库可以执行的线程任务，按照预先设置的分库分表规则发送到多个数据库服务端，可以有效缓解单机数据库的负载压力，起到削峰的作用。为了数据库中间件能够支持高可用，可添加配置中心和监控服务形成简单的高可用架构。通过监控服务监测集群状态，如有变更，推送变更信息到配置中心，数据库代理Proxy拉取配置中心的变更信息，从而更新数据库配置，数据库中间件框架如图1。

图1 数据库中间件框架Fig.1 Database middleware architecture

为了降低锥形检索服务的负载和开销，可采用主从读写分离分布、分库分表的方式，实现数据库的横向扩展，提高锥形检索效率和并发量。

1.1 分库分表

分库分表是数据库中间件的核心功能。常用的切分方法有垂直切分和水平切分，在分布式领域，常用水平分库分表的方式解决单一数据库的瓶颈，缓解单机数据库的访问压力。使用关系型数据库MySQL来水平划分，根据水平分表规则将全局关系的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 读写分离

由于数据库读取操作的比例远远大于写入操作，常使用一主多从的分布方式，主节点负责写操作，从节点负责读操作，通过读写分离，将负载均衡到多个节点。使用读写分离机制需要维护好数据一致性问题，常用的数据同步方式除了主从复制，还有Paxos，Raft，Term和ZAB等协议算法[11]。MySQL中常使用MySQL Proxy作为读写分离的中间层，通过内嵌式Lua解析器定义查询处理等[12]。

2 动态索引工具插件

动态索引工具[13]是开源的MySQL/MariaDB数据库插件，由C++库、Perl脚本和SQL存储过程编译而成，采用离散化二维空间的方法，并使用像素化方法将其映射到一维空间。然后为每个像素标记一个唯一的索引ID，如果只按照穷举的方式进行检索，时间复杂度为O(n)。在进行锥形检索时，需要建立伪球面索引降低检索的时间复杂度，而大多数索引基于树结构。B-Tree[14]索引方法可以将时间复杂度减少到log2N，但是由于B-Tree的深度随着数据量的增加而增加，因此难以应用于海量数据的索引。基于B+树的索引方法是数据库系统中最常用的动态索引结构，也是动态索引工具通过MySQL建立伪球面索引使用的方法。

动态索引工具使用目前应用最广泛的几种伪球面索引方法中的分层三角网格和HEALPix。分层三角网格作为天区划分的经典索引方式，最早应用于斯隆数字巡天(Sloan Digital Sky Survey, SDSS)数据。HEALPix用等面积的四边形区块划分替换三角形划分方式[15]，但是它们同样具有四叉树式的层次递归规律。目前，与HEALPix相关的伪球面索引和高效锥形检索等在海量天文数据检索中得到广泛应用[16]。

本文使用动态索引工具预先建立HEALPix Nest索引，然后通过DIF_Circle(RA,DEC,SR)函数实现锥形检索，其中，RA为赤经，DEC为赤纬，SR为角距离。 动态索引工具使用healpix_

base工具包计算HEALPix Nest中与圆锥相交的像素，然后，通过MySQL数据库查找对应像素，返回结果集。

3 设计与实现

为了实现海量天文大数据的高效锥形检索，本文设计了基于数据库中间件、MySQL数据库和动态索引工具的方案。图2是设计的主体框架。在图2框架中，锥形检索服务不是直接访问底层数据库，而是先通过代理服务器按照预先设定的策略，将锥形检索命令定向转发到数据库中间件，经过中间件的解析、路由、改写、执行以及结果集合并，其中，底层通过DBI/DBD-MySQL模块和MySQL数据库进行通信，可以通过MySQL数据库函数调用。

图2 框架设计Fig.2 Framework design

4 试验及讨论

为了验证本文分布式锥形检索框架的优势，本文进行了单机关系型数据库MySQL与分布式架构的锥形检索对比试验。

4.1 测试环境

分布式测试平台是由中科曙光(Sugon)服务器组成的集群，服务器处理器Intel(R)Xeon(R)CPU E7-4807，内存16 G，存储为2 × 256 GB的固态驱动器(Solid State Disk, SSD)，服务器间通过千兆网络连接，操作系统是Ubuntu 18.04.4 LTS。一台服务器搭建中间件系统，另外3台搭建MySQL 5.7.31和DIF 0.5.5。单机测试环境与分布式测试平台服务器配置相同。

4.2 测试数据

本测试使用盖亚(Gaia)数据集第2版的源数据表，表中包含基本的源参数。如表1，过滤原数据集中和锥形检索无关的数据列，从中提取source_id，ra和dec 3列数据作为测试数据，然后通过动态索引工具建立HEALPix Nest索引。

表1 数据集描述Table 1 Description of dataset

动态索引工具和大圆公式的锥形检索对比如表2，试验在分布式测试环境下进行，其中检索中心为(0，50)，检索半径为1°。第1种， 动态索引工具的SQL模板表示以赤经、赤纬(RA，DEC)为中心，SR为角距离进行锥形检索。第2种，首先建立赤纬索引，然后进行(DEC-SR，DEC+SR)的范围过滤，最后利用大圆公式计算球面角距离小于SR的集合，从而实现锥形检索的目的，其中角距离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 动态索引工具与大圆公式对比Table 2 Comparison between DIF and Great-circle formula

由表2可知，两种方式的结果集数量(Count)与两结果集的交集(Intersect)数量一致，可以确定动态索引工具实现方式和优化的大圆公式的结果一致，此外， 动态索引工具查询方式的效率更高。

4.3 测试结果及分析

为了测试数据库节点数量以及HEALPix Nest的索引级别对检索效率的影响，从而确定数据库节点数量和索引级别的选用，我们进行了以下对比实验。根据图3，数据库节点分别为1，3，15，30，60和100时锥形检索的对比，试验的检索中心为(40，0)，横轴为检索半径SR从30到240，竖轴为检索时间。为了消除缓存机制对实验的干扰，试验过程中通过set global query_cache_size=0或者set global query_cache_type=0临时关闭缓存。对比发现，在节点由1增加到30的过程中，检索时间呈递减趋势，然而，当节点继续增加到60甚至100时，检索时间呈递增趋势。所以，本文选择30节点为试验测试节点数量。

图3 数据库节点的对比Fig.3 Comparison for database nodes

为了对比HEALPix Nest各个索引等级对锥形检索效率的影响，选择在30节点下进行以(40，0)为中心、60′为检索半径的锥形检索试验，结果如图4。

图4 索引等级对比Fig.4 Comparison for index level

文[18]进行了索引等级与检索效率之间的对比实验，得出索引等级为12时方案最佳，并指出对于不同密度的数据集可能有不同的选择。文[19]对比了HTM，HEALPix索引在Solaris，Windows和Windows Server数据库服务器的性能，提高索引等级可提高性能，但是索引等级并不是越大越好，还得考虑索引粒度过细造成的性能退化以及硬件输入输出吞吐量等因素。本文结合文[18-19]及图4的结果，选择索引等级12为本数据样本的最佳方案，不至于粒度过大影响检索结果的正确率，也不至于索引等级过高造成检索效率下降。

由图3的对比，选择30个节点和单机通过Jmeter工具进行压力测试，测试采用500个并发，对系统进行以(40，0)为中心、查询半径为60、索引等级为12的锥形检索，检索性能指标对比如表3，中央处理器性能对比如图5。

表3 检索性能指标对比Table 3 Comparison of retrieval performance indicators

图5 中央处理器性能对比Fig.5 Comparison for CPU performance

锥形检索属于数据密集型计算，十分消耗中央处理器资源。由表3可知，数据库中间件的分布式方案不仅可以有效加速锥形检索效率，而且还具有更大的吞吐量。在图5中，MySQL单机进行锥形检索查询的中央处理器占用率达到90%以上，本文中间件框架下的分布式检索的中央处理器占用率在50%左右。本文提出的面向海量天文数据的数据库中间件分布式解决方案，能够有效提高锥形检索的效率，为未来巡天项目的锥形检索提供参考。

5 结束语

日益增长的海量天文数据始终面临着数据存储和高效检索的问题，本文提出了一种通过数据库中间件和动态索引工具，来扩展MySQL数据库系统的方案。主要通过数据库中间件实现MySQL数据库的分库分表，缓解海量天文数据存储、检索的压力。为了进一步加快天文数据的检索，引入了动态索引工具整合MySQL数据库，使方案能够满足对海量天文数据进行高效锥形检索的需求。通过测试，本文的分布式检索方案选择索引等级为12时，能够对海量天文数据进行高效的锥形检索，不仅可以缓解锥形检索带来的负载压力，还能有效保证数据的安全性、数据库的高可用性。未来的研究工作是对比不同的索引算法(HTM，HEALPix和Q3C等)是否同样适用于本文的架构方案，以及列式数据库或者向量引擎对锥形检索的影响。另外动态索引工具适用于mariaDB和MySQL，需对比两者的检索性能。最后， 动态索引工具的算法是否可以利用图形处理器加速，以及如何改进锥形检索的算法，需要进一步的试验和探索。

致谢：感谢国家天文台-阿里云天文大数据联合研究中心对本项工作的支持。