这是本节的多页打印视图。 点击此处打印.

返回本页常规视图.

体系结构

了解 Vertica 的工作原理有助于您有效地设计、构建、操作和维护 Vertica 数据库。此部分假定您熟悉关系数据库管理系统和 SQL 的基本概念和术语。

列存储

Vertica 以列格式存储数据，以便可以查询数据以获得最佳性能。与基于行的存储相比，列存储可减少磁盘 I/O，使其成为读取密集型工作负载的理想选择。Vertica 仅读取回答查询所需的列。对列进行编码和压缩可进一步提高性能。

Vertica 使用许多不同的编码策略，具体取决于列数据类型、表基数和排序顺序。编码可提高性能，因为执行查询只需较少的磁盘 I/O。此外，还可以在较少的空间中存储更多的信息。

使用压缩后，列存储占用的存储空间大大少于行存储。在列存储中，投影列中存储的每个值都具有相同的数据类型。这极大地方便了压缩操作，尤其是在经过排序的列中更是如此。在行存储中，行中的每个值都具有不同的数据类型，因此实际压缩效果要低很多。Vertica 使用的高效存储方法使得您能够在物理存储中维护更多历史数据。

投影

一个投影由一组具有相同排序顺序的列组成，该排序顺序由要用作排序依据的一个列或一系列的列定义。与传统数据库中的索引或实体化视图一样，投影可加快查询处理速度。当根据原始表编写查询时，查询会使用投影返回查询结果。有关详细信息，请参阅投影。

投影会分布和复制到群集中的各个节点，确保在一个节点不可用时，数据的另一个副本仍然可用。这种冗余称为 K-safety。

自动数据复制、故障转移和恢复可实现主动冗余，从而提高性能。节点可通过查询系统实现自动恢复。

Eon 模式和企业模式

Vertica 数据库采用以下两种模式之一运行：Eon 模式或企业模式。这两种模式都可以部署在内部部署或云中。在 Eon 模式下，计算和存储分开；数据库使用共享的公共存储，您可以根据需要添加或移除节点或子群集。在企业模式下，每个数据库节点都有一份数据，并且会分发查询以利用数据局部性。了解这些模式之间的差异至关重要。请参阅Eon 模式与企业模式。

1 - Eon 模式与企业模式

Vertica 数据库采用以下两种模式之一运行：Eon 模式或企业模式。这两种模式都可以部署在内部部署或云中。了解这两种模式之间的区别是关键。如果您要部署 Vertica 数据库，则必须在部署规划的早期确定以哪种模式运行该数据库。如果您使用的是已部署的 Vertica 数据库，则应该了解每种模式如何影响数据加载和查询。

在 Eon 模式和 Enterprise 模式下运行的 Vertica 数据库将以不同的方式存储其数据：

  • Eon 模式数据库使用公共存储来存储其数据。

  • 企业模式数据库将数据本地存储在组成数据库的节点的文件系统中。

这些不同的存储方法导致两种模式之间存在许多重要差异。

存储概述

Eon 模式将数据存储在称为公共存储的共享对象存储中：

在云环境中部署时，Vertica 将其数据存储在基于云的存储容器中，例如 AWS S3 存储桶。当部署在本地部署中时，Vertica 将数据存储在本地部署的对象存储中，例如 Pure Storage FlashBlade 设备。将永久性数据存储与计算资源（加载数据和处理查询的节点）分开可以提供灵活性。

企业模式跨数据库节点的文件系统存储数据：

该图显示企业模式数据库。

每个节点负责存储和处理部分数据。无论是基于云还是在本地，数据都以相同方式存放在数据库的各个节点中，以便在节点发生故障时提供复原能力。将数据存放在接近计算节能力的位置可提供一系列不同的优势。当节点添加到群集或者在不可用之后重新上线时，会自动查询其他节点以更新其本地数据。

每种模式的主要优势

Eon 模式和企业模式存储数据的不同方式使每种模式在不同的环境中具有优势。下表总结了这些差异。有关详细信息，请参阅Eon 模式与企业模式。

性能

正确配置后，Eon 模式和企业模式数据库在相同环境中具有大致相同的性能。

Eon 模式数据库通常支持缓存来自节点的本地存储库上的公共存储的数据，节点使用这些数据处理查询。启用存储库缓存后，Eon 模式数据库的查询性能相当于企业模式数据库，其中每个节点都在本地存储数据库的一部分。在这两种情况下，节点都会访问本地存储的数据以解析查询。

为了进一步提高性能，您可以在 Eon 模式数据库上启用存储库预热。启用存储库预热后，正在启动的节点会抢先加载其存储库，其中包含频繁查询和固定的数据。当节点完成启动并开始执行查询时，它的存储库已经包含了处理这些查询所需的大部分数据。这减少了从公共存储中提取数据的需要，并相应地提高了查询性能。

如果存储库太小，Eon 模式数据库中的查询性能可能会下降。小型存储库增加了查询需要的数据不在存储库中的机会。这导致节点不得不更频繁地从公共存储中检索数据。

安装

Eon 模式数据库必须具有对象存储，才能以公共方式存储其数据。除了安装在其节点上的存储之外，企业模式数据库不需要任何额外的存储硬件。根据您为 Vertica 数据库选择的环境（尤其是在内部部署中安装时），配置对象存储的需要可能会使您的安装更加复杂。

因为企业模式不需要额外的硬件来存储数据，所以安装起来会更简单一些。内部部署 Eon 模式安装需要为提供公共存储的对象存储提供额外的硬件和额外的配置。

企业模式对于开发环境特别有用，因为它不需要用于运行它的节点之外的其他硬件。您甚至可以在物理硬件或虚拟机上创建单节点企业模式数据库。您可以下载已准备好运行的预配置单节点企业模式虚拟机。有关详细信息，请参阅Vertica 社区版 (CE)。

在云环境中安装 Eon 模式数据库通常比内部部署安装更简单。云环境为您提供其自己的对象存储。例如，当您在 Amazon 的 AWS 中安装 Eon 模式数据库时，您只需为公共数据存储创建一个 S3 存储桶。然后，当创建数据库时，您可以将 S3 URL 提供给 Vertica。无需安装和配置单独的数据存储。

在云中安装企业模式数据库类似于安装内部部署数据库。您在云中创建的虚拟机必须具有足够的本地存储，才能存储您的数据库数据。

工作负载隔离

您通常希望防止密集型工作负载干扰其他可能对时间敏感的工作负载。例如，您可能希望将 ETL 工作负载与查询工作负载隔离开来。可以将依赖实时分析的用户组与运行批处理报告的组隔离开来。

Eon 模式数据库提供了最佳的工作负载隔离选项。它允许您创建称为子群集的节点组来隔离工作负载。查询仅在单个子群集中的节点上运行。它不影响子群集外的节点。您可以为不同的用户组分配不同的子群集以供使用。

在 Eon 模式数据库中，子群集和可扩展性是密不可分的。您经常添加、移除、停止和启动整个节点子群集，而不是单独扩展节点。

企业模式不提供子群集来隔离工作负载。您可以使用资源池和其他设置等功能，为特定查询提供优先级和对更多资源的访问权限。但是，这些功能并没有像子群集那样真正隔离工作负载。有关使用这些功能管理工作负载的说明，请参阅管理工作负载。

可扩展性

您可以通过添加或移除节点来扩展 Vertica 数据库，以满足不断变化的分析需求。在您按小时为数据库中的每个节点付费的云环境中，可扩展性通常更为重要。如果您的数据库不忙，则没有理由让未充分利用的节点花费您的资金。您可以在空闲时间（例如周末和节假日）减少数据库中的节点数量以节省资金。

对于内部部署安装，可扩展性通常不太重要。当未完全使用节点时，运行节点所涉及的额外成本有限。

企业模式数据库的扩展效率低于 Eon 模式数据库。当企业模式数据库扩展时，它必须对其数据进行重新分段（重新平衡），以便在新数量的节点之间分布。

重新平衡是一项代价高昂的操作。当扩展数据库时，Vertica 必须分解文件，并以物理方式将一定比例的数据从原始节点移动到新节点。当收缩数据库时，Vertica 必须将数据从要移除的节点中移出，并将其分布到其余节点中。在重新平衡期间，数据库不可用。此过程可能需要 12、24 甚至 36 小时才能完成，具体取决于数据库的大小。在扩展企业模式数据库后，查询应该运行得更快，因为每个节点负责的数据更少。因此，每个节点处理每个查询的工作量更少。收缩企业模式数据库通常会产生相反的效果 - 查询会运行得更慢。有关扩展企业模式数据库的详细信息，请参阅弹性群集。

Eon 模式数据库可以更有效地扩展，因为数据存储与计算资源是分开的。

当您扩展 Eon 模式数据库时，不需要对数据库数据进行重新分段。相反，附加节点订阅公共存储中预先存在的数据段（称为分片）。当扩展群集时，Vertica 会重新平衡分配给每个节点的分片，而不是以物理方式拆分数据存储并在节点之间移动。新节点准备通过从公共存储中检索数据以填充其存储库（来自公共存储的数据的本地缓存）来处理查询。在扩展时，数据库仍然可用，该过程需要几分钟而不是几小时才能完成。

如果公共存储中的分片数量等于或大于新节点数量（如上图所示），则扩展群集后查询性能会提高。每个节点负责处理较少的数据，因此在您扩展群集后，相同的查询将运行得更快。

您还可以扩展数据库以提高查询吞吐量。查询吞吐量提高了数据库并行处理的查询数量。当您的工作负载包含许多运行时间较短的查询（“仪表板查询”）时，您通常会关心查询吞吐量。要提高吞吐量，请在新的 子群集中向数据库添加更多节点。子群集将连接到它的客户端运行的查询与数据库中的其他节点隔离开来。子群集独立且并行地工作。隔离工作负载意味着您的数据库同时运行更多查询。

如果子群集包含的节点数多于公共存储中的分片数，则多个节点订阅同一个分片。在这种情况下，Vertica 使用一种称为弹性处理扩展的功能来更快地执行查询。Vertica 在订阅节点之间划分每个分片中数据的责任。每个节点只需要处理其订阅的分片中的数据子集。要处理的数据更少意味着每个节点通常会更快地完成其查询部分。这通常转化为查询更快地完成其执行。

收缩 Eon 模式数据库的工作原理类似。关闭整个子群集降低了数据库的查询吞吐量。如果您从子群集中移除节点，其余节点将订阅没有订户的任何分片。该过程很快，并且数据库在此过程中仍在运行。

可扩充性

随着您将更多数据加载到数据库中，您最终可能需要扩充其数据存储。由于 Eon 模式数据库将计算与存储分开，因此您通常会在不更改节点数量的情况下扩充其存储。

在云环境中，您通常没有存储限制。例如，AWS S3 存储桶可以存储任意数量的数据。只要您愿意支付额外的存储费用，就不必担心扩充数据库的存储。

当您安装 Eon 模式内部部署时，扩充存储的方式取决于所使用的对象存储。例如，Pure Storage FlashBlade 支持热插拔新刀片以添加额外的存储。借助此功能，您无需停机即可扩充 Eon 模式数据库中的存储。

在大多数情况下，您通常会查询数据库中的数据子集（称为工作数据集）。由于 Eon 模式对计算和存储进行解耦，让您可以根据工作数据集和所需性能而不是整个数据集调整计算能力（数据库中的节点数）。

例如，如果您正在执行时间序列分析，其中活动数据集通常是最近 30 天，则可以调整群集的大小以管理 30 天的数据。超过 30 天的数据只会在公共存储中增长。需要向 Eon 模式数据库添加更多节点的唯一原因是，为了满足额外的工作负载。另一方面，如果您想在小数据集上获得非常高的性能，则可以添加任意数量的节点以获得所需的性能。

在企业模式数据库中，节点负责存储和计算。由于计算和存储之间的紧密耦合，在企业模式数据库中扩充存储的最佳方法是添加新节点。如可扩展性部分中所述，将节点添加到企业模式数据库需要重新平衡数据库中的现有数据。

由于重新平衡对数据库造成中断，通常很少扩充企业模式数据库中的存储。当您扩充其存储时，您通常会添加大量存储以允许未来的增长。

通过添加节点来增加存储的缺点是，您可能会为群集添加不必要的计算能力。例如，假设您正在执行专注于最近数据的时间序列分析，并且当前群集为您提供了足够的查询性能来满足您的需求。但是，您需要添加额外的存储来保存历史数据。在这种情况下，将新节点添加到数据库以获得额外的存储会增加您实际上不需要的计算能力。您的查询可能会运行得更快一些。然而，更快的结果带来的微小好处可能并不能证明增加更多计算能力的成本是合理的。

2 - Eon 模式概念

Eon 模式将计算过程与数据库的公共存储层分开。这种分离使您能够将数据存储在单个位置（例如 AWS 上的 S3 或 Pure Storage），并根据您的计算需求弹性地改变连接到该位置的计算节点数。可以在不中断分析工作负载的情况下调整群集的大小，随着工作量的变化添加或移除节点。

以下主题介绍了 Eon 模式的工作原理。

2.1 - Eon 模式体系结构

Eon 模式将计算资源与数据库的存储层分开。这种分离使您能够将数据存储在单个位置。您可以根据计算需求弹性地改变连接到该位置的节点数。调整群集大小不会中断分析工作负载。

您可以在云环境中创建 Eon 模式数据库，也可以在您自己的系统上本地创建 Eon 模式数据库。

Eon 模式适用于各种需求和数据量。由于计算和存储分开，因此可以单独扩展它们。

公共存储

Eon 模式不将数据存储在本地，而是对所有数据和编录（元数据）使用单个公共存储位置。公共存储是数据库的集中式存储位置，在数据库节点之间共享。公共存储基于对象存储，例如云中的 Amazon S3 或内部部署中的 PureStorage FlashBlade 设备。无论哪种情况，Vertica 都依赖对象存储来维护数据的持久副本。

公共存储具有以下属性：

  • 与单个计算机上的磁盘存储相比，云中的公共存储更具弹性，并且不易因存储故障而导致数据丢失。

  • 任何节点都可以使用相同的路径读取任何数据。

  • 容量不受节点上磁盘空间的限制。

  • 由于数据是以公共方式存储的，因此您可以弹性扩展群集以满足不断变化的需求。如果数据本地存储在节点上，则添加或移除节点将需要在节点之间移动大量数据，以将其从要移除的节点上移出，或移动到新创建的节点上。

公共存储位置列在 STORAGE_LOCATIONS 系统表中，其中 SHARING_TYPE 为 COMMUNAL。

在公共存储中，数据被划分到称为 分片的部分。分片是 Vertica 在数据库中的节点之间划分数据的方式。节点订阅特定的分片，在节点之间平衡订阅。当加载或查询数据时，每个节点负责其订阅的分片中的数据。有关详细信息，请参阅分片和订阅。

存储库存储

公共存储的一个潜在缺点是它的速度，特别是在云环境中。从共享云位置访问数据要慢于从本地磁盘读取数据。此外，如果许多节点同时从公共存储中读取数据，则与公共存储的连接可能会成为瓶颈。为了提高数据访问速度，Eon 模式数据库中的节点维护一个称为存储库的本地磁盘数据缓存。当执行查询时，节点首先检查它需要的数据是否在存储库中。如果是，则节点使用数据的本地副本完成查询。如果数据不在存储库中，则节点从公共存储中提取数据，并在存储库中保存副本。

节点将新加载的数据存储在存储库中，然后将其发送到公共存储。有关详细信息，请参阅下面的“加载数据”。

默认情况下，Vertica 将存储库的最大大小设置为存储该存储库的文件系统的总磁盘空间的 60%。如果您愿意，可以调整存储库的大小。Vertica 将存储库的最大大小限制为包含它的文件系统的 80%。此上限可确保有足够的磁盘空间用于其他用途，例如 Vertica 在数据加载期间创建的临时文件。

每个节点还存储数据库编录的本地副本。

加载数据

在 Eon 模式下，COPY 语句通常写入节点存储库中的读取优化存储 (ROS) 文件以提高性能。COPY 语句通过分段、排序和压缩来实现高度优化。在语句提交之前，Vertica 将 ROS 文件传送到公共存储。

因为加载缓冲在执行加载的节点上的存储库中，所以存储库的大小会限制可以在单个操作中加载的数据量。除非在并行会话中执行多个加载，否则不太可能遇到此限制。

在加载时，参与节点将文件写入存储库，并将其同步发送到公共存储。还会将数据发送到订阅分片（要将数据加载到其中）的所有节点。这种在加载时向对等节点发送数据的机制可以在节点出现故障时提高性能，因为接管故障节点的对等节点的缓存已经预热。文件压缩机制（合并）将其输出文件放入缓存中，同时将它们上传到公共存储。

下图显示了执行 COPY 语句期间的数据流。

查询数据

在 Eon 模式下，Vertica 使用略有不同的流程计划查询，以合并分片机制和远程存储。Vertica 不使用固定分段方案将数据分发到每个节点，而是使用分片机制将数据分段为至少一个（通常更多）节点订阅的特定数量的分片。当优化器选择投影时，投影的布局由会话的参与订阅确定。优化器生成与企业模式中的查询计划等效的查询计划。它选择订阅每个分片的节点之一来参与查询执行。

Vertica 首先尝试使用存储库中的数据来解决查询。当存储库中的数据无法解决查询时，Vertica 将从公共存储中读取数据。当大量查询从公共存储读取数据时，您可能会看到对查询性能的影响。如果是这种情况，那么您应该考虑调整存储库的大小，或使用存储库系统表来更好地了解导致问题的原因。您可以使用 ALTER_LOCATION_SIZE 来更改存储库大小。

工作负载隔离和扩展

Eon 模式允许您定义子群集，这些子群集划分节点以相互隔离工作负载。您还可以使用子群集来确保缩减群集不会导致 Vertica 进入只读模式，以保持数据完整性。有关详细信息，请参阅子群集。

2.2 - 分片和订阅

在 Eon 模式下，Vertica 会将数据以公共方式存储在共享数据存储位置（例如，在 AWS 上运行时存储在 S3 中）。所有节点都能够访问公共存储位置中的所有数据。为了让节点划分处理查询的工作，Vertica 必须以某种方式在它们之间划分数据。它会将公共存储中的数据分成称为分片的段。数据库中的每个节点都订阅公共存储位置中的分片子集。公共存储位置中的分片类似于企业模式数据库中的分段投影集合。

当 K-Safety 为 1 或更高（高可用性）时，每个子群集中都有多个节点订阅每个分片。其中一个订户负责执行涉及分片的查询。其他订户充当备份。如果主订户关闭或停止，则另一个订户将取而代之。有关详细信息，请参阅Eon 模式数据库中的数据完整性和高可用性。

数据库中的每个分片都有一个主订户。此订户是 主节点，它通过计划分片上的 Tuple Mover 操作来维护分片中的数据。此节点可以将执行这些操作委派给数据库群集中的另一个节点。有关这些操作的详细信息，请参阅 Tuple mover。如果主订户节点停止或关闭，Vertica 会选择另一个订阅该分片的主节点作为该分片的主订户。如果订阅分片的所有主节点都关闭或停止，则数据库将进入只读模式以保持数据完整性。作为分片唯一订户的任何主节点都是 关键节点。

一种称为副本分片的特殊类型的分片存储未分段投影的元数据。副本分片存在于所有节点上。

您可以在创建数据库时定义分片的数量。为了获得最佳性能，您选择的分片数量不应大于 2× 节点数。您最多应该将分片与节点的比率限制为不大于 3:1。MC 警告您要考虑分片计数的各个方面。分片数应始终是数据库中节点数的倍数（或偶数除数）。有关详细信息，请参阅选择分片数和初始节点计数。

创建数据库后，可以使用 RESHARD_DATABASE 更改数据库中的分片数。有关详细信息，请参阅更改数据库中的分片数。

为了提高效率，Vertica 直接在数据库节点之间传输有关分片的元数据。这种点对点传输仅适用于元数据；存储在每个节点上的实际数据会根据需要从公共存储复制到节点的存储库。

2.3 - 子群集

由于 Eon 模式将计算和存储分开，因此您可以在群集中创建子群集来隔离工作。例如，您可能希望将一些节点专用于加载数据，而将其他节点专用于执行查询。或者，您可能希望为专门的用户组（他们可能有不同的优先级）创建子群集。您还可以使用子群集将节点组织成组，以便轻松地扩展和收缩群集。

Eon 模式数据库中的每个节点都必须属于一个子群集。这一要求意味着您的数据库必须始终至少有一个子群集。当您创建新的 Eon 模式数据库时，Vertica 会创建一个名为 default_subcluster 的子群集，其中包含您在创建数据库时创建的节点。如果您将节点添加到数据库而不将它们分配给子群集，Vertica 会将它们添加到默认子群集。您可以选择将另一个子群集指定为默认子群集，或者将 default_subcluster 重命名为更具描述性的名称。有关详细信息，请参阅更改子群集设置。

使用子群集进行工作隔离

数据库管理员通常关心工作负载管理。密集的分析查询可能会消耗如此多的资源，以至于它们会干扰其他重要的数据库任务（例如数据加载）。子群集通过将工作负载相互隔离来帮助您防止资源问题。

在 Eon 模式下，默认情况下，查询仅在包含启动程序节点的子群集中的节点上运行。例如，考虑下图中显示的两个子群集。如果您连接到节点 4，您的查询将在节点 4 到节点 9 上运行。

此图像显示两个子群集，一个子群集标记为“负载子群集”，包含节点 1 到节点 3。另一个子群集名为“查询子群集”，包含节点 4 到节点 8。

同样，在节点 1 上启动的查询仅在节点 1 到节点 3 上运行。

这种隔离使您可以配置数据库群集以防止工作负载相互干扰。您可以将子群集分配给特定任务，例如加载数据、执行深入分析和短时间运行的仪表板查询。您还可以为组织中的不同组创建子群集，这样他们的工作负载就不会相互干扰。您可以调整每个子群集的设置（例如资源池）以匹配其特定的工作负载。

子群集类型

有两种类型的子群集：主子群集和辅助子群集。

主子群集构成 Vertica 数据库的核心。它们负责规划公共存储中数据的维护。您的主子群集必须始终运行。如果所有主子群集都关闭，您的数据库也会关闭，因为如果没有主子群集，数据库就无法在公共存储中维护数据。

通常，您的数据库中只有一个主子群集。您可以选择拥有多个主子群集。额外的主子群集可以使您的数据库在主节点发生故障时更具弹性。但是，额外的主子群集会降低数据库的可扩展性。您通常不会从主子群集中动态添加或移除节点，也不会关闭它们来扩展数据库。在大多数情况下，一个主子群集就足够了。

辅助子群集专为动态扩展而设计：您可以根据分析需求添加和移除或启动和停止这些子群集。它们对于维护数据库数据不是必需的。因此，您可以轻松地添加、移除和扩展或收缩辅助子群集，而不会影响数据库正常运行的能力。

子群集中的节点从包含它们的子群集继承其主或辅助状态；主子群集包含主节点，辅助子群集包含辅助节点。

子群集类型和弹性扩展

主子群集和辅助子群集之间最重要的区别在于，它们对 Vertica 如何确定数据库是否为 K-Safe 和是否具有 仲裁的影响。当确定数据库中的所有分片是否都有订阅节点时，Vertica 仅考虑主子群集中的节点。当确定数据库中是否有一半以上的节点正在运行时，它也仅考虑主节点（也称为具有主节点的仲裁）。如果不满足上述任一条件，数据库将进入只读模式以防止数据损坏。有关 Vertica 如何维护数据完整性的详细信息，请参阅 Eon 模式数据库中的数据完整性和高可用性。

当确定数据库是否具有分片覆盖率或节点仲裁时，Vertica 不考虑辅助节点。这一事实使得辅助子群集非常适合管理您计划动态扩展和减少的节点组。您可以停止或移除辅助节点的整个子群集，而无需强制数据库进入只读模式。

K-safe 数据库的最小子群集大小

在 K-safe 数据库中，子群集必须至少具有三个节点才能运行。每个子群集都尝试维护对数据库中所有分片的订阅。如果一个子群集的节点少于三个，则它无法保持冗余分片覆盖率，其中每个分片在子群集中至少有两个订户。如果没有冗余覆盖，子群集在丢失节点时将无法继续处理查询。如果您尝试在 K-safe 数据库中具有三个以下节点的子群集中重新平衡分片，Vertica 会返回错误。

另请参阅

2.4 - 弹性

弹性是指通过添加或移除节点来调整数据库适应不断变化的工作负载需求的能力。当数据库遇到高需求时，可以添加新节点或启动已停止的节点，以增加可用的计算量。当数据库遇到较低需求时（例如在节假日或周末），可以停止或终止节点以节省资金。还可以随着数据库需求的增长而逐渐添加节点。

Eon 模式数据库中的所有节点都属于一个子群集。通过选择哪些子群集获得新节点，可以影响新节点对数据库的影响。将节点添加到数据库时，可以实现两个目标：

  • 提高查询吞吐量：更高的吞吐量意味着数据库同时处理更多查询。当您有“仪表板查询”（许多运行时间相对较短的查询）工作负载时，您通常希望提高吞吐量。在这种情况下，加快单个查询的处理速度不如让更多查询并行运行重要。

  • 提高查询性能：更高的查询性能意味着复杂的深入分析查询完成得更快。

针对查询吞吐量进行扩展

要针对查询吞吐量进行扩展，请在一个或多个新 子群集中向数据库添加额外的节点。子群集独立处理查询：查询仅在包含启动程序节点的子群集中的节点上运行。通过添加一个或多个子群集，数据库可以同时处理更多查询。为了获得最佳性能，请向每个新子群集中添加与数据库中的分片数量相同的节点数量。例如，如果数据库中有 6 个分片，则向您创建的每个新子群集中添加 6 个节点。

为了利用新子群集提供的更高吞吐量，客户端必须连接到它们。要确保用户利用您为扩展吞吐量而添加的子群集，最佳方法是创建连接负载均衡策略，将客户端连接分散到所有这些子群集中的所有节点上。有关详细信息，请参阅连接负载均衡策略。

子群集还将节点组织到可以轻松地一起停止或启动的组中。此功能使扩展和收缩数据库更加轻松。有关详细信息，请参阅启动和停止子群集。

针对查询性能进行扩展

要提高子群集中单个查询的性能，请向其中添加更多节点。当有更多的计算能力可用于处理查询时，查询的执行速度会更快。

如果子群集中的节点数少于数据库中的分片数，则添加节点特别有效。在这种情况下，节点负责处理多个分片中的数据。当添加更多节点时，新添加的节点会接管一些分片的责任。由于要处理的数据变少，因此每个节点可以更快地完成其查询部分，从而提高整体性能。为了获得最佳性能，请将子群集中的节点数设置为数据库中分片数的偶数除数（或等于分片数）。例如，在 12 分片数据库中，请将子群集中的节点数设置为 3、6 或 12。

您可以通过添加比数据库中的分片更多的节点来进一步提高查询性能。当节点数量超过分片数量时，子群集中的多个节点订阅同一个分片。在这种情况下，当处理查询时，Vertica 使用一种称为弹性处理扩展 (ECS) 的功能让子群集中的所有节点都参与查询。ECS 将每个分片中的数据子集分配给分片的订户。例如，在一个三分片数据库的六节点子群集中，每个分片有两个订户。在查询期间，ECS 为每个订户分配分片中一半的数据进行处理。在大多数情况下，由于要处理的数据更少，节点可以更快地完成查询的执行。当向子群集中添加比分片数更多的节点数时，请将节点数设置为分片数的倍数，以确保均匀分布。例如，在三分片数据库中，将子群集中的节点数设置为 6、9、12，依此类推。

对不同的查询类型使用不同的子群集

您不必在数据库中选择一种弹性形式，而舍弃另一种形式。您可以创建一组子群集用于提高查询吞吐量，并创建一个或多个子群集用于提高查询性能。两种子群集类型之间的区别主要在于您创建的子群集数以及它们包含的节点数。要提高吞吐量，请添加多个子群集，其中包含的节点数等于或小于数据库中的分片数。添加的子群集越多，实现的吞吐量就越大。要提高查询性能，请添加一个或多个子群集，其中节点数是数据库中分片数的倍数。

创建一组子群集后，必须根据将运行的查询类型，让客户端连接到正确的子群集。对于频繁执行简单仪表板查询的客户端，请创建一个连接负载均衡策略，以将客户端连接到吞吐量扩展子群集中的节点。对于运行更复杂分析查询的客户端，请创建另一个负载均衡策略，以将客户端连接到性能扩展子群集中的节点。

有关扩展 Eon 模式数据库的详细信息，请参阅扩展 Eon 模式数据库。

2.5 - Eon 模式数据库中的数据完整性和高可用性

Eon 模式数据库的 主子群集中的节点负责维护数据库中的数据。这些节点（统称为数据库的 主节点）计划用于管理分片中数据的 Tuple Mover 合并操作。如果它们是执行这些操作的最佳候选者，它们也可以执行这些操作（请参阅 Eon 模式数据库中的 Tuple Mover）。

主节点可以分布在多个主子群集中 - 它们一起协同工作以维护分片中的数据。主节点的运行状况是数据库继续正常运行的关键。

辅助子群集中的节点不计划 Tuple Mover 操作。如果主节点将 Tuple Mover 分配给它们，它们也可以执行 Tuple Mover 合并操作。您的数据库群集可能会丢失其所有辅助节点，但仍会维护分片中的数据。

维护数据完整性是数据库的首要目标。如果数据库丢失了太多主节点，将无法安全地处理数据。在这种情况下，它会进入只读模式，以防止数据不一致或损坏。

高可用性（即使个别节点丢失，数据库也能继续运行）是 Vertica 的另一个目标。它具有多种冗余功能，可帮助其防止停机。启用这些功能后，即使数据库丢失一个或多个主节点，它仍会继续运行。

数据库继续正常运行有两个要求：维护仲裁和维护分片覆盖率。

维护仲裁

对于 Eon 模式数据库中的主节点，基本要求是维护主节点的 仲裁始终运行。为了维护仲裁，必须有一半以上的主节点（50% 加 1）处于运行状态。例如，在具有 6 个主节点的数据库中，必须至少有 4 个主节点处于运行状态。如果一半或更多主节点关闭，数据库将进入只读模式，以防止潜在的数据完整性问题。在具有 6 个主节点的数据库中，如果数据库丢失 3 个或更多主节点，则数据库将进入只读状态。请参阅下面的只读模式。

Vertica 在确定数据库是否具有仲裁时，仅对当前属于数据库的主节点进行计数。移除主节点不会导致仲裁丢失。在移除过程中，Vertica 会调整节点计数以防止丢失仲裁。

Eon 模式数据库必须至少有一个主节点才能运行。在大多数情况下，它需要多个主节点。请参阅下面的 Eon 模式数据库操作的最低节点要求。

维护分片覆盖率

为了继续处理数据，数据库必须能够维护其分片中的数据。要维护数据，每个分片必须有一个订阅主节点，负责在其上运行 Tuple Mover。此要求称为具有分片覆盖率。如果一个或多个分片没有主节点维护其数据，则数据库将丢失分片覆盖率并进入只读模式（如下所述），以防止可能出现数据完整性问题。

衡量 Eon 模式数据库对主节点丢失有多大弹性的度量指标称为 K-safety 级别。K 值是 Eon 模式数据库群集维护的冗余分片订阅数。它还表示数据库中可以发生故障但仍能够安全运行的主节点的数量。在许多情况下，数据库可能会丢失超过 K 个节点，但仍然可以继续正常运行，只要它维护分片覆盖率。

Vertica 建议始终将数据库的 K-safety 值设置为 1 (K=1)。在 K=1 的数据库中，每个分片都有两个订户：一个负责分片的主订户，另一个是在主订户丢失时可以补位的辅助订户。主订户负责对分片中的数据运行 Tuple Mover。辅助订户维护分片编录元数据的副本。以便在主订户丢失时可以补位。

如果分片的主订户失败，则辅助订户会补位主订户。因为它没有为其辅助订阅维护单独的存储库，所以辅助订户始终直接访问公共存储中的分片数据。在辅助订户补位主订户时，这种直接访问会影响数据库的性能。因此，请始终尽快重新启动或替换已关闭的主节点。

对于 K=1 数据库中的主订户和辅助订户，丢失单个主节点不会影响数据库处理和维护数据的能力。但是，如果辅助订户在补位主订户时失败，则数据库将丢失分片覆盖率，并被迫进入只读模式。

弹性 K-safety

Vertica 使用一种称为弹性 K-safety 的功能来帮助限制分片覆盖率丢失的可能性。默认情况下，如果分片的主订户或辅助订户失败，Vertica 会为该分片订阅一个额外的主节点。建立此订阅需要一些时间，因为新订阅的节点必须获取分片元数据的副本。如果分片的唯一订户在新订户获取分片元数据时失败，则数据库将丢失分片覆盖率并可能关闭。一旦新订阅的节点获得元数据的副本，它就能够在另一个订户失败时接管分片的维护。此时，您的数据库再次拥有两个分片订户。

一旦关闭的节点恢复并重新加入子群集，Vertica 便会移除它为弹性 K-safety 添加的订阅。所有节点重新加入群集后，分片订阅将与节点丢失之前相同。

借助弹性 K-safety，您的数据库便可以在逐渐丢失主节点直至丢失仲裁的过程中设法维护分片覆盖率。只要新订阅的节点有足够的时间收集分片的元数据，您的数据库便能够维护分片覆盖率。但是，如果在新的主节点完成订阅分片的过程之前，数据库失去了分片的主订户和辅助订户，那么数据库仍然可能由于分片覆盖率丢失而被迫进入只读模式。

数据库只读模式

如果数据库丢失仲裁或主分片覆盖率，它将进入只读模式。此模式可防止当太多节点关闭或无法访问数据库中的其他节点时可能导致的潜在数据损坏。只读模式可防止对数据库进行需要更新全局编录的更改。

只读模式下的 DML 和 DDL

在只读模式下，更改全局编录的语句（例如大多数 DML 和 DDL 语句）会失败，并显示错误消息。例如，当数据库处于只读模式时执行 CREATE TABLE 等 DDL 语句会导致以下错误：

=> CREATE TABLE t (a INTEGER, b VARCHAR);
ERROR 10428:  Transaction commit aborted since the database is currently in read-only mode
HINT:  Commits will be restored when the database restores the quorum

COPY 等 DML 语句返回不同的错误。Vertica 会在它们执行任何工作之前停止它们的执行：

=> COPY warehouse_dimension from stdin;
ERROR 10422:  Running DML statements is not possible in read-only mode
HINT:  Running DMLs will be restored when the database restores the quorum

通过提前返回错误，Vertica 可避免执行加载数据所需的所有工作，在尝试提交事务时便会失败。

不影响全局编录的 DDL 和 DML 语句仍然有效。例如，在数据库处于只读模式时，可以创建一个本地临时表并将数据加载到其中。

只读模式下的查询

查询可以在具有分片覆盖率的任何子群集上运行。例如，假设您有一个 Eon 模式数据库，其中包含一个 3 节点主子群集和一个 3 节点辅助子群集。如果两个主节点出现故障，数据库将丢失仲裁并进入只读模式。主子群集也会丢失分片覆盖率，因为它的两个节点已关闭。剩余的一个节点没有订阅至少部分分片。在这种情况下，剩余主节点上的查询（某些系统表查询除外）始终会失败：

=> SELECT * FROM warehouse_dimension;
ERROR 9099:  Cannot find participating nodes to run the query

辅助子群集仍然具有分片覆盖率，因此可以对其执行查询。

监控只读模式

除了注意到 DML 和 DDL 语句返回错误之外，还可以通过监控系统表来确定数据库是否已进入只读模式：

  • NODES 系统表具有一个名为 is_readonly 的列，当数据库处于只读模式时，该列对所有节点都变为 true。

    => SELECT node_name, node_state, is_primary, is_readonly, subcluster_name FROM nodes;

      node_name       | node_state | is_primary | is_readonly |  subcluster_name
----------------------+------------+------------+-------------+--------------------
 v_verticadb_node0001 | UP         | t          | t           | default_subcluster
 v_verticadb_node0002 | DOWN       | t          | t           | default_subcluster
 v_verticadb_node0003 | DOWN       | t          | t           | default_subcluster
 v_verticadb_node0004 | UP         | f          | t           | analytics
 v_verticadb_node0005 | UP         | f          | t           | analytics
 v_verticadb_node0006 | UP         | f          | t           | analytics
(6 rows)

  • 当数据库进入只读模式时，数据库中仍在运行的每个节点都会记录一个群集只读事件（事件代码 20）。您可以通过查询事件监控系统表（例如 ACTIVE_EVENTS）找到这些事件：

    => \x
Expanded display is on.

=> SELECT * FROM ACTIVE_EVENTS WHERE event_code = 20;
-[ RECORD 1 ]-------------+--------------------------------------------------------------------------
node_name                 | v_verticadb_node0001
event_code                | 20
event_id                  | 0
event_severity            | Critical
event_posted_timestamp    | 2021-11-22 15:57:24.514475+00
event_expiration          | 2089-12-10 19:11:31.514475+00
event_code_description    | Cluster Read-only
event_problem_description | Cluster cannot perform updates due to quorum loss and can only be queried
reporting_node            | v_verticadb_node0001
event_sent_to_channels    | Vertica Log
event_posted_count        | 1
-[ RECORD 2 ]-------------+--------------------------------------------------------------------------
node_name                 | v_verticadb_node0004
event_code                | 20
event_id                  | 0
event_severity            | Critical
event_posted_timestamp    | 2021-11-22 15:57:24.515022+00
event_expiration          | 2089-12-10 19:11:31.515022+00
event_code_description    | Cluster Read-only
event_problem_description | Cluster cannot perform updates due to quorum loss and can only be queried
reporting_node            | v_verticadb_node0004
event_sent_to_channels    | Vertica Log
event_posted_count        | 1
-[ RECORD 3 ]-------------+--------------------------------------------------------------------------
node_name                 | v_verticadb_node0005
event_code                | 20
event_id                  | 0
event_severity            | Critical
event_posted_timestamp    | 2021-11-22 15:57:24.515019+00
event_expiration          | 2089-12-10 19:11:31.515019+00
event_code_description    | Cluster Read-only
event_problem_description | Cluster cannot perform updates due to quorum loss and can only be queried
reporting_node            | v_verticadb_node0005
event_sent_to_channels    | Vertica Log
event_posted_count        | 1
-[ RECORD 4 ]-------------+--------------------------------------------------------------------------
node_name                 | v_verticadb_node0006
event_code                | 20
event_id                  | 0
event_severity            | Critical
event_posted_timestamp    | 2021-11-22 15:57:24.515172+00
event_expiration          | 2089-12-10 19:11:31.515172+00
event_code_description    | Cluster Read-only
event_problem_description | Cluster cannot perform updates due to quorum loss and can only be queried
reporting_node            | v_verticadb_node0006
event_sent_to_channels    | Vertica Log
event_posted_count        | 1

    请参阅监控事件。

从只读模式恢复

要从只读模式恢复，请重新启动关闭的节点。重新启动节点即可解决导致数据库进入只读模式的仲裁丢失或主分片覆盖率丢失的问题。

一旦关闭的节点重新启动并重新加入数据库，Vertica 便会在处于只读模式的节点上重新启动。为了让节点能够重新订阅其分片，必须执行此步骤。在此重新启动期间，与这些节点的客户端连接将断开。例如，通过 vsql 连接到 Vertica 正在重新启动的节点之一的用户会看到以下消息：

server closed the connection unexpectedly
    This probably means the server terminated abnormally
    before or while processing the request.
The connection to the server was lost. Attempting reset: Succeeded.

在 Vertica 重新启动时，使用 vsql 连接到节点的用户会看到以下消息：

vsql: FATAL 4149:  Node startup/recovery in progress. Not yet ready
to accept connections

Vertica 在节点上重新启动后，数据库将恢复正常运行。

当 Vertica 在 Eon 模式数据库中设置 K-safety 值时

当您的数据库中有三个或更多主节点时，Vertica 会自动将数据库的 K-safety 设置为 1 (K=1)。它还会自动配置分片订阅，以便每个节点都可以充当另一个节点的备份，如维护分片覆盖率中所述。

此行为与企业模式数据库不同，在企业模式数据库中，您必须设计数据库的物理架构以满足多个标准，然后才能让 Vertica 将数据库标记为 K-safe。有关详细信息，请参阅下面的企业模式和 Eon 模式 K-safe 设计之间的差异。

Eon 模式数据库操作的最低节点要求

数据库的 K-safety 级别决定了它必须具有的最小主节点数：

  • 当 K=0 时，数据库必须至少具有 1 个主节点。将 K 设置为 0 允许您拥有单节点 Eon 模式数据库。请注意，在 K=0 数据库中，主节点丢失将导致数据库进入只读模式。
  • 当 K=1（最常见的情况）时，数据库必须至少具有三个主节点。此数量的主节点让 Vertica 能够在主节点出现故障时维护数据完整性。
  • 如果要手动将 K-safe 值设置为 2（请参阅下面的企业模式和 Eon 模式 K-safe 设计之间的差异），则必须至少具有 5 个主节点。

如果群集将会低于数据库 K-safety 设置的下限，Vertica 会阻止您移除主节点。如果要移除处于此下限的数据库中的节点，则必须使用 MARK_DESIGN_KSAFE 函数降低 K-safety 级别，然后调用 REBALANCE_SHARDS。

关键节点和子群集

Vertica 将数据库中丢失便会导致数据库进入只读模式的任何节点或子群集指定为关键节点或子群集。例如，在 Eon 模式数据库中，当主节点出现故障时，对其分片具有辅助订阅的节点将接管分片的数据维护。这些节点变为关键节点。它们的丢失将导致数据库丢失分片覆盖率，并被迫进入只读模式。

Vertica 在两个系统表中维护关键节点和子群集列表： CRITICAL_NODES 和 CRITICAL_SUBCLUSTERS。在停止节点或子群集之前，请检查这两个表以确保要停止的节点或子群集不是关键节点或子群集。

企业模式和 Eon 模式 K-safe 设计之间的差异

在企业模式数据库中，可以使用 MARK_DESIGN_KSAFE 函数在数据库中启用高可用性。在设计了数据库的物理架构以满足 K-safe 设计的所有要求（通常，通过运行 Database Designer）之后，便可以调用此函数。如果在物理架构不支持传递给 MARK_DESIGN_KSAFE 的 K-safety 级别时尝试将数据库标记为 K-safe，则会返回错误。有关详细信息，请参阅为 K-safety 安全设计分段投影。

在 Eon 模式下，您不需要使用 MARK_DESIGN_KSAFE，因为当您具有三个或更多主节点时，Vertica 会自动将数据库设置为 K-safe。您可以使用此函数更改数据库的 K-safety 级别。在 Eon 模式数据库中，此函数更改 Vertica 配置分片订阅的方式。您可以使用所需的任何 K-safety 级别调用 MARK_DESIGN_KSAFE。仅当您调用 REBALANCE_SHARDS 来更新数据库中节点的分片订阅时，它才会生效。

2.6 - 停止、启动、终止和恢复 Eon 模式数据库群集

如果您在一段时间内不需要 Eon 模式数据库，则可以选择停止或终止其群集。当在云环境中运行时，停止或终止群集可以为您节省资金。

停止和启动数据库群集

当您停止数据库群集时，会关闭群集中的节点。关闭群集是除了仅关闭数据库之外的额外步骤。当您在云环境中关闭群集时，节点的实例不再运行，但仍在云平台中定义。当需要再次使用群集和数据库时，可以快速重新启动它。

当您在中短期内不需要数据库群集时，停止它是最好的选择。例如，如果在周末或节假日没有人访问您的数据库，则可以考虑停止群集。

当在云环境中关闭数据库群集时，可以节省资金。停止的群集不会消耗昂贵的 CPU 资源。但是，停止的群集仍然会花费您的资金。如果您为节点配置了永久性本地存储，您的云提供商通常仍会收取少量费用来维护该存储空间。

终止和恢复数据库群集

终止数据库群集会释放数据库群集节点使用的资源。

在云平台上，终止数据库群集会删除节点的虚拟机实例。数据库的数据和编录仍然存储在公共存储中。您可以通过恢复数据库来重新启动它。当恢复数据库时，您需要配置一个新的数据库群集，并将其配置为使用存储在公共存储中的数据库数据和元数据。

在内部部署 Eon 模式数据库中，终止数据库群集通常意味着关闭数据库，然后重新调整运行节点的硬件的用途。

当您长时间不需要数据库时（或者如果您不确定是否会再次需要数据库），终止数据库群集是最佳选择。只要您不删除公共存储位置，您就可以通过恢复数据库来让它再次运行。

要恢复数据库，您需要创建一个新的 Vertica Eon 模式群集，并将其配置为使用数据库的公共存储位置。在云中恢复数据库的最简单方法是，使用管理控制台。它可以为您配置一个新的 Eon 模式群集，然后在其中恢复数据库。

恢复数据库比启动停止的数据库需要更长的时间。即使您使用 MC 自动执行该过程，配置一组新节点所需的时间也比重新启动停止的节点要长得多。当新节点首次启动时，它们必须从头开始从公共存储中加载数据。

当数据库的节点具有永久性本地存储时，终止数据库群集可以比简单地停止数据库节省更多资金。云提供商通常会针对节点上的永久性本地存储所占用的空间向您收取少量经常性费用。

另请参阅

3 - 企业模式概念

在企业模式 Vertica 数据库中，物理体系结构设计为将数据移动到尽可能靠近计算资源的位置。这种体系结构不同于在 Eon 模式概念中描述的以 Eon 模式运行的群集。

企业模式数据库中的数据分布在数据库中的各节点中。理想情况下，数据均匀分布，以确保每个节点具有相等数量的分析工作负载。

混合数据存储

在企业模式下运行时，Vertica 将数据库中的数据存储在读取优化存储 (ROS) 容器中。ROS 数据经过分段、排序和压缩，以实现高度优化。为了避免数据在许多小型 ROS 容器之间碎片化，Vertica 会定期执行合并操作，将 ROS 数据合并到更少更大的容器中。

数据冗余

在企业模式下，Vertica 数据库的每个节点都在本地存储和操作数据。如果没有某种形式的冗余，节点丢失将迫使数据库关闭，因为它的某些数据将无法用于查询。

您通常选择让企业模式数据库冗余存储数据，以防止在节点关闭时出现数据丢失和服务中断。有关详细信息，请参阅企业模式数据库中的 K-safety。

3.1 - 企业模式数据库中的 K-safety

K-safety 设置企业模式数据库群集中的容错能力。值 K 表示复制数据库群集中的数据的次数。这些副本允许其他节点接管任何故障节点的查询处理。

在 Vertica 中，K 值可以为零 (0)、一 (1) 或二 (2)。如果 K-safety 为一 (K=1) 的数据库失去一个节点，该数据库可继续正常运行。其他节点发生故障时，只要群集中至少有一个其他节点拥有故障节点的数据副本，数据库都可以继续运行。将 K-safety 增加到 2 可确保 Vertica 在任何两个节点发生故障时仍可以正常运行。当一个或多个故障节点返回并成功恢复时，它们可以再次参加数据库操作。

K-safety 为 1 的数据库中有最多一半的节点出现故障可能不会导致数据库关闭。只要每个故障节点上的数据在其他活动节点上可用，数据库就继续运行。

伙伴实例投影

为了确定 K-safety 值，Vertica 会创建伙伴实例投影，这些投影是分布在数据库节点上的分段投影的副本。（请参阅分段投影和未分段投影。）Vertica 会将包含相同数据的段分布到不同的节点上。这可确保在某个节点下线时，其中的所有数据都能在余下的节点中找到。

K-Safety 示例

上图显示了 K-safety 级别为 1 的五节点群集。每个节点都包含下一个高编号节点中存储的数据的伙伴实例投影（节点 1 包含节点 2 的伙伴实例投影，节点 2 包含节点 3 的伙伴实例投影，依此类推）。如果任何节点发生故障，数据库将继续运行。数据库的性能将下降，因为其中一个节点必须处理自己的工作负载和故障节点的工作负载。

下图显示了节点 2 发生故障的情况。在此情况下，节点 1 将处理节点 2 的工作，因为它含有节点 2 数据的副本。节点 1 也将继续执行自身的处理工作。此时，数据库容错能力会从 1 降至 0，因为再有一个节点故障将导致数据库变得不安全。在此示例中，无论是节点 1 还是节点 3 出现故障，数据库都会变得不安全，因为此时并非所有数据都可用。如果节点 1 发生故障，节点 2 的数据将不再可用。如果节点 3 发生故障，其数据将不再可用，因为节点 2 已关闭，无法使用伙伴实例投影。在这种情况下，节点 1 和节点 3 会被视为关键节点。在 K-safety 级别为 1 的数据库中，包含故障节点伙伴实例投影的节点，以及其伙伴实例投影位于故障节点上的节点，始终会成为关键节点。

节点 2 下线后，如果节点 4 或节点 5 发生故障，数据库仍具有全部可用数据。下图显示了节点 4 发生故障时节点 3 可以使用其伙伴实例投影来补位。在此情况下，如果再有节点发生故障，数据库将关闭，因为群集中的所有节点现在都成为关键节点。此外，如果再有一个节点发生故障，半数或半数以上的节点将关闭，无论所有数据是否可用，都需要 Vertica 自动关闭。

在 K-safety 级别为 2 的数据库中，节点 2 和群集中的任何其他节点之一发生故障时，数据库仍会继续运行。下图显示了群集中的每个节点都包含其前后邻居的伙伴实例投影（例如，节点 1 包含节点 5 和节点 2 的伙伴实例投影）。在此情况下，节点 2 和节点 3 发生故障时，数据库仍会继续运行。此时节点 1 会补位节点 2，而节点 4 会补位节点 3。由于要求群集中有半数或半数以上的节点可用才能使数据库继续运行，因此，如果节点 5 发生故障，群集将无法继续运行，即使节点 1 和节点 4 都具有节点 5 数据的伙伴实例投影。

监控 K‑safety

可以访问系统表以监控和记录 Vertica 操作的各个方面。使用 SYSTEM 表可以监控与 K-safety 相关的信息，例如：

  • NODE_COUNT：群集中的节点数

  • NODE_DOWN_COUNT：群集中当前已关闭的节点数

  • CURRENT_FAULT_TOLERANCE：K‑safety 级别

3.2 - 使用投影的高可用性

为确保由三个或更多节点构成的数据库群集的高可用性和恢复能力，Vertica 会：

  • 复制未分段的小型投影

  • 为已分段的大型投影创建伙伴实例投影。

复制（未分段的投影）

创建投影时，Database Designer 会复制它们，从而在数据库中的所有节点上创建和存储这些投影的副本。

复制可确保：

  • 将查询执行工作分散到多个节点上。

  • 实现高可用性和恢复能力。在 K-safe 数据库中，复制的投影用作伙伴实例投影。这意味着，您可以使用任何节点上复制的投影进行恢复。

下图显示了在三节点群集上复制的两个投影 B 和 C。

伙伴实例投影（分段投影）

Vertica 会创建伙伴实例投影，这些投影是分布在数据库节点上的分段投影的副本（请参阅分段投影）。Vertica 会将包含相同数据的段分布到不同的节点上。这可确保在某个节点下线时，其中的所有数据都能在余下的节点中找到。Vertica 通过使用偏移量将各个段分布到不同的节点上。例如，构成第一个伙伴实例投影 (A_BP1) 的段会与投影 A 偏移一个节点，而第二个伙伴实例投影 (A_BP2) 的段会与投影 A 偏移两个节点。

下图显示了三节点群集中名为 A 的投影及其伙伴实例投影 A_BP1 和 A_BP2 的分段。

下图显示了 Vertica 如何使用偏移量来确保每个节点都有一组完整的投影数据。

结果集的存储方式

Vertica 会在群集中的所有节点上复制表列，以确保高可用性和恢复能力。因此，如果一个节点在 K-Safe 环境中出现故障，数据库会使用其余节点上的重复数据继续运行。一旦故障节点恢复正常，它便会自动查询其他节点，从而恢复缺失的对象和数据。

Vertica 会对数据进行压缩和编码，以大大减少存储空间。它也会尽可能使用编码数据执行操作，以避免解码开销。这种结合了压缩和编码的方法可在优化磁盘空间的同时最大限度地提高查询性能。

Vertica 将表列存储为投影。借此，您可以针对特定的查询和查询集来优化存储的数据。Vertica 提供了两种数据存储方法：

  • 建议对大型表（事实表和大型维度表）进行投影分段

  • 对其余表建议复制。

3.3 - 使用容错组的高可用性

使用容错组可减少物理环境中固有的关联故障带来的风险。关联故障是指一个故障导致两个或更多节点发生故障。例如，因为共享资源问题（如断电、网络问题或存储）便可能发生此类故障。

Vertica 可通过在群集上定义容错组将发生关联故障的风险降至最低。然后，Vertica 使用容错组将数据段分布到整个群集中，以便在发生单个故障事件时数据库仍能继续运行。

Vertica 支持使用具有不同形状和大小的复杂、层次结构容错组。可以将容错组与弹性群集和大型群集布置集成在一起，以增加群集的灵活性和可靠性。

通过容错组使 Vertica 了解群集拓扑

还可以通过容错组使 Vertica 了解运行 Vertica 数据库的群集的拓扑。当使用 Terrace 路由时，需要使 Vertica 了解群集拓扑，这可以显著减少大型群集数据库上的消息缓冲。

自动容错组

配置包含 120 个或更多节点的群集时，Vertica 会围绕控制节点自动创建容错组。控制节点是管理 Spread（控制消息传递）的一个群集节点子集。Vertica 会将共用一个控制节点的节点放在同一个容错组中。有关详细信息，请参阅大型群集。

用户定义的容错组

在以下情况下定义您自己的容错组：

  • 群集布局可能会出现关联故障。

  • 您希望影响哪些群集主机管理控制消息传递。

示例群集拓扑

下图用示例介绍了单个群集上配置的层次结构容错组：

  • 容错组 FG–A 仅包含节点。

  • 容错组 FG-B（父）含有子容错组 FG-C 和 FG-D。每个子容错组也含有节点。

  • 容错组 FG–E（父）含有子容错组 FG-F 和 FG-G。父容错组 FG–E 也含有节点。

如何创建容错组

定义容错组之前，必须充分了解物理群集布局。容错组需要精心规划。

要定义容错组，请创建群集布置的输入文件。然后，将该文件传递到 Vertica 提供的脚本，该脚本会返回您需要运行的 SQL 语句。有关详细信息，请参阅容错组。