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

返回本页常规视图.

管理存储位置

Vertica 存储位置是您指定存储数据和临时文件的文件目的地的路径。每个群集节点至少需要两个存储位置：一个用于存储数据，另一个用于存储数据库编录文件。您可以在安装和设置期间设置这些位置。（有关磁盘空间要求的信息，请参阅 准备磁盘存储位置）。

Vertica 如何使用存储位置

当您向数据库添加数据或执行 DML 操作时，新数据将作为 ROS 容器添加到磁盘上的存储位置。根据数据库的配置，系统中可能存在许多 ROS 容器。

您可以标记自己创建的存储位置，以便在对象存储策略中引用它们。如果对象没有与之关联的存储策略，Vertica 将使用默认存储算法将数据存储在可用存储位置。如果对象具有存储策略，Vertica 会将数据存储在对象的指定存储位置。您可以在不再需要时停用或删除存储位置。

本地存储位置

默认情况下，Vertica 将数据存储在每个节点的唯一位置。每个位置都位于节点可以访问的文件系统目录中，而且通常位于节点的自有文件系统中。您可以为群集中的单个节点或全部节点创建本地存储位置。群集范围的存储位置是最常用的存储类型。Vertica 默认使用本地群集范围的存储位置来存储所有数据。如果要以不同方式存储数据，您必须创建其他存储位置。

共享存储位置

您可以创建共享存储位置，其中数据存储在群集中的所有节点都可以访问的单个文件系统上。此共享文件系统通常托管在群集之外，例如托管在分布式文件系统（如 HDFS）上。当前，Vertica 仅支持 HDFS 共享存储位置。除非使用 MapR 挂载点，否则不能将 NFS 用作 Vertica 共享存储位置。有关详细信息，请参阅适用于 HDFS 的 Vertica 存储位置。

创建用于 DATA 和/或 TEMP 用途的共享存储位置时，Vertica 群集中的每个节点都会在该共享位置下创建自己的子目录。创建不同的目录可防止节点覆盖彼此的数据。

对于在 Eon 模式下运行的数据库，STORAGE_LOCATIONS 系统表会显示第三种类型的位置：公共。

1 - 查看存储位置和策略

您可以监控有关可用存储位置标签和当前存储策略的信息。

查看磁盘存储信息

在 V_MONITOR.DISK_STORAGE 系统表中查询每个数据库节点上的磁盘存储信息。有关详细信息，请参阅使用系统表和 更改位置用途。V_MONITOR.DISK_STORAGE 系统表包括 CATALOG 注释，指示该位置用于存储编录文件。

查看位置标签

以下三个系统表在 location_labels 列中包含有关存储位置标签的信息：

  • storage_containers

  • storage_locations

  • partitions

对 storage_containers 系统表的相关列使用类似于以下内容的查询：

VMART=> select node_name,projection_name, location_label from v_monitor.storage_containers;
    node_name     |   projection_name    | location_label
------------------+----------------------+-----------------
 v_vmart_node0001 | states_p             |
 v_vmart_node0001 | states_p             |
 v_vmart_node0001 | t1_b1                |
 v_vmart_node0001 | newstates_b0         | FAST3
 v_vmart_node0001 | newstates_b0         | FAST3
 v_vmart_node0001 | newstates_b1         | FAST3
 v_vmart_node0001 | newstates_b1         | FAST3
 v_vmart_node0001 | newstates_b1         | FAST3
 .
 .
 .

对 v_catalog.storage_locations 系统表的列使用类似于以下内容的查询：

VMart=> select node_name, location_path, location_usage, location_label from storage_locations;
    node_name     |               location_path               | location_usage | location_label
------------------+-------------------------------------------+----------------+----------------
 v_vmart_node0001 | /home/dbadmin/VMart/v_vmart_node0001_data | DATA,TEMP      |
 v_vmart_node0001 | home/dbadmin/SSD/schemas                  | DATA           |
 v_vmart_node0001 | /home/dbadmin/SSD/tables                  | DATA           | SSD
 v_vmart_node0001 | /home/dbadmin/SSD/schemas                 | DATA           | Schema
 v_vmart_node0002 | /home/dbadmin/VMart/v_vmart_node0002_data | DATA,TEMP      |
 v_vmart_node0002 | /home/dbadmin/SSD/tables                  | DATA           |
 v_vmart_node0002 | /home/dbadmin/SSD/schemas                 | DATA           |
 v_vmart_node0003 | /home/dbadmin/VMart/v_vmart_node0003_data | DATA,TEMP      |
 v_vmart_node0003 | /home/dbadmin/SSD/tables                  | DATA           |
 v_vmart_node0003 | /home/dbadmin/SSD/schemas                 | DATA           |
(10 rows)

对 v_monitor.partitions 系统表的列使用类似于以下内容的查询：

VMART=> select partition_key, projection_name, location_label from v_monitor.partitions;
 partition_key |   projection_name    | location_label
---------------+----------------------+---------------
 NH            | states_b0            | FAST3
 MA            | states_b0            | FAST3
 VT            | states_b1            | FAST3
 ME            | states_b1            | FAST3
 CT            | states_b1            | FAST3
 .
 .
 .

查看存储层次

查询 storage_tiers 系统表以查看带标签和不带标签的存储容器及其相关信息：

VMart=> select * from v_monitor.storage_tiers;
 location_label | node_count | location_count | ros_container_count | total_occupied_size
----------------+------------+----------------+---------------------+---------------------
                |          1 |              2 |                  17 |           297039391
 SSD            |          1 |              1 |                   9 |                1506
 Schema         |          1 |              1 |                   0 |                   0
(3 rows)

查看存储策略

查询 storage_policies 系统表以查看适当位置的当前存储策略。

VMART=> select * from v_monitor.storage_policies;
 schema_name | object_name |  policy_details  | location_label
-------------+-------------+------------------+-----------------
             | public      | Schema           | F4
 public      | lineorder   | Partition [4, 4] | M3
(2 rows)

2 - 创建存储位置

可以使用 CREATE LOCATION 添加和配置存储位置（不同于所需的默认值），以便提供用于以下用途的存储：

  • 将执行引擎临时文件与数据文件隔离开。

  • 创建 带标签的位置，以便在存储策略中使用。

  • 根据预测或测量的访问模式创建存储位置。

  • 为特定用户或用户组创建 USER 存储位置。

可以将新存储位置从一个节点添加到另一个节点，或从单个节点添加到所有群集节点。但是请勿在一个节点上使用供其他群集节点访问的共享目录。

计划存储位置

在添加存储位置之前，请执行以下步骤：

  1. 验证计划用于存储位置目标的目录是否是对 Vertica 进程具有写入权限的空目录。

  2. 规划标签，以便在创建位置时为位置添加标签时。

  3. 确定要在存储位置中存储的信息类型：

    • DATA,TEMP （默认值）：存储位置可以存储 DML 生成的永久和临时数据，以及临时表的数据。

    • TEMP：path 指定的位置，用于存储 DML 生成的临时数据。如果 path 设置为 S3，则仅当 RemoteStorageForTemp 配置参数设置为 1 且 TEMP 必须使用 ALL NODES SHARED 加以限定。有关详细信息，请参阅临时数据的 S3 存储。

    • DATA：存储位置只能存储永久数据。

    • USER：具有 READ 和 WRITE 权限的用户可以访问此存储位置的数据和外部表。

    • DEPOT：该存储位置用于在 Eon 模式中存储存储库。仅在本地 Linux 文件系统上创建 DEPOT 存储位置。

      Vertica 允许每个节点有单个 DEPOT 存储位置。如果要将存储库移动到不同的位置（例如，在不同的文件系统上），您必须首先删除旧的存储库存储位置，然后创建新位置。

    在不同存储位置中存储临时和数据文件极为有利，因为两种数据类型具有不同的磁盘 I/O 访问模式。临时文件根据可用存储空间在各个位置中分布。但是，数据文件可以根据存储策略存储在不同的存储位置，以反映预测或测量的访问模式。

如果您计划在 HDFS 上放置存储位置，请参阅HDFS 存储位置的要求了解其他要求。

创建不带标签的本地存储位置

本示例显示了一个三节点群集，其中每个节点具有一个用于存储的 vertica/SSD 目录。

在群集中的每个节点上，创建供节点存储其数据的目录。例如：

$ mkdir /home/dbadmin/vertica/SSD

Vertica 建议在每个节点上创建相同的目录路径。在创建存储位置时使用此路径。

使用 CREATE LOCATION 语句添加存储位置。指定以下信息：

  • 节点上供 Vertica 存储数据的路径

  • 在上面有位置可用的节点，或 ALL NODES。如果指定 ALL NODES，该语句将在单个事务中在群集的所有节点上创建存储位置。

  • 要存储的信息的类型。

要授予非特权（非 dbadmin）Linux 用户对数据的访问权限，您必须创建一个 USER 存储位置。还可以使用 USER 存储位置为没有自己凭据的用户提供对共享文件系统和对象存储（如 HDFS 和 S3）的访问权限。请参阅创建供 USER 访问的存储位置。

以下示例显示了如何添加在所有节点上可用的位置以仅存储数据：

=> CREATE LOCATION '/home/dbadmin/vertica/SSD/' ALL NODES USAGE 'DATA';

以下示例显示了如何添加 v_vmart_node0001 节点上可用于存储数据和临时文件的位置：

=> CREATE LOCATION '/home/dbadmin/vertica/SSD/' NODE 'v_vmart_node0001';

假设您正在使用适用于数据文件的存储位置，且要创建排名的存储位置。在此排名中，列根据其测量的性能存储在不同磁盘上。要创建带排名的存储位置，请参阅测量存储性能和设置存储性能。

创建存储位置之后，可以使用一些限制，更改其存储的信息类型。请参阅更改位置用途。

存储位置子目录

不能在现有存储位置的子目录中创建存储位置。这样做会导致出现与以下内容类似的错误：

=> CREATE LOCATION '/tmp/myloc' ALL NODES USAGE 'TEMP';
CREATE LOCATION
=> CREATE LOCATION '/tmp/myloc/ssd' ALL NODES USAGE 'TEMP';
ERROR 5615:  Location [/tmp/myloc/ssd] conflicts with existing location
[/tmp/myloc] on node v_vmart_node0001

创建带标签的存储位置

可以使用 CREATE LOCATION 语句的 LABEL 关键字添加带描述性标签的存储位置。可以使用带标签的位置设置存储策略。请参阅创建存储策略。

以下示例显示了如何在 v_mart_node0002 上创建带标签 SSD 的存储位置：

=> CREATE LOCATION '/home/dbadmin/SSD/schemas' NODE 'v_vmart_node0002'
   USAGE 'DATA' LABEL 'SSD';

以下示例显示了如何在所有节点上创建存储位置。指定 ALL NODES 关键字可通过单个事务将存储位置添加到所有节点：

=> CREATE LOCATION '/home/dbadmin/SSD/schemas' ALL NODES
   USAGE 'DATA' LABEL 'SSD';

新存储位置列在 DISK_STORAGE 系统表中：

=> SELECT * FROM v_monitor.disk_storage;
.
.
-[ RECORD 7 ]-----------+-----------------------------------------------------
node_name               | v_vmart_node0002
storage_path            | /home/dbadmin/SSD/schemas
storage_usage           | DATA
rank                    | 0
throughput              | 0
latency                 | 0
storage_status          | Active
disk_block_size_bytes   | 4096
disk_space_used_blocks  | 1549437
disk_space_used_mb      | 6053
disk_space_free_blocks  | 13380004
disk_space_free_mb      | 52265
disk_space_free_percent | 89%
...

创建供 USER 访问的存储位置

要授予非特权（非 dbadmin）Linux 用户对数据的访问权限，您必须创建一个 USER 存储位置。

默认情况下，Vertica 使用用户提供的凭据来访问外部文件系统，例如 HDFS 和云对象存储。您可以覆盖此默认设置并创建一个 USER 存储位置来管理对这些位置的访问。要覆盖默认设置，请设置 UseServerIdentityOverUserIdentity 配置参数。

创建 USER 存储位置之后，可以授予一个或多个用户访问该位置的权限。USER 存储位置仅授予对数据文件的访问权限，而不授予对临时文件的访问权限。不能将 USER 存储位置指定给存储策略。不能将现有存储位置更改为具有 USER 访问权限。

以下示例显示了如何在特定节点上创建 USER 存储位置：

=> CREATE LOCATION '/home/dbadmin/UserStorage/BobStore' NODE
   'v_mcdb_node0007' USAGE 'USER';

以下示例显示了如何为特定用户授予对该位置的读写权限：

=> GRANT ALL ON LOCATION '/home/dbadmin/UserStorage/BobStore' TO Bob;
GRANT PRIVILEGE

以下示例显示了如何使用 USER 存储位置授予对 S3 上位置的访问权限。Vertica 使用服务器凭据来访问该位置：

   --- set database-level credential (once):
=> ALTER DATABASE DEFAULT SET AWSAuth = 'myaccesskeyid123456:mysecretaccesskey123456789012345678901234';

=> CREATE LOCATION 's3://datalake' SHARED USAGE 'USER' LABEL 's3user';

=> CREATE ROLE ExtUsers;
   --- Assign users to this role using GRANT (Role).

=> GRANT READ ON LOCATION 's3://datalake' TO ExtUsers;

有关配置用户权限的详细信息，请参阅数据库用户和权限，以及 GRANT（存储位置）和 REVOKE（存储位置）参考页面。

共享存储与本地存储

SHARED 关键字指示该位置被所有节点共享。大多数远程文件系统（如 HDFS 和 S3）都是共享的。对于这些文件系统，path 实参表示远程文件系统中供所有节点存储数据的单个位置。每个节点在共享存储位置中为其各自的文件创建一个相应的子目录。这样做可以防止一个节点覆盖属于其他节点的文件。

如果使用远程文件系统，必须指定 SHARED，即使对于单节点群集也是如此。如果位置被声明为 USER，Vertica 不会为每个节点都创建子目录。USER 的设置优先于 SHARED。

如果在创建位置时省略此关键字，则新存储位置将被视为本地位置。每个节点都必须具有对指定路径的唯一访问权限。该位置通常是节点自己的文件系统中的一个路径。位于每个节点本地的文件系统（如 Linux）中的存储位置始终是本地位置。

Eon 模式下临时数据的 S3 存储

如果在 Eon 模式下使用 Vertica 并且本地磁盘空间有限，则该空间可能不足以处理某些 DML 操作可能生成的大量临时数据。对于大型加载操作和刷新操作尤其如此。

您可以利用 S3 存储来处理临时数据，如下所示：

  1. 使用 CREATE LOCATION 创建远程存储位置，其中 path 设置为 S3，如下所示：

    => CREATE LOCATION 's3://bucket/path' ALL NODES SHARED USAGE 'TEMP';

  2. 将 RemoteStorageForTemp 会话配置参数设置为 1：

    => ALTER SESSION SET RemoteStorageForTemp= 1;

    在将此参数设置为 1 之前，S3 上必须已经存在临时存储位置；否则，Vertica 会引发错误并提示创建存储位置。

  3. 运行需要额外临时存储的查询。

  4. 将 RemoteStorageForTemp 重置为其默认值：

    => ALTER SESSION DEFAULT CLEAR RemoteStorageForTemp;

当设置 RemoteStorageForTemp 时，Vertica 会将所有 DML 操作的临时数据重定向到指定的远程位置。在被显式重置为其默认值 (0) 或当前会话结束之前，该参数设置将一直有效。

3 - HDFS 上的存储位置

除了本地 Linux 文件系统之外，还可以将存储位置放在 HDFS 中。因为 HDFS 存储位置不在本地，所以查询它们可能会更慢。您可以将 HDFS 存储位置用于优先级较低的数据或很少查询的数据（冷数据）。将优先级较低的数据移至 HDFS 可以释放 Vertica 群集上的空间以存储优先级较高的数据。

如果在 Apache Hadoop 上使用 Vertica for SQL，则通常仅将存储位置放在 HDFS 上。

3.1 - HDFS 存储位置的要求

要将 Vertica 的数据存储在 HDFS 上，请执行以下操作：

  • 确认您的 Hadoop 群集已启用 WebHDFS。

  • 确认 Vertica 群集中的所有节点均可连接到 Hadoop 群集中的所有节点。两个群集之间的任何防火墙都必须允许在 HDFS 使用的端口上建立连接。

  • 在 HDFS 群集不安全时，确认您有一个 Hadoop 用户，其用户名与 Vertica 数据库超级用户（通常名为 dbadmin）的名称匹配。该 Hadoop 用户必须具有您希望 Vertica 用于存储其数据的 HDFS 目录的读写权限。

  • 确认在 HDFS 群集使用 Kerberos 身份验证时：

    • 您拥有 Vertica 的 Kerberos 主体，该主体对将用于存储位置的 HDFS 目录具备读写权限。有关说明，请参阅下面的 Kerberos。

    • Kerberos KDC 正在运行。

  • 确认您的 HDFS 群集具有足以容纳 Vertica 数据的存储空间。有关详细信息，请参阅下面的空间要求。

  • 确认您在支持 HDFS 的存储位置存储的数据不会将数据库大小扩展到超出 Vertica 许可证中规定的任何数据限额。Vertica 将支持 HDFS 的存储位置中存储的数据视为许可证规定的任何数据限额的一部分。有关详细信息，请参阅《管理员指南》中的管理许可证。

备份/还原还有其他要求。

空间要求

如果 Vertica 数据库属于 K-safe，基于 HDFS 的存储位置包含您在该位置中存储的数据的两个副本。一个副本为主投影，另一个为同伴投影。如果您已启用 HDFS 的数据冗余功能，Hadoop 会将这两个投影存储多次。这种重复可能看似有些过多。但它与 RAID 1 级或更高级别存储主投影和伙伴实例投影的冗余副本的方式类似。冗余副本还可通过启用多个节点处理文件请求，帮助提高 HDFS 的性能。

验证 HDFS 安装有足够的空间可用于冗余存储 K-safe 数据的主投影和同伴投影。您可以通过设置 HadoopFSReplication 配置参数，调整 HDFS 存储的副本数量。有关详细信息，请参阅对 HDFS 存储位置进行故障排除。

Kerberos

要将 HDFS 中的存储位置与 Kerberos 一起使用，请执行以下附加步骤：

  1. 为每个 Vertica 节点创建 Kerberos 主体，如将 Kerberos 与 Vertica 结合使用中所述。

  2. 授予所有节点主体对将用作存储位置的 HDFS 目录的读写权限。

如果您计划使用 vbr 来备份和还原位置，请参阅备份和还原 HDFS 存储位置的要求中的其他要求。

将 HDFS 存储位置添加到新节点

如果将节点添加到 Vertica 群集中，它们不会自动拥有对现有 HDFS 存储位置的访问权限。您必须使用 CREATE LOCATION 语句，为新节点手动创建存储位置。请不要在此语句中使用 ALL NODES 选项，而应该使用 NODE 选项提供新节点的名称，以告知 Vertica 只有该节点需要添加共享位置。

请考虑一个借助于以下语句在三节点群集上创建的 HDFS 存储位置：

=> CREATE LOCATION 'hdfs://hadoopNS/vertica/colddata' ALL NODES SHARED
    USAGE 'data' LABEL 'coldstorage';

=> SELECT SET_OBJECT_STORAGE_POLICY('SchemaName','coldstorage');

以下示例显示了如何将存储位置添加到新群集节点：

=> CREATE LOCATION 'hdfs://hadoopNS/vertica/colddata' NODE 'v_vmart_node0004'
   SHARED USAGE 'data' LABEL 'coldstorage';

当您创建 HDFS 存储位置时，群集中的所有活动备用节点均将自动创建其自己的位置实例。而当备用节点替代出现故障的节点后，它会采用 HDFS 存储策略，使用自己的位置实例存储对象数据。请将存储位置创建后添加的备用节点视为任何其他新节点。您必须手动定义 HDFS 存储位置。

3.2 - HDFS 存储位置如何存储数据

Vertica 将数据存储在 HDFS 上的存储位置与它在 Linux 文件系统中存储数据的方式相似。如果您在 HDFS 上创建存储位置，Vertica 会将容纳其数据的 ROS 容器存储在 HDFS 上。您可以选择让哪些数据使用 HDFS 存储位置：从仅单个表或分区的数据到数据库的所有数据。

当 Vertica 从 HDFS 存储位置读取数据或向 HDFS 存储位置写入数据时，存储或检索该数据的节点会直接连接 Hadoop 群集以传输数据。如果一个单 ROS 容器文件拆分到多个 HDFS 节点，Vertica 节点将连接到每个节点。Vertica 节点将检索文件片段，然后重新组合文件。由于每个节点直接从来源提取其自己的数据，因此将并行传输数据，从而提高传输效率。让 Vertica 节点直接检索文件拆分片段还可以降低对 Hadoop 群集的影响。

您可以在 HDFS 上存储什么

请用 HDFS 存储位置只存储数据。您不能在 HDFS 存储位置中存储编录信息。

HDFS 存储位置不能执行的操作

由于 Vertica 使用存储位置以专用格式存储 ROS 容器，因此 MapReduce 和其他 Hadoop 组件无法访问 HDFS 中存储的 Vertica ROS 数据。切勿允许具有 HDFS 访问权限的其他程序写入到 ROS 文件。在外部对这些文件所做的任何修改均可能导致数据损坏和丢失。应用程序必须使用 Vertica 客户端库来访问 Vertica 数据。如果您想与其他 Hadoop 组件共享 ROS 数据，可以将其导出（请参阅文件导出）。

3.3 - Apache Hadoop 上 Vertica for SQL 的最佳实践

如果您在 Apache Hadoop 产品上使用 Vertica for SQL，Vertica 建议针对存储位置采用以下最佳实践：

  • 只将数据类型存储位置放在 HDFS 存储上。

  • 将临时空间直接放在本地 Linux 文件系统（而不是 HDFS）中。

  • 为获得最佳性能，请将 Vertica 编录直接放在本地 Linux 文件系统上。

  • 首先在本地 Linux 文件系统上创建数据库。然后，您可以将数据库扩展至 HDFS 存储位置，并设置只将数据块放在 HDFS 存储位置的存储策略。

  • 如果仅在部分 HDFS 节点上运行 Vertica，请勿在这些节点上运行 HDFS 平衡器，以便获得更好的性能。HDFS 平衡器会将数据块移动至较远的距离，导致 Vertica 在执行查询期间读取非本地数据。不需要执行网络 I/O 时，查询运行速度更快。

一般来说，HDFS 要为群集中的每个节点准备 2 GB 左右的内存。要在 Vertica 配置中支持此要求：

  1. 创建一个 2 GB 资源池。

  2. 不要为此池分配任何 Vertica 执行资源。此方法可保留 HDFS 使用的空间。

或者，使用 Ambari 或 Cloudera Manager 查找 HDFS 所需的最大堆大小并将资源池的大小设置为该值。

有关如何配置资源池的详细信息，请参阅管理工作负载。

3.4 - 对 HDFS 存储位置进行故障排除

本主题将介绍 HDFS 存储位置的一些常见问题。

HDFS 存储磁盘消耗

默认情况下，HDFS 为其存储的每个文件制作三个副本。这种复制有助于防止由磁盘或系统故障导致的数据丢失。还可以通过允许多个节点处理一个文件请求，来帮助提高性能。

K-Safety 值为 1 或更大的 Vertica 数据库还使用伙伴实例投影以冗余方式存储其数据。

当 K-Safe Vertica 数据库将数据存储在 HDFS 存储位置时，其数据冗余会因为 HDFS 的冗余而增加。HDFS 将存储主投影数据的三个副本外加伙伴实例投影的三个副本，从而总共存储数据的六个副本。

如果您想降低 HDFS 位置使用的磁盘存储量，您可以更改 HDFS 存储的数据副本数量。名为 HadoopFSReplication 的 Vertica 配置参数控制 HDFS 存储的数据副本数量。

您可以通过登录到 Hadoop NameNode 并发出以下命令，确定当前的 HDFS 磁盘使用情况：

$ hdfs dfsadmin -report

此命令可打印出整个 HDFS 存储的使用情况，后面则是 Hadoop 群集中各个节点的详细信息。下面的示例显示了此命令输出的开头部分，其中磁盘总空间已突出显示：

$ hdfs dfsadmin -report
Configured Capacity: 51495516981 (47.96 GB)
Present Capacity: 32087212032 (29.88 GB)
DFS Remaining: 31565144064 (29.40 GB)
DFS Used: 522067968 (497.88 MB)
DFS Used%: 1.63%
Under replicated blocks: 0
Blocks with corrupt replicas: 0
Missing blocks: 0
. . .

将一个简单的百万行表加载到 HDFS 存储位置中存储的一个表之后，报告将显示更大的磁盘使用量：

Configured Capacity: 51495516981 (47.96 GB)
Present Capacity: 32085299338 (29.88 GB)
DFS Remaining: 31373565952 (29.22 GB)
DFS Used: 711733386 (678.76 MB)
DFS Used%: 2.22%
Under replicated blocks: 0
Blocks with corrupt replicas: 0
Missing blocks: 0
. . .

以下 Vertica 示例演示了下列操作：

  1. 在 HDFS 上创建存储位置。

  2. 删除 Vertica 中的表。

  3. 将 HadoopFSReplication 配置选项设置为 1。这将规定 HDFS 存储 HDFS 存储位置数据的一个副本。

  4. 重新创建表并重新加载数据。

=> CREATE LOCATION 'hdfs://hadoopNS/user/dbadmin' ALL NODES SHARED
    USAGE 'data' LABEL 'hdfs';
CREATE LOCATION

=> DROP TABLE messages;
DROP TABLE


=> ALTER DATABASE DEFAULT SET PARAMETER HadoopFSReplication = 1;

=> CREATE TABLE messages (id INTEGER, text VARCHAR);
CREATE TABLE


=> SELECT SET_OBJECT_STORAGE_POLICY('messages', 'hdfs');
 SET_OBJECT_STORAGE_POLICY
----------------------------
Object storage policy set.
(1 row)

=> COPY messages FROM '/home/dbadmin/messages.txt';
 Rows Loaded
-------------
1000000

现在在 Hadoop 上运行 HDFS 报告将显示磁盘空间使用量减少：

$ hdfs dfsadmin -report
Configured Capacity: 51495516981 (47.96 GB)
Present Capacity: 32086278190 (29.88 GB)
DFS Remaining: 31500988416 (29.34 GB)
DFS Used: 585289774 (558.18 MB)
DFS Used%: 1.82%
Under replicated blocks: 0
Blocks with corrupt replicas: 0
Missing blocks: 0
. . .

错误 6966： StorageBundleWriter

将数据加载到小型 Hadoop 群集（数据节点不超过 5 个）上的存储位置时，您可能会遇到错误 6966。此错误是由 HDFS 管理写入管道和复制的方式引起的。您可以通过减少副本数量来缓解此问题，如 [HDFS 存储磁盘消耗](#HDFS Sto)中所述。有关可以在 Hadoop 群集中进行的配置更改，请参阅 Hortonworks 中的这篇博文。

创建存储位置时的 Kerberos 身份验证

如果 HDFS 使用 Kerberos 身份验证，那么 CREATE LOCATION 语句将使用 Vertica keytab 主体而不是执行操作的用户的主体进行身份验证。如果因为身份验证错误导致创建失败，请验证您已遵循 Kerberos 中所述的步骤来配置此主体。

如下面的示例所示，使用 Kerberos 在 Hadoop 群集上创建 HDFS 存储位置时，CREATE LOCATION 可以报告正在使用的主体：

=> CREATE LOCATION 'hdfs://hadoopNS/user/dbadmin' ALL NODES SHARED
             USAGE 'data' LABEL 'coldstorage';
NOTICE 0: Performing HDFS operations using kerberos principal [vertica/hadoop.example.com]
CREATE LOCATION

备份或还原失败

有关 HDFS 存储位置的备份/还原问题，请参阅备份和还原故障排除。

4 - 更改位置用途

ALTER_LOCATION_USE 可用于更改 Vertica 在存储位置存储的文件类型。您通常仅将标签用于 DATA 存储位置，而不用于 TEMP 存储位置。

以下示例显示了如何将 v_vmartdb_node0004 上的存储位置更改为仅存储数据文件：

=> SELECT ALTER_LOCATION_USE ('/thirdVerticaStorageLocation/' , 'v_vmartdb_node0004' , 'DATA');

更改 HDFS 存储位置

更改 HDFS 存储位置时，必须对 Vertica 群集中的所有节点进行更改。为此，请指定节点值 ''，如以下示例所示：

=> SELECT ALTER_LOCATION_USE('hdfs:///user/dbadmin/v_vmart',
   '','TEMP');

您不能更改 USER 使用类型的存储位置（如果存储位置是以这种方式创建的），也不能将存储位置更改为 USER 类型（如果存储位置不是以这种方式创建的）。可以更改 USER 存储位置以指定 DATA（不支持存储 TEMP 文件）。但是，这样做不会影响 USER 存储位置的主要目标可由具有已分配权限的非 dbadmin 用户访问。

您不能将存储位置从 SHARED TEMP 或 SHARED USER 更改为 SHARED DATA，反之亦然。

更改存储位置用途的影响

在更改存储位置用途类型之前，注意必须保留至少一个位置用来存储节点上的数据文件和临时文件。可将数据文件和临时文件存储在相同或单独的存储位置中。

更改现有存储位置具有以下影响：

5 - 更改位置标签

ALTER_LOCATION_LABEL 可用于以多种方式更改存储位置的标签：

您可以在单个节点或群集范围内执行这些操作。

添加位置标签

使用 ALTER_LOCATION_LABEL 为不带标签的存储位置添加位置标签。例如，在三节点群集上定义有不带标签的存储位置 /home/dbadmin/Vertica/SSD：

您可以在所有节点上将此存储位置标记为 SSD，如下所示：

=> SELECT ALTER_LOCATION_LABEL('/home/dbadmin/vertica/SSD', '', 'SSD');

移除位置标签

只有当这两个条件都为真时，您才能移除位置标签：

  • 未在数据库对象的存储策略中指定标签。

  • 标记的位置不是其关联对象的最后一个可用存储。

以下语句从所有节点上的指定存储位置移除 SSD 标签：

=> SELECT ALTER_LOCATION_LABEL('/home/dbadmin/SSD/tables','', '');
          ALTER_LOCATION_LABEL
------------------------------------------
 /home/dbadmin/SSD/tables label changed.
(1 row)

更改位置标签所产生的影响

更改位置标签会产生以下影响：

6 - 创建存储策略

Vertica 元函数 SET_OBJECT_STORAGE_POLICY 可以创建 存储策略，将数据库对象与带标签的存储位置相关联。当对象具有存储策略时，Vertica 使用带标签的位置作为对象数据的默认存储位置。

可以为任何数据库、架构、表和分区范围创建存储策略。每个对象都可以与一个存储策略相关联。每次加载和更新数据时，Vertica 都会检查对象是否具有存储策略。如果有，Vertica 将自动使用带标签的存储位置。如果对象或其父代实体没有存储策略，数据存储处理将在可用的存储位置上使用标准存储算法继续。如果所有存储位置都带标签，Vertica 将使用其中之一。

存储策略可用于确定存储重要数据的位置。例如，可以创建带标签 SSD 的存储位置，用以表示群集节点上最快可用的存储位置。随后可以创建存储策略以将表与此带标签的位置相关联。例如，下面的 SET_OBJECT_STORAGE_POLICY 语句将 test 表上的存储策略设置为使用带有 SSD 标签的存储作为其默认位置：

=>  SELECT SET_OBJECT_STORAGE_POLICY('test','ssd', true);
            SET_OBJECT_STORAGE_POLICY
--------------------------------------------------
Object storage policy set.
Task: moving storages
(Table: public.test) (Projection: public.test_b0)
(Table: public.test) (Projection: public.test_b1)

(1 row)

创建一个或多个存储策略并不需要所有数据库对象都存在策略。站点可以支持具有或不具有存储策略的对象。可以为离散的优先级对象集添加存储策略，同时允许存在其他没有策略的对象，以便其使用可用的存储空间。

基于存储性能创建策略

可以测量任何磁盘存储位置的性能（请参阅测量存储性能）。然后使用性能测量值设置存储位置性能。Vertica 使用您设置的性能测量值为其存储位置排名，并通过排名确定哪些键投影列存储在性能更高的位置，如设置存储性能中所述。

如果已设置站点存储位置的性能，并决定使用存储策略，则具有关联策略的任何存储位置的优先级都高于存储排名设置。

您可以使用存储策略将旧数据移至成本较低的存储位置，同时保持其可用于查询。请参阅为低优先级数据创建存储策略。

存储层次结构和优先级

Vertica 根据下面的存储策略层次结构确定对象数据的存储位置，下面列出的存储位置按优先级升序排列：

  1. 数据库

  2. 架构

  3. 表

  4. 表分区

如果对象缺少自己的存储策略，它将使用其父对象的存储策略。例如，数据库 Sales 中的表 Region.Income 按月分区。带标签的存储策略 FAST 和 STANDARD 分别分配给表和数据库。没有为表的分区或其父架构分配存储策略，因此这些分区或架构分别使用其父对象 FAST 和 STANDARD 的存储策略：

当发生 Tuple Mover 操作（如合并）时，所有 Income 数据都会移至 FAST 存储位置。Region 架构中的其他表使用其各自的存储策略。如果 Region 表缺少自己的存储策略，Tuple Mover 将使用它上面的下一个存储策略 — 在这种情况下，它使用数据库存储策略并将表数据移至 STANDARD。

查询现有存储策略

可以查询在 STORAGE_CONTAINERS 系统表的 location_label 列中列出的现有存储策略：

=> SELECT node_name, projection_name, location_label FROM v_monitor.storage_containers;
    node_name     |   projection_name    | location_label
------------------+----------------------+----------------
 v_vmart_node0001 | states_p             |
 v_vmart_node0001 | states_p             |
 v_vmart_node0001 | t1_b1                |
 v_vmart_node0001 | newstates_b0         | LEVEL3
 v_vmart_node0001 | newstates_b0         | LEVEL3
 v_vmart_node0001 | newstates_b1         | LEVEL3
 v_vmart_node0001 | newstates_b1         | LEVEL3
 v_vmart_node0001 | newstates_b1         | LEVEL3
 v_vmart_node0001 | states_p_v1_node0001 | LEVEL3
 v_vmart_node0001 | states_p_v1_node0001 | LEVEL3
 v_vmart_node0001 | states_p_v1_node0001 | LEVEL3
 v_vmart_node0001 | states_p_v1_node0001 | LEVEL3
 v_vmart_node0001 | states_p_v1_node0001 | LEVEL3
 v_vmart_node0001 | states_p_v1_node0001 | LEVEL3
 v_vmart_node0001 | states_b0            | SSD
 v_vmart_node0001 | states_b0            | SSD
 v_vmart_node0001 | states_b1            | SSD
 v_vmart_node0001 | states_b1            | SSD
 v_vmart_node0001 | states_b1            | SSD
...

将现有数据存储强制移动到新存储位置

默认情况下，Tuple Mover 在所有挂起的合并操作完成后强制执行对象存储策略。 SET_OBJECT_STORAGE_POLICY 立即将现有数据存储移至新位置，但前提是它的 enforce-storage-move 参数设置为 true。如果要移动的数据是旧数据，您可能需要强制移动，即使这意味着需要等待操作完成才能继续也是如此。Tuple Mover 在旧数据上的运行频率较低。

7 - 为低优先级数据创建存储策略

如果您的某些数据位于分区表中，您可以将查询较少的分区移至成本较低的存储，例如 HDFS。您仍然可以通过查询访问这些数据，只不过访问的速度更慢。在这种情况下，速度更快的存储通常被称为“热存储”，速度较慢的存储被称为“冷存储”。

假设您有一个名为 messages 的表，其中包含已按照时间戳的年份和月份分区的社交媒体消息。您可以通过查询 PARTITIONS 系统表列出表中的分区。

=> SELECT partition_key, projection_name, node_name, location_label FROM partitions
   ORDER BY partition_key;
partition_key | projection_name |    node_name     | location_label
--------------+-----------------+------------------+----------------
201309        | messages_b1     | v_vmart_node0001 |
201309        | messages_b0     | v_vmart_node0003 |
201309        | messages_b1     | v_vmart_node0002 |
201309        | messages_b1     | v_vmart_node0003 |
201309        | messages_b0     | v_vmart_node0001 |
201309        | messages_b0     | v_vmart_node0002 |
201310        | messages_b0     | v_vmart_node0002 |
201310        | messages_b1     | v_vmart_node0003 |
201310        | messages_b0     | v_vmart_node0001 |
. . .
201405        | messages_b0     | v_vmart_node0002 |
201405        | messages_b1     | v_vmart_node0003 |
201405        | messages_b1     | v_vmart_node0001 |
201405        | messages_b0     | v_vmart_node0001 |
(54 rows)

接下来，假设您发现，对此表执行的大多数查询仅访问最近一两个月的数据。您可能会决定将旧数据移至基于 HDFS 的存储位置中的冷存储。数据在移动后仍可用于查询，但查询性能会降低。

要将分区移至 HDFS 存储位置，请在 SET_OBJECT_STORAGE_POLICY 函数调用中提供最低和最高的待移动分区键值。以下示例演示了如何移动两个日期之间的数据。在此示例中：

  • 分区键值 201309 代表 2013 年 9 月。

  • 分区键值 201403 代表 2014 年 3 月。

  • 名称 coldstorage 是基于 HDFS 的存储位置的标签。

  • 最后一个可选的实参是 true，这意味着在移动完成之前，该函数不会返回。默认情况下，该函数立即返回，并在下次运行 Tuple Mover 时移动数据。但是，当数据较旧时，Tuple Mover 的运行频率会降低，这会延迟原始存储空间的恢复。

=> SELECT SET_OBJECT_STORAGE_POLICY('messages','coldstorage', '201309', '201403', 'true');

下次运行 Tuple Mover 时，指定范围内的分区将移至带有 coldstorage 标签的 HDFS 存储位置。这个位置的名称现在显示在 PARTITIONS 系统表的 location_label 列中。

=> SELECT partition_key, projection_name, node_name, location_label
   FROM partitions ORDER BY partition_key;
partition_key | projection_name |    node_name     | location_label
--------------+-----------------+------------------+----------------
201309        | messages_b0     | v_vmart_node0003 | coldstorage
201309        | messages_b1     | v_vmart_node0001 | coldstorage
201309        | messages_b1     | v_vmart_node0002 | coldstorage
201309        | messages_b0     | v_vmart_node0001 | coldstorage
. . .
201403        | messages_b0     | v_vmart_node0002 | coldstorage
201404        | messages_b0     | v_vmart_node0001 |
201404        | messages_b0     | v_vmart_node0002 |
201404        | messages_b1     | v_vmart_node0001 |
201404        | messages_b1     | v_vmart_node0002 |
201404        | messages_b0     | v_vmart_node0003 |
201404        | messages_b1     | v_vmart_node0003 |
201405        | messages_b0     | v_vmart_node0001 |
201405        | messages_b1     | v_vmart_node0002 |
201405        | messages_b0     | v_vmart_node0002 |
201405        | messages_b0     | v_vmart_node0003 |
201405        | messages_b1     | v_vmart_node0001 |
201405        | messages_b1     | v_vmart_node0003 |
(54 rows)

完成首次数据移动之后，您可以定期将额外的数据移至该 HDFS 存储位置。您可以使用相同的方法将个别分区或一系列分区从“热”存储移至“冷”存储位置：

=> SELECT SET_OBJECT_STORAGE_POLICY('messages', 'coldstorage', '201404', '201404', 'true');

=> SELECT projection_name, node_name, location_label
   FROM PARTITIONS WHERE PARTITION_KEY = '201404';
 projection_name |    node_name     | location_label
-----------------+------------------+----------------
 messages_b0     | v_vmart_node0002 | coldstorage
 messages_b0     | v_vmart_node0003 | coldstorage
 messages_b1     | v_vmart_node0003 | coldstorage
 messages_b0     | v_vmart_node0001 | coldstorage
 messages_b1     | v_vmart_node0002 | coldstorage
 messages_b1     | v_vmart_node0001 | coldstorage
(6 rows)

将分区移至 HDFS 上存储的表中

将分区从热存储移至冷存储的另一种方法是，将分区的数据移至其他存储位置中单独的表中。这种方法将数据分成两个表，一个包含热数据，另一个则包含冷数据。如果希望防止查询无意中访问存储在冷存储中的数据，您可以使用这种方法。要查询旧数据，您必须显式查询冷表。

要移动分区：

  1. 创建一个架构与现有已分区表的架构相匹配的新表。

  2. 将新表的存储策略设置为使用基于 HDFS 的存储位置。

  3. 使用 MOVE_PARTITIONS_TO_TABLE 函数，将一系列分区从热表移至冷表。这些分区将在下次运行 Tuple Mover 时迁移。

下面的示例演示了上述步骤。您首先创建一个名为 cold_messages 的表。然后向其分配名为 coldstorage 的基于 HDFS 的存储位置；最后，移动一系列分区。

=> CREATE TABLE cold_messages LIKE messages INCLUDING PROJECTIONS;
=> SELECT SET_OBJECT_STORAGE_POLICY('cold_messages', 'coldstorage');
=> SELECT MOVE_PARTITIONS_TO_TABLE('messages','201309','201403','cold_messages');

8 - 移动数据存储位置

SET_OBJECT_STORAGE_POLICY 将数据存储从现有位置（带标签和不带标签）移至另一个带标签的位置。该函数执行两个任务：

  • 为对象创建存储策略，或更改其当前策略。

  • 将指定对象的所有现有数据移至目标存储位置。

在该函数将对象数据移至指定的目标位置之前，Vertica 会计算所需的存储并检查目标处的可用空间。在调用 SET_OBJECT_STORAGE_POLICY 之前，请检查新目标位置上的可用空间。请注意，检查并不能保证在 Tuple Mover 实际执行移动时该空间仍然可用。如果存储位置没有足够的可用空间，该函数将返回错误。

默认情况下，Tuple Mover 在所有待定的合并任务返回后才将对象数据移至新的存储位置。您可以通过将函数的 enforce-storage-move 实参设置为 true 来强制立即移动数据。例如，以下语句设置表的存储策略并立即实施移动操作：

=> SELECT SET_OBJECT_STORAGE_POLICY('states', 'SSD', 'true');
                            SET_OBJECT_STORAGE_POLICY
------------------------------------------------------------------------------------------------
 Object storage policy set.
Task: moving storages
(Table: public.states) (Projection: public.states_p1)
(Table: public.states) (Projection: public.states_p2)
(Table: public.states) (Projection: public.states_p3)
(1 row)

9 - 清除存储策略

CLEAR_OBJECT_STORAGE_POLICY 元函数从数据库、架构、表或表分区中清除存储策略。例如，以下语句清除表的存储策略：

=> SELECT CLEAR_OBJECT_STORAGE_POLICY ('store.store_sales_fact');
  CLEAR_OBJECT_STORAGE_POLICY
--------------------------------
 Object storage policy cleared.
(1 row)

Tuple Mover 会将现有存储容器移至父存储策略的位置，若无父策略，则移至默认存储位置。默认情况下，此移动发生在所有待定的合并任务返回之后。

您可以通过将函数的 enforce-storage-move 实参设置为 true 来强制立即移动数据。例如，以下语句清除表的存储策略并立即执行移动操作：

=> SELECT CLEAR_OBJECT_STORAGE_POLICY ('store.store_orders_fact', 'true');
                         CLEAR_OBJECT_STORAGE_POLICY
-----------------------------------------------------------------------------
 Object storage policy cleared.
Task: moving storages
(Table: store.store_orders_fact) (Projection: store.store_orders_fact_b0)
(Table: store.store_orders_fact) (Projection: store.store_orders_fact_b1)

(1 row)

对相关元素的影响

清除一个级别（如表）的存储策略不一定会影响其他级别（如该表的分区）的存储策略。

例如，lineorder 表有一个存储策略用来将表数据存储在带有 F2 标签的位置。为该表中的各个分区单独分配各自的存储位置，通过查询 STORAGE_POLICIES 系统表进行验证：

=> SELECT * from v_monitor.storage_policies;
 schema_name | object_name |  policy_details  | location_label
-------------+-------------+------------------+----------------
             | public      | Schema           | F4
 public      | lineorder   | Partition [0, 0] | F1
 public      | lineorder   | Partition [1, 1] | F2
 public      | lineorder   | Partition [2, 2] | F4
 public      | lineorder   | Partition [3, 3] | M1
 public      | lineorder   | Partition [4, 4] | M3
(6 rows)

从 lineorder 表中清除当前的存储策略对其各个分区的存储策略没有影响。例如，对于以下 CLEAR_OBJECT_STORAGE_POLICY 语句：

=> SELECT CLEAR_OBJECT_STORAGE_POLICY ('lineorder');
      CLEAR_OBJECT_STORAGE_POLICY
-------------------------------------
 Default storage policy cleared.
(1 row)

表中的各个分区保留其存储策略：


=> SELECT * from v_monitor.storage_policies;
 schema_name | object_name |  policy_details  | location_label
-------------+-------------+------------------+----------------
             | public      | Schema           | F4
 public      | lineorder   | Partition [0, 0] | F1
 public      | lineorder   | Partition [1, 1] | F2
 public      | lineorder   | Partition [2, 2] | F4
 public      | lineorder   | Partition [3, 3] | M1
 public      | lineorder   | Partition [4, 4] | M3
(6 rows)

如果您从表中的一个分区键范围中清除存储策略，则父对象和其他分区范围的存储策略不受影响。例如，以下语句从分区键 0 到 3 中清除存储策略：

=> SELECT CLEAR_OBJECT_STORAGE_POLICY ('lineorder','0','3');
      clear_object_storage_policy
-------------------------------------
 Default storage policy cleared.
(1 row)
=> SELECT * from storage_policies;
 schema_name | object_name |  policy_details  | location_label
-------------+-------------+------------------+----------------
             | public      | Schema           | F4
 public      | lineorder   | Table            | F2
 public      | lineorder   | Partition [4, 4] | M3
(2 rows)

10 - 测量存储性能

Vertica 可用于测量站点上任何存储位置的磁盘 I/O 性能。可使用返回的测量值设置性能，从而自动进行排名。根据您的存储需求，也可以使用性能确定作为站点存储策略一部分的关键数据所需的存储位置。存储性能测量仅适用于数据存储位置，不适用于临时存储位置。

测量存储位置性能会计算在磁盘中读写 1 MB 数据所需的时间，计算公式如下：

IO time = time to read/write 1MB + time to seek = 1/throughput + 1/Latency

  • 吞吐量为顺序读写的平均吞吐量（以每秒兆字节表示）。

  • 延迟适用于随机读取（仅在查找中，单位为每秒查找次数）。

因此，存储位置较快的 I/O 时间要比存储位置较慢的 I/O 时间短。

Vertica 提供两种测量存储位置性能的方法，具体视数据库是否正在运行而定。您可以执行以下操作之一：

  • 在正在运行的数据库上测量性能。

  • 设置群集之前测量性能。

这两种方法都将返回存储位置的吞吐量和延迟。记录或捕获吞吐量和延迟信息，以便您可以使用它来设置位置性能（请参阅设置存储性能）。

在正在运行的 Vertica 数据库上测量性能

使用 MEASURE_LOCATION_PERFORMANCE() 函数可在数据库正在运行时测量存储位置的性能。此函数具有以下要求：

  • 存储路径必须已存在于数据库中。

  • 存储位置中需要有 RAM*2 的可用磁盘空间来测量其性能。例如，如果 RAM 为 16 GB，则需 32 GB 的可用磁盘空间。如果磁盘空间不足，函数将返回一个错误。

使用系统表 DISK_STORAGE 可获取每个数据库节点上的磁盘存储的相关信息。

以下示例显示了如何在 v_vmartdb_node0004 上测量存储位置的性能：

=> SELECT MEASURE_LOCATION_PERFORMANCE('/secondVerticaStorageLocation/','v_vmartdb_node0004');
WARNING:  measure_location_performance can take a long time. Please check logs for progress
           measure_location_performance
--------------------------------------------------
 Throughput : 122 MB/sec. Latency : 140 seeks/sec

在设置群集之前测量性能

您可以在设置群集之前测量性能。当要验证磁盘在正常参数范围内是否正常运行时，此方法非常有用。要执行此测量，必须事先安装 Vertica。

要测量磁盘性能，请使用以下命令：

opt/vertica/bin/vertica -m <path to disk mount>

例如：

opt/vertica/bin/vertica -m /secondVerticaStorageLocation/node0004_data

11 - 设置存储性能

可以使用 MEASURE_LOCATION_PERFORMANCE 函数返回的测量值作为 SET_LOCATION_PERFORMANCE() 函数的输入值。

以下示例显示了如何使用由 MEASURE_LOCATION_PERFORMANCE 函数为 v_vmartdb_node0004 上的某个存储位置返回的值设置该位置的性能。将吞吐量设置为 122 MB/s 并将延迟设置为 140 seeks/s。 MEASURE_LOCATION_PERFORMANCE

=> SELECT SET_LOCATION_PERFORMANCE('/secondVerticaStorageLocation/','node2','122','140');

通过位置性能设置对排序顺序进行分级

设置性能数据参数之后，Vertica 每次存储投影列时会自动利用性能数据对存储位置进行分级。

Vertica 将投影排序顺序中包含的列存储在最快的可用存储位置。未包含在投影排序顺序中的列将存储在稍慢的磁盘中。每个投影的列按如下方式排序：

  • 排序顺序中的列具有最高优先级（编号 &gt；1000）。

  • 排序顺序中最后一列的排序编号为 1001。

  • 排序顺序中倒数第二的列排序编号为 1002，以此类推，直到排序顺序中的第一列，其排序编号为 1000 + 排序列数。

  • 剩余列的排序编号在 1000–1 之间，从 1000 开始，每列减一。

Vertica 随后将列从最高排号到最低排号存储在磁盘中。它将最高排号的列放在最快的磁盘上，将最低排号的列放在最慢的磁盘上。

结合使用位置性能设置与存储策略

首先测量位置性能并在 Vertica 数据库中进行设置。之后，您可以利用性能结果来确定要在存储策略中使用的最快的存储。

  • 将具有最高性能的位置设置为重要数据的默认位置。

  • 将速度较慢的位置用作旧数据或不太重要的数据的默认位置。如果您不想指定默认位置，这种速度较慢的位置可能根本不需要策略。

Vertica 会按如下方式确定数据存储，具体取决于是否存在存储策略：

12 - 停用存储位置

您可以停用存储位置以停止使用它。停用某个存储位置只是禁止 Vertica 将数据或临时文件存储到其中，而不会移除实际位置。先前存储在已停用位置中的所有数据最终将由 Tuple Mover 合并。使用 RETIRE_LOCATION 函数停用位置。

以下示例从单个节点停用位置：

=> SELECT RETIRE_LOCATION('/secondStorageLocation/' , 'v_vmartdb_node0004');

要停用所有节点上的存储位置，请为第二个实参使用空字符串 ('')。如果位置是 SHARED，则只能在所有节点上停用它。

您可以通过传递可选的第三个实参 enforce 为 true 来加快存储位置的停用和删除操作。该函数使用此指令将数据从存储位置中移出，而不必等待 Tuple Mover 来处理，这样您便能够立即删除该位置。

此外，还可以使用 ENFORCE_OBJECT_STORAGE_POLICY 函数立即触发所有存储位置的移动操作，从而可用于删除这些位置。这种方法等效于使用 enforce 实参。

以下示例显示了如何停用所有节点上的存储位置，以便可以立即删除它：

=> SELECT RETIRE_LOCATION('/secondStorageLocation/' , '', true);

可将数据文件和临时文件存储在一个存储位置或多个单独的存储位置中。

有关在停用某个位置后删除该位置的详细信息，请参阅删除存储位置。

13 - 还原已停用的存储位置

您可以还原先前停用的存储位置。该位置还原后，Vertica 会对存储位置重新排名并使用还原后的位置来处理查询（由其排名决定）。

使用 RESTORE_LOCATION 函数还原已停用的存储位置。

以下示例显示了如何还原单个节点上的已停用存储位置：

=> SELECT RESTORE_LOCATION('/secondStorageLocation/' , 'v_vmartdb_node0004');

要还原所有节点上的存储位置，请为第二个实参使用空字符串 ('')。以下示例演示了在所有节点上创建、停用和还原某个位置：

=> CREATE LOCATION '/tmp/ab1' ALL NODES USAGE 'TEMP';
CREATE LOCATION

=> SELECT RETIRE_LOCATION('/tmp/ab1', '');
retire_location
------------------------
/tmp/ab1 retired.
    (1 row)

=> SELECT location_id, node_name, location_path, location_usage, is_retired
          FROM STORAGE_LOCATIONS WHERE location_path ILIKE '/tmp/ab1';
location_id       | node_name           | location_path | location_usage | is_retired
------------------+---------------------+---------------+----------------+------------
45035996273736724 | v_vmart_node0001    | /tmp/ab1      | TEMP           | t
45035996273736726 | v_vmart_node0002    | /tmp/ab1      | TEMP           | t
45035996273736728 | v_vmart_node0003    | /tmp/ab1      | TEMP           | t
45035996273736730 | v_vmart_node0004    | /tmp/ab1      | TEMP           | t
    (4 rows)

=> SELECT RESTORE_LOCATION('/tmp/ab1', '');
restore_location
-------------------------
/tmp/ab1 restored.
    (1 row)

=> SELECT location_id, node_name, location_path, location_usage, is_retired
          FROM STORAGE_LOCATIONS WHERE location_path ILIKE '/tmp/ab1';
location_id       | node_name           | location_path | location_usage | is_retired
------------------+---------------------+---------------+----------------+------------
45035996273736724 | v_vmart_node0001    | /tmp/ab1      | TEMP           | f
45035996273736726 | v_vmart_node0002    | /tmp/ab1      | TEMP           | f
45035996273736728 | v_vmart_node0003    | /tmp/ab1      | TEMP           | f
45035996273736730 | v_vmart_node0004    | /tmp/ab1      | TEMP           | f
    (4 rows)

RESTORE_LOCATION 仅在位置存在且被停用的节点上还原位置。这个元函数不会将存储位置传播到先前没有该位置的节点。

如果已在任何节点上删除位置，则无法在所有节点上执行还原操作。如果您已删除相同节点上的位置，则有两个选择：

  • 如果不再希望使用已在其上删除该位置的节点，请在其他的每个节点上单独还原位置。

  • 或者，可以在删除位置的节点上重新创建位置。为此，请使用 CREATE LOCATION。重新创建位置后，可随后在所有节点上还原该位置。

以下示例演示了如果您尝试在已删除位置的节点上进行还原，操作将失败：

=> SELECT RETIRE_LOCATION('/tmp/ab1', '');
retire_location
------------------------
/tmp/ab1 retired.
    (1 row)

=> SELECT DROP_LOCATION('/tmp/ab1', 'v_vmart_node0002');
drop_location
------------------------
/tmp/ab1 dropped.
    (1 row)

==> SELECT location_id, node_name, location_path, location_usage, is_retired
          FROM STORAGE_LOCATIONS WHERE location_path ILIKE '/tmp/ab1';
location_id       | node_name           | location_path | location_usage | is_retired
------------------+---------------------+---------------+----------------+------------
45035996273736724 | v_vmart_node0001    | /tmp/ab1      | TEMP           | t
45035996273736728 | v_vmart_node0003    | /tmp/ab1      | TEMP           | t
45035996273736730 | v_vmart_node0004    | /tmp/ab1      | TEMP           | t
    (3 rows)

=> SELECT RESTORE_LOCATION('/tmp/ab1', '');
ERROR 2081:  [/tmp/ab1] is not a valid storage location on node v_vmart_node0002

14 - 删除存储位置

要删除存储位置，请使用 DROP_LOCATION 函数。您不能删除 DATA 用途的位置，只能删除 TEMP 或 USER 用途的位置。（请参阅在删除之前更改存储位置）。

由于删除存储位置的操作无法撤消，因此 Vertica 建议先停用存储位置（请参阅停用存储位置）。通过在删除之前停用存储位置，您可以验证这样做不会对任何数据访问产生负面影响。如果您决定不删除它，可以进行还原（请参阅还原已停用的存储位置）。

以下示例显示了如何删除单个节点上的存储位置：

=> SELECT DROP_LOCATION('/secondStorageLocation/' , 'v_vmartdb_node0002');

删除存储位置时，此操作会级联到关联的对象，包括授予存储的任何权限。

在删除之前更改存储位置

您只能删除包含临时文件的存储位置。因此，在可以删除之前，必须将存储位置更改为 TEMP 使用类型。但是，如果存储位置中仍存在数据文件，Vertica 会禁止您删除该存储位置。删除数据文件不会清除存储位置，并且可能会导致数据库崩溃。要处理包含数据文件的存储区域以便能够删除它，请使用以下选项之一：

  • 手动合并数据文件。

  • 等待 Tuple Mover 自动合并数据文件。

  • 停用位置，并强制所做的更改立即生效。

  • 手动删除分区。

删除 HDFS 存储位置

删除 HDFS 上的存储位置后，清理 HDFS 上的残留文件和快照，如移除 HDFS 存储位置中所述。

删除 USER 存储位置

使用 USER 使用类型创建的存储位置只能包含数据文件，而非临时文件。但是，您可以删除 USER 位置，而不考虑剩下的任何数据文件。此行为与未指定用于 USER 访问的存储位置的行为不同。

检查位置属性

您可以在 STORAGE_LOCATIONS 系统表中检查存储位置的属性，例如是 USER 位置还是仅用于 TEMP 文件。还可以使用此表来确认位置是否已停用。