管理查询的制作方法

专利名称：管理查询的制作方法
技术领域：
本说明书涉及管理查询。
背景技术：
一些数据存储系统(例如数据库)存储大量数据，所述数据是以意欲支持处理大量查询的方式存储的。例如，一些系统通过使用并行存储设备、并行查询处理引擎或者两者而包括并行处理能力。

发明内容
总地来说，在一个方面，一种用于管理对一个或多个数据源执行的查询的方法包括将至少第一查询存储在存储介质中；选择用于处理的第一查询；指示查询引擎在第一查询间隔内在所述一个或多个数据源中的数据的第一部分上处理第一查询；基于在数据的第一部分上处理第一查询，从查询引擎接收结果数据；在第一查询间隔之后，将第一查询的状态保存在存储介质中；在第一查询间隔之后的第二查询间隔期间，指示查询引擎处理第二查询；以及在第二查询间隔之后的第三查询间隔期间，指示查询引擎在所述一个或多个数据源中的数据的第二部分上处理第一查询。各个方面可以包括以下特征中的一个或多个。该方法还包括将与第一查询相关联的优先级存储在存储介质中；在选择用于处理的第一查询之前改变与第一查询相关联的优先级；其中，选择用于处理的第一查询包括部分地基于所述优先级来选择该查询。第一查询间隔由预定时间量定义。第一查询的优先级影响将所述一个或多个数据源中的多少数据包括在第一查询间隔内在其上执行第一查询的数据的第一部分中。存储第一查询包括存储在通知提供第一查询的请求者之前可以获得的结果数据的数量的通知阈值。该方法还包括当结果数据的数量超过通知阈值时通知请求者，其中，保存第一查询的状态包括存储从查询引擎接收的结果数据的数量。该方法还包括当从请求者请求时返回结果数据；以及将返回给请求者的结果数据的数量存储在存储介质中。选择查询是基于从查询引擎接收的结果数据的数量和返回给请求者的结果数据的数量进行的。保存第一查询的状态包括指示查询引擎中止第一查询；以及在中止第一查询之后保存第一查询的状态。指示查询引擎在数据的第二部分上处理第一查询包括加载所保存的第一查询的状态；以及指示查询引擎重新开始第一查询。保存第一查询的状态包括将偏移量保存在二级索引中。二级索引是块压缩索引文件。该方法还包括将第一查询划分为多个子查询，并且指示查询引擎并发地处理所述子查询中的至少一些。 在第一查询间隔开始之后接收第二查询并且将其存储在存储介质中。在第一查询间隔开始之前接收第二查询并且将其存储在存储介质中。一般地说，在另一方面，一种计算机可读介质存储用于管理对一个或多个数据源执行的查询的计算机程序。该计算机程序包括指令，该指令用于使计算机将至少第一查询存储在存储介质中；选择用于处理的第一查询；指示查询引擎在第一查询间隔内在所述一个或多个数据源中的数据的第一部分上处理第一查询；基于在数据的第一部分上处理第一查询，从查询引擎接收结果数据；在第一查询间隔之后，将第一查询的状态保存在存储介质中；在第一查询间隔之后的第二查询间隔期间，指示查询引擎处理第二查询；以及在第二查询间隔之后的第三查询间隔期间，指示查询引擎在所述一个或多个数据源中的数据的第二部分上处理第一查询。一般地说，在另一方面，一种用于管理对一个或多个数据源执行的查询的系统。该系统包括存储介质，其存储至少第一查询。该系统包括查询引擎，其被配置为在所述一个或多个数据源中的数据上处理查询。所述系统还包括服务器，其被配置为选择用于处理的第一查询；指示查询引擎在第一查询间隔内在所述一个或多个数据源中的数据的第一部分上处理第一查询；基于在数据的第一部分上处理第一查询，从查询引擎接收结果数据；在第一查询间隔之后，将第一查询的状态保存在存储介质中；在第一查询间隔之后的第二查询间隔期间，指示查询引擎处理第二查询；以及在第二查询间隔之后的第三查询间隔期间，指示查询引擎在所述一个或多个数据源中的数据的第二部分上处理第一查询。一般地说，在另一方面，一种用于管理对一个或多个数据源执行的查询的系统。该系统包括存储介质，其存储至少第一查询。该系统包括查询引擎，其被配置为在所述一个或多个数据源中的数据上处理查询。所述系统包括用于管理存储介质中的查询的部件，所述管理包括指示查询引擎在第一查询间隔内在所述一个或多个数据源中的数据的第一部分上处理第一查询；基于在数据的第一部分上处理第一查询，从查询引擎接收结果数据；在第一查询间隔之后，将第一查询保存在存储介质中；在第一查询间隔之后的第二查询间隔期间，指示查询引擎处理第二查询；以及在第二查询间隔之后的第三查询间隔期间，指示查询引擎在所述一个或多个数据源中的数据的第二部分上处理第一查询。各个方面可以包括以下优点中的一个或多个。部分地基于与查询相关联的优先级选择查询可以允许并行查询处理系统中的高效处理。将时间切分为多个间隔(在各间隔中查询的各部分可以被部分地处理并且然后被中止)允许一些查询被更快地处理，并且减少系统中的一些潜在的积压(backlog)，尤其是对于高优先级的查询。根据以下描述以及权利要求，本发明的其他特征和优点将变得显而易见。


图I和图2是示出查询处理的示意图。图3是数据存储系统的框图。图4是加索引的压缩数据存储器的示意图；图5A-5B、6A_6B以及7A-7D是示出与处理查询相关联的时间的间隔的图。图8是切分后的查询处理的示意图。图9是示出加索引的压缩数据存储器的查询处理的示意图。图10和11是用于管理查询的处理的流程图。
具体实施例方式I.概述参照图1，在分布式查询管理中可能出现若干问题。例如，当以先进先出的方式将查询传递到数据存储系统的查询引擎时，系统可能出现积压。在一些情况下，所传递的查询可以包括短查询102、104、108、112、118，其快速地执行，并且对资源的需求较少；长查询110、114、116，其需要较长的时间来执行，并且使用大量系统资源；以及落在短查询和长查询之间的某处的查询。在执行特定查询之前预先确定该查询将需要的系统资源量可能是不实际的。图I示出了使用多个查询引擎处理查询的系统的示例。查询被异步地接收并且被存储在队列101中，等待由在数据存储系统的查询服务器100上执行的查询引擎处理的机会。在此示例中，最初，将长查询116分配给第一查询引擎120以便处理，并且将短查询118分配给第二查询引擎122以便处理。参照图2，一段短的时间之后，短查询118可能已经完成，并且队列中的下一个查询，即长查询114被分配给空闲的查询引擎122。此时，剩余的查询102、104、108、110、112—直等待到长查询116、114之一完成处理并且释放掉查询引擎中的处理资源为止。这种现象增大了较短的查询的等待时间，并且可能在期望对其作出快速答复的查询中导致不可接受的延迟。参照图3，数据存储系统300被配置为提供前端服务302，例如web服务，以便接收执行查询的请求。协调(mediation)服务器304调度由多个查询引擎312进行的查询的执行。每个查询被允许执行所指派的时段，该时段可以通过例如时间(例如由CPU时钟测量)、持续时间、处理的行数、或者检索的行数来测量。查询引擎312访问来自一个或多个数据源310A、310B、310C的数据，以便处理查询，从而产生结果集314。提供所述数据源的存储设备可以相对于系统300是本地的，例如被存储在连接到实现协调服务器304的计算机的存储介质(例如硬盘驱动器)上，或者可以相对于协调服务器304是远程的，例如驻留在经由远程连接进行通信的远程系统(例如大型机)上。
协调服务器304管理结果集314。协调服务器304可以存储关于查询的附加信息，例如查询的优先级、所请求的行数、从查询返回的行数、返回给请求者的行数、对于将如何使用查询的指示、一次需要多少行、查询引擎执行查询的最后时间以及状态指示符。状态指示符可以指示查询正在等待、正在运行、被中止、被中断或者完成。在一些配置中，查询状态也可以指示在查询处理期间发生的错误状态的存在。处于等待状态的查询有资格被执行，但不是当前正在运行。处于运行状态的查询当前正由查询引擎处理。处于中止状态的查询没有资格被执行，因为协调服务器已经返回了客户端当前请求的行数。处于中断状态的查询没有资格被执行，因为他们已经被更高优先级的查询取代。处于完成状态的查询已经完成了执行。在一些配置中，支持附加的状态。协调服务器304也可以存储标识应当何时以及如何向请求者通知查询结果已经准备好以供处理的信息。在一些配置中，多个查询引擎可以对单个查询的不同部分独立地操作。每个查询引擎独立地更新协调数据库。一旦在发生触发事件时，例如在组合的查询引擎返回了所请求的行数时，就将触发通知事件。在一些实现方式中，协调服务器包括协调逻辑模块306和协调数据库308。在一些 实现方式中，协调逻辑模块306可以被合并到单独的查询引擎312、前端服务302中，或者在多个服务之间被划分。查询引擎312可以针对结果集314中的可用行数而更新协调数据库308。在一些实现方式中，参照图4，数据源310包括加索引的压缩数据存储器402。加索引的压缩数据存储器包括例如被存储在文件中的多个压缩数据块404。每个压缩数据块与至少一个索引406相关联，所述索引使得能够定位该压缩数据块中的数据。在一些实现方式中，提供一级索引，可以基于第一关键字(例如主关键字)搜索一级索引，并且提供一个或多个二级索引，可以基于其他关键字(例如外部关键字)搜索所述二级索引。一些索引可以由代理(surrogate )关键字组成，其中每个关键字的值是唯一的,其他索引基于自然关键字，其中关键字的值在数据集中可以不是唯一的。在一些实现方式中，可以组合自然索引以创建单个合并索引(consolidated index)。在美国专利申请公开No. 2008/0104149A1中更详细地描述了加索引的压缩数据存储器技术和系统，其通过引用而被合并于此。2.查询切分参照图5A，在示出与不同查询相关联的时间间隔的图中示出了一系列查询A502、B504、C506和D508。如果查询被按照传递它们的顺序执行，则在间隔502上执行查询A至完成，然后在间隔504上执行查询B至完成，然后是间隔506上的查询C以及间隔508上的查询D。在这些状况下，查询A不会返回结果，直到它在时刻510完成，查询B不会返回结果，直到它在时刻512完成，查询C不会返回结果，直到它在时刻514完成，查询D不会返回结果，直到它在时刻516完成。尽管查询D是短查询，但是它花费较长的时间来返回任何结果，因为它碰巧位于其它更长的查询之后。在协调服务器304的一些实现方式中，代替必须依序运行查询至完成，协调服务器将查询划分为多个不同的更小的部分。指示查询引擎304在特定间隔内执行查询。该间隔可以由时间段、要返回的行数、处理的行数来定义，或者可以基于某种其他标准来定义。使用这一方法，参照图5B，查询A在间隔528内运行，查询B在间隔530内运行，查询C在间隔532内运行，查询D在间隔534内运行(至完成)，然后，查询A在第二个间隔内再次运行。在一些情况下，可以在处理查询的每个间隔之后，将来自查询的一些结果返回给提交了该查询的进程(process)。例如,可以在时刻520之后返回来自查询A的一些结果,并且可以分别在时刻522、524、526之后返回来自查询B、C和D的一些结果。通过将查询划分为小执行间隔，与系统必须等待查询完成才能执行其他查询相比，系统300可以更快地产生更多查询的一些结果。此外，在使其他查询延迟的折衷下，一些查询可以比在其他情况下完成它们更快地完成。在此示例中，在时刻526完成查询D，在时刻540完成查询C，在时刻542完成查询A，在时刻544完成查询B。因此，在此示例中，以使较长的查询A和B延迟为代价，较短的查询C和D更快地完成。对于如何划分查询的确定可取决于对于系统希望的操作特性。例如，提供基于时间来划分查询可以保证允许每个查询执行特定数量的工作，但是不保证该工作可以花费多少日历时间，也没有关于在一个执行间隔中可以返回多少行的保证。相比之下，允许查询一直执行直到返回多行为止决定了将需要多少执行间隔来产生多个结果，但是不存在关于间隔可以持续多久的保证。允许查询一直运行直到处理了多行为止可以允许系统识别将需要多少执行间隔来完成查询，但是不会告知需要多少周期来返回特定数量的行或者特定执行周期将具体花费多长时间。用于处理查询的时间可以被划分为执行间隔(或“查询间隔”)，即使正在处理单个查询。在查询间隔结束时，如果新查询到达，则中止正在处理的查询，并且使用下一查询间隔来处理该新查询。可替换地，如果在查询间隔结束时新查询没有到达，则正在处理的查询可以在附加的查询间隔内继续被处理。例如，在图6A的示例中，在查询A的处理期间，查询B在时刻610到达，在图6B的示例中，查询A和B均在查询A或查询B的处理开始之前达 到。在图6A的示例中，查询A在间隔602内运行，并且，如果在间隔602结束时没有完成查询A，则系统检查以确定是否应当在附加的查询间隔内处理查询A或者是否存在等待被处理的另一个查询。由于在间隔602结束时查询B尚未到达，因此在查询间隔604期间处理查询A。类似地，在接下来的查询间隔606中也处理查询A。然而，在查询间隔606结束时，系统确定在间隔608期间应当处理在时刻610到达的查询B。然后，在交替的间隔中处理查询A和B，直到每一个完成为止(在此示例中，查询A在时刻612完成，查询B在时刻614完成)。在图6B的示例中，查询A在间隔620中运行，并且如果在间隔620结束时查询A尚未完成，则系统检查以确定是否应当在附加的查询间隔内处理查询A或者是否存在等待被处理的另一个查询。由于查询B在间隔620结束之前到达，因此在查询间隔622期间处理查询B。然后，在交替的间隔中处理查询A和B，直到每一个完成为止。在查询间隔结束时中止查询包括将该查询的状态保存在协调数据库中。在一种配置中，在一个间隔之后，可以在协调数据库中将查询状态更新为“中止”或者指示查询没有资格被执行的另一个状态。在预定间隔之后，可以将查询的状态更新为“等待”以使得查询能够再次运行。在其他配置中，协调服务器紧接在所述预定间隔之后自动地调度查询。3.查询优先级划分和优先级重新划分协调数据库可以存储与各个查询相关联的优先级。优先级可以影响查询运行的频率和方式。参照图7A，可以向高优先级查询A提供比查询B (在间隔704期间处理)或低优先级查询C (在间隔706期间处理)更大的执行间隔702。在此示例中，向高优先级查询A提供比提供给查询B的执行间隔704更大的执行间隔702，并且向查询B提供比提供给低优先级查询C的执行间隔706更大的执行间隔704。可替换地，参照图7B，可以向高优先级查询A提供比标准优先级查询B (在间隔710期间处理)更频繁的执行间隔708，并且可以将标准优先级查询B提供比低优先级查询C (在间隔712期间处理)更频繁的执行间隔。参照图7C，在一些情况中，可以向查询A提供足够高以使得其他查询B和C的处理被中止直到查询A完成执彳丁为止(在间隔714之后)的优先级，在查询A完成执彳丁的时刻，对被中止的查询B和C的执行重新开始，分别在间隔716和718之间交替。协调数据库还允许在查询执行的同时对查询重新划分优先级。例如，参照图7D，协调数据库将高优先级查询A (在间隔720期间)与正常优先级查询B (在间隔722期间)和低优先级查询C (在间隔724期间)一起调度。在时刻726，将高优先级查询A重新划分优先级为正常优先级等级。此时，协调数据库基于新的优先级划分调整查询的调度。在优先级重新划分之后继续进行，现在向正常优先级查询A提供具有与提供给正常优先级查询B的间隔722相似的大小的执行间隔728。优先级重新划分可以因为请求进程做出的确定而发生，或者可以在协调数据库中基于其自己的标准而发生。例如，可以向协调数据库提供完成查询的最后期限，当该最后期限临近时，服务器可以提高查询的优先级以确保及时完成。在一些情况下，可以向查询提供多个较小的执行间隔，而不是单个较大的执行间隔，以便允许协调服务器检查较高优先级的业务(traffic)。在其他情况下，协调服务器可以能够中断正在运行的查询的执行间隔以便允许执行更高优先级的查询。在一些情况下，在执行查询之前，可以在执行前一查询之前或在执行前一查询期间，对所述查询进行调度，其中，新的查询在下一间隔中进入。在一些情况下，可以基于选择标准在执行之前选择要调度以便执行的下一查询。4.并行查询处理对于很多系统来说，一次执行多个查询可能是有利的。例如，相对于在系统上运行单个查询，在单个系统上运行两个查询可能具有提高的性能。例如，这可能由于一个查询可能正在使用一个计算资源而第二个查询正在使用不同的资源而发生。通过一次运行两个查询，提高了吞吐量。在一些实现方式中，参照图8，将高优先级查询802划分为查询片段(slice) 804、806、808、810、812。每个片段可由单独的查询引擎 814、816、818、820、822 处理。如上所述，可以基于要处理的行数来切分高优先级查询802。可以将分割信息与作为查询目标的加索引的压缩数据存储器的二级索引进行比较，以便确定将需要多少执行间隔来完成查询。这也将识别出每个查询片段将处理加索引的压缩数据存储器的哪些部分。例如，参照图9，加索引的压缩文件902包括多个数据块904、906、908、910，每个数据块包括多个数据记录。加索引的压缩文件902与指定(reference)数据块的索引912相关联。在一些配置中，索引可以对于每个数据块包括一个索引记录922，在其他配置中，索引912可以包括比数据块少的索引记录922。在一些配置中，每个索引记录922指定数据块904、906、908、910，在其他配置中，每个索引记录922指定数据块的第一个数据记录。协调服务器审查索引912，并且基于索引记录确定查询执行间隔(或者“查询片段”)。在此示例中，查询引擎基于索引912而选择创建四个查询片段914、916、918、920。一个查询片段914以块I 904开始处理数据记录并且以块10 (未示出)的末尾结束，查询片段916以块11 906开始处理数据并且以块20 (未示出)的末尾结束，查询片段918以块21 908开始处理并且以块30 (未示出)的末尾结束，最后，查询片段920以块31 910开始处理并且在加索引的压缩文件902的末尾结束处理。在此示例中，协调服务器可以选择创建任何数量的查询片段，所述数量仅受到索引912中的索引记录922的数量限制。参照图8，查询的每个片段可以由查询引擎814、816、818、820、822中不同的查询、引擎同时处理。例如，查询片段804可由查询引擎814处理，而查询片段806基本上同时地由查询引擎816处理。同时，查询片段808由查询引擎818处理；查询片段810由查询引擎820处理；查询片段812由查询引擎822处理。每个查询引擎产生对于它们的查询分割的结果集。一旦产生了所有结果集，就可以将所述结果集组合在一起以形成对于整个查询的完整结果集。使用这一方法，可以在完成所述操作通常花费的时间的一小部分内完成高优先级查询。5.回调系统提供当通过预先指定的标准定义的触发物被满足时的通知。参照图3，当新查询被提交到前端服务302时，该提交可以包括请求协调服务器304在条件满足时(经由前端服务302)通知请求者的信息。在一些配置中，所述条件可以是当特定数量的结果数据元 素准备好由请求者访问时的通知。例如，当一百个结果记录就绪时，可以通知请求者。在一些情况下，请求者可以指定在通知之前应当就绪的结果数据元素的数量。在其他情况下，请求者可以提供在通知该请求者之前必须满足的其他标准。例如，请求者可能希望在查询被中止时或者在所有处理完成时被通知。在一些情况下，触发标准可以被限制为在协调数据库308中跟踪的状态信息。在其他情况下，可以不限制触发标准。可以以很多种不同的方式向协调服务器304提供触发物。例如，可以作为协调服务器304在每个查询间隔之后执行的脚本或者符合预定应用编程接口(API)的编译类来提供触发物。在一些情况下，所述条件可以仅发生一次，例如已经发现100个结果记录的条件。在其他配置中，所述条件可以再次发生,例如对于每次发现100个额外的结果记录时通知的请求。在一些情况下，触发条件的提交也可以包括动作定义。该动作可以与触发物一起被存储在协调数据库308中。该动作定义当满足条件时协调服务器304如何响应。该动作可以是诸如通知、总结等的一组预定的可能动作之一。该动作可以是在协调服务器304上执行的脚本。例如，一个动作可以使用所返回的结果作为查询参数来向系统提交额外的查询。可以作为符合预先建立的API的编译类来提供该动作。6.查询中止在一些实现方式中，协调服务器304能够中止查询的处理。协调服务器可以将查询标记为被中止，并且在查询重新开始之前将不会进行处理。与中止查询一起，查询服务器可以保存查询的状态。这一状态是查询的进程的指示。例如，该状态可以是对于加索引的压缩数据存储器的偏移，或者该状态可以包括b树中最后处理的节点。在一些情况下，协调服务器可以主动地选择中止查询。例如，这可以发生在查询产生了结果集中的多个记录并且等待传递给请求者的结果集中的行的数量超过阈值的时候。例如，提交查询的请求者可以稍后请求传递固定数量的行，例如，如果用户界面可能需要25行数据的“页”来填充屏幕，则系统可以请求来自所述查询的25行的数据。稍后，如果用户指示他希望看到更多的查询结果，则系统可以请求下一“页”的查询结果或者二十六到五十的结果。协调数据库跟踪从查询返回的结果的数量以及返回给用户的结果的数量。例如，查询可能已经返回了 300行，但是可能已经将25行发送给请求者。如果从查询返回的行数相比于发送给请求者的行数超出了一个余量(例如25、50、75或100行)，则协调数据库可以中止该查询的处理。这可以通过在协调数据库中将查询标记为被中止或者经由在调度该查询的下次执行之前的检查来完成。
在一些情况下，可以由系统300定义阈值，在其他情况下，可以根据将如何使用查询而对于每个查询单独地定义阈值。例如，当四个页面的数据在等待时，可以中止其结果将被用来与固定数量的项目显示一起在网页上显示数据列表的查询。相比之下，其结果将被用来创建由查询返回的所有数据的总结报告(例如月末报告)的查询根本不能中止。在一些情况下，可以从在通知请求者之前要收集的行数来推断所述阈值。在一些情况下，可以通过更新协调数据库中的查询的状态信息来显式地中止查询。例如，可以将查询标记为被中止以允许更高优先级查询执行。在其他情况下，因为协调服务器调度算法是使得不会调度具有被中止的查询的状态的查询，所以可以隐式地中止查询。中止查询具有使提交查询时的资源浪费最少的附加优点，并且，调用程序随后在查询完成之前终止。如果请求者在预先定义的时段内没有访问所述结果，则协调服务器可以选择删除查询和结果集。7.协调服务器处理 参照图10，流程图1000表示协调服务器304的操作的示例配置，所述操作包括关于在没有外部请求的情况下是否终止查询的确定。操作包括选择用于执行的查询1002。在一个示例中，可以作为由协调服务器建立的预定日程表的一部分来选择查询。在另一示例中，可以基于某种标准来选择查询，所述标准可以包括查询的优先级和查询运行的最后时间。在一些配置中，协调服务器在等待执行(例如处于等待状态)的查询上循环(iterate)。每个查询按计划在查询引擎上运行。一旦执行了所有等待的查询，协调服务器就重复对于仍在等待执行的查询的处理。在其他配置中，协调服务器选择已经等待了最长的间隔的查询以便执行。在其他配置中，协调服务器选择具有最高优先级的查询以便执行。操作还包括在查询引擎上运行查询1004。在一个示例中，可以将所选择的查询分配给针对数据记录执行查询、更新结果集并且向协调服务器通知所返回的行数的查询引擎。操作还包括检查等待传递的行数1006。如果等待传递的行数超过通知阈值，则协调服务器执行对请求者的回调1008。操作还包括检查1010,如果等待请求者访问的行数超过中止阈值,则中止查询1012。无论是否中止查询，协调服务器都继续选择要处理的下一个查询。参照图11，流程图1100表示协调服务器304响应于例如在回调已经向请求者通知所述结果已经准备好访问之后请求者访问由查询返回的结果集的一部分而进行的操作的示例配置。操作包括请求者请求来自查询的结果1102。在一些配置中，请求者可以发送要返回的行数的指示，例如返回25行的请求。在其他配置中，请求者可以请求返回特定范围的结果。例如，请求者可以请求返回50到126的结果。在其他配置中，请求者可以请求返回所收集的所有结果。操作还包括返回结果并且更新记录1104。响应于所述请求，协调服务器可以提供对所请求的行的访问。在一些配置中，协调服务器也可向请求者发送关于查询仍然在处理附加结果的指示。在其他配置中，协调服务器也可以提供关于可以获得附加结果以进行即刻传递的指示。
操作还包括检查1106以确定当前查询是否被中止。如果查询被中止，则控制传递到下一操作1108。否则，该处理完成。操作还包括检查1108以确定等待传递的行数是否小于中止阈值。如果是这样，则重新开始查询1110，并且协调服务器可以调度该查询以进行处理。上述查询管理方法可以使用用于在计算机上执行的软件来实现。例如，所述软件形成一个或多个计算机程序中的例程，所述计算机程序在一个或多个已编程或可编程计算机系统(其可以是各种架构，例如分布式、客户端/服务器或网格)上执行，每个计算机系统包括至少一个处理器、至少一个数据存储系统(包括易失性和非易失性存储器和/或存储元件)、至少一个输入设备或端口、以及至少一个输出设备或端口。所述软件可以形成例如更大程序的一个或多个模块，所述更大程序提供与计算图的设计和配置有关的其他服务。图的节点和元素可以被实现为数据结构，该数据结构被存储在计算机可读介质或者符合存储在数据储存库中的数据模型的其他有组织数据。 可以在诸如CD-ROM的存储介质上提供所述软件，所述存储介质可由通用或专用可编程计算机读取，或者可以经由网络的通信介质将所述软件传递(编码在传播信号中)到执行该软件的计算机。可以在专用计算机上执行所有功能，或者可以使用诸如协处理器之类的专用硬件来执行所有功能。可以以分布式方式实现所述软件，其中，由不同的计算机执行所述软件指定的不同的计算部分。每个这样的计算机程序优选地被存储在或下载到可由通用或专用可编程计算机读取的存储介质或设备(例如固态存储器或介质、或者磁或光介质)上，用于在计算机系统读取所述存储介质或设备时配置和操作所述计算机以执行这里描述的例程。也可以考虑将本发明的系统实现为配置了计算机程序的计算机可读存储介质，其中如此配置的存储介质使得计算机系统以特定和预先定义的方式操作以执行这里描述的功能。已经描述了本发明的很多实施例。然而，将理解，可以进行各种修改而不背离本发明的精神和范围。例如，上述步骤中的一些可以是与顺序无关的，因此可以按照与上述顺序不同的顺序来执行。应当理解，前面的描述意图是说明而不是限制由所附权利要求的范围限定的本发明的范围。例如，可以按照不同的顺序执行很多上述功能步骤，而基本上不影响整个处理。其他实施例处于所附权利要求的范围内。
权利要求
1.一种用于管理对ー个或多个数据源执行的查询的方法，包括 将至少第一查询存储在存储介质中； 选择用于处理的第一查询； 指示查询引擎在第一查询间隔内在所述ー个或多个数据源中的数据的第一部分上处理第一查询； 基于在数据的第一部分上处理第一查询，从查询引擎接收结果数据； 在第一查询间隔之后，将第一查询的状态保存在存储介质中； 在第一查询间隔之后的第二查询间隔期间，指示查询引擎处理第二查询；以及在第二查询间隔之后的第三查询间隔期间，指示查询引擎在所述ー个或多个数据源中的数据的第二部分上处理第一查询。
2.如权利要求I所述的方法，还包括 将与第一查询相关联的优先级存储在存储介质中； 在选择用于处理的第一查询之前改变与第一查询相关联的优先级； 其中，选择用于处理的第一查询包括部分地基于所述优先级来选择该查询。
3.如权利要求I所述的方法，其中，第一查询间隔由预定时间量定义。
4.如权利要求3所述的方法，其中，第一查询的优先级影响将所述ー个或多个数据源中的多少数据包括在第一查询间隔内在其上执行第一查询的数据的第一部分中。
5.如权利要求I所述的方法，其中，存储第一查询包括存储在通知提供第一查询的请求者之前可以获得的结果数据的数量的通知阈值。
6.如权利要求5所述的方法，还包括当结果数据的数量超过通知阈值时通知请求者，其中，保存第一查询的状态包括存储从查询引擎接收的结果数据的数量。
7.如权利要求6所述的方法，还包括当从请求者请求时返回结果数据；以及将返回给请求者的结果数据的数量存储在存储介质中。
8.如权利要求7所述的方法，其中，选择查询是基于从查询引擎接收的结果数据的数量和返回给请求者的结果数据的数量进行的。
9.如权利要求I所述的方法，其中，保存第一查询的状态包括 指示查询引擎中止第一查询；以及 在中止第一查询之后保存第一查询的状态。
10.如权利要求9所述的方法，其中，指示查询引擎在数据的第二部分上处理第一查询包括 加载所保存的第一查询的状态；以及 指示查询引擎重新开始第一查询。
11.如权利要求9所述的方法，其中，保存第一查询的状态包括将偏移量保存在ニ级索引中。
12.如权利要求11所述的方法，其中，ニ级索引是块压缩索引文件。
13.如权利要求I所述的方法，还包括 将第一查询划分为多个子查询，以及 指示查询引擎并发地处理所述子查询中的至少ー些。
14.如权利要求I所述的方法，其中，在第一查询间隔开始之后接收第二查询并且将其存储在存储介质中。
15.如权利要求I所述的方法，其中，在第一查询间隔开始之前接收第二查询并且将其存储在存储介质中。
16.一种计算机可读介质，存储用于管理对ー个或多个数据源执行的查询的计算机程序，该计算机程序包括指令，该指令用于使计算机 将至少第一查询存储在存储介质中； 选择用于处理的第一查询； 指示查询引擎在第一查询间隔内在所述ー个或多个数据源中的数据的第一部分上处理第一查询； 基于在数据的第一部分上处理第一查询，从查询引擎接收结果数据； 在第一查询间隔之后，将第一查询的状态保存在存储介质中； 在第一查询间隔之后的第二查询间隔期间，指示查询引擎处理第二查询；以及在第二查询间隔之后的第三查询间隔期间，指示查询引擎在所述ー个或多个数据源中的数据的第二部分上处理第一查询。
17.一种用于管理对ー个或多个数据源执行的查询的系统，该系统包括 存储介质，其存储至少第一查询； 查询引擎，其被配置为在所述ー个或多个数据源中的数据上处理查询；以及 服务器，其被配置为 选择用于处理的第一查询； 指示查询引擎在第一查询间隔内在所述ー个或多个数据源中的数据的第一部分上处理第一查询； 基于在数据的第一部分上处理第一查询，从查询引擎接收结果数据； 在第一查询间隔之后，将第一查询的状态保存在存储介质中； 在第一查询间隔之后的第二查询间隔期间，指示查询引擎处理第二查询；以及在第二查询间隔之后的第三查询间隔期间，指示查询引擎在所述ー个或多个数据源中的数据的第二部分上处理第一查询。
18.一种用于管理对在数据存储系统中存储的数据执行的查询的系统，该系统包括 存储介质，其存储至少第一查询； 查询引擎，其被配置为在所述ー个或多个数据源中的数据上处理查询；以及 用于管理存储介质中的查询的部件，所述管理包括 指示查询引擎在第一查询间隔内在所述ー个或多个数据源中的数据的第一部分上处理第一查询； 基于在数据的第一部分上处理第一查询，从查询引擎接收结果数据； 在第一查询间隔之后，将第一查询的状态保存在存储介质中； 在第一查询间隔之后的第二查询间隔期间，指示查询引擎处理第二查询；以及在第二查询间隔之后的第三查询间隔期间，指示查询引擎在所述ー个或多个数据源中的数据的第二部分上处理第一查询。
全文摘要
管理对一个或多个数据源(310A，310B，310C)执行的查询包括将至少第一查询存储在存储介质(308)中；选择用于处理的第一查询；指示查询引擎(312)在第一查询间隔内在所述一个或多个数据源中的数据的第一部分上处理第一查询；基于在数据的第一部分上处理第一查询，从查询引擎接收结果数据(314)；在第一查询间隔之后，将第一查询的状态保存在存储介质中；在第一查询间隔之后的第二查询间隔期间，指示查询引擎处理第二查询；以及在第二查询间隔之后的第三查询间隔期间，指示查询引擎在所述一个或多个数据源中的数据的第二部分上处理第一查询。
文档编号G06F17/30GK102687144SQ201080058553
公开日2012年9月19日 申请日期2010年12月23日 优先权日2009年12月23日
发明者C.W.斯坦菲尔, J.麦克莱恩 申请人:起元技术有限责任公司