英语原文共 15 页，剩余内容已隐藏，支付完成后下载完整资料
适用于多用户数据管理的自适应数据库架构模式设计
摘 要
多用户数据管理是软件即服务（SaaS）的主要应用。例如，许多公司希望将其数据外包给第三方，该第三方托管多用户数据库系统以提供数据管理服务。多用户数据库系统需要具有高性能，低空间需求和卓越的可扩展性。一个巨大的挑战是设计高质量的数据库模式。独立表共享实例（ITSI）和共享表共享实例（STSI）是设计模式的两种最先进的方法。但是，它们受到一些限制。由于需要维护大量表格，ITSI的可扩展性差。 STSI以牺牲性能和高空间开销为代价实现了良好的可扩展性。因此，需要一种解决这些问题的有效架构模式设计方法。在本文中，我们提出了一种适用于多用户应用的自适应数据库架构模式设计方法。我们权衡ITSI和STSI，并在它们之间找到平衡点，以在低空间要求下实现良好的可扩展性和高性能。为此，我们确定重要的属性并使用它们来生成适当数量的基表。对于其余属性，我们构造补充表。我们讨论如何使用核心矩阵来确定基表的数量，应用图分区算法来构建基表，并使用众所周知的PageRank算法评估属性的重要性。我们提出了一个基于成本的模型来自适应生成基表和补充表。我们的方法具有以下优点。首先，我们的方法实现了高可扩展性。其次，我们的方法实现了高性能，并且可以权衡性能和空间要求。第三，我们的方法只需稍作修改就可以很容易地应用到现有的数据库（例如MySQL）。第四，我们的方法可以适应任何模式和查询工作负载，包括OLAP和OLTP应用程序。对真实和合成数据集的实验结果表明，我们的方法在空间要求低的情况下实现了高性能和良好的可扩展性，并且胜过了最先进的方法。
关键词 ：SaaS，多用户，自适应架构设计
1绪论
软件即服务（SaaS）近来引起了极大关注，并成为许多商业应用的通用软件交付模式。 SaaS已被许多领先的互联网或软件公司采用，例如谷歌，亚马逊，甲骨文，微软，SAP，IBM和Salesforce。
多用户数据管理是SaaS的主要应用。例如，许多公司希望将其数据外包给第三方，该第三方托管多用户数据库系统以提供数据管理服务。每家公司都被称为租户。租户通过向数据库系统提出SQL查询，像本地计算机上的传统数据库一样管理和查询他们的数据。
在大多数传统企业中，部署数据库专用数据库服务器上。通常这些服务器大部分时间都没有充分利用。据报道，来自不同组织的近200台生产服务器的跟踪报告显示，平均CPU利用率低于4％。极低的利用率可以通过在一台或多台机器上整合多个数据库解决，降低硬件和运营成本。多租户数据管理系统将硬件，软件和专业服务的成本分摊给大量租户，从而通过增加规模来显着降低每租户成本。由于服务提供商希望尽可能多地支持租户，因此多租户数据库系统需要具有出色的性能，低空间需求和良好的可扩展性。一个巨大的挑战是设计高质量的数据库模式，这是多租户数据库中非常重要的因素。
据我们所知，独立表共享实例（ITSI）和共享表共享实例（STSI）是设计模式的两种最先进的方法。但是，它们受到一些限制。ITSI由于需要维护大量表格而具有较差的可扩展性（见第2.2.2节）。STSI以牺牲性能不佳和高空间开销为代价实现了良好的可扩展性（见第2.2.3节）。因此它需要有效的模式设计方法来解决这些问题。
在本文中，我们提出了一个自适应数据库模式多用户应用的设计方法。我们折衷ITSI和STSI，并在两种方法之间找到平衡点，以实现良好的可扩展性和高性能，同时需要较小的空间。为此，我们确定重要的属性并使用它们来生成几个基表。对于其他每个属性，我们构建补充表。我们讨论如何使用内核矩阵确定基表的数量，应用图分区算法来构造基表和评估使用众所周知的属性的重要性PageRank算法。我们开发了一个基于成本的模型来自适应地生成基表和补充表。 总而言之，我们做出以下贡献。
- 我们为多租户应用程序提出了一种自适应数据库模式设计方法。 我们的方法具有以下优点。首先，我们的方法实现了高可扩展性，因为表的数量取决于tennents共享的属性数量，而不是租户数量。其次，我们的方法可以权衡性能和空间需求。第三，我们的方法可以很容易地应用到现有的数据库（例如，MySQL），只需稍作修改。第四，我们的方法可以适应任何模式和查询工作负载，包括OLAP和OLTP应用程序。
- 我们建议使用核矩阵来确定基表的数量并采用图分区算法来构建基表。
- 我们使用众所周知的PageRank算法分析属性的重要性，并讨论如何识别重要属性。
- 我们提出了一个基于成本的模型来自动生成高质量的数据库模式。
- 实际和合成数据集上的实验结果表明，我们的方法在空间要求低的情况下实现了高性能和良好的可扩展性，并且超越了最先进的方法。
本文的其余部分安排如下。 在第2节中，我们阐述了多租户数据库模式设计的问题，并介绍了三种主要方法。 第3节介绍了我们方法的基本思想。 在第4节和第5节中，我们分析了如何构建基表。实验结果在第6节中提供。我们在第7节回顾相关工作。第8节结束本文。
2 准备工作
在本节中，我们首先制定第2.1节中的多租户数据库模式设计问题，然后回顾第2.2节中的现有研究。
2.1问题制定
在多租户数据管理应用中，租户将他们的数据外包给服务提供商，该服务提供商设计了多租户数据库来管理多租户数据。租户向系统返回相应答案的SQL查询。 接下来我们正式确定问题。
每个租户都用一组表{T1，T2，...，Tn}来外包数据库。 每个表被称为源表。为了向每个租户提供快速响应，多租户数据库需要实现高性能。为了服务于大量租户，多租户数据库需要具有出色的可扩展性和低空间需求。为了实现这些目标，多租户数据库面临的一个巨大挑战就是设计出高质量的模式。这意味着服务提供商需要重新设计数据库模式以有效地管理数据。多租户数据库中重新设计的表称为物理表。在本文中，我们研究如何自适应地设计高质量的物理表。
例如，我们从TPC-H [1]中选择五个核心表作为源表，如图1所示。这里为了简单起见，我们只使用表CUSTOMER作为我们的运行示例，如表1所示。在我们的例子中，我们只显示三个租户。
2.2研究现状
在本节中，我们将回顾现有的多租户数据库模式设计方法并讨论它们的局限性。
2.2.1独立数据库和独立数据库实例（IDII）
设计多租户数据库的第一种方法是独立数据库和独立实例（IDII）。在这种方法中，硬件将由不同的用户共享。 服务提供商将创建一个特定数据库来为每个租户提供服务。这意味着每个租户可以将源表存储在自己的数据库中。
显然，IDII很容易部署，可以直接在任何当前数据库之上构建。 IDII具有良好的数据隔离和安全性。但是，IDII的维护成本非常昂贵。 为了管理不同的数据库实例，服务提供者需要做很多配置工作，包括一些文件和参数。另外，对于每个实例，系统将分配一定数量的内存。例如，新的MySQL实例的初始化将消耗30M内存。此外，在IDII方法中，服务器中的数据库数量与租户数量成比例增长。例如，5000名租户将涉及5000个数据库实例。因此，服务提供商的维护成本非常大，这意味着IDII的可扩展性非常差。
2.2.2独立表和共享数据库实例（ITSI）
第二种多租户模式设计方法是独立表和共享实例（ITSI）。在这种方法中，租户不仅共享硬件，还共享数据库实例。服务提供者使用相同的数据库实例来存储来自多个租户的所有源表。 ITSI为每个租户保留私人表格。由于来自不同租户的源表可能会创建具有相同名称的表，因此我们需要添加租户ID以区分不同租户的表。因此，可以使用租户ID翻译提交的查询，以便将正确的答案返回给相应的租户。在我们的运行实例中，ITSI为所有租户创建了一个共享数据库。 对于每个租户，我们使用其源表作为其私人表。
由于ITSI管理单个数据库实例而不是多个数据库实例，与IDII相比，ITSI可以降低维护成本。因此ITSI提供比IDII更好的可扩展性。 但是，共享数据库中的私有表的数量与租户的数量成比例增长。然后，ITSI的可扩展性受到数据库系统可以很好支持的表的数量的限制。 在数据库中，需要为每个表的元数据分配多个缓冲页面。当表的数量很大时，内存成本会明显增加。争夺许多租户中的左派记忆将成为瓶颈。当表的数量超过50000时，服务器上的性能开始下降。因此，ITSI的可扩展性仍然是多租户数据库为大量租户提供服务的限制因素。
2.2.3共享表和共享数据库实例（STSI）
第三种多租户数据库模式设计方法是共享表和共享实例（STSI）。在STSI中，不同的租户不仅共享数据库实例，还共享表。服务提供商使用大表来管理多租户数据。大表的属性是所有租户属性的联合。来自每个租户的所有元组将被整合到大表中。为了区分不同租户的元组，我们添加列租户ID（TID）。请注意，有些租户在大表中可能没有属性（这些属性可能来自其他租户），因此我们必须在大表中为这些租户的这些属性设置NULL。例如，在我们的运行示例中，STSI构建了一个大表（表2）。
使用STSI，服务提供商可以显着降低维护成本，因为大表的总数仅由来自不同租户的最大源表数决定。因此，STSI比IDII和ITSI具有更好的可扩展性。 但是，STSI有一些限制。首先，如果某些属性由少数租户共享，则会涉及大量空值并浪费大量空间。其次，即使很多数据库可以有效地处理NULL，Hui等人表明，当数据库表变得太稀疏时，性能明显降低。某些面向列的功能（如索引或完整性约束）无法有效用于提高性能。另外，可以在一个MySQL表上建立的索引数量有限制。因此，当属性数量变大时，我们不能充分使用索引技术，性能将显着降低。
由于所有最先进的方法都有各种限制，本文中我们提出了一种自适应方法来设计数据库模式以解决这些限制。
3我们的自适应方法
在本节中，我们将在第3.1节中首先介绍自适应方法的概述。 在3.2节中，我们将介绍我们的自适应方法的框架。 然后我们将在3.3节中展示自适应方法的优点。
3.1概述
STSI方法通过将不同的租户整合到一个表中，以牺牲涉及大量NULL的代价来实现高可伸缩性。它会浪费许多不必要的空间并降低性能。与STSI相比，ITSI的可扩展性差，因为表的数量会随着租户数量的增加而增加。为了解决这些问题，在本文中，我们折衷这两种方法，并在两种方法之间找到平衡点，以实现良好的可扩展性，高性能和低空间要求。
基本思路：在实际应用中，很多来自不同租户的外包表是与主题相关的，所有租户配置的属性数量并不大。基于这一观察，我们从属性级别而不是租户级别构建物理表。我们首先从租户中提取非常重要的属性，并使用这些重要属性构建几个基本表。然后，对于剩下的不重要的属性，我们为每个属性创建补充表，如基于列的表。为此，我们提出了一种自适应方法（称为ADAPT），以基于不同租户和查询工作负载的数据库模式构建基表和补充表。很显然，在ADAPT中，表的数量远小于不同属性的总数，并且不会与租户数量成比例增长。
接下来我们将讨论如何设计基本表格和补充表格。 为了便于演示，我们首先介绍几个概念。
定义1（通用属性）。如果源表的属性是高度共享的属性，则源表的属性称为通用属性，即包含该属性的租户数量与租户总数的比率不小于给定阈值tau;。
由于通用属性被多个租户高度共享，我们可以说它们非常重要。 例如，在表2中，假设tau;= 0.8，所有租户1,4和9共享C_NAME和C_ADDRESS，它们是通用属性。
定义2（星形属性）。如果来自源表的属性是主键，则它被称为星形属性。可能会被其他一些源表引用。
由于星形属性将被多个表使用，它们将导致低性能，因为它们可能涉及许多昂贵的连接操作。 因此我们可以说这些明星属性非常重要。 在表CUSTOMER中，属性C_CUSTKEY是主键，由表ORDERS引用（如图1所示），则它是星形属性。
定义3（罕见属性）。如果属性既不是普通属性也不是星形属性，则该属性称为罕见属性。
除了常见属性和星属性外，一些不常见的属性也很重要。 我们用一个例子来展示我们的想法。 例如，考虑来自租户的以下SQL查询。
SELECT C_CUSTKEY,C_NAME,C_SALARY
FROM CUSTOMER
ORDER BY C_CUSTKEY;
如果C_SALARY和公共属性C_NAME来自不同的物理表，则会有一个连接操作。由于C_SALARY仅在SELECT子句中出现，并且包含C_SALARY的元组占总数的80％，因此加入成本很高。相反，如果将C_SALARY插入到基表中，将避免昂贵的连接操作。而且由于只有一个NULL产生，它不会涉及巨大的空间。因此，C_SALARY属性在查询处理方面非常昂贵，但在空间方面非常轻便，我们称之为依赖属性。我们将正式定义这个概念，并讨论如何确定第5节中的依赖属性。
例如，在给定的工作负载中，表3列出了昂贵操作中那些昂贵属性的出现次数。这些昂贵的操作是由昂贵的属性表和基表之间的大量连接操作引起的，甚至是由聚合函数造成的。在表3中，如果将昂贵的属性插入到相应的基本表中，我们还会记录增加NULL的数量。同时，我们需要为每个昂贵的属性记录相应的基本表编号。 我们可以将属性C_SALARY作为依赖属性。
3.2自适应模式设计
在本节中，我们提出了一种自适应模式设计方法来构建基表
全文共14060字，剩余内容已隐藏，支付完成后下载完整资料
资料编号：[15801]，资料为PDF文档或Word文档，PDF文档可免费转换为Word
