中等待执行的任务的平均等 待时间为Ti，任务数量为Π2,而其当前任务队列中的任务的预估平均等待时间已经超过了 r X Τι，则不让该数据库节点参与任务T及其子任务的执行，其中，1.3含r，300含t6含7200，1 < η2，Τ? = ?6/π2;
[0037] 前述的基于阵列模型的数据库系统中，进行任务分配时，根据系统监控子系统收 集的监控数据按照如下的分配方法分配任务：
[0038] 如果某数据库节点在过去的时间t7秒内，其任务等待队列的长度为Ν，而该数据库 节点当前的任务队列中等待执行的任务的数量已经超过了 rXN，则不让该数据库节点参与 任务T及其子任务的执行，其中，1.3含r，300含t7含7200，10 < N。
[0039] 前述的基于阵列模型的数据库系统中，进行任务分配时，根据系统监控子系统收 集的监控数据按照如下的分配方法分配任务：
[0040].对于能够执行任务T及其子任务的η个数据库节点，将它们记为CNi，CN2， ......CNn，若在过去的时间t8秒内，运行于CNl、CN连CNn上的任务的平均等待时间分别为 TCNi，TC化，......TCNn，若TCNi是TC化，TCN2，......TCNn中取值最小者，则分配数据库节点 CNi参与任务T及其子任务的执行，对于任务平均等待时间相同的数据库节点，则按照数据 库节点可用内存量更大、CPU利用率更低的优先原则，进行任务分配;其中，300含t8含7200。
[0041] 前述的基于阵列模型的数据库系统中，进行任务分配时，根据系统监控子系统收 集的监控数据按照如下的分配方法分配任务：
[0042] 若所有的数据库节点不具备参与执行任务T及其子任务的资格，则将任务T分成更 多的子任务，然后按照在过去t9秒内，任务队列中的任务的平均等待时间最短的数据库节 点优先的原则，分配对应的数据库节点参与任务T及其子任务的执行，对于任务平均等待时 间相同的数据库节点，则按照可用内存量更大、CPU利用率更低的优先原则，进行任务分配， 其中，300 <t9< 7200。
[0043] 为了满足大规模科学数据的存储和分析需求，本文提出了一种基于阵列模型的数 据库系统(FASTDB)。它基于面向阵列的SciDB软件系统研发，是一个能够对大规模科学数据 进行存储分析的科学数据库系统。
[0044] 与现有技术相比，本发明通过在FASTDB系统中内置了系统监控子系统，该子系统 可W实时收集监控数据库集群中的和负载状况相关的数据，包括CPU利用率、内存量、磁盘 读写速率、网络带宽利用率、平均等待时间和任务数量等。收集到的运些数据后，反馈给数 据处理子系统，数据处理子系统基于系统监控子系统收集的监控数据制定任务分配方法， 然后应用运些分配方法来将系统中等待执行的任务分配到合适的数据库节点予W执行， FASTDB系统设计并满足了科学数据的分析存储需求，进而适应了系统的调优和优化分析的 进一步需要;本发明中增加了KVM虚拟化技术的应用接口，因而FASTDB数据库集群中的数据 库节点，可W通过方便的部署到KVM虚拟机节点中，而无需过多的人工干预。
[0045] 申请人将本申请的FASTDB系统和基于传统关系数据库的SkyServer系统进行了一 系列对比实验，实验设计与性能分析如下：
[0046] 实验环境
[0047] SkyServer为斯隆数字巡天数据仓库提供了公有接口，允许天文学家和大众进行 访问。实验所使用的是第九版本的斯隆数字巡天数据集(SDSS DR9KSDSS DR9是斯隆数字 巡天观测25%的天空，获取到的一百多万个天体的多色测光数据和光谱数据，其中关系型 数据的大小大约为12TB。
[004引实验的所有集群节点采用的是Intel(R)Xeon(I0E5-26202.00GHz双CPU,操作系统 采用Centos 6.4和Windows 2008,协调节点的配置为40GB的内存和1TB的硬盘空间，每个工 作节点（数据库节点）的配置为8GB的内存和1TB的硬盘空间。FASTDB的存储引擎采用SciDB 14.3，SkySe;rve;r的存储引擎采用Microsoft SQL Server 2008 R2。为了结果的可重复性， SciDB 14.3和Microsoft SQL Server 2008 R2均采用默认配置。
[0049] 实验设计
[0050] 在商业领域，传统的数据存储管理系统大多是基于关系型数据库，而基于 S化Server的数据存储和管理系统是其中一种比较成熟而且被广泛应用的系统。在天文学 领域，基于SkyServer的数据存储和管理系统也是一种被广泛认可的系统，计算机专家对该 系统针对天文领域中常用的一些查询和分析语句的执行做了一定的优化。FASTDB是基于 SciDB来实现天文大数据的存储和管理，SkyServer则是基于SQL Server的，因而，选取 SkyServer和SciDB的进行性能对比实验。实验中为了评估SkyServer和FASTDB的性能，采用 Ξ种不同类型的天文分析任务进行实验。Ξ种分析任务总共包含如下的8个查询分析任务： [0051 ] Q1查询分析是从化otoObj表中找到一个运动速度为1336,场数为11的天体。
[0052] Q2查询分析是从Galaxy表中找到满足比22光度更亮、本地消光大于0.175的所有 星系。其中，光度值越小则越亮，r是光亮数，extinction_;r是本地消光。
[0053] Q3查询分析是通过坐标从Gala巧表中找到满足-0.642788*cx+0.766044相y〉= 0 与-0.984808*cx-0.173648*巧<0范围区域的星系。
[0054] Q4查询分析是通过白矮星W及近卫卫星从曲otoPrima巧表中找到激变变星或者 激变前变星。
[0055] Q5查询分析是从Star表中找到类星体。
[0056] Q6查询分析是从Galaxy表中找出混杂在星体中的星系，并输出该星系的光度W及 天体的obj ID等信息。
[0057] Q7查询分析从化otoPrima巧表找出30角秒内有相近色的所有天体，其中，天体通 过obj ID来标识信息。
[0058] Q8查询分析分析会通过合并所有星系，并输出星系的总数。
[0059] W上的分析任务中，Q1到Q5属于第一种类型的天文分析，该类语句可W归为 "SELECT冲R0M*WHERE*"形式。Q1是通过特定条件寻找天体，Q2通过指定亮度信息等寻找星 系，Q3、Q4、Q5在给定的条件中捜索整个星空寻找天体。Q6属于第二种类型的天文分析任务， 该类语句可W归为"沈LECT冲R0M*J0IN*0N*W肥RE*"形式。第Ξ种类型的天文分析任务可W 归为"SELECT 冲 R0M*AS*J0IN*0N*AS*J0IN*0N*W 肥 RE*AND*"形式。Q7、Q8 就是属于运类分析。 此外，我们通过SDSS DR9随机抽取了5种不同大小的数据集进行试验，具体数据大小和记录 数如表1所示。
[0060] 表 1
[0061]
[0062] 当我们对SkyServer和FASTDB进行对比分析的时候，实验环境采用冷启动的方式， 并且清除系统缓存，W免对实验造成影响。我们抽取80000条记录作为最小的数据集，而 8000000记录作为最大的数据集进行实验。
[0063] 实验结果与性能分析
[0064] 图3到图10清楚的表明SkyServer和FASTDB在5种不同数据集上执行8个分析任务 的性能对比结果。横坐标指代的是数据大小，纵坐标表示完成各个分析任务所消耗的时间。 在FASTDB运行Q6、Q7和Q8是消耗的时间远远大于化yServer，同时其响应时间超过了规定的 有效时间阔值，因此我们忽略超过的运部分时间区间。如图8到图10。
[0065] 根据实验结果分析图所示，FASTDB执行Q1到Q5五个查询分析所得的响应时间远远 低于SkyServer系统。取总的响应时间的平均值来看，FASTDB的性能表现比SkyServer的性 能表现快2个数量级。从图中可W更进一步发现，随着数据集大小的增大，FASTDB的性能表 现越来越好。造成FASTDB性能表现如此之好有W下两个原因，首先，FASTDB使用阵列作为一 等公民，它所支持的多维阵列模型能够满足大部分科学领域中的数据存储模型，如今科学 领域中大部分的科学数据都是W阵列形式存在的，若能在分析的时刻保持其数据存储特征 (即阵列）则非常有利于进一步的挖掘其科学价值。实际上，大部分的科学分析任务都会用 到线性操作，比如矩阵操作等，运些操作的最大特征是基于阵列模型的。因此FASTDB的数据 模型特性很好的支持了科学数据的分析。其次，FASTDB把数据压缩并且分割存储到每个工 作节点中的特性也对其优越的性能表现提供了支持。FASTDB中压缩机制能够加快查询分析 的速度，同时减少其响应时间，此外其压缩机制可W是数据W更小的粒度进行网络传输，进 而减少网络开销。
[0066] 从第二和第Ξ