为 Eon 模式配置 Vertica 群集
在 Eon 模式下运行 Vertica 可将群集大小从数据量中分离出来,让您可以独立于存储需求来配置计算需求。在决定使用哪种类型的实例以及 Eon 模式群集的大小时,您必须考虑许多因素。
开始操作之前
Vertica Eon 模式可在云和本地工作。作为 Vertica 管理员,设置在 Eon 模式下运行的生产群集时,您必须决定要使用的虚拟或物理硬件以满足您的需求。本主题为在 Eon 模式下运行的 Vertica 数据库选择服务器类型和群集大小提供指南和最佳实践,并假设您对 Eon 模式架构和概念(例如 公共存储、 存储库和 分片)具有基本的了解。如果需要增加了解程度,请参阅 Eon 模式体系结构。
群集大小概述
由于 Eon 模式将数据存储与节点的计算能力分开,因此选择群集大小比选择企业模式数据库更复杂。通常,您选择的节点基数将构成一个或多个 主子群集。这些子群集包含始终在数据库中运行的节点。您通常会将它们用于数据加载和执行 DDL 语句等工作负载,很少会动态更改这些子群集的大小。由于需要额外的计算资源来执行查询,因此您可以向数据库中添加一个或多个节点子群集(通常是 辅助子群集)。
在为 Eon 模式选择实例和调整群集大小时,请考虑数据库将要处理的工作数据大小。这是大多数查询会处理的数据量。例如,假设您的数据库存储的是销售数据。如果您的数据库上运行的大多数查询对过去一两个月的销售情况进行分析以创建有关销售趋势的报告,那么工作数据大小就是您通常在几个月内加载的数据量。
选择实例或物理硬件
根据工作负载的复杂性和预期并发性,请选择具有足够 CPU 和内存的物理或虚拟硬件。对于生产群集,Vertica 建议对 Eon 模式数据库中的虚拟或物理节点进行以下最低配置:
-
16 核
-
128 GB RAM
-
2 TB 本地存储
注意
上述规格只是最低建议值。您应考虑根据工作负载和正在处理的数据量增加这些规格值。Eon 模式数据库群集中必须至少有 3 个节点。
有关基于云的 Eon 模式数据库实例的具体建议,请参阅:
确定本地存储要求
对于虚拟和物理硬件,您必须确定节点所需的本地存储量。在 Eon 模式下,数据库数据的最终副本驻留在公共存储中。此存储由基于云的对象存储(如 AWS S3)或本地对象存储(如 Pure Storage FlashBlade 设备)提供。
即使数据库的数据存储在公共存储中,节点也仍需一些本地存储。Eon 模式数据库中的节点会出于三种用途使用本地存储:
-
存储库存储:要以最短的时间响应频繁执行的查询,请提供足够大的存储库以在数据压缩后保存工作数据集。将工作数据大小除以子群集中拥有的节点数,可以估计出子群集中每个节点所需的存储库大小。请参阅下面的选择分片数和初始节点数,以了解您希望在初始数据库子群集中拥有的节点数量。如果您希望动态扩展群集,请根据您预计在子群集中拥有的最小节点数来估计存储库大小。
还需考虑在调整存储库大小时一次加载的数据量。加载数据时,Vertica 会默认将未提交的 ROS 文件写入到存储库中,然后再将文件上传到公共存储。如果存储库中的可用空间不足,Vertica 会从存储库中逐出文件以便为新文件腾出空间。
如果您尝试在单个事务中加载的数据量大于子群集中所有存储库的总大小,则数据加载将失败。要使加载的数据量多于子群集的组合存储库中的空间,请将 UseDepotForWrites 设置为 0。此配置参数会告知 Vertica 将数据直接加载到公共存储中。
-
数据存储:数据存储位置可保存属于临时表的文件和溢出到磁盘的排序运算符中的临时数据。将数据加载到 Vertica 时,排序运算符可能会溢出到磁盘。根据加载的大小,Vertica 可能会在多个合并阶段执行排序。并发加载到 Vertica 的数据量不能大于所有节点之间的临时存储位置大小之和的一半。
-
编录存储。编录大小取决于每个分片的数据库对象数和每个节点的分片订阅数。
Vertica 建议每个节点的最小本地存储容量为 2 TB,其中 60% 会为存储库保留,其他 40% 由编录和数据位置共享。如果您确定每个节点需要大于 1.2 TB 的存储库(即 2 TB 的 60%),请添加多于此最低建议值的存储空间。您可以使用以下公式计算所需的空间:
例如,假设压缩工作数据大小为 24 TB,并且您希望拥有包含 3 个节点的初始主子群集。在等式中使用这些值所计算出的结果为 13.33 TB:
选择分片数和初始节点数
分片是 Vertica 如何在节点之间拆分公共存储中数据的责任。子群集中的每个节点需要至少订阅公共存储中的一个分片。在查询、数据加载和其他数据库任务期间,每个节点负责其订阅的分片中的数据。有关详细信息,请参阅分片和订阅。
分片与节点之间的关系是指在为数据库选择分片数量时,您必须考虑数据库中拥有的节点数。
创建数据库时设置初始分片数。如果将来群集大小或使用模式发生变化,您可以调用 RESHARD_DATABASE 来更改分片数量。有关详细信息,请参阅更改数据库中的分片数。
初始节点数是您核心主子群集中拥有的节点数。分片数应始终是节点数的倍数或除数。这样可确保分片在节点之间平均分配。例如,在一个六分片数据库中,您应该拥有包含两个、三个、六个或六的倍数个节点的子群集。如果分片数不是节点数的除数或倍数,则分片订阅不会均匀地分布在各个节点上。这会导致某些节点的负载比其他节点更重。
注意
在节点数是分片数倍数的数据库中,子群集将使用 Elastic Crunch Scaling (ECS) 将分片覆盖率平均分配给两个或更多节点。有关详细信息,请参阅使用 Elastic Crunch Scaling 提高查询性能。在选择分片数量时,请考虑如何增加或减少子群集中的节点数量。某些数量的分片可提高灵活性。例如,如果数据库中有七个分片,则这些分片只能在节点数为七的倍数的子群集中平均分配。对于包含 12 个分片的数据库,这些分片可以平均分布在具有 2 个、3 个、4 个、6 个、12 个或 12 的倍数个节点的子群集中。
下表显示了基于工作数据大小的建议分片数和初始节点数:
重要
为保证性能,建议分片与节点之比为 2:1,而不是硬限制。如果您尝试使用高于 3:1 的比率,MC 会发出警告,以确保您已将分片数的各个方面都考虑在内。分片数量对群集扩展产生的影响
为数据库选择的分片数量会影响您将来能否扩展数据库。如果分片太少,则高效扩展数据库可能受到限制。如果分片太多,则数据库性能可能受到影响。较多数量的分片会增加节点间通信和编录的复杂性。
决定分片数的一个关键因素是确定您希望扩展数据库的方式。将节点添加到数据库时可以使用两种策略。这两种策略都可以提高不同类型的数据库的性能:
-
要提高复杂且运行时间长的查询的性能,请向现有子群集添加节点。这些额外的节点会通过将负载分散到更多计算节点来提高这些复杂查询的整体性能。向子群集添加的节点数可以多于数据库中的分片数。在这种情况下,订阅同一分片的子群集中的节点会在执行查询时拆分该分片中的数据。有关详细信息,请参阅弹性。
-
要增加多个短期查询(通常称为“仪表板查询”)的吞吐量,请通过添加额外的 子群集来提高群集的并行度。子群集将独立且并行处理这些较短的查询。有关详细信息,请参阅子群集。
这两种方法都会影响您启动数据库时选择使用的分片数量。复杂的分析查询在具有更多节点的子群集上拥有更出色的性能,这意味着具有 6 个分片的 6 个节点比具有 6 个分片的 3 个节点的性能更出色。节点数多于分片数可以进一步提高性能,但性能增益不是线性的。例如,在 6 分片数据库中包含 12 个节点的子群集不如在 12 分片数据库中包含 12 个节点的子群集高效。在 6 分片数据库中的 3 节点子群集与 6 分片数据库中的 6 节点子群集之间,处理较小数据集的仪表板类型查询的性能可能没有太大区别。
通常,应选择与未来 6-12 个月的预期工作数据大小相匹配的分片数。有关扩展数据库的详细信息,请参阅弹性。
用例
下面我们来看看一些用例,了解如何调整 Eon 模式群集的大小以满足您自己的特定需求。
用例 1:在需要时而不是在高峰时通过配置来降低成本
此用例通过将群集从 6 个节点扩展到 18 个节点(3 个子群集,每个子群集包含 6 个节点)来强调在 Eon 模式下增加查询吞吐量。在此用例中,您需要在 24 TB 或更少的工作数据集上支持高并发、短查询工作负载。创建包含 6 个节点和 6 个分片的初始数据库。您可以通过在预期出现峰值加载的一周中的某些天或特定日期范围添加一个或多个子群集,按需扩展数据库以增加并发吞吐量。然后,当数据库需求较低时,可以关闭或终止添加的子群集。通过在 Eon 模式下使用 Vertica,您可以通过按需进行配置而不是针对高峰时间进行配置来降低成本。
用例 2:复杂的分析工作负载需要更多的计算节点
此用例展示了以下观点:大型工作数据集上的复杂分析工作负载可受益于较多的分片数和节点数。创建包含 24 个节点和 24 个分片的初始子群集。根据需要,您可以向初始子群集额外添加 24 个节点。这些额外添加的节点支持子群集使用 Elastic Crunch Scaling 来缩短完成复杂分析查询所需的时间。
用例 3:工作负载隔离
此用例展示了以下观点:使用单独的子群集隔离 ETL 和报告工作负载。创建包含 6 个节点和 6 个分片的初始 主子群集,以服务于 ETL 工作负载。然后,添加另一个 6 节点 辅助子群集,用于执行查询工作负载。要分离这两个工作负载,您可以在 Vertica 中配置网络负载均衡器或创建连接负载均衡策略,以根据客户端需要执行的工作负载类型引导客户端连接到正确的子群集。