CN102346744B - 用于在多租户应用系统中处理物化表的装置 - Google Patents

Abstract

本发明涉及多租户应用系统。公开了一种用于在多租户应用系统中处理物化表的装置和方法，其中，在所述多租户应用系统中，多个租户共享一个或多个基表，该装置包含：更新模式分析器，用于根据多个租户的数据访问历史信息，分析所述多个租户对所述一个或多个基表的更新的模式的相似程度；租户分组器，用于按照更新模式分析器的所分析的相似程度，将所述多个租户划分为多个租户分组；物化表构造器，用于根据租户分组器划分的租户分组，由所述一个或多个基表构造与租户分组对应的租户分组物化表。

Description

用于在多租户应用系统中处理物化表的装置

技术领域

本发明涉及多租户应用，尤其涉及多租户应用中数据库的管理，更具体来说，涉及一种用于在多租户应用系统中处理物化表的装置。

背景技术

多租户应用系统，通过多租户MT(Multi-Tenancy)技术，向软件的用户提供多租户应用，即在服务提供商的服务器上运行软件应用程序的单个实例，为多个租户(例如企业之类的组织)提供软件应用服务，由此能够降低软件应用程序的开发、部署和运行的费用。

数据库是一种系统化的数据组织，用于对数据进行有效而可靠的存储、检索和处理。数据库由表组成，表中有一行一行的关联数据。对数据的访问和操作是通过查询(query)完成的。

基本数据库是一种数据库，顾名思义，基本数据库中含有基本数据。例如，用于商店每日的销售数据的数据库，包括商品、销售数量、售价、售出时间。

根据基本数据库，就可以进行数据分析。例如，从商品的角度，计算出每一种商品每天的销售总量；随着时间的推移，计算出每一种商品每个月的销售总量，计算出每一种商品每年的销售总量。

在本发明的上下文中，基本数据库也被称作基表BT(Basic Table)。

由基表可以创建物化视图MV(materialized View)，亦称物化表。物化表也是一种数据库，可以存储从基表导出的中间数据，例如上文所述的商品月销售总量。使用物化表进行查询，能利用物化表中的中间数据，可以减少复杂的查询所需的计算量，所以可以提高查询的效率。

在大规模的多租户应用系统中，广泛采用物化表来提高数据查询操作的效率。在这种情况下，多个租户共享一个或多个基表以及与基表对应的物化表，通常在基表和物化表中用租户标识符来区分数据所属的租户。

在数据库对物化表的设计中，基表与物化表之间，必须保持数据同步。当对基表进行增、删、改等操作时，物化表需要刷新同步后才能被查询和检索，当物化表在刷新同步的过程中，物化表会被锁定，这时，用户的SQL查询将不能利用物化表。例如，当在基表中增加新的一天的商品的销售总量数据时，对应的物化表不能用，因为物化表中的商品的月销售量尚未反映新增加的一天的商品销售总量，如果使用物化表中的数据，结果是错误的。当对基表进行增、删、改等操作后，物化表必须在其数据与修改后的基表的数据同步化后，才能被使用，例如，根据变化了的基表，重新导出或生成物化表，使物化表的商品月销售总量包括新增加的一天的销售总量。

在采用物化表的多租户应用系统中，不同的租户对共享的基表可能有不同的更新模式--例如在不同的时间和/或以不同的频率对基表进行数据的增、删、改等更新操作。如果共用基表和物化表的租户很多，则在任何时候，都可能有租户在对公用的一个或多个基表进行更新操作。由于物化表对应多个基表，从物化表的角度来看，基表的更新率总是很高。结果，物化表的刷新机率很大，被锁定的频率也很高，这使得租户几乎不可能使用物化表来提高查询效率，从而影响租户的业务操作的速度。

发明内容

发明人发现，对于有些租户群来说，他们的对基表的更新模式在一定程度上具有一致性或相似性。据此，本发明提出按照租户的更新模式的相似性构造MV，使更新模式一致或相似租户共享同一个MV。一旦发生对基表的大规模更新，就暂时禁用(disable)对应的MV，而直接使用基表，直到对应的MV与基表重新同步。

按照本发明的一个方面，提供一种用于在多租户应用系统中处理物化表的装置，其中，在所述多租户应用系统中，多个租户共享一个或多个基表，该装置包含：

更新模式分析器，用于根据多个租户的数据访问历史信息，分析所述多个租户对所述一个或多个基表的更新的模式的相似程度；租户分组器，用于按照更新模式分析器的所分析的相似程度，将所述多个租户划分为多个租户分组；物化表构造器，用于根据租户分组器划分的租户分组，由所述一个或多个基表构造租户分组物化表。

按照本发明的另一个方面，提供一种用于在多租户应用系统中处理物化表的方法，其中，在所述多租户应用系统中，多个租户共享一个或多个基表，该方法包含：

根据多个租户的数据访问历史信息，分析所述多个租户对所述一个或多个基表的更新的模式的相似程度；按照所分析的相似程度，将所述多个租户划分为多个租户分组；根据租户分组器划分的租户分组，由所述一个或多个基表构造租户分组物化表。

附图说明

所附权利要求中阐述了被认为是本发明的特点的创造性特征。但是，通过参照附图阅读下面对示例性实施例的详细说明可更好地理解发明本身以及其使用模式、另外的目标、特征以及优点，在附图中：

图1示例性表示基表与物化表的关系；

图2示意性表示一种可在其中实施本发明实施例的多租户应用系统的体系结构；

图3A表示可在图2A的体系结构中实现的按照本发明实施例的装置和系统；

图3B示意性表示按照本发明实施例构造的租户分组物化表与基表的关系；

图4A和4B示例性地表示反映租户的更新模式的数据和图表；

图5A和5B示例性地表示对图4A的数据作进一步处理后得到的数据和图表；

图6A和6B示例性地对图4A和4B数据和图表的处理；

图7示意性表示作为历史信息源的部分日志内容；

图8示例性地表示按照本发明实施例的方法的总体流程图。

具体实施方式

下面参照附图来说明本发明的实施例。在下面的说明中，阐述了许多具体细节以便更全面地了解本发明。但是，对于本技术领域内的技术人员很明显，本发明的实现可不具有这些具体细节。此外，应当理解的是，本发明并不限于所介绍的特定实施例。相反，可以考虑用下面的特征和元素的任意组合来实施和实践本发明。而无论它们是否涉及不同的实施例。因此，下面的方面、特征、实施例和优点仅作说明之用而不应被看作是所附权利要求的要素或限定，除非权利要求中明确提出。

参看图1，该图示例性地表示基表与物化表的关系。

图1中左侧表示基表BT，右侧表示基表对应的物化表MV0。

图1中例示了三个基表，即“EMPLOYEE”(职员)、“SALARY”(工资)、“SALARYITEM”(工资项)。

基表“EMPLOYEE”的属性包括主键EMP_ID(职员标识)和NAME(姓名)。

基表“SALARY”的属性包括主键SAL_ID(工资标识)、外键EMP_ID(职员标识)和MONTH(月份)。

基表“SALARYITEM”的属性包括主键SI_ID(工资项标识)、外键SAL_ID(工资标识)、WORKITEM(工作项)、WORKTIME(工作时间)和INCOME(收入)。

三个基表之间可以通过主外键相关联。例如，基表“EMPLOYEE”与基表“SALARY”之间，通过基表“EMPLOYEE”的主键(PK)EMP_ID与基表“SALARY”的外键(FK)EMP_ID关联；同样，基表“SALARY”与基表“SALARYITEM”之间，通过基表“SALARY”的主键(PK)SAL_ID与基表“SALARYITEM”的外键(FK)SAL_ID关联，由此，三个基表“EMPLOYEEL”、“SALARY”和“SALARYITEM”之间就能实现关联。通过这种关联，可以构造物化表。

数据库模式定义语言DDL(Data Definition Language)，是用于描述数据库中要存储的现实世界实体的语言。数据库系统通常用DDL脚本(script)来构造物化表。

以下是为上述三个基表EMPLOYEE、SALARY、SALARYITEM创建一个名称为EMPL_SALARY的物化表MV0的DDL脚本的例子。

CREATE TABLE EMPL_SALARY AS(SELECT E.NAME，S.MONTH，AMOUNT(I.INCOME)，AMOUNT(I.WORKTIME)FROM EMPLOYEE E，SALARY S，SALARYITEM I WHERE E.EMP_ID＝S.EMP_ID AND S.SAL_ID＝I.SAL_ID)

DATA INITIALLY DEFERRED REFRESH DEFERRED。

所构造的物化表MV0如图1右侧所示。该物化表包含以下属性：NAME，MONTH，AMOUNT(I.INCOME)，AMOUNT(I.WORKTIME)(图中未予示出)，其中，AMOUNT(I.INCOME)表示收入总计，AMOUNT(I.WORKTIME)表示工作时间总计，因此，该物化表的内容包含是某人(NAME)某月(MONTH)的收入总计和工作时间总计。

图2示意性表示一种多租户MT应用系统的体系结构，本发明的各种实施例可在这种体系结构中实现。如图2所示的体系结构包含服务器21、访问路由器22、存储多租户(MT)应用数据的数据库23、存储多租户(MT)元数据的储存库24。其中，数据库23包含由多租户应用的多个租户T1、T2...Tn共享的基表BT和对应的物化表MV。

用于构造物化表DDL脚本，也可存储在例如数据库23中(未予示出)。

当多租户应用系统的多个租户T1、T2...Tn中的某个租户Tn通过多租户应用发出涉及访问数据库的请求时，访问路由器22根据储存库24中的元数据，将该租户的请求路由到服务器21，以执行所请求的服务。

租户发出的涉及访问数据库的请求，可以是对数据库23的内容的查询。对于复杂的SQL查询，服务器根据租户的身份，判断是否存在该租户的查询请求可用的物化表。如果存在，服务器在物化表MV上执行查询，否则，服务器就在基表BT中执行查询。如果租户的请求属于仅需要基表中的基本数据的简单查询，服务器只需在租户共享的基表BT上执行查询。

租户发出的涉及访问数据库的请求，也可以是对数据库23的内容的更新。服务器将按照请求，对基表BT进行更新操作，例如进行对基表中的数据进行增、删、改等操作。

在服务器对基表进行更新操作期间，对应的物化表MV被锁定，其它租户都不能访问被锁定的物化表。当对基表的更新操作完成后，要将物化表与基表进行同步。例如，删除原来的物化表，然后基于更新后的基表创建或构造新的物化表。

服务器21进行的操作，都被作为历史信息保存起来。租户对数据访问历史，也是历史信息的一部分。历史信息的一个例子是系统的日志，例如，日志中记录的租户对数据访问的信息，包括操作的时间、涉及的租户以及操作类型等等。

图3A表示按照本发明一个实施例的用于管理多租户应用中的物化表的系统。

如图3A所示的用于管理多租户应用中的物化表的系统，包含了与图2所示的体系结构中的相同或相当的部件，例如服务器21、访问路由器22、数据库23包含由多租户应用系统的多个租户T1、T2...Tn共享的基表BT的数据库23、存储多租户(MT)元数据的储存库24。数据库23中，还可以存储与多个租户T1、T2...Tn共享的基表BT对应的物化表MV。

同样，服务器21进行的操作，都被作为历史信息保存起来，例如被记录在日志中。例如，日志中记录了租户的数据访问的历史信息，包括操作的时间、涉及的租户以及操作类型等等。

如上文结合图2所述的那样，物化表MV由多个租户共享，并与一个或多个基表BT相关联。

与图2相比，图3A的系统还包含一个用于管理多租户应用中的物化表的装置300，该装置300包含更新模式分析器35、租户分组器36和物化表构造器37。

其中，更新模式分析器35用于根据多个租户T1、T2...Tn的数据访问历史信息，分析所述多个租户对基表BT进行更新的模式(本文中也简称为“更新模式”或“租户的更新模式”)的相似程度。

后文将结合图4A和4B，更详细地说明更新模式分析器35分析更新模式的相似程度的具体实施方式。

租户分组器36用于按照更新模式分析器35所分析的相似程度，将多个租户T1、T2...Tn划分为多个租户分组。

例如，租户分组器36将多个租户划分为两个租户分组TG1和TG2(图3A中未予示出)，其中，租户分组TG1中包含的各个租户，具有互相相似的更新模式；租户分组TG2中包含的各个租户，具有互相相似的更新模式。当然，租户分组器36可以根据具体情况，将多个租户划分为两个以上的租户分组。

物化表构造器37，用于根据租户分组器36划分的租户分组，构造租户分组物化表。

例如，租户分组器36将多个租户划分为两个租户分组TG1和TG2，则物化表构造器37根据这样的划分，由基表BT构造两个租户分组物化表MV1和MV2，如图3B所示。这两个租户分组物化表MV1和MV2，分别对应于对应于租户分组TG 1和TG2。

租户分组物化表MV1和MV2与物化表MV的结构相同，只是内容因租户分组的不同而异。例如，租户分组物化表MV1只含有与租户分组TG1中的租户有关的数据。

后文将结合图6A和6B进一步说明物化表构造器37根据租户分组构造租户分组MV的具体实施方式。

按照本发明的一个实施例，用于管理多租户应用中的物化表的装置进一步包含物化表调度器38。

物化表调度器38用于基于租户对基表的更新情况，确定启用还是禁用对应的租户分组物化表。

按照本发明的一个实施例，物化表调度器基于当前将有多个租户中至少一个租户对基表的大规模更新的判断，确定禁用该租户所属租户分组的租户分组物化表。就是说，物化表调度器38如果判断当前将要发生租户对基表的大规模更新，则将该租户所属租户分组的租户分组物化表的状态由“启用”标记为“禁用”。

按照本发明的另一个实施例，在多个租户中至少一个租户对基表的大规模更新后，物化表调度器确定启用通过物化表构造器构造的该租户所属租户分组的租户分组物化表。就是说，物化表调度器38在发生租户对基表的大规模更新后，通过物化表构造器37构造该租户所属租户分组的租户分组物化表以替代被禁用的租户分组物化表，并将新构造的租户分组物化表的状态由“禁用”标记为“启用”。

按照本发明，多租户应用系统的访问路由器22可以响应于来自租户的数据访问请求，例如SQL请求，根据多租户元数据中存储的分组与租户分组物化表的对应关系，将该SQL请求路由到与该租户所属租户分组的租户分组物化表。

现在结合图4A和4B，更详细地说明更新模式分析器35分析更新模式的相似程度的具体实施方式。

发明人发现，对于有些租户群来说，他们的更新模式具有一定的相似性。

按照本发明的一个实施例，更新模式分析器35所分析的更新模式的相似程度，包括对物化表的关联基表的记录进行删除、插入或重写操作的时间的相近度。

换言之，在该实施例中，更新的模式，就是对物化表的关联基表的记录进行删除、插入或重写操作的模式，包括对物化表的关联基表的记录进行删除、插入或重写操作的时机。

参看图4A，该图以表格的形式示意性地表示不同租户对图1所示的基表BT的更新模式。

图4A中第一列的T1、T2...T10表示不同的租户，第一行的1、2...15表示不同的时间(或时间段)，这里假设分别表示每月的第1天、第2天...第15天。除第1行和第1列外的每个单元，表示某租户在某天对基表BT(“EMPLOYEE”“SALARY”或“SALARY ITEM”)的更新次数。例如，如第2列所示，在第2天，租户T5进行了320次更新，租户T10进行了110次更新，其余租户在第2天没有进行更新。从表1中还可以看出，租户T7与租户T9，均在第9天进行大量的更新，租户T4和租户T8均在第12天进行大量的更新。

租户T1、T2...T10的更新模式，也可以用图4B的图表来表示。图4B的横座标表示时间，纵坐标表示更新次数。图4B的图表可以由图4A所示的表格中的数据导出，从中可以直观地观察租户的更新在时间上的分布。

从图4B可以直观地看出，租户T5和租户T10对应的曲线在时间2上重叠，这表明租户T5和租户T10均在第2天进行了大量的更新，因此，就更新时间而言，租户T5和租户T10的更新模式是相似的，或者具有较高的相似度。

同样，租户T7和租户T9的更新模式具有较高的相似度，租户T4和租户T8的更新模式具有较高的相似度，租户T1和租户T2的更新模式具有较高的相似度。

按照本发明的一个实施例，更新模式分析器35分析更新模式的相似程度所基于的数据访问历史信息，是从日志中记录的租户的数据访问操作的信息中获得的。

例如，图4A所示的数据，就可以从租户以往对数据库(基表、物化表)的操作的历史信息中收集。

后文将结合图7，更详细地说明从计算机系统的日志中收集这些数据的具体实施方式。

所属技术领域的技术人员知道，根据这些数据，有各种方式可以分析租户的更新模式的相似程度。

如上文结合图3A所述的那样，本发明的租户分组器36于是可以根据多个租户对与物化表的关联基表的更新模式的相似程度，将多个租户划分为多个租户分组，如图6A所示。

例如，租户T1-T10被划分为六个分组TG1-TG6，租户T1、T2被划分在租户分组TG1，租户T5、T10被划分在租户分组TG2，租户T4、T8被划分在租户分组TG3，租户T7、T9被划分在租户分组TG4，租户分组TG5只包含租户T5，租户分组TG6只包含租户T6。图6A还表示，与租户分组TG1-TG6相对应，在第13天、第2天、第12天、第9天、第5天和第6天，分别发生了对基表的大规模更新。

按照本发明的实施例，租户分组器36可以将如图6A所示的关于租户与租户分组的对应关系和/或大规模更新时间的信息，作为元数据的一部分，记录在储存库24中。该信息可以由物化表构造器37使用，也可以由访问路由器22使用。

如上文结合图3A所述的那样，本发明的物化表构造器37于是可以根据租户分组器36划分的租户分组，构造出对应的租户分组物化表

按照本发明的实施例，物化表构造器37可以根据租户分组，用DDL脚本构造租户分组物化表。

例如，物化表构造器37可以获得预先定义的DDL脚本，例如上文结合图1所述的DDL脚本，用来自MV分组器36的或者从元数据中的租户分组信息，修改DDL脚本，然后用修改后的DDL脚本为租户分组构造租户分组物化表。

例如，为包含租户T1和T2的租户分组TG1创建租户分组物化表EMPL_SALARY_TG1，可以用以下修改后的DDL脚本来实现。

CREATE TABLE EMPL_SALARY AS(SELECT E.NAME，S.MONTH，AMOUNT(I.INCOME)，AMOUNT(I.WORKTIME)FROM EMPLOYEE E，SALARY S，SALARYITEM I WHERE E.EMP_ID＝S.EMP_ID AND S.SAL_ID＝I.SAL_ID)ANDa.tenantID IN(‘T1’，‘T2’)AND c.t enantID IN(‘T1’，‘T2’)

DATA INITIALLY DEFERRED REFRESH DEFERRED

上述对DDL脚本的修改，是增加了表示租户分组TG1的成员租户T1和T2的代码“AND a.tenantID IN(‘T1’，‘T2’)AND c.tenantID IN(‘T1’，‘T2’)”，以使所构造的租户分组EMPL_SALARY_TG1只包含与租户分组TG1的成员租户T1和T2相关联的数据。

再如，以下是为包含租户T5和T10的租户分组TG2创建租户分组物化表EMPL_SALARY_TG2的代码实现。

CREATE TABLE EMPL_SALARY AS(SELECT  E.NAME，S.MONTH，AMOUNT(I.INCOME)，AMOUNT(I.WORKTIME)FROM EMPLOYEE E，SALARY S，SALARYITEM I WHERE E.EMP_ID＝S.EMP_ID AND S.SAL_ID＝I.SAL_ID)ANDa.tenantID IN(‘T5’，’T10’)AND c.tenantID IN(‘T5’，’T10’)

DATA INITIALLY DEFERRED REFRESH DEFERRED

其中，代码“AND a.tenantID IN(‘T5’，‘T10’)AND c.tenantIDIN(‘T5’，‘T10’)”，表示所构造的租户分组EMPL_SALARY_TG2只包含与租户分组TG 2的成员租户T5和T10相关联的数据。

类似地，可以为其它租户分组TG 3-TG6创建租户分组物化表EMPL_SALARY_TG3-EMPL_SALARY_TG6，这样，就可以构造出6个租户分组物化表EMPL_SALARY_TG1...EMPL_SALARY_TG6。如图6B所示，这6个租户分组物化表与6个租户分组TG1...TG6分别对应。所属技术领域的技术人员明白，所构造的租户分组物化表EMPL_SALARY_TG1...EMPL_SALARY_TG6与物化表EMPL_SALARY，结构相同，但是内容不同，租户分组物化表只涉及对应的租户分组中的租户的内容。例如，EMPL_SALARY_TG1只包含与T1和T2相关的内容。

按照本发明的一个实施例，物化表构造器37可以将如图6B所示的租户分组物化表与租户分组物化表之间的对应关系的信息，作为元数据的一部分，记录在储存库24中。该信息可以由物化表调度器38使用，也可以由访问路由器22使用。

如图6B所示的表中还有一栏标题为“状态”的数据，用于表示相应的租户分组MV的状态。如果状态为“启用”，表明相应的租户分组MV已经与其基表同步，是可用的。如果状态为“禁用”，表明相应的租户分组MV是不可用的。

按照本发明的一个实施例，构造器37在新构造一个租户分组物化表后，将新构造的租户分组物化表的状态设置为“启用”，并将该状态信息作为元数据的一部分，记录在储存库24中。该信息可以由物化表调度器38使用，也可以由访问路由器22使用。

如在前文结合图3A所作的描述中所述，物化表调度器38用于基于租户对基表的更新情况，确定启用还是禁用对应的租户分组物化表。物化表调度器38可以在判断当前将要发生租户对基表的大规模更新时，将该租户所属租户分组的租户分组物化表的状态由“启用”标记为“禁用”；可以在发生租户对基表的大规模更新后，通过物化表构造器37构造该租户所属租户分组的租户分组物化表以替代被禁用的租户分组物化表，并新构造的租户分组物化表的状态由“禁用”标记为“启用”。由物化表调度器38引起的对租户分组物化表的状态的改变，也可以作为元数据的一部分，记录在储存库24中。

以下更详细地说明分析租户的更新模式的相似性的一个实施例。按照该实施例，通过对例如图4A所示的租户更新基表的数据进行归一化处理，分析租户的更新模式的相似性。

可以根据下述公式进行所述归一化处理，使得经过归一化处理后的每个租户在特定时间的更新次数的最大值都是1，最小值都是0。

$\mathrm{\Σ}{x}_{\mathrm{ij}}=\frac{x_{\mathrm{ij}}-\underset{i}{\min }\left\{x_{\mathrm{ij}}\right\}}{\underset{i}{\max }\left\{x_{\mathrm{ij}}\right\}-\underset{i}{\min }\left\{x_{\mathrm{ij}}\right\}}$

上式中Xij表示某一租户在第i天时更新j次；min{xij}表示某一租户在i天内除第i天的最小日更新次数；max{xij}表示某一租户在i天内最大的更新次数，包含第i天。

对于租户T1来说，其在第13天更新100次，最大更新100次，其他时间最小日更新次数为0。

所以代入公式：

在i＝13时，xij＝100，max{xij}＝100，min{xij}＝0，

所以∑x_ij＝(100-0)/(100-0)＝1；

在i＝其他值时，xij＝0，max{xij}＝100，min{xij}＝0，

所以∑x_ij＝(0-0)/(100-0)＝0。

经过归一化处理后，租户T1的刷新次数的最大值是1，最小值是0。

对于租户T2来说，其在第13天更新220次，最大更新220次，其他时间最小日更新次数为0。

所以代入公式：

在i＝13时，xij＝220，max{xij}＝220，min{xij}＝0，

所以∑x_ij＝(220-0)/(220-0)＝1；

在i＝其他值时，xij＝0，max{xij}＝220，min{xij}＝0，

所以∑x_ij＝(0-0)/(220-0)＝0。

对图4中的所有租户的数据作同样的处理，可以得到图5A所示的数据表。经过归一化处理，图5A所示的数据表中只包含0和1两种数值，其中数值1表示发生了大规模更新，数值0表示没有发生更新或者更新次数小于预定的阈值，可以忽略不计。

由该数据表可以导出图5B所示的图表，其中的横座标表示时间，纵坐标表示经过归一化处理的更新次数。

从图4B中可以直观地观察租户的更新在时间上的分布。例如，表征租户T1的更新模式的曲线为TG1，表征租户T2的更新模式的曲线也为TG1。

换言之，经过归一化处理后，表征租户T1的更新模式的曲线与表征租户T2的更新模式的曲线重合，表明这两个租户的更新模式是高度相似的。因此，将租户T1和T2分在同一个租户分组TG1。

现在结合图7，说明从计算机系统的日志中收集这些数据的具体实施方式。

如上文所述，在实施本发明时，可以从计算机系统的日志中获得关于租户的数据访问操作的信息，用于分析租户的更新模式的相似程度。

利用日志中的信息，作为历史信息来分析计算机用户的操作行为，是本领域技术人员常用的技术手段。

按照本发明的实施例，更新模式分析器35首先从从日志中收集关于租户的数据访问操作的信息，获得如图7所示的部分日志内容。如图7所示的日志数据，记录了租户对数据库进行更新操作的细节，包括操作发生的时间71(例如“2009-11-1316：23：51，640”)、租户72(例如“{conn-100001-T1}”)和操作73(例如“insert salary values”)。其中，操作“insert salary values”的类型是数据插入，这属于对基表(例如图1所示的基表“SALARY”)进行更新的操作。

按照本发明的实施例，可以根据所收集的上述日志数据，构造图4A所示的数据表，用于分析租户的更新模式的相似程度。

以上通过实施例，说明了本发明的用于管理多租户应用中的物化表的装置300的各种实施方式。在同一个发明构思下，本发明也提供一种用于在多租户应用系统中处理物化表的方法。

如图8所示的本发明的方法800，用于在如图3A所示的多租户应用系统中处理物化表，在所述多租户应用系统中，多个租户共享一个或多个基表。

该方法主要包含三个步骤S850、S860和S870。

在步骤S850，根据多个租户的数据访问历史信息，分析所述多个租户对所述一个或多个基表的更新的模式的相似程度；

在步骤S860，按照更新模式分析器的所分析的相似程度，将所述多个租户划分为多个租户分组；

在步骤S870，根据租户分组器划分的租户分组，由所述一个或多个基表构造租户分组物化表。

按照本发明一个实施例，该方法进一步基于租户对所述一个或多个基表的更新情况，确定启用还是禁用对应的租户分组物化表。

按照本发明一个实施例，该方法进一步基于当前将有多个租户中至少一个租户对基表的大规模更新的判断，禁用该租户所属租户分组的租户分组物化表。

按照本发明一个实施例，该方法进一步在多个租户中至少一个租户对基表的大规模更新后，启用通过物化表构造器构造的该租户所属租户分组的租户分组物化表。

在上述方法的各种实施例中，所述更新的模式的相似程度，包括对物化表的关联基表的记录进行删除、插入或重写操作的时间的相近度。

按照本发明一个实施例，在上述方法的各种实施例中，可以利用DDL脚本构造与租户分组对应的租户分组物化表。

按照本发明一个实施例，在上述方法的各种实施例中，存储以下的至少之一：租户和租户分组的对应关系；租户的大规模更新时间；租户分组物化表被启用或禁用的信息。例如，将它们作为多租户应用系统的多租户元数据的一部分存储起来。

按照本发明一个实施例，在上述方法的各种实施例中，所述数据访问历史信息是所述多租户应用系统的日志中记录的租户的数据访问操作的信息。

上文所述的装置300及其各种实施例，可用于说明和实现本发明用于在多租户应用系统中处理物化表的方法800的各种实施例。为简明起见，在以上对方法800各种实施例的描述中，省略了与上文对相应装置300的描述中重复的部分内容。因此，可参见以上关于相应方法的描述来了解该装置的细节。

以上对用于在多租户应用系统中处理物化表装置300和方法800及其各种实施例的描述和图示仅仅为示例性的，而不是对本发明的限制。在本发明的其他实施例中，该装置可具有更多、更少或不同的模块，且各模块之间的连接或包含关系可以与所描述和图示的不同。

本发明可以硬件、软件、或硬件与软件的结合的方式实现。本发明可以集中的方式在一个计算机系统中实现，或以分布方式实现，在这种分布方式中，不同的部件分布在若干互连的计算机系统中。适于执行本文中描述的方法的任何计算机系统或其它装置都是合适的。一种典型的硬件和软件的组合可以是带有计算机程序的通用计算机系统，当该计算机程序被加载和执行时，控制该计算机系统而使其执行本发明的方法，并构成本发明的装置。

本发明也可体现在计算机程序产品中，该程序产品包含使能实现本文中描述的方法的所有特征，并且当其被加载到计算机系统中时，能够执行所述方法。

尽管已参照优选实施例具体示出和说明了本发明，但是本领域内的那些技术人员应理解，可在形式和细节上对其进行各种改变而不会背离本发明的精神和范围。

Claims (10)

1.一种用于在多租户应用系统中处理物化表的装置，其中，在所述多租户应用系统中，多个租户共享一个或多个基表，该装置包含： 

更新模式分析器，用于根据多个租户的数据访问历史信息，分析所述多个租户对所述一个或多个基表的更新的模式的相似程度，其中，所述更新的模式的相似程度，包括对物化表的关联基表的记录进行删除、插入或重写操作的时间的相近度； 

租户分组器，用于按照更新模式分析器所分析得到的相似程度，将所述多个租户划分为多个租户分组； 

物化表构造器，用于根据租户分组器划分的租户分组，基于所述一个或多个基表构造租户分组物化表； 

物化表调度器，用于基于租户对所述一个或多个基表的更新情况，确定启用还是禁用对应的租户分组物化表，其中，物化表调度器基于当前将有多个租户中至少一个租户对基表的大规模更新的判断，确定禁用该租户所属租户分组的租户分组物化表，在多个租户中至少一个租户对基表的大规模更新后，物化表调度器确定启用通过物化表构造器构造的该租户所属租户分组的租户分组物化表。 

2.如权利要求1所述的装置，其中，物化表构造器利用DDL脚本构造租户分组物化表。 

3.如权利要求1所述的装置，其中，租户分组器还用于在元数据中存储以下的至少之一： 

租户和租户分组的对应关系； 

租户的大规模更新时间。 

4.如权利要求1所述的装置，其中，物化表调度器还用于在元数据中存储租户分组物化表被启用或禁用的信息。 

5.如权利要求1所述的装置，其中，所述数据访问历史信息是所述多租户应用系统的日志中记录的租户的数据访问操作的信息。 

6.一种用于在多租户应用系统中处理物化表的方法，其中，在所述多租户应用系统中，多个租户共享一个或多个基表，该方法包含： 

根据多个租户的数据访问历史信息，分析所述多个租户对所述一个或多个基表的更新的模式的相似程度，其中，所述更新的模式的相似程度，包括对物化表的关联基表的记录进行删除、插入或重写操作的时间的相近度； 

按照更新模式分析器的所分析的相似程度，将所述多个租户划分为多个租户分组； 

根据租户分组器划分的租户分组，由所述一个或多个基表构造租户分组物化表； 

基于租户对所述一个或多个基表的更新情况，确定启用还是禁用对应的租户分组物化表，其中，基于当前将有多个租户中至少一个租户对基表的大规模更新的判断，禁用该租户所属租户分组的租户分组物化表，在多个租户中至少一个租户对基表的大规模更新后，启用通过物化表构造器构造的该租户所属租户分组的租户分组物化表。 

7.如权利要求6所述的方法，其中，所述由所述一个或多个基表构造租户分组物化表，包含利用DDL脚本构造与租户分组对应的租户分组物化表。 

8.如权利要求6所述的方法，进一步包含： 

存储以下的至少之一： 

租户和租户分组的对应关系； 

租户的大规模更新时间。 

9.如权利要求6所述的方法，进一步包含：存储租户分组物化表被启用或禁用的信息。 

10.如权利要求6所述的方法，其中，所述数据访问历史信息是所述多租户应用系统的日志中记录的租户的数据访问操作的信息。 

Images