CN102053975A

CN102053975A - 数据库系统和跨数据库查询优化方法

Info

Publication number: CN102053975A
Application number: CN200910209075XA
Authority: CN
Inventors: 高波; 郭常杰; 蒋忠波; 唐凯; 孙伟; 王凤娟
Original assignee: International Business Machines Corp
Current assignee: International Business Machines Corp
Priority date: 2009-10-30
Filing date: 2009-10-30
Publication date: 2011-05-11
Also published as: US8768915B2; US20110106789A1

Abstract

本发明涉及数据库系统和跨数据库查询优化方法。该数据库系统包括：多个数据库，所述多个数据库中的至少两个数据库存储有一个或多个由具有相同结构的表组成的数据集合，在所述至少两个数据库中的每个数据库上创建有所述数据集合的联合视图；和请求路由层，在运行时根据预定路由规则将跨所述数据集合的查询请求路由到所述至少两个数据库中的一个数据库，以便利用该数据库的联合视图进行查询。

Description

数据库系统和跨数据库查询优化方法

技术领域

本发明一般涉及数据库领域，具体地说，涉及一种数据库系统和跨数据库查询优化方法。

背景技术

目前，在数据库领域，如果要进行的查询涉及多个数据库中存储的同结构数据表，通常可以采用诸如以下两种方法。

作为一种方法，可以对多个数据库中的每个数据库执行查询，然后在应用逻辑中将得自各个数据库的查询结果聚集在一起，之后提供给查询请求者。但是，该方法所涉及的编程逻辑非常复杂，并且查询性能低。

作为另一种方法，可以定期地或实时地在作为查询目标的一个数据库中对于多个数据库中的其它数据库中的部分数据进行同步，并且仅对该作为查询目标的数据库进行查询。但是，该方法尤其在需要同步大量数据时会产生数据冗余问题，需要目标数据库具有相当大的容量。另外，这种将多个数据库中的数据同步到一个数据库中的方法难以保持数据的一致性。另外，进行同步需要有复杂的同步机制或逻辑并且可能需要实时支持，这都增加了系统的复杂度。

上述问题在SaaS环境下尤为突出。SaaS是Software-as-a-Service(软件即服务)的简称，它是一种通过Internet提供软件的模式。利用该模式，用户不用再购买软件，而是向服务提供商租用基于Web的软件来管理企业经营活动，且无需对软件进行维护。租用软件的用户称为租户(tenant)。服务提供商会全权管理和维护软件，服务提供商在向租户提供互联网应用的同时，也提供软件的离线操作和本地数据存储，让租户随时随地都可以使用其租用的软件和服务。对于许多小型企业来说，SaaS是采用先进技术的最好途径，它消除了企业购买、构建和维护基础设施和应用程序的需要。

大型SaaS应用会有大量租户和数据，随着业务的增长，一般都会利用平面扩容(scale out)机制。所谓平面扩容就是将应用的数据拆分，将原本要集中存储的数据根据一定的规则分布到不同的物理数据库上。

图1示出了一个利用平面扩容机制的示例性SaaS数据库系统。在该SaaS数据库系统中，使用了三个下层数据库，并且根据租户将数据划分到这三个下层数据库中。在下文中，属于一个租户的数据的集合被称为该租户的“租户数据”。在图1所示的SaaS数据库系统中，租户T1、T2、T5的租户数据位于数据库A中，租户T3、T4的租户数据位于数据库B中，租户T6的租户数据位于数据库B中。

目前，在许多典型的SaaS应用中，存在跨租户访问的需求。图2示出了需要进行跨租户访问的几个示例情况。例如，当零售商和批发商同为一个SaaS应用的租户的情况下，在批发商授权的情况下，零售商可能希望看到它的批发商的全部或部分数据。例如，母公司可能希望看到其子公司的数据，子公司可能希望看到其分支机构的数据。此外，SaaS的运营商(例如操作人员)基于某些考虑可能需要访问所有租户的数据以产生报告或进行操作等。

为了满足上述需求，现有技术一般进行如下的处理。例如，对于图1中的情况，假定在数据库A和B中分别存在如图3所示的订单表SalesOrder。在图3所示的作为简单示例的表SalesOrder中，各个列分别表示如下含义。ID为用于区别行的标识，Tenant表示该行数据所属于的租户，Name表示订单涉及的商品名，Num表示订单涉及的商品数量，Price表示订单涉及的商品价格。

例如，如果租户T1希望查询自身的所有订单数据，同时希望查询位于另一数据库B中的租户T3的订单涉及的商品数量大于500的订单数据，则通过租户T1在基于Web的软件上的操作而由该基于Web的软件生成如下的SQL查询语句：

SELECT＊FROM SalesOrder WHERE Tenant＝’T1’OR(Tenant＝’T3’AND Num＞500)；

该SQL语句被基于Web的软件发送到图1中的请求路由层，该请求路由层将上述语句发送到各个数据库A、B和C。在数据库A、B和C中分别执行该SQL语句，例如在数据库A中执行该SQL语句获得dbA.SalesOrder中的ID为001和002的两行数据，在数据库B中执行该SQL语句获得dbB.SalesOrder中的ID为002的一行数据，而在数据库C中执行该SQL语句获得空集。各数据库执行上述查询之后，将结果集分别发送回请求路由层。然后，请求路由层将从数据库A和B返回的查询的结果集聚集在一起，在本示例中通过求合集得到最终查询结果。最后，请求路由层将查询结果返回给基于Web的软件，以向租户T1显示最终结果。但是，如上所述，该方法所涉及的编程逻辑非常复杂，并且需要每个数据库均执行查询，因此查询性能低。

此外，采用现有技术，无法在SQL查询语句中使用AVG(求平均值)等函数。这是因为，使用AVG等函数，在每个数据库中仅能针对存储于该数据库中的数据求平均值，而无法作用于存储于其它数据库中的数据。例如，在图3的情况下，如果希望得到租户T1和T3两者的订单的价格平均值，产生如下SQL语句：SELECT AVG(Price)FROM SalesOrder WHERE Tenant＝’T1’OR Tenant＝’T3’。在数据库A和B中分别执行该语句仅能返回租户T1的订单的价格平均值以及租户T3的订单的价格平均值，而无法得到租户T1和T3两者的订单的价格平均值。因此，在这种情况下无法使用诸如AVG的函数。这里，AVG函数仅是函数的一个示例，所述函数还可以包括但不限于COUNT、MAX、MIN、SUM以及自定义函数等。

近年来，开发出了一种称为联合数据库的技术。许多组织的包括在部门或分部作为独立系统存在的局域网(LAN)、小型计算机和大型计算机具有各自的数据库，当建造一个企业计算平台来互连一个组织时，组织内分散的异构数据库系统就应结合成联合数据库以供多个用户访问数据。利用中间件产品或诸如分布式计算环境(DCE)的环境提供一个软件层，通过它用户可以与不同的系统互操作。采用联合数据库技术，可以使用一条SQL语句查询多个数据源中的数据。这些数据源可以多种多样，既可以是多种关系数据库，也可以是非关系数据库，比如微软Excel、xml等。

联合视图(Federated View)是联合数据库中一个视图，其基本表位于远程数据源上。基本表在联合视图中是按昵称而不是按数据源表名引用的。当从联合视图查询时，数据是从远程数据源检索到的。

联合数据库和联合视图技术可以应用于SaaS环境。例如，可以在应用了联合数据库技术的SaaS数据库系统中的一个下层数据库A中建立一个联合视图(FV，Federated View)，该联合视图是联合了多个下层数据库所包含的一个结构相同的表的视图。通过针对建立了联合视图的该数据库，利用该联合视图进行查询，可以向查询者提供透明的跨数据库查询服务。

另外，在现有的SaaS数据库系统中还存在以下问题，由于租户是逐渐增加的，当一个数据库无法容纳更多租户的租户数据时，服务提供商通过平面扩容(增加新数据库)来容纳新租户。通常，容纳较多租户的数据库的负载较重，而容纳较少租户的数据库的负载较轻。因而，还需要一种对数据库系统中的各数据库的负载进行平衡的机制。

发明内容

为了解决上述问题，本发明的主要目的是提供一种能够在包含多个数据库的数据库系统中通过在各数据库上建立联合视图来进行跨数据库查询优化的数据库系统和跨数据库查询优化方法。

根据本发明的一方面，提供了一种数据库系统，该数据库系统包括：多个数据库，所述多个数据库中的至少两个数据库存储有一个或多个由具有相同结构的表组成的数据集合，在所述至少两个数据库中的每个数据库上创建有所述数据集合的联合视图；和请求路由层，，用于响应跨所述数据集合的查询请求，根据预定路由规则将跨所述数据集合的查询请求路由到所述至少两个数据库中的一个数据库，以便利用该数据库的联合视图进行查询。

根据本发明的另一方面，提供了一种数据库系统中的跨数据库查询优化方法，所述数据库系统包括多个数据库，所述多个数据库中的至少两个数据库存储有一个或多个由具有相同结构的表组成的数据集合，该方法包括以下步骤：联合视图建立步骤，在所述至少两个数据库中的每个数据库上创建所述数据集合的联合视图；以及路由步骤，响应跨所述数据集合的查询请求，根据预定路由规则将跨所述数据集合的查询请求路由到所述至少两个数据库中的一个数据库，以便利用该数据库的联合视图进行查询。

采用本发明的数据库系统和跨数据库查询优化方法，能够降低编程逻辑的复杂性，减少进行跨数据库查询时的数据传输量和平衡数据库间的查询请求强度，从而能够提高查询速度和效率。此外，采用本发明的数据库系统和跨数据库查询优化方法，还能够在跨数据库查询SQL语句中使用函数。

附图说明

以下通过结合附图阅读参考下述对说明性实施例的详细描述，将更好地理解本发明本身、实施方式、其它目的及其优点。在附图中：

图1示出了一个利用平面扩容机制的示例性SaaS数据库系统；

图2示出了需要进行跨租户访问的几个示例情况；

图3示出了在数据库上存储的表的示例；

图4是示出了根据本发明的第一实施例的SaaS数据库系统的示意图；

图5示出了根据本发明实施例的在SaaS数据库系统中的每个数据库上建立联合视图的处理的流程图；

图6是示出了根据本发明的第二实施例的SaaS数据库系统的示意图；

图7是示出了请求跟踪器610获得的跟踪结果的一个示例的加权有向图；

图8是示出了根据本发明的第一实施例的跨数据库查询优化方法的流程图；

图9是示出了根据本发明的第二实施例的跨数据库查询优化方法的流程图；

图10是示出了由根据本发明的租户数据移动器执行的移动步骤的一个实施例的流程图；以及

图11是示出了图10中的判断处理的一个实施例的流程图。

具体实施方式

以下将参照附图对本发明的实施方式进行详细说明。

以下以SaaS数据库系统作为示例进行说明，但是本发明不限于此。本领域技术人员应该明白，当在具有多个数据库(这些数据库中的部分或全部数据库含有同结构的表)的任何其它数据库系统中进行跨数据库查询的情况下，本发明同样适用。另外，术语“数据集合”是指表的集合或数据库中的其它数据结构的集合。术语“远程数据库”是指位于不同硬件服务器上的数据库。术语“远程表”是指远程数据库中的表。

图4是示出了根据本发明的第一实施例的SaaS数据库系统的示意图。在图4中，在数据库A、B和C上均建立了联合视图，联合视图的建立是在离线状态下进行的。尽管示出了三个下层数据库，但这仅仅是一个示例。因为SaaS数据库系统是可扩容的，所以在其它SaaS数据库系统中，下层数据库的数目不限于三个。数据库A、B和C中的两个或全部可以位于同一服务器中；数据库A、B和C也可以是例如通过LAN或互联网相连的分布式数据库。在本发明中，为了便于说明，假定数据库A、B和C是分布式数据库。

这里，为了便于说明，假定租户T1至T6是租用同一SaaS应用的租户并且它们的租户数据包含相同结构的表。当然，T1至T6也可能是租用同一SaaS服务提供商的不同SaaS应用的租户。例如，租户T1至T5租用应用X，租户T6租用应用Y。在这种情况下，租户T1至T5和租户T6的租户数据包含的表的结构很可能不同，因此，只在存储含有相同结构的表的租户数据的数据库上，为含有相同结构的表建立联合视图。另外，在实践中，即使租户T1至T6是租用同一SaaS应用的租户，它们的租户数据包含的表的数量和结构也可能不完全相同。但是考虑到T1和T6是租用同一SaaS应用的租户，所以它们的租户数据所包含的大部分表的结构是相同的。因此，针对其中的结构相同的大部分表建立联合视图，同样可以实现本发明的发明目的。

下面，以附图4中的情况为例，参照图5描述如何在每个数据库上均建立联合视图。

图5示出了根据本发明的实施例的在SaaS数据库系统中的每个数据库上建立联合视图的处理的流程图。首先，在步骤510中判断是否针对SaaS数据库系统中的所有数据库均建立联合视图。当步骤510中的判断结果为是时，处理结束。当步骤510中的判断结果为否时，处理前进至步骤520。在步骤520中，选择一个尚未建立联合视图的数据库作为当前数据库，在当前数据库中执行操作。然后，在步骤530中，将所有远程数据库联合到当前数据库。然后，在步骤540中在当前数据库中为远程数据库中的远程表创建别名。

下面以IBM公司的DB2数据库为例，针对3个数据库dbA、dbB和dbC的情况，通过下面的代码段说明步骤530和540的操作。

CONNECT TO dbA；

CREATE WRAPPER DRDA LIBRARY′libdb2drda.so′；

CREATE SERVER dbB TYPE DB2/UDB VERSION′9.5′WRAPPER“DRDA”OPTIONS(ADD DBNAME′dbB′)；

CREATE NICKNAME sfa.SalesOrder d2FOR dbB.SalesOrder；

/＊为数据库dbB中的表SalesOrder创建别名sfa.SalesOrder_d2＊/

CREATE SERVER dbC TYPE DB2/UDB VERSION′9.5′WRAPPER“DRDA”OPTIONS(ADD DBNAME′dbC′)；

CREATE NICKNAME sfa.SalesOrder_d3 FOR dbC.SalesOrder；

/＊为数据库dbC中的表SalesOrder创建别名sfa.SalesOrder_d3＊/

通过执行上面的代码段，在数据库dbA中联合了远程数据库dbB和dbC，并在dbA中为远程数据库dbB和dbC中的远程表SalesOrder分别创建了别名。

然后，在步骤550中，以与远程数据库中的表相同的名字创建联合视图，该视图将联合所有数据库中的同名表。通过下述代码段完成了dbA上的联合视图的创建。

在完成步骤500中的操作后，处理返回到步骤510，开始针对其余数据库创建联合视图。在dbB和dbC上创建联合视图的方式与上述方式相似，在此不再重复说明。当在全部三个数据库上均创建了联合视图后，图5中的处理结束。需要注意的是，为了便于说明，上述示例仅联合了各数据库中的一个表SalesOrder。但是，在实际中，需要将各数据库中的同结构表全部联合。

返回参照图4，在图4的示意图中包含请求路由层，该请求路由层在运行时根据预定路由规则将跨租户查询请求路由到数据库A、B和C中的一个数据库，以便利用该数据库的联合视图进行查询。所述请求路由层例如由中间件产品或者分布式计算环境(DCE)提供，可以被实现为单独的机器，或者可以通过JDBC Wrapper/Driver而实现为应用逻辑的一部分，用于将来自租户的SQL请求路由到对应的下层数据库。

对于正常的仅涉及单个租户数据的查询请求，本发明的请求路由层(图4)起到与图1中的现有技术的请求路由层相同的作用，即，根据租户的SQL查询把来自一租户的查询请求路由到该SQL查询涉及的租户数据所处的下层数据库。然而，对于涉及多个租户数据的查询请求，图1中的请求路由层必须将该查询请求发送到每个下层数据库。而按照本发明通过图5所示的处理，在图4中的数据库A、B和C中均创建了联合视图，从而本发明的请求路由层具有了将跨租户查询请求路由到任一单个数据库的能力。

按照本发明的实施例，由于在每个数据库上均建立了联合视图，对于包含如AVG的函数的SQL查询语句，诸如上述的SELECTAVG(Price)FROM SalesOrder WHERE Tenant＝’T1’ORTenant＝’T3’，可将该查询语句仅路由到任何一个下层数据库来执行。请求路由层可以根据以下预定路由规则对跨租户查询请求进行路由：

1)将来自租户的跨租户查询请求路由到该租户的租户数据所处的数据库；

2)将来自租户的跨租户查询请求路由到大多数涉及的租户数据所处的数据库。

在按照本发明实施例的SaaS数据库系统中能够利用上述路由规则；而在图1的情况中，在数据库A、B和C上没有建立联合视图，从而不能将查询请求路由到单个数据库来处理跨租户查询请求。

路由规则1

因为满足一租户的跨租户查询请求所需的数据通常包含该租户本身的租户数据中的数据，通过利用路由规则1进行路由，可以减少数据库间的数据传输量。当一跨租户查询请求所涉及的租户数据处于一个数据库中时，甚至避免了数据库间的数据传输。例如，将请求T3(T3，T4)路由到数据库B就避免了数据传输。这里，请求T3(T3，T4)示意性地表示来自租户T3的涉及租户T3、T4的查询请求。

路由规则2

对于请求T3(T1，T2，T3)，如果按照路由规则1，则该请求会被路由到数据库B。但是T1和T2位于数据库A中，利用数据库B执行该查询仍然会产生数据库A和B之间的数据传输。在这种情况下，采用路由规则2会进一步减少数据库间的数据传输量。具体地，利用数据库命令或其它机制从下层数据库获得T1、T2和T3的大小a、b和c，其例如可以是T1、T2和T3中的当前查询涉及的表中的记录的数量。然后，比较数据库A中的涉及数据量(a+b)与数据库B中的涉及数据量c的大小。如果前者较大，则把请求T3(T1，T2，T3)路由到数据库A；如果后者较大，则把请求T3(T1，T2，T3)路由到数据库B。通过采用路由规则2，可以将跨租户查询请求路由到拥有满足该查询所需的大多数数据的数据库，从而可以减少数据库间的数据传输量。

以上仅仅例示了对跨租户查询请求进行路由的几种可能的路由规则，并不是要穷举所有的路由规则。本领域技术人员可以理解，可以采用许多已知的方法进行SQL路由。上述路由规则1和2的目的是尽量减少数据库间的数据传输。但是，出于负载平衡的考虑，也可以采用路由规则3：基于下层数据库的状态，将跨租户查询请求路由到负载最低的数据库。

路由规则3

对于路由规则3的应用，例如，考虑下面的情形。当发起请求的租户(例如租户T1)的租户数据所处的数据库(数据库A)处于高负载状态或者响应速度慢(例如低于阈值)时，可以利用路由规则3。将来自租户T1的跨租户请求(例如T1(T1，T2))路由到数据库B和C中负载较低的数据库。这里，下层数据库的状态是指SaaS系统中的各下层数据库的负载以及响应速度等。所述负载是指各数据库所处服务器的CPU使用率、内存使用率等，这些信息可以通过例如调用系统函数等的公知方法而获得。所述响应速度是指返回查询结果所需的时间，该时间例如可以通过在请求路由层中计时而获得。

图6是示出了根据本发明的第二实施例的SaaS数据库系统的示意图。除了在图6中加入了请求跟踪器610和租户数据移动器620外，图6中的数据库系统的各组成部件与图4中的数据库系统的各组成部件完全相同，因此这里省略对它们的重复说明。

图6中的请求跟踪器610位于请求路由层中，用于在运行时跟踪跨租户数据的查询请求行为，具体地说，用于跟踪各租户的涉及到其余租户的查询的频率。例如现有技术的Log4JDBC就可用于实现请求跟踪器610的功能。Log4JDBC是一个JDBC驱动器，能够记录SQL日志和SQL执行时间等信息。例如，通过在运行时分析SQL语句或者分析返回的结果集(ResultSet)，嵌入在请求路由层中的请求跟踪器610能够对跨租户查询行为进行跟踪。请求跟踪器610的跟踪结果被累积在请求路由层中，能够被请求路由层用来进行路由选择。

请求跟踪器610的跟踪结果可以被表示为加权有向图的形式。图7以加权有向图的形式示出了请求跟踪器610获得的跟踪结果的一个示例。在图7中，节点表示租户，节点之间的有向边表示跨租户查询请求。例如，T1到T2的有向边表示存在来自租户T1的涉及租户T2的租户数据的查询请求。有向边上的权重值w_ij代表跨租户查询的频率，其中权重的下标中的i表示发出查询请求的租户的序号，j表示被查询的租户的序号。例如w₄₃表示租户T4的涉及租户T3的租户数据的查询请求的次数。当w_ij为零时，代表不存在来自租户Ti的涉及租户Tj的租户数据的查询请求。上述加权有向图可被存储为一个简单的二维数组结构w[i][j]。当然，也可以采用本领域技术人员公知的其它数据结构来存储该加权有向图。

请求跟踪器610在运行时跟踪跨租户查询请求并更新所述加权有向图。由于随着跟踪的进行，权重值被不断累加，所以需要定期将数组w[i][j]清零。例如，可由系统管理员根据需要进行设定从而每小时或每天或在任何需要时将数组w[i][j]清零一次，从而能够总是保持最近时段内的有效跟踪结果。

图6中的租户数据移动器620用于基于请求跟踪器610的跟踪结果在多个数据库之间移动租户数据。在多个数据库之间移动租户数据移动租户数据的主要目的是要将具有跨租户查询行为的租户的租户数据聚集到一起，从而减小发生数据库间的数据传输的可能性。在下文中，将给出一种租户数据移动器620使用的移动租户数据的示例性方法。

另外，应当注意的是，尽管在图6中例示的租户数据移动器620位于数据库系统中但是在请求路由层之外，但是也可以将租户数据移动器620设置于请求路由层中。

图8是示出了根据本发明的第一实施例的跨数据库查询优化方法的流程图。该跨数据库查询优化方法适用于包括多个数据库的数据库系统，所述多个数据库中的至少两个数据库存储有一个或多个由具有相同结构的表组成的数据集合。首先在离线状态下执行联合视图建立步骤810，即，在所述至少两个数据库中的每个数据库上创建所述数据集合的联合视图。然后，在运行时执行路由查询步骤820，利用请求路由层在运行时根据预定路由规则将跨所述数据集合的查询请求路由到所述至少两个数据库中的一个数据库，以便利用该数据库的联合视图进行查询。联合视图建立步骤810的具体实现方式例如可以采用图5中示出的处理流程。路由查询步骤820例如可以采用上面描述的路由规则1至3将跨所述数据集合的查询请求路由到所述至少两个数据库中的一个数据库，以便利用该数据库的联合视图进行查询。由于在上文中已经对示例性的路由规则1至3进行了详细描述，在此不再重复说明。

图9是示出了根据本发明的第二实施例的跨数据库查询优化方法的流程图。图9中的处理包括联合视图建立步骤910、路由查询步骤920、跟踪步骤930和移动步骤940。其中步骤910和920与图8中的步骤810和820的操作相同，这里不再重复描述。在步骤920之后，图9中的处理进行到步骤930，利用请求跟踪器610，在运行时跟踪跨租户数据的查询请求行为(例如跟踪各租户的涉及到其余租户的查询及查询频率)。另外，请求跟踪器610将跟踪结果例如以权重数组w[i][j]的形式累积在请求路由层中。在步骤930之后，图9中的处理进行到步骤940。在步骤940中，利用租户数据移动器620，在离线时基于对所述跨租户数据的查询请求行为的跟踪结果在所述多个数据库之间移动租户数据。

图10是示出了由根据本发明的租户数据移动器620执行的移动步骤940的一个实施例的流程图。图10中的处理在图9中的跟踪步骤930结束时开始。在步骤1000中，确定从上一次判断是否需要移动租户数据时起是否经过了一个时间间隔T。需要注意的是，当首次执行步骤1000时，要确定的是从系统启动开始是否经过了时间间隔T。时间间隔T可由系统操作员进行设置，其表示间隔多长时间进行计算来判断是否需要移动租户数据，同时也表示请求跟踪器累积跟踪结果的时长。时间间隔T越小，进行计算的频率越高。例如可将时间间隔T设置为1周或1天或1小时等。如果在步骤1000中确定尚未经过时间间隔T，则处理返回到步骤920。

另一方面，如果在步骤1000中确定经过了时间间隔T，则处理进行到步骤1010。在步骤1010中判断是否需要移动租户数据。如果判断不需要移动租户数据，则处理前进到步骤1020，将由请求跟踪器610在时间间隔T中获得的跟踪结果清零。然后，处理返回到步骤920。如果判断需要移动租户数据，则处理前进到步骤1030，租户数据移动器620根据步骤1010中的判断结果移动租户数据，然后处理进行到步骤1020，将由请求跟踪器610所获得的跟踪结果清零，使请求跟踪器可以重新开始累积跟踪结果。然后，处理返回到步骤920。

图11是示出了图10中的步骤1010中的判断处理的一个实施例的流程图。图11描述了判断是否移动租户数据以及将租户数据移动到哪个数据库的示例性算法。当步骤1000中的判断结果为是时，图11中的处理开始。首先，在步骤1100中，计算当前租户Ti与其所处数据库中的其余租户的权值和(例如为X)。当Ti为T1时，以图7中的情况作为示例，T1在数据库A中的权值和X＝W₁₂+W₂₁。然后，在步骤1110中，计算当前租户Ti与其各个其它数据库中的各租户的权值和(例如为Y、Z、...)。当Ti为T1时，以图7中的情况作为示例，T1在数据库B中的权值和Y＝W₁₃，T1在数据库C中的权值和Z＝0。然后，在步骤1120中，找到X、Y、Z、...之中的最大值MAX。在步骤1130中判断X是否为最大值，即MAX是否等于X。如果X为最大值，则判断不移动Ti，处理前进至步骤1150。如果X不是最大值，则在步骤1140中将Ti标记为要移动到计算出了MAX的数据库。例如，以图7中的T1作为示例，如果MAX＝Y，则将T1标记为要移动到数据库B。同时，将用于记录要移动的租户数据的数目的变量num增加1(该变量在进行步骤1010的处理前被初始化为0)。在步骤1140之后或者在步骤1130的判断为否时，处理前进到步骤1150。在步骤1150中，判断是否针对每个租户都执行了上述处理。如果存在未计算的租户，则处理返回到步骤1100并针对下一租户执行步骤1100至步骤1140的处理。当针对所有租户均执行了上述处理时，流程前进到步骤1160，将移动比率(即num/租户数目)与一阈值(例如为10％)进行比较，如果移动比率大于阈值，则处理前进到步骤1030，根据在步骤1140中针对各租户所作的标记，将判断要进行移动的租户数据移动到相应的数据库。而如果移动比率小于阈值，则处理前进到步骤1020，从而不进行移动。这样做的目的是为了减少移动租户数据的频率，避免仅因非常少的租户数据需要移动就进行离线操作的次数。系统操作员可以设置上述阈值，例如还可以将其设置为5％、15％、20％或其它值。

以图7中的情况为例，此时将阈值设置为20％。当针对T1的计算得出W₁₃＞W₁₂+w₂₁(即T1在数据库B中的权值和最大)时并且当针对T4计算得出W₄₅＞W₄₃＞W₄₆(即T4在数据库A中的权值和最大)时，需要将T1移动到数据库B并将T4移动到数据库A。此时移动比率＝2/6＝33.3％＞20％，所以在步骤1030中执行移动处理，将T1移动到数据库B并将T4移动到数据库A。

需要注意的是，给出以上的简化示例仅仅是为了使本发明的优化方法的说明易于理解。本领域技术人员应该理解，采用本发明的这种思想，完全可以针对更复杂的情况进行判断。

图11中的处理仅是实现图10中的步骤1010中的判断的一种实施方式。除了权值(查询频率)之和外，本领域技术人员还能够想到利用数据量之和来进行上述计算。例如，利用查询频率与租户数据大小的乘积之和来进行上述计算从而进行判断。

此外，在考虑负载平衡的情况下，在步骤1010中，除了基于对所述跨租户数据的查询请求行为的跟踪结果之外，还基于各数据库的状态进行判断。首先，例如，基于下层数据库的状态(例如响应速度和负载)进行判断，当某个数据库的响应速度明显下降或者某个数据库的输入输出压力高于平均值达一阈值(例如30％)时，决定移动该数据库中的租户数据。其次，针对该数据库中的每个租户，计算它与该数据库中的其它租户的权值和，并将权值和最小的租户确定为要移动的租户。然后，计算要移动的租户与其它数据库中的租户的权值和，并将要移动的租户的租户数据移动到结果值最大的数据库。

本领域技术人员会认识到，可以以方法、系统或计算机程序产品的形式提供本发明的实施例。因此，本发明可采取全硬件实施例、全软件实施例，或者组合软件和硬件的实施例的形式。硬件和软件的典型的结合可以是带有计算机程序的通用计算机系统，当程序被加载并被执行时，控制计算机系统，从而可以执行上述的方法。

本发明可以嵌入在计算机程序产品中，它包括使此处描述的方法得以实施的所有特征。所述计算机程序产品被包含在一个或多个计算机可读存储介质(包括，但不限于，磁盘存储器、CD-ROM、光学存储器等)中，所述计算机可读存储介质具有包含于其中的计算机可读程序代码。

已参考根据本发明的方法、系统及计算机程序产品的流程图和/或方框图说明了本发明。流程图和/或方框图中的每个方框，以及流程图和/或方框图中的方框的组合显然可由计算机程序指令实现。这些计算机程序指令可被提供给通用计算机、专用计算机、嵌入式处理器或者其他可编程的数据处理设备的处理器，以产生一台机器，从而指令(所述指令通过计算机或者其他可编程数据处理设备的处理器)产生用于实现在流程图和/或方框图的一个或多个方框中规定的功能的装置。

这些计算机程序指令也可保存在一个或多个计算机的读存储器中，每个这种存储器能够指挥计算机或者其他可编程数据处理设备按照特定的方式发挥作用，从而保存在计算机可读存储器中的指令产生一种制造产品，所述制造产品包括实现在流程图和/或方框图的一个或多个方框中规定的功能的指令装置。

计算机程序指令也可被加载到一个或多个计算机或者其他可编程数据处理设备上，使得在所述计算机或者其他可编程数据处理设备上执行一系列的操作步骤，从而在每个这样的设备上产生计算机实现的过程，以致在该设备上执行的指令提供用于实现在流程图和/或方框图的一个或多个方框中规定的步骤。

以上结合本发明的实施方式对本发明的原理进行了说明，但这些说明只是示例性的，不应理解为对本发明的任何限制。本领域技术人员可以对本发明进行各种改变和变形，而不会背离由随附权利要求所限定的本发明的精神和范围。

Claims

1.一种数据库系统，包括：

多个数据库，所述多个数据库中的至少两个数据库存储有一个或多个由具有相同结构的表组成的数据集合，在所述至少两个数据库中的每个数据库上创建有所述数据集合的联合视图；和

请求路由层，用于响应跨所述数据集合的查询请求，根据预定路由规则将跨所述数据集合的查询请求路由到所述至少两个数据库中的一个数据库，以便利用该数据库的联合视图进行查询。

2.根据权利要求1所述的数据库系统，其中，所述数据库系统是软件即服务SaaS数据库系统，并且每个所述数据集合是SaaS数据库系统中的称为租户数据的、属于一个租户的数据的集合。

3.根据权利要求2所述的数据库系统，其中，所述预定路由规则包括：

路由规则1，将来自租户的跨租户数据的查询请求路由到该租户的租户数据所处的数据库。

4.根据权利要求2所述的数据库系统，其中，所述预定路由规则包括：

路由规则2，将来自租户的跨租户数据的查询请求路由到大多数涉及的租户数据所处的数据库。

5.根据权利要求2所述的数据库系统，其中，所述预定路由规则包括：

路由规则3，基于各数据库的状态，将跨租户数据的查询请求路由到负载最低的数据库。

6.根据权利要求2所述的数据库系统，还包括：

请求跟踪器，用于在运行时跟踪跨租户数据的查询请求行为；和

租户数据移动器，用于在离线时基于请求跟踪器的跟踪结果在所述多个数据库之间移动租户数据。

7.根据权利要求6所述的数据库系统，其中，跟踪跨租户数据的查询请求行为包括跟踪各租户的涉及到其余租户的查询的频率。

8.根据权利要求6所述的数据库系统，其中，租户数据移动器还基于各数据库的状态在所述多个数据库之间移动租户数据。

9.根据权利要求5或8所述的数据库系统，其中，所述数据库的状态至少包括各数据库的负载和对查询的响应速度。

10.根据权利要求1至8之一所述的数据库系统，其中，所述数据库是分布式数据库。

11.根据权利要求1所述的数据库系统，其中，所述跨数据集合的查询请求是SQL语句，并且所述SQL语句能够包含函数。

12.一种数据库系统中的跨数据库查询优化方法，所述数据库系统包括多个数据库，所述多个数据库中的至少两个数据库存储有一个或多个由具有相同结构的表组成的数据集合，该方法包括以下步骤：

联合视图建立步骤，在所述至少两个数据库中的每个数据库上创建所述数据集合的联合视图；以及

路由步骤，响应跨所述数据集合的查询请求，根据预定路由规则将跨所述数据集合的查询请求路由到所述至少两个数据库中的一个数据库，以便利用该数据库的联合视图进行查询。

13.根据权利要求12所述的跨数据库查询优化方法，其中，所述数据库系统是软件即服务SaaS数据库系统，并且每个所述数据集合是SaaS数据库系统中的称为租户数据的、属于一个租户的数据的集合。

14.根据权利要求13所述的跨数据库查询优化方法，其中，所述预定路由规则包括：

15.根据权利要求13所述的跨数据库查询优化方法，其中，所述预定路由规则包括：

16.根据权利要求13所述的跨数据库查询优化方法，其中，所述预定路由规则包括：

17.根据权利要求12所述的跨数据库查询优化方法，还包括以下步骤：

在运行时跟踪跨租户数据的查询请求行为；和

在离线时基于对所述跨租户数据的查询请求行为的跟踪结果在所述多个数据库之间移动租户数据。

18.根据权利要求17所述的跨数据库查询优化方法，进一步基于各数据库的状态在所述多个数据库之间移动租户数据。

19.根据权利要求17或18所述的跨数据库查询优化方法，其中，跟踪跨租户数据的查询请求行为包括跟踪各租户的涉及到其余租户的查询的频率。

20.根据权利要求16或18所述的跨数据库查询优化方法，其中，所述数据库的状态至少包括各数据库的负载和对查询的响应速度。

21.根据权利要求12至18之一所述的跨数据库查询优化方法，其中，所述数据库是分布式数据库。

22.根据权利要求12所述的跨数据库查询优化方法，其中，所述跨数据集合的查询请求是SQL语句，并且所述SQL语句能够包含函数。