您可以在开发过程中多次使用此通用配置过程，也可以在每次使用时对其进行修改以便符合不断变化的目标。您可以忽略准备实际数据文件和示例查询等步骤，并运行 Database Designer，而无需针对查询进行优化。例如，对于开发和测试，您可以创建、加载和查询数据库多次，并在最后一次时创建并加载生产数据库。

1.1 - 准备磁盘存储位置

必须创建并指定目录，以便在其中存储编录和数据文件（物理架构）。可以在安装或配置数据库时，或以后在数据库操作期间指定这些位置。编录和数据目录都必须归数据库超级用户所有。

为数据库编录文件指定的目录（目录路径）将跨群集中的所有节点使用。例如，如果指定 /home/catalog 作为编录目录，Vertica 将在所有节点上使用该编录路径。编录目录应始终与任何数据文件目录相分离。

注意

请勿将一个共享目录用于多个节点。每个节点的数据目录和编录目录必须不同。多个节点不能写入相同的数据目录和编录目录。

指定的数据路径也将跨群集中的所有节点使用。指定应该将数据存储在 /home/data 后，Vertica 将在所有数据库节点上使用此路径。

不要使用单个目录包含编录和数据文件。可以在不同的驱动器上存储编录和数据目录，这些目录可能位于主机的本地驱动器（建议用于编录目录）或共享存储位置（例如外部磁盘存储模块或 SAN）上。

在指定编录或数据路径之前，确保数据库的所有节点上都存在父目录。在 admintools 中创建数据库还会创建编录和数据目录，但每个节点上必须存在父目录。

安装期间无需指定磁盘存储位置。但可以通过在 install_vertica 脚本中使用 --data-dir 参数来执行该操作。请参阅在安装期间指定磁盘存储位置。

1.1.1 - 指定数据库创建期间的磁盘存储位置

当您在管理工具中调用创建数据库命令时，有个对话框允许您指定编录和数据位置。群集中的每个主机上都必须存在这些位置，并且这些位置必须归数据库管理员所有。

数据库数据目录

当单击确定 (OK) 时，Vertica 会自动创建以下子目录：

catalog-pathname/database-name/node-name_catalog/data-pathname/database-name/node-name_data/

例如，如果将 /home/dbadmin 的默认值（数据库管理员的主目录）用于 Stock Exchange 示例数据库，则将在群集中的每个节点上创建如下所示的编录和数据目录：

/home/dbadmin/Stock_Schema/stock_schema_node1_host01_catalog/home/dbadmin/Stock_Schema/stock_schema_node1_host01_data

注意

编录和数据路径名称只能包含字母数字字符，不能有前置空格字符。如果不能遵守这些限制条件，将导致数据库创建失败。
如果其他数据库正在使用目录，Vertica 将拒绝覆盖目录。因此，如果您创建了一个用于评估的数据库，然后删除了该数据库，而您想要再使用该数据库名称，请确保您已彻底清理先前使用的磁盘存储位置。有关详细信息，请参阅管理存储位置。

1.1.2 - 指定 MC 上的磁盘存储位置

可采用以下方法，使用 MC 界面指定在群集中存储数据库元数据的位置：

首次配置 MC 时
创建在 MC 上使用的新数据库时

另请参阅

配置管理控制台。

1.1.3 - 配置磁盘使用情况以优化性能

创建初始存储位置之后，以后可以向数据库中添加其他存储位置。此操作不仅可以提供更多空间，还可以用于通过隔离具有不同 I/O 或访问模式的文件来控制磁盘使用情况并提高 I/O 性能。例如，考虑：

通过为临时空间创建单独的存储位置，将执行引擎临时文件与数据文件隔离。
创建设置了标签的存储位置和存储策略，其中选定的数据库对象基于测量的性能统计信息或预测的访问模式而存储在不同存储位置。

另请参阅

管理存储位置

1.1.4 - 与 Vertica 一起使用共享存储

如果使用共享 SAN 存储，请确保在磁盘空间或宽带的节点之间不存在资源争夺情况。

每个主机必须拥有其自己的编录和数据位置。主机不能共享编录或数据位置。
配置存储，以便每个节点都有足够的 I/O 带宽来单独访问存储。

1.1.5 - 查看数据库存储信息

您可以通过管理控制台在 Vertica 群集上查看节点特定信息。有关详细信息，请参阅使用 MC 进行监控。

1.1.6 - 防病毒扫描排除项

您应从防病毒扫描中排除 Vertica 编录和数据目录。某些防病毒产品已被识别为针对 Vertica 目录，有时会锁定或删除其中的文件。这将对 Vertica 性能和数据完整性产生不利影响。

已识别的防病毒产品包括：

ClamAV
SentinelOne
Sophos
Symantec
Twistlock

重要

这份清单并不全面。

1.2 - Vertica 的磁盘空间要求

除了数据库中存储的实际数据外，Vertica 对若干数据重组操作均需磁盘空间，如合并和在群集中管理节点。为获得最佳结果，Vertica 建议对于 K-安全=1 的数据库，每个节点的磁盘利用率不超过百分之六十 (60%) 以允许此类操作继续。

此外，某些查询执行运算符（如哈希联接和排序）若无法在内存 (RAM) 中完成，还会临时需要磁盘空间。您在查询、恢复、刷新投影等过程中可能会遇到此类运算符。所需的磁盘空间量（称为临时空间）取决于查询性质、节点上的数据量以及系统上的并发用户数。默认情况下，数据磁盘上的任何未用磁盘空间均可用作临时空间。但是，Vertica 建议配置与数据磁盘空间分开的临时空间。

另请参阅

配置磁盘使用情况以优化性能。

1.3 - 管理控制台的磁盘空间要求

您可以在群集的任何节点上安装管理控制台，所以除了为数据库群集分配的磁盘空间外，它没有其他特殊的磁盘要求。

1.4 - 准备逻辑架构脚本

为 Vertica 数据库设计逻辑架构与为任何其他 SQL 数据库设计逻辑架构无任何区别。设计逻辑架构中更完整地描述了详细信息。

要创建逻辑架构，请准备一个 SQL 脚本（纯文本文件，扩展名通常为 .sql）以执行下列操作：

创建其他架构（根据需要）。请参阅使用多个架构。
使用 CREATE TABLE 命令在数据库中创建表和列约束。
使用 ALTER TABLE 命令定义必要的表约束。
使用 CREATE VIEW 命令定义表上的任何视图。

可使用下列项生成脚本：

架构设计器应用程序。
从现有数据库提取的架构。
文本编辑器。
作为模板的数据库 example-name_define_schema.sql 脚本之一。（请参阅 /opt/vertica/examples 中的示例数据库目录。）

在您的脚本文件中，请确保以下几点：

每个语句均以分号结尾。
您使用 Vertica 支持的数据类型，如《SQL 参考手册》中所述。

创建数据库后，可通过执行架构脚本来对其进行测试，如创建逻辑架构中所述。如果遇到错误，请删除所有表，更正错误，然后再次运行脚本。

1.5 - 准备数据文件

准备两个数据文件集：

测试数据文件。在完成部分数据加载后，使用测试文件来测试数据库。如果可以，使用部分实际数据文件来准备测试数据文件。
实际数据文件。测试并优化数据库之后，将您的数据文件用于初始数据加载。

如何命名数据文件

可以命名每个数据文件，使其与逻辑架构中的相应表匹配。不用区分大小写。

可以使用扩展名 .tbl 或者希望使用的任何名称。例如，如果表的名称为 Stock_Dimension，则相应数据文件的名称应为 stock_dimension.tbl。当使用多个数据文件时，可在文件名称后附加 _nnn（其中 nnn 是 001 至 999 之间的正整数）。例如，stock_dimension.tbl_001、stock_dimension.tbl_002 以此类推。

1.6 - 准备加载脚本

注意

如果您的目标是测试逻辑架构设计的有效性，则可推迟此步骤。

准备 SQL 脚本以使用 vsql 上的 COPY 或通过 ODBC 将数据直接加载到物理存储中。

您需要加载下列项的脚本：

大型表
小型表

Vertica 建议您使用多个文件来加载大型表。要测试加载过程，请使用大小为 10GB 至 50GB 的文件。该大小具有以下优势：

可使用数据文件之一作为 Database Designer 的示例数据文件。
可以仅加载足够的数据来执行部分数据加载，然后再加载剩余数据。
如果单个加载失败并回退，您不会浪费过多时间。
测试加载过程之后，对于多太字节表，请以 250–500GB 的文件大小中断完全加载。

另请参阅

提示

可将示例数据库中包含的加载脚本用作模板。

1.7 - 创建可选的示例查询脚本

示例查询脚本用于测试架构和加载脚本中是否有错误。

包括您的用户希望针对数据库运行的查询的示例。如果没有执行任何真正的查询，仅编写可收集每个表的计数的简单 SQL。或者，您可以跳过此步骤。

1.8 - 创建空数据库

有两种方法可以创建空数据库：

使用管理控制台。有关详细信息，请参阅使用 MC 创建数据库。
使用管理工具。

尽管可以创建多个数据库（例如，一个用于生产，一个用于测试），安装的每个 Vertica 分析数据库只能有一个活动数据库。

1.8.1 - 创建数据库名称和密码

数据库名称

数据库名称必须遵循以下规则：

1-30 个字符
以字母开头
后跟字母（大写和小写）、数字和/或下划线的任意组合。

数据库名称区分大小写；但是，Vertica 强烈建议您不要使用仅大小写不同的名称创建数据库。例如，请勿创建名称分别为 mydatabase 和 MyDataBase 的两个数据库。

数据库密码

数据库密码可以包含字母、数字和下表中列出的特殊字符。密码不能包含非 ASCII Unicode 字符。

允许的密码长度介于 0-100 个字符之间。数据库超级用户可以使用 ALTER PROFILE 更改 Vertica 用户的最大密码长度。

您可以使用配置文件配置文件指定和控制密码定义。例如，配置文件可以定义密码的最大长度、重用次数、最小数字或所需位数以及其他详细信息。

下表列出了 Vertica 允许在数据库密码中使用的特殊 (ASCII) 字符。特殊字符可以出现在密码字符串的任何位置。例如，mypas$word 或 $mypassword 都是有效的。

当心

如果使用除以下字符之外的任何特殊字符，则有可能会导致数据库不稳定。

另请参阅

1.8.2 - 使用管理工具创建数据库

从管理主机中运行管理工具，如下所示：
```
$ /opt/vertica/bin/admintools
```
如果您正在使用远程终端应用程序，如 PuTTY 或 Cygwin bash shell，请参阅远程终端用户须知。
接受许可协议并指定许可证文件的位置。有关详细信息，请参阅管理许可证。

仅当您第一次运行管理工具时，才需要执行此步骤
在“主菜单 (Main Menu)”上，单击配置菜单 (Configuration Menu)，然后单击确定 (OK)。
在“配置菜单 (Configuration Menu)”上，单击创建数据库 (Create Database)，然后单击确定 (OK)。
输入数据库名称和可选注释，然后单击确定 (OK)。有关命名准则和限制，请参阅创建数据库名称和密码。
为数据库设立超级用户密码。
- 要提供一个密码，请输入该密码，然后单击确定 (OK)。再次输入以确认该密码，然后单击确定 (OK)。
- 如果不想提供密码，请将其留空，然后单击确定 (OK)。如果不设置密码，Vertica 会提示您确认您确实不想为此数据库设立超级用户密码。单击是 (Yes) 创建没有密码的数据库，或者单击否 (No) 设立密码。
当心
如果此时不输入密码，超级用户密码将设置为空。除非数据库用于评估或学术目的，否则 Vertica 强烈建议您输入超级用户密码。有关准则，请参阅创建数据库名称和密码。
从安装 Vertica ( install_vertica -s) 时指定的主机列表中选择要包括在数据库中的主机，然后单击确定 (OK)。
指定用于存储数据和编录文件的目录，然后单击确定 (OK)。

注意
请勿将一个共享目录用于多个节点。每个节点的数据目录和编录目录必须不同。多个节点不能写入相同的数据目录和编录目录。
编录和数据路径名称只能包含字母数字字符，不能有前置空格。如果不能遵守这些限制条件，将导致数据库创建失败。

例如：

编录路径名： /home/dbadmin

数据路径名： /home/dbadmin
查看当前数据库定义 (Current Database Definition) 屏幕，确认它表示您要创建的数据库，然后单击是 (Yes) 继续操作，或者单击否 (No) 修改数据库定义。
如果单击是 (Yes)，Vertica 会创建您定义的数据库，然后显示一条消息，指示已成功创建数据库。

注意

: 对于使用 3 个或更多节点创建的数据库，Vertica 会自动将

K-safety 设置为 1，从而确保在节点出现故障时数据库具有容错能力。有关详细信息，请参阅《管理员指南》和 MARK_DESIGN_KSAFE 中的故障恢复。
单击确定 (OK) 确认消息。

1.9 - 创建逻辑架构

连接到数据库。

在管理工具的“主菜单 (Main Menu)”上，单击连接到数据库 (Connect to Database)，再单击确定 (OK)。

有关详细信息，请参阅连接到数据库。

将显示 vsql 欢迎脚本：
```
Welcome to vsql, the Vertica Analytic Database interactive terminal.
Type:  \h or \? for help with vsql commands
       \g or terminate with semicolon to execute query
       \q to quit

=>
```
运行逻辑架构脚本

在 vsql 中使用 \i meta-command 运行早前准备的 SQL 逻辑架构脚本。
与数据库断开连接

在 vsql 中使用 \q meta-command 返回管理工具。

1.10 - 执行部分数据加载

Vertica 建议，针对大型表，应首先执行部分数据加载并对数据库进行测试，然后再完成全部数据加载。此加载应加载具有代表性的数据量。

加载小型表。

使用 SQL 加载脚本和您之前准备的数据文件来加载小型表数据文件。
部分加载大型表。

使用 SQL 加载脚本和您之前准备的数据文件为每个表加载 10GB 到 50GB 的表数据。

有关投影的详细信息，请参阅投影。

1.11 - 测试数据库

测试数据库以验证其是否正在按照预期效果运行。

检查查询是否存在语法错误并检查执行时间。

使用 vsql \timing meta-command 启用查询执行时间的显示（单位为毫秒）。
执行您先前准备的 SQL 示例查询脚本。
执行多个临时查询。

1.12 - 优化查询性能

优化数据库由优化压缩和调优查询组成。（请参阅创建数据库设计。）

要优化数据库，请使用 Database Designer 创建和部署一个用于优化数据库的设计。请参阅使用 Database Designer 创建完整的设计。

运行 Database Designer 后，使用查询优化中介绍的技巧来提高某些查询类型的性能。

注意

数据库响应时间取决于多个因素，例如，应用程序查询的类型和规模、数据库设计、存储的数据大小和数据类型、可用的计算能力及网络带宽。如果要将节点添加到数据库群集，不必改善每个查询的系统响应时间，尤其是在响应时间已经很短（例如，小于 10 秒，或响应时间不受硬件约束）时。

1.13 - 完成数据加载

要完成加载：

监控系统资源使用情况。

当加载脚本运行时，继续运行 top、free 和 df 实用程序并观察（如监控 Linux 资源使用情况中所述）。可以在群集中的任意节点或所有节点上执行此操作。确保系统未过度交换（查看 top 中的 kswapd ）或耗尽交换空间（查看是否有大量可用交换空间已使用）。

注意
Vertica 需要一个专用服务器。如果加载程序或其他进程占用了大量 RAM，则可能会导致交换。
完成大型表加载。

运行剩余大型表加载脚本。

1.14 - 测试优化的数据库

可通过检查查询执行时间来测试优化的设计：

使用 vsql \timing 元命令启用查询执行时间（以毫秒为单位）的显示。

执行 SQL 示例查询脚本，以测试架构和加载脚本中是否有错误。

注意
包括您的用户希望针对数据库运行的查询的示例。如果没有执行任何真正的查询，仅编写可收集每个表的计数的简单 SQL。或者，您可以跳过此步骤。

执行多个临时查询

运行管理工具并选择连接到数据库 (Connect to Database)。

使用 \i meta-command 执行查询脚本；例如：

vmartdb=> \i vmart_query_03.sql  customer_name   | annual_income
------------------+---------------
 James M. McNulty |        999979
 Emily G. Vogel   |        999998
(2 rows)
Time: First fetch (2 rows): 58.411 ms. All rows formatted: 58.448 ms
vmartdb=> \i vmart_query_06.sql
 store_key | order_number | date_ordered
-----------+--------------+--------------
        45 |       202416 | 2004-01-04
       113 |        66017 | 2004-01-04
       121 |       251417 | 2004-01-04
        24 |       250295 | 2004-01-04
         9 |       188567 | 2004-01-04
       166 |        36008 | 2004-01-04
        27 |       150241 | 2004-01-04
       148 |       182207 | 2004-01-04
       198 |        75716 | 2004-01-04
(9 rows)
Time: First fetch (9 rows): 25.342 ms. All rows formatted: 25.383 ms

数据库优化后，应高效地运行查询。如果发现要优化的查询，可以对设计进行逐步修改和更新。

1.15 - 为国际数据集实施区域设置

区域设置指定用户的语言、所在国家/地区以及任何特殊的可变首选项（例如排序规则）。Vertica 会根据区域设置确定某些字符串函数的行为。此外，区域设置还确定了需要进行排序和比较的各种 SQL 命令（例如聚合 GROUP BY 和 ORDER BY 子句、联接和分析 ORDER BY 子句）的排序规则。

Vertica 数据库的默认区域设置为 en_US@collation=binary（美国英语）。可以定义供数据库中的所有会话使用的新默认区域设置，也可以覆盖单个会话的区域设置。但是，无论会话排序规则如何，请始终采用默认 en_US@collation=binary 排序规则来对投影进行排序。特定区域设置的排序功能会在查询时应用。

如果您将区域设置设为 NULL，则 Vertica 会将区域设置设为 en_US_POSIX。您可以通过发出 vsql 元命令 \locale 将区域设置设回默认区域设置和排序规则。例如：

注意

=> set locale to '';
INFO 2567:  Canonical locale: 'en_US_POSIX'
Standard collation: 'LEN'
English (United States, Computer)
SET
=> \locale en_US@collation=binary;
INFO 2567:  Canonical locale: 'en_US'
Standard collation: 'LEN_KBINARY'
English (United States)
=>  \locale
en_US@collation-binary;

可以通过 ODBC、JDBC 和 ADO.net 设置区域设置。

ICU 区域设置支持

Vertica 将 ICU 库用于区域设置支持；您必须使用 ICU 区域设置语法指定区域设置。数据库会话使用的区域设置并非来源于操作系统（通过 LANG 变量），因此 Vertica 建议您为运行 vsql 的每个节点设置 LANG，如下一个部分所述。

虽然 ICU 库可以指定排序规则、货币和日历首选项，但 Vertica 仅支持排序规则组件。与排序规则无关的任何关键字都将被拒绝。无论会话排序规则如何，始终使用 en_US@collation=binary 排序规则对投影进行排序。特定区域设置的排序功能会在查询时应用。

SET DATESTYLE TO ... 命令提供了日历的一些方面，但 Vertica 仅支持将美元作为货币。

为会话更改 DB 区域设置

此示例将会话区域设置设置为“泰语(Thai)”。

在操作系统级别，针对每个运行 vsql 的节点，按照以下方式将 LANG 变量设置为区域设置语言：
```
export LANG=th_TH.UTF-8
```
注意
如果按照所示方法设置 LANG= 未起作用，则表示可能未安装区域设置的操作系统支持。
针对每个 Vertica 会话（从 ODBC/JDBC 或 vsql 中），设置语言区域设置。

从 vsql 中：
```
\locale th_TH
```
从 ODBC/JDBC 中：
```
"SET LOCALE TO th_TH;"
```
在 PUTTY（或 ssh 终端）中，按照以下步骤更改设置：
```
settings > window > translation > UTF-8
```
单击应用 (Apply)，然后单击保存 (Save)。

加载的所有数据必须采用 UTF-8 格式而非 ISO 格式，如分隔数据中所述。与 UTF-8 不兼容的字符集（例如 ISO 8859-1 (Latin1)）不受支持，因此 SUBSTRING 等函数对于多字节字符而言无法正常工作。因此，区域设置的设置应无法正常工作。如果转换设置 ISO-8859-11:2001 (Latin/Thai) 正常工作，则表示未正确加载数据。要正确转换数据，请使用一个实用程序，例如 Linux iconv。

注意

VARCHAR 和 CHAR 数据类型的最大长度参数是指可以存储在该字段中的八位字节（字节）数，而非字符数。使用多字节 UTF-8 字符时，确保字段的大小可容纳每个字符 1 到 4 个字节，具体取决于数据。

另请参阅

1.15.1 - 为数据库指定默认区域设置

启动数据库之后，默认区域设置配置参数 DefaultSessionLocale 会设置初始区域设置。您可以覆盖各个会话的这个值。

要为数据库设置区域设置，请按照以下方式使用配置参数：

=> ALTER DATABASE DEFAULT SET DefaultSessionLocale = 'ICU-locale-identifier';

例如：

=> ALTER DATABASE DEFAULT SET DefaultSessionLocale = 'en_GB';

1.15.2 - 为会话覆盖默认区域设置

您可以通过两种方式覆盖当前会话的默认区域设置：

VSQL 命令 \locale。例如：

=> \locale en_GBINFO:
INFO 2567:  Canonical locale: 'en_GB'
Standard collation: 'LEN'
English (United Kingdom)

SQL 语句 SET LOCALE。例如：


=> SET LOCALE TO en_GB;
INFO 2567:  Canonical locale: 'en_GB'
Standard collation: 'LEN'
English (United Kingdom)

这两种方法都接受区域设置的短形式和长形式。例如：

=> SET LOCALE TO LEN;
INFO 2567:  Canonical locale: 'en'
Standard collation: 'LEN'
English


=> \locale LEN
INFO 2567:  Canonical locale: 'en'
Standard collation: 'LEN'
English

另请参阅

SET LOCALE

1.15.3 - 服务器区域设置与客户端区域设置

Vertica 将数据库服务器的区域设置与客户端应用程序的区域设置区分开来：

服务器区域设置仅影响服务器端查询处理的排序行为。
客户端应用程序将验证区域设置是否适当，以正确显示字符。

以下部分描述了最佳实践，以确保可预测的结果。

服务器区域设置

服务器会话的区域设置应按照为数据库指定默认区域设置中所述进行设置。如果不同会话的区域设置不同，请的每个会话开始时，从客户端设置服务器的区域设置。

vsql 客户端

如果数据库没有默认的会话区域设置，请将会话的服务器区域设置设置为所需的区域设置。
运行 vsql 客户端的终端仿真器中的区域设置应该设置为等同于服务器端的会话区域设置（ICU 区域设置）。这样就能在服务器上正确排序数据，并在客户端上正确显示数据。
vsql 的所有输入数据应该为 UTF-8，而所有输出数据都以 UTF-8 进行编码。
Vertica 不支持非 UTF-8 编码和关联的区域设置值；
有关设置区域设置和编码的说明，请参阅终端仿真器文档。

ODBC 客户端

ODBC 应用程序可以采用 ANSI 或 Unicode 模式。如果用户应用程序采用 Unicode，ODBC 使用的编码是 UCS-2。如果用户应用程序采用 ANSI，数据必须为单字节 ASCII，这与数据库服务器上使用的 UTF-8 兼容。向 Vertica 服务器传递数据时，ODBC 驱动程序会将 UCS-2 转换为 UTF-8，并会将 Vertica 服务器发来的数据从 UTF-8 转换为 UCS-2。
如果用户应用程序尚未采用 UCS-2，应用程序必须将输入数据转换为 UCS-2，否则会发生异常结果。例如：
- 对于传递到 ODBC API 的非 UCS-2 数据，当它被解释为 UCS-2 时，它可能会导致无效的 UCS-2 符号传递给 API，从而导致错误。
- 在备用编码中提供的符号可以是有效的 UCS-2 符号。如果发生这种情况，则会将不正确的数据插入数据库。
如果数据库没有默认会话区域设置，ODBC 应用程序应该使用 SQLSetConnectAttr 来设置所需的服务器会话区域设置（如果它不同于数据库范围设置）。这样可以在服务器上实现预期的排序规则以及字符串函数行为。

JDBC 和 ADO.NET 客户端

JDBC 和 ADO.NET 应用程序使用 UTF-16 字符集编码并负责将任何非 UTF-16 编码数据转换为 UTF-16。如果违反此编码，同样的警告也适用于 ODBC。
在传递到 Vertica 服务器并将 Vertica 服务器发送的数据从 UTF-8 转换为 UTF-16 时，JDBC 和 ADO.NET 驱动程序会将 UTF-16 数据转换为 UTF-8。
如果在数据库级别没有默认会话区域设置，JDBC 和 ADO.NET 应用程序应该通过执行 SET LOCALE TO 命令设置正确的服务器会话区域设置，以便在服务器上实现预计的排序规则以及字符串函数行为。有关详细信息，请参阅SET LOCALE。

1.16 - 更改事务隔离级别

默认情况下，Vertica 对所有会话使用 READ COMMITTED 隔离级别。您可以更改数据库或给定会话的默认隔离级别。

事务将保留其隔离级别直至其完成，即使在事务处理期间会话的隔离级别发生更改也是如此。Vertica 内部进程（例如 Tuple Mover 和刷新操作）以及 DDL 操作始终以 SERIALIZABLE 隔离级别运行以确保一致性。

数据库隔离级别

配置参数 TransactionIsolationLevel 将指定数据库隔离级别，并用作所有会话的默认值。使用 ALTER DATABASE 更改默认隔离级别。例如：

=> ALTER DATABASE DEFAULT SET TransactionIsolationLevel = 'SERIALIZABLE';
ALTER DATABASE
=> ALTER DATABASE DEFAULT SET TransactionIsolationLevel = 'READ COMMITTED';
ALTER DATABASE

数据库隔离级别的更改仅适用于将来的会话。现有会话及其事务会继续使用原始隔离级别。

使用 SHOW CURRENT 查看数据库隔离级别：

=> SHOW CURRENT TransactionIsolationLevel;
  level   |           name            |    setting
----------+---------------------------+----------------
 DATABASE | TransactionIsolationLevel | READ COMMITTED
(1 row)

会话隔离级别

SET SESSION CHARACTERISTICS AS TRANSACTION 更改特定会话的隔离级别。例如：

=> SET SESSION CHARACTERISTICS AS TRANSACTION ISOLATION LEVEL SERIALIZABLE;
SET

使用 SHOW 查看当前会话的隔离级别：

=> SHOW TRANSACTION_ISOLATION;

另请参阅

事务

2 - 配置参数管理

Vertica 支持一系列影响数据库多个方面行为的配置参数。通过在一个或多个级别使用适当的 ALTER 语句，可以设置这些参数。以下按优先级降序对其进行排列：

用户 (ALTER USER)
会话 (ALTER SESSION)
节点 (ALTER NODE)
数据库 (ALTER DATABASE)

您可以查询系统表 CONFIGURATION_PARAMETERS，获取所有用户可访问参数的当前设置。例如，以下查询获取分区参数的设置：它们的当前值和默认值、可以设置的级别，以及更改后是否需要重新启动数据库才能生效：

=> SELECT parameter_name, current_value, default_value, allowed_levels, change_requires_restart FROM configuration_parameters
     WHERE parameter_name ILIKE '%partition%';
           parameter_name           | current_value | default_value | allowed_levels | change_requires_restart
------------------------------------+---------------+---------------+----------------+-------------------------
 MaxPartitionCount                  | 1024          | 1024          | NODE, DATABASE | f
 PartitionSortBufferSize            | 67108864      | 67108864      | DATABASE       | f
 DisableAutopartition               | 0             | 0             | SESSION, USER  | f
 PatternMatchingMaxPartitionMatches | 3932160       | 3932160       | NODE, DATABASE | f
 PatternMatchingMaxPartition        | 20971520      | 20971520      | NODE, DATABASE | f
 ActivePartitionCount               | 1             | 1             | NODE, DATABASE | f
(6 rows)

有关按类别分组的各个配置参数的详细信息，请参阅配置参数。

设置和清除配置参数

您可以使用适当的 ALTER 语句更改特定的配置参数。这些语句还允许您将配置参数重置为其默认值。例如，以下 ALTER 语句将数据库级别的 ActivePartitionCount 从 1 更改为 2，将会话级别的 DisablePartitionCount 从 0 更改为 1：

=> ALTER DATABASE DEFAULT SET ActivePartitionCount = 2;
ALTER DATABASE
=> ALTER SESSION SET DisableAutopartition = 1;
ALTER SESSION
=> SELECT parameter_name, current_value, default_value FROM configuration_parameters
      WHERE parameter_name IN ('ActivePartitionCount', 'DisableAutopartition');
    parameter_name    | current_value | default_value
----------------------+---------------+---------------
 ActivePartitionCount | 2             | 1
 DisableAutopartition | 1             | 0
(2 rows)

您可以稍后将这些配置参数重置为默认值：

=> ALTER DATABASE DEFAULT CLEAR ActivePartitionCount;
ALTER DATABASE
=> ALTER SESSION CLEAR DisableAutopartition;
ALTER DATABASE
=> SELECT parameter_name, current_value, default_value FROM configuration_parameters
      WHERE parameter_name IN ('ActivePartitionCount', 'DisableAutopartition');
    parameter_name    | current_value | default_value
----------------------+---------------+---------------
 DisableAutopartition | 0             | 0
 ActivePartitionCount | 1             | 1
(2 rows)

当心

Vertica 经过专门设计，可在最小配置更改条件下正常运行。请按照文档中描述的指导意见小心谨慎地更改配置参数。

2.1 - 查看配置参数值

您可以通过两种方式来查看有效的配置参数值：

SHOW 语句
与查询相关的系统表

SHOW 语句

使用以下 SHOW 语句查看有效的配置参数：

SHOW CURRENT：返回有效配置参数值的设置。Vertica 按以下优先级升序检查所有级别的设置：
- 会话
- 节点
- 数据库
如果任何范围内均未设置任何值，则 SHOW CURRENT 将返回参数的默认值。
SHOW DATABASE：显示为数据库设置的配置参数值。
SHOW USER：显示为指定用户和所有用户设置的配置参数。
SHOW SESSION：显示为当前会话设置的配置参数值。
SHOW NODE：显示为节点设置的配置参数值。

如果配置参数需要重新启动才能生效，SHOW CURRENT 语句中的值可能与 SHOW 语句中的值有所不同。要查看哪些参数需要重新启动，请查询 CONFIGURATION_PARAMETERS 系统表。

系统表

您可以在多个系统表中查询配置参数。

SESSION_PARAMETERS 返回会话范围的参数。
CONFIGURATION_PARAMETERS 返回所有范围的参数：数据库、节点和会话。
USER_CONFIGURATION_PARAMETERS 提供对数据库用户有效的用户级别的配置参数信息。

3 - 设计逻辑架构

为 Vertica 数据库设计逻辑架构与为任何其他 SQL 数据库设计逻辑架构相同。逻辑架构由架构、表、视图以及引用完整性约束等对 SQL 用户可见的对象组成。Vertica 支持任何您选择的关系架构设计。

3.1 - 使用多个架构

如果只有一个数据库用户或者几个用户合作共享数据库，使用单个架构即可。但在许多情况下，需要使用更多架构来让用户及其应用程序能在单独的命名空间中创建和访问表。例如，使用更多架构将允许：

许多用户在不相互干扰的情况下访问数据库。

对各个架构进行配置，以便授予特定用户对该架构及其表的访问权限，同时限制其他用户。
使用第三方应用程序来创建在不同架构中名称相同的表，从而防止表冲突。

与其他 RDBMS 不同，Vertica 数据库中的架构不是绑定到一个用户的对象集合。

3.1.1 - 多个架构示例

本部分提供有关何时以及如何使用多个架构分离数据库用户的示例。这些示例分为两类：使用多个专用架构；组合使用专用架构（即仅限单个用户的架构）和共享架构（即跨多个用户共享的架构）。

使用多个专用架构

使用多个专用架构可以在涉及敏感信息时有效地将数据库用户彼此分离。通常，用户仅被授予一个架构及其内容的访问权限，从而提供架构级别的数据库安全性。数据库用户可以同时运行不同的应用程序、同一应用程序的多个副本，甚至同一应用程序的多个实例。这样一来，您便可以合并一个数据库上的应用程序，从而减少管理开销，同时更有效地利用资源。以下示例突出强调使用多个专用架构。

使用多个架构分离用户及其唯一的应用程序

在本示例中，两位数据库用户都为同一家公司工作。一位用户 (HRUser) 使用人力资源 (HR) 应用程序访问敏感的个人资料（如工资），而另一位用户 (MedUser) 通过医疗保健管理应用程序访问与公司医疗保健成本有关的信息。HRUser 不应能够访问公司医疗保健成本信息，而 MedUser 不应能够查看员工个人资料。

为了允许这些用户访问他们需要的数据，同时限制他们查看不应看到的数据，我们创建了两个具有适当用户访问权限的架构，如下所示：

HRSchema — 此架构归 HRUser 所有，且通过 HR 应用程序进行访问。
HRSchema — 此架构归 MedUser 所有，且通过医疗保健管理应用程序进行访问。

使用多个架构支持多租户

本示例与最后一个示例相类似，它也是通过将用户分离到不同的架构中，限制对敏感数据的访问。但在这种情况下，每位用户都使用同一应用程序的一个虚拟实例。

一个相关示例是零售市场分析公司，该公司向大型零售商提供数据和“软件即服务”(SaaS)，帮助他们确定使用哪些促销方法能够最有效地推动客户销售额。

在本示例中，每位数据库用户相当于一位零售商，且每位用户只能访问自己的架构。零售市场分析公司需向每位零售客户提供同一应用程序的一个虚拟实例，且每个实例指向该用户的特定架构，以便在其中创建和更新表。这些架构中的表是由同一应用程序的实例创建的，所以使用相同名称，但由于它们处于单独的架构中，因此不会发生冲突。

此数据库中的架构示例可以是：

MartSchema — 归一家大型连锁百货商店 MartUser 所有的架构。
PharmSchema — 归一家大型连锁药店 PharmUser 所有的架构。

使用多个架构迁移至应用程序的新版本

使用多个架构是迁移至新软件应用程序版本的一种有效方法。在这种情况下，需创建一个新架构来支持软件的新版本，原有架构将保留到不再需要为止，以支持软件的原始版本。这称为“滚动应用程序升级”。

例如，公司可能使用 HR 应用程序存储员工资料。以下架构可用于软件的原始版本和更新版本：

HRSchema — 此架构归原始 HR 应用程序的架构用户 HRUser 所有。
V2HRSchema — 此架构归新版 HR 应用程序的架构用户 V2HRUser 所有。

组合使用专用架构和共享架构

在上述示例显示的情况中，数据库中的所有架构都是专用的，且用户之间不共享信息。但是，用户可能希望共享公共信息。例如，在零售案例中，MartUser 和 PharmUser 可能希望将其每个商店的特定产品销售额与整个行业内每个商店销售额的平均值相比较。由于此信息是行业平均值，不是特定于任何零售连锁店，因此可以将其放置在两位用户都被授予 USAGE 权限的架构中。

此数据库中的架构示例可能是：

MartSchema — 归一家大型连锁百货商店 MartUser 所有的架构。
PharmSchema — 归一家大型连锁药店 PharmUser 所有的架构。
IndustrySchema — 此架构归 DBUser（来自零售市场分析公司）所有，而 MartUser 和 PharmUser 对此架构具有 USAGE 权限。零售商不太可能获得除 USAGE（对于此架构）和 SELECT（对于其中的一个或多个表）以外的任何权限。

3.1.2 - 创建架构

您可以根据需要为数据库创建任意数量的架构。例如，您可以为每个数据库用户创建一个架构。但是，架构与用户并不像在 Oracle 中一样是同义词。

默认情况下，只有超级用户可以创建架构或者授予某个用户创建架构的权限。（请参阅《SQL 参考手册》中的GRANT（数据库）。）

要创建架构，请使用 CREATE SCHEMA 语句，如《SQL 参考手册》中所述。

3.1.3 - 指定多个架构中的对象

创建两个或多个架构后，每个 SQL 语句或函数必须识别与所引用的对象相关联的架构。您可以通过以下方式在多个架构中指定一个对象：

通过使用以点分隔的架构名称和对象名称来限定对象名称。例如，若要指定位于 Schema1 中的 MyTable，请将名称限定为 Schema1.MyTable。
如果引用的某个对象未加以限定，可使用包括所需架构的搜索路径。通过设置搜索路径，Vertica 将自动搜索指定架构来查找对象。

3.1.4 - 设置搜索路径

每个用户会话都有一个架构搜索路径。Vertica 使用此搜索路径来查找未按架构名称限定的表和用户定义函数 (UDF)。会话搜索路径最初是从用户的配置文件中设置的。您可以随时通过调用 SET SEARCH_PATH 来更改会话的搜索路径。此搜索路径一直有效，直到处理下一个 SET SEARCH_PATH 语句或会话结束为止。

查看当前搜索路径

SHOW SEARCH_PATH 返回会话的当前搜索路径。例如：


=> SHOW SEARCH_PATH;
    name     |                      setting
-------------+---------------------------------------------------
 search_path | "$user", public, v_catalog, v_monitor, v_internal

架构按优先级降序排列。第一个架构在搜索顺序中具有最高优先级。如果此架构存在，它也会定义为当前架构，供以非限定名称创建的表使用。您可以通过调用函数 CURRENT_SCHEMA 来识别当前架构：

=> SELECT CURRENT_SCHEMA;
 current_schema
----------------
 public
(1 row)

设置用户搜索路径

会话搜索路径最初是从用户的配置文件中设置的。如果用户配置文件中的搜索路径不是通过 CREATE USER 或 ALTER USER 设置，则该搜索路径将设置为数据库默认值：

=> CREATE USER agent007;
CREATE USER
=> \c - agent007
You are now connected as user "agent007".
=> SHOW SEARCH_PATH;
    name     |                      setting
-------------+---------------------------------------------------
 search_path | "$user", public, v_catalog, v_monitor, v_internal

$user 解析为会话用户名（在此示例中为 agent007）且具有最高优先级。如果架构 agent007 存在，Vertica 将开始在该架构中搜索不合格的表。此外， CURRENT_SCHEMA 的调用将返回此架构。否则，Vertica 使用 public 作为当前架构并开始在其中进行搜索。

使用 ALTER USER 可修改现有用户的搜索路径。这些更改会覆盖搜索路径中的所有非系统架构，其中包括 $USER。系统架构保持不变。对用户搜索路径的更改仅在用户启动新会话时生效；当前会话不受影响。

重要

修改用户的搜索路径之后，请验证用户是否具有访问权限，能否访问更新后的搜索路径上的所有架构。

例如，以下语句将修改 agent007 的搜索路径，并授予对新搜索路径上的架构和表的访问权限：

=> ALTER USER agent007 SEARCH_PATH store, public;
ALTER USER
=> GRANT ALL ON SCHEMA store, public TO agent007;
GRANT PRIVILEGE
=> GRANT SELECT ON ALL TABLES IN SCHEMA store, public TO agent007;
GRANT PRIVILEGE
=> \c - agent007
You are now connected as user "agent007".
=> SHOW SEARCH_PATH;
    name     |                     setting
-------------+-------------------------------------------------
 search_path | store, public, v_catalog, v_monitor, v_internal
(1 row)

要验证用户的搜索路径，请查询系统表 USERS：

=> SELECT search_path FROM USERS WHERE user_name='agent007';
                   search_path
-------------------------------------------------
 store, public, v_catalog, v_monitor, v_internal
(1 row)

要将用户的搜索路径恢复为数据库默认设置，请调用 ALTER USER 并将搜索路径设置为 DEFAULT。例如：


=> ALTER USER agent007 SEARCH_PATH DEFAULT;
ALTER USER
=> SELECT search_path FROM USERS WHERE user_name='agent007';
                    search_path
---------------------------------------------------
 "$user", public, v_catalog, v_monitor, v_internal
(1 row)

忽略的搜索路径架构

Vertica 仅在当前用户具有访问权限的现有架构中进行搜索。如果搜索路径中的架构不存在或用户缺乏对其的访问权限，Vertica 会默认将其排除搜索。例如，如果 agent007 缺乏架构 public 的 SELECT 权限，Vertica 会默认为跳过此架构。仅当 Vertica 在搜索路径的任何位置都找不到表时，它才会返回错误。

设置会话搜索路径

Vertica 最初会根据用户的配置文件来设置会话的搜索路径。您可以使用 SET SEARCH_PATH 更改当前会话的搜索路径。您可以通过两种方式使用 SET SEARCH_PATH：

显式将会话搜索路径设置为一个或多个架构。例如：


=> \c - agent007
You are now connected as user "agent007".
dbadmin=> SHOW SEARCH_PATH;
    name     |                      setting
-------------+---------------------------------------------------
 search_path | "$user", public, v_catalog, v_monitor, v_internal
(1 row)

=> SET SEARCH_PATH TO store, public;
SET
=> SHOW SEARCH_PATH;
    name     |                     setting
-------------+-------------------------------------------------
 search_path | store, public, v_catalog, v_monitor, v_internal
(1 row)

将会话搜索路径设置为数据库默认值：


=> SET SEARCH_PATH TO DEFAULT;
SET
=> SHOW SEARCH_PATH;
    name     |                      setting
-------------+---------------------------------------------------
 search_path | "$user", public, v_catalog, v_monitor, v_internal
(1 row)

SET SEARCH_PATH 覆盖搜索路径中的所有非系统架构，其中包括 $USER。系统架构保持不变。

3.1.5 - 创建跨越多个架构的对象

Vertica 支持跨多个架构引用表的视图。例如，用户可能需要将员工薪资与行业平均值进行比较。在这种情况下，应用程序将查询两个架构：

平均薪资的共享架构 IndustrySchema
特定于公司的工资信息的专用架构 HRSchema

最佳实践： 在创建跨越多个架构的对象时，请使用限定的表名。如果架构内的查询路径或表结构在未来的某个日期发生变化，此命名约定可避免发生混淆。

3.2 - 架构中的表

在 Vertica 中，您可以分别通过 CREATE TABLE 和 CREATE TEMPORARY TABLE 创建永久表和临时表。

有关这两种类型的详细信息，请参阅创建表和创建临时表。

永久表

CREATE TABLE 在 Vertica 逻辑架构中创建一个表。例如：

CREATE TABLE vendor_dimension (
   vendor_key        INTEGER      NOT NULL PRIMARY KEY,
   vendor_name       VARCHAR(64),
   vendor_address    VARCHAR(64),
   vendor_city       VARCHAR(64),
   vendor_state      CHAR(2),
   vendor_region     VARCHAR(32),
   deal_size         INTEGER,
   last_deal_update  DATE

);

有关详细信息，请参阅创建表。

临时表

CREATE TEMPORARY TABLE 创建数据仅存在于当前会话中的表。临时表数据容始终对其他会话不可见。

临时表可用于将复杂查询处理分为多步来进行。通常情况下，报告工具会容纳创建报告过程中产生的中间结果 — 例如，工具首先获取一个结果集，然后查询该结果集，等等。

CREATE TEMPORARY TABLE 可分别通过关键字 GLOBAL 和 LOCAL 在两个范围（全局和本地）创建表：

GLOBAL （默认值）：表定义对所有会话均可见。但是，表数据限定在会话范围内。
LOCAL：表定义仅对在其中创建了它的会话可见。当会话结束时，Vertica 会自动删除表。

有关详细信息，请参阅创建临时表。

4 - 创建数据库设计

设计是用于优化查询性能的物理存储计划。Vertica 中的数据以物理方式存储在投影中。最初使用 INSERT、COPY（或 COPY LOCAL）将数据加载到某个表中时，Vertica 会为该表创建一个默认的超投影。该超投影可确保所有数据均可用于查询。但是，这些超投影可能不会优化数据库性能，这导致查询性能较低、数据压缩较慢。

要提高性能，请为 Vertica 数据库创建一个设计以优化查询性能和数据压缩。您可以通过多种方式创建设计：

使用 Database Designer，这是一种建议用于设计以获得最佳性能的工具。
手动创建设计
使用 Database Designer 创建初始设计，然后手动对其进行修改。

Database Designer 可帮助您将花费在手动数据库优化上的时间降至最低。也可以使用 Database Designer 按照要求以增量方式重新设计数据库，比如工作负载随时间的变化。

Database Designer 作为后台进程运行。如果您需要通宵运行一个大型设计，这非常有用。由于无需活动的 SSH 会话，因此设计和部署操作会在会话结束时继续无中断运行。

提示

Vertica 建议您首先使用 Database Designer 中的“全面 (Comprehensive)”设置全局优化数据库。如果全面设计的性能不够充分，可使用增量设计以手动方式设计自定义投影，如创建自定义设计中所述。

4.1 - 关于 Database Designer

Vertica Database Designer 使用复杂的策略创建一个设计，该设计可以为临时查询和特定查询提供卓越的性能，同时高效地使用磁盘空间。

在设计过程中，Database Designer 会分析逻辑架构定义、示例数据和示例查询，然后以您自动或手动部署的 SQL 脚本的形式创建一个物理架构（投影）。此脚本创建一个最小的超投影集来保证 K-safety。

大多数情况下，Database Designer 创建的投影可在物理约束范围内实现出色的查询性能，同时高效地使用磁盘空间。

常规设计选项

当您运行 Database Designer 时，可使用几个常规选项：

创建全面或增量设计。
优化查询的执行、加载或平衡这两者。
需要 K-safety。
如果可行，建议使用未分段投影。
在创建设计前分析统计信息。

设计输入

Database Designer 的设计基于您提供的以下信息：

您通常在正常数据库操作期间运行的设计查询。
包含示例数据的设计表。

输出

Database Designer 生成以下输出：

一个设计脚本，该脚本以满足优化目标以及在整个群集中均匀分布数据的方式为设计创建投影。
一个部署脚本，该脚本为设计创建和刷新投影。为了获得全面的设计，部署脚本包含一些用于移除非优化投影的命令。部署脚本包括完整的设计脚本。
一个备份脚本，该脚本包含一些 SQL 语句，用于部署在部署前存在于系统上的设计。如果您需要还原到部署前的设计，此文件非常有用。

设计限制

Database Designer 生成的设计：

不包括实时聚合投影或 Top-K 投影。必须手动创建这些投影。请参阅CREATE PROJECTION。
不要在 LONG VARBINARY 和 LONG VARCHAR 列上对投影进行排序、分段或分区。

设计后选项

运行 Database Designer 时，您可以选择在创建部署脚本后自动部署您的设计，或者在审查并测试了设计后手动部署该设计。Vertica 建议先在非生产服务器上测试设计，然后再将该设计部署到生产服务器。

4.2 - Database Designer 如何创建设计

设计建议

Database Designer 生成的设计可包括以下建议：

以相同的顺序对伙伴实例投影排序，这样可显著提高加载、恢复和站点节点性能。所有伙伴实例投影均具有相同的基本名，因此可将其标识为一个组。

注意
如果您手动创建投影，Database Designer 建议使用排序顺序相同的伙伴实例（如果其尚不存在）。默认情况下，Database Designer 建议超级和非超级分段投影使用排序顺序和分段相同的伙伴实例。
对于全面设计，接受的查询数不受限制。
标识类似设计查询并为其分配一个签名。

对于具有相同签名的查询，Database Designer 会根据此签名具有的查询数为这些查询加权，然后再在创建设计时考虑加权的查询。
建议创建投影时在群集上均匀分布数据，以便将数据偏离降至最低。
考虑使用 UPDATE、DELETE 和 SELECT 语句，以生成质量更高的设计。

4.3 - Database Designer 访问要求

默认情况下，只有具有 DBADMIN 角色的用户才能运行 Database Designer。非 DBADMIN 用户只有在被授予必要的权限和 DBDUSER 角色之后，才能运行 Database Designer，如下所述。此外，您还可以允许用户在管理控制台上运行 Database Designer（请参阅允许用户在管理控制台上运行 Database Designer）。

使用 CREATE LOCATION 将临时文件夹添加到所有群集节点中：
```
=> CREATE LOCATION '/tmp/dbd' ALL NODES;
```
使用 GRANT DATABASE 授予所需用户在当前（默认）数据库上创建架构的 CREATE 权限：
```
=> GRANT CREATE ON DATABASE DEFAULT TO dbd-user;
```
使用 GRANT ROLE 将 DBDUSER 角色授予 dbd-user：
```
=> GRANT DBDUSER TO dbd-user;
```
在群集的所有节点上，使用 GRANT LOCATION 授予 dbd-user 临时文件夹的访问权限。
```
=> GRANT ALL ON LOCATION '/tmp/dbd' TO dbd-user;
```

分别使用 GRANT SCHEMA 和 GRANT TABLE 授予 dbd-user 对一个或多个数据库架构及其表的权限：

=> GRANT ALL ON SCHEMA this-schema[,...] TO dbd-user;
=> GRANT ALL ON ALL TABLES IN SCHEMA this-schema[,...] TO dbd-user;

通过以下方式之一启用 dbd-user 中的 DBDUSER 角色：
- 对于 dbd-user，使用 SET ROLE 启用 DBDUSER 角色：
```
=> SET ROLE DBDUSER;
```
- 对于 DBADMIN，使用 ALTER USER 在每次登录时自动为 dbd-user 启用 DBDUSER 角色：
```
=> ALTER USER dbd-user DEFAULT ROLE DBDUSER;
```

重要

当您授予 DBDUSER 角色时，请确保将资源池与该用户相关联以在 Database Designer 运行期间管理资源。

多个用户可以同时运行 Database Designer，他们互相之间不会出现干扰，也不会耗尽群集的所有资源。当一个用户使用管理控制台或通过编程方式运行 Database Designer 时，其执行操作通常会限制在该用户的资源池内，但不太密集的任务可能会使用系统资源。

使用户能够在管理控制台上运行 Database Designer

如上文所述，已授予 DBDUSER 角色和所需权限的用户也可以在管理控制台上运行 Database Designer：

以超级用户身份登录管理控制台。
单击 MC 设置 (MC Settings)。
单击用户管理 (User Management)。
指定 MC 用户
- 要创建 MC 用户，请单击 添加 (Add)。
- 要使用现有的 MC 用户，请选择该用户并单击 编辑 (Edit)。
单击数据库访问级别 (DB access level) 窗口旁边的添加 (Add)。
在添加权限 (Add Permissions) 窗口中：
1. 从选择数据库 (Choose a database) 下拉列表中，选择要为其创建设计的数据库。
2. 在 数据库用户名 (Database username) 字段中，输入您先前创建的 dbd-user 用户名。
3. 在数据库密码字段中，输入数据库密码。
4. 在限制访问 (Restrict access) 下拉列表中，选择此用户具有的 MC 用户级别。
单击确定 (OK) 以保存更改。
退出 MC 超级用户帐户。

现在，MC 用户已映射到 dbd-user。以 MC 用户身份登录，然后使用 Database Designer 为数据库创建优化设计。

DBDUSER 功能和限制

对于 DBDUSER，以下约束适用：

设计必须将 K-safety 设置为等于系统 K-safety。如果设计因缺少足够的表伙伴实例投影而违反 K-safety，则设计不会完成。
只有部署设计完成之后，才可显式推进 Ancient History Mark (AHM)（例如，调用 MAKE_AHM_NOW）。

创建设计时，会自动获得处理该设计的权限。其他任务可能需要额外的权限：

提交设计表

对于设计表架构的 USAGE
对于设计表的 OWNER

提交单个设计查询

对于设计查询的 EXECUTE

提交设计查询文件

对于查询文件所在存储位置的读取权限
文件中所有查询的 EXECUTE 权限

根据用户查询结果提交设计查询

对于用户查询的 EXECUTE 权限
从用户查询结果中获取的每个设计查询的 EXECUTE 权限

创建设计和部署脚本

对于设计脚本存储位置的 WRITE 权限
对于部署脚本存储位置的 WRITE 权限

4.4 - 记录 Database Designer 的投影数据

当您运行 Database Designer 时，优化器会根据您指定的选项提出一组理想的投影建议。当您部署设计时，Database Designer 会根据这些投影创建设计。但是，由于空间或预算约束，Database Designer 可能无法创建所有建议的投影。此外，Database Designer 可能无法使用理想条件实施投影。

要获取有关投影的信息，请先启用 Database Designer 日志记录功能。启用后，Database Designer 会将有关所建议投影的信息存储在两个数据收集器表中。当 Database Designer 部署设计后，这些日志便会包含实际创建的所建议投影的相关信息。部署后，日志包含下列项的相关信息：

优化器提出的投影建议
Database Designer 在部署设计时实际创建的投影
Database Designer 创建但不具备优化器所标识的理想条件的投影
用于创建所有投影的 DDL
列优化

如果您未立即部署设计，请查看日志以确定是否需要进行更改。如果已经部署设计，则仍可以手动创建某些 Database Designer 未创建的投影。

要启用 Database Designer 日志记录功能，请参阅启用 Database Designer 的日志记录。

要查看记录的信息，请参阅查看 Database Designer 日志。

4.4.1 - 启用 Database Designer 的日志记录

默认情况下，不会记录优化器提出并且 Database Designer 部署的投影的相关信息。

要启用 Database Designer 日志记录，请输入以下命令：

=> ALTER DATABASE DEFAULT SET DBDLogInternalDesignProcess = 1;

要禁用 Database Designer 日志记录，请输入以下命令：

=> ALTER DATABASE DEFAULT SET DBDLogInternalDesignProcess = 0;

另请参阅

4.4.2 - 查看 Database Designer 日志

您可以在两个数据收集器表中找到 Database Designer 考虑和部署的投影的相关数据：

DC_DESIGN_PROJECTION_CANDIDATES
DC_DESIGN_QUERY_PROJECTION_CANDIDATES

DC_DESIGN_PROJECTION_CANDIDATES

DC_DESIGN_PROJECTION_CANDIDATES 表包含有关优化器建议的所有投影的信息。该表还包括创建它们的 DDL。is_a_winner 字段指示此投影是否是实际部署的设计的一部分。要查看 DC_DESIGN_PROJECTION_CANDIDATES 表，请输入：

=> SELECT *  FROM DC_DESIGN_PROJECTION_CANDIDATES;

DC_DESIGN_QUERY_PROJECTION_CANDIDATES

DC_DESIGN_QUERY_PROJECTION_CANDIDATES 表列出所有设计查询的计划特征。

可能的特征包括：

FULLY DISTRIBUTED JOIN
MERGE JOIN
GROUPBY PIPE
FULLY DISTRIBUTED GROUPBY
RLE PREDICATE
VALUE INDEX PREDICATE
LATE MATERIALIZATION

对于所有设计查询，DC_DESIGN_QUERY_PROJECTION_CANDIDATES 表包括以下计划特征信息：

优化程序路径成本。
Database Designer 优势。
理想的计划特征及其描述，用于标识应如何优化引用的投影。
如果已部署设计，实际计划特征及其描述将包括在表中。此信息用于标识所引用投影的实际优化方式。

由于大多数投影都具有多个优化，因此每个投影通常具有多个行。要查看 DC_DESIGN_QUERY_PROJECTION_CANDIDATES 表，请输入：

=> SELECT *  FROM DC_DESIGN_QUERY_PROJECTION_CANDIDATES;

要查看这些表中的示例数据，请参阅 Database Designer 日志示例数据。

4.4.3 - Database Designer 日志示例数据

在以下示例中，Database Designer 在为 VMart 示例数据库创建全面设计之后，创建了日志。输出显示 DC_DESIGN_PROJECTION_CANDIDATES 表中的两个记录。

第一个记录包含有关 customer_dimension_dbd_1_sort_$customer_gender$__$annual_income$ projection 的信息。此记录包含 Database Designer 用于创建投影的 CREATE PROJECTION 语句。is_a_winner 列为 t，表示 Database Designer 在部署设计时创建了此投影。

第二个记录包含有关 product_dimension_dbd_2_sort_$product_version$__$product_key$ projection 的信息。对于此投影，is_a_winner 列为 f。优化器建议 Database Designer 在设计过程中创建此投影。但是，Database Designer 在部署设计时，没有创建该投影。日志包含 CREATE PROJECTION 语句的 DDL。如果要手动添加投影，您可以使用该 DDL。有关详细信息，请参阅手动创建设计。

=> SELECT * FROM dc_design_projection_candidates;
-[ RECORD 1 ]--------+---------------------------------------------------------------
time                 | 2014-04-11 06:30:17.918764-07
node_name            | v_vmart_node0001
session_id           | localhost.localdoma-931:0x1b7
user_id              | 45035996273704962
user_name            | dbadmin
design_id            | 45035996273705182
design_table_id      | 45035996273720620
projection_id        | 45035996273726626
iteration_number     | 1
projection_name      | customer_dimension_dbd_1_sort_$customer_gender$__$annual_income$
projection_statement | CREATE PROJECTION v_dbd_sarahtest_sarahtest."customer_dimension_dbd_1_
            sort_$customer_gender$__$annual_income$"
(
customer_key ENCODING AUTO,
customer_type ENCODING AUTO,
customer_name ENCODING AUTO,
customer_gender ENCODING RLE,
title ENCODING AUTO,
household_id ENCODING AUTO,
customer_address ENCODING AUTO,
customer_city ENCODING AUTO,
customer_state ENCODING AUTO,
customer_region ENCODING AUTO,
marital_status ENCODING AUTO,
customer_age ENCODING AUTO,
number_of_children ENCODING AUTO,
annual_income ENCODING AUTO,
occupation ENCODING AUTO,
largest_bill_amount ENCODING AUTO,
store_membership_card ENCODING AUTO,
customer_since ENCODING AUTO,
deal_stage ENCODING AUTO,
deal_size ENCODING AUTO,
last_deal_update ENCODING AUTO
)
AS
SELECT customer_key,
customer_type,
customer_name,
customer_gender,
title,
household_id,
customer_address,
customer_city,
customer_state,
customer_region,
marital_status,
customer_age,
number_of_children,
annual_income,
occupation,
largest_bill_amount,
store_membership_card,
customer_since,
deal_stage,
deal_size,
last_deal_update
FROM public.customer_dimension
ORDER BY customer_gender,
annual_income
UNSEGMENTED ALL NODES;
is_a_winner          | t
-[ RECORD 2 ]--------+-------------------------------------------------------------
time                 | 2014-04-11 06:30:17.961324-07
node_name            | v_vmart_node0001
session_id           | localhost.localdoma-931:0x1b7
user_id              | 45035996273704962
user_name            | dbadmin
design_id            | 45035996273705182
design_table_id      | 45035996273720624
projection_id        | 45035996273726714
iteration_number     | 1
projection_name      | product_dimension_dbd_2_sort_$product_version$__$product_key$
projection_statement | CREATE PROJECTION v_dbd_sarahtest_sarahtest."product_dimension_dbd_2_
        sort_$product_version$__$product_key$"
(
product_key ENCODING AUTO,
product_version ENCODING RLE,
product_description ENCODING AUTO,
sku_number ENCODING AUTO,
category_description ENCODING AUTO,
department_description ENCODING AUTO,
package_type_description ENCODING AUTO,
package_size ENCODING AUTO,
fat_content ENCODING AUTO,
diet_type ENCODING AUTO,
weight ENCODING AUTO,
weight_units_of_measure ENCODING AUTO,
shelf_width ENCODING AUTO,
shelf_height ENCODING AUTO,
shelf_depth ENCODING AUTO,
product_price ENCODING AUTO,
product_cost ENCODING AUTO,
lowest_competitor_price ENCODING AUTO,
highest_competitor_price ENCODING AUTO,
average_competitor_price ENCODING AUTO,
discontinued_flag ENCODING AUTO
)
AS
SELECT product_key,
product_version,
product_description,
sku_number,
category_description,
department_description,
package_type_description,
package_size,
fat_content,
diet_type,
weight,
weight_units_of_measure,
shelf_width,
shelf_height,
shelf_depth,
product_price,
product_cost,
lowest_competitor_price,
highest_competitor_price,
average_competitor_price,
discontinued_flag
FROM public.product_dimension
ORDER BY product_version,
product_key
UNSEGMENTED ALL NODES;
is_a_winner          | f
.
.
.

以下示例显示了 DC_DESIGN_QUERY_PROJECTION_CANDIDATES 中两个记录的内容。这两个行应用于投影 ID 45035996273726626。

在第一个记录中，优化器建议 Database Designer 为 GROUPBY PIPE 算法优化 customer_gender 列。

在第二个记录中，优化器建议 Database Designer 为后续执行的实体化优化 public.customer_dimension 表。后续执行的实体化可以提高可能会溢出到磁盘的联接的性能。

=> SELECT * FROM dc_design_query_projection_candidates;
-[ RECORD 1 ]-----------------+------------------------------------------------------------
time                           | 2014-04-11 06:30:17.482377-07
node_name                      | v_vmart_node0001
session_id                     | localhost.localdoma-931:0x1b7
user_id                        | 45035996273704962
user_name                      | dbadmin
design_id                      | 45035996273705182
design_query_id                | 3
iteration_number               | 1
design_table_id                | 45035996273720620
projection_id                  | 45035996273726626
ideal_plan_feature             | GROUP BY PIPE
ideal_plan_feature_description | Group-by pipelined on column(s) customer_gender
dbd_benefits                   | 5
opt_path_cost                  | 211
-[ RECORD 2 ]-----------------+------------------------------------------------------------
time                           | 2014-04-11 06:30:17.48276-07
node_name                      | v_vmart_node0001
session_id                     | localhost.localdoma-931:0x1b7
user_id                        | 45035996273704962
user_name                      | dbadmin
design_id                      | 45035996273705182
design_query_id                | 3
iteration_number               | 1
design_table_id                | 45035996273720620
projection_id                  | 45035996273726626
ideal_plan_feature             | LATE MATERIALIZATION
ideal_plan_feature_description | Late materialization on table public.customer_dimension
dbd_benefits                   | 4
opt_path_cost                  | 669
.
.
.

您可以查看 Database Designer 为其创建的投影而实施的实际计划功能。为此，请查询 V_INTERNAL.DC_DESIGN_QUERY_PROJECTIONS 表：

=> select * from v_internal.dc_design_query_projections;
-[ RECORD 1 ]-------------------+-------------------------------------------------------------
time                            | 2014-04-11 06:31:41.19199-07
node_name                       | v_vmart_node0001
session_id                      | localhost.localdoma-931:0x1b7
user_id                         | 45035996273704962
user_name                       | dbadmin
design_id                       | 45035996273705182
design_query_id                 | 1
projection_id                   | 2
design_table_id                 | 45035996273720624
actual_plan_feature             | RLE PREDICATE
actual_plan_feature_description | RLE on predicate column(s) department_description
dbd_benefits                    | 2
opt_path_cost                   | 141
-[ RECORD 2 ]-------------------+-------------------------------------------------------------
time                            | 2014-04-11 06:31:41.192292-07
node_name                       | v_vmart_node0001
session_id                      | localhost.localdoma-931:0x1b7
user_id                         | 45035996273704962
user_name                       | dbadmin
design_id                       | 45035996273705182
design_query_id                 | 1
projection_id                   | 2
design_table_id                 | 45035996273720624
actual_plan_feature             | GROUP BY PIPE
actual_plan_feature_description | Group-by pipelined on column(s) fat_content
dbd_benefits                    | 5
opt_path_cost                   | 155

4.5 - 常规设计设置

在运行 Database Designer 之前，您必须提供待创建设计的具体信息。

设计名称

使用 Database Designer 创建的所有设计均必须具有符合标识符中所述约定的唯一名称，且长度不超过 32 个字符（如果您在管理工具或管理控制台中使用 Database Designer，则不超过 16 个字符）。

设计名称将合并到 Database Designer 生成的文件（例如其部署脚本）的名称中。这可以帮助您区分与不同设计关联的文件。

设计类型

Database Designer 可以创建两种不同的设计类型：全面设计或增量设计。

全面设计

全面设计将为指定架构中的所有表创建一个初始设计或替换设计。当您创建新的数据库时创建全面设计。

要帮助 Database Designer 创建一个有效的设计，请将具有代表性的数据加载到表中，然后再开始设计流程。当您将数据加载到表时，Vertica 会创建一个未经过优化的超投影，这样 Database Designer 便拥有了一些有待优化的投影。如果某个表不包含任何数据，Database Designer 将无法优化该表。

或者，为 Database Designer 提供您计划使用的具有代表性的查询，以便 Database Designer 可以优化这些查询的设计。如果您未提供任何查询，Database Designer 会创建一个超投影常规优化方案，该方案可最大限度减少存储并且不包含任何查询特定的投影。

在全面设计期间，Database Designer 会创建一些用于执行以下操作的部署脚本：

创建投影以优化查询性能。
当 Database Designer 更改其决定保留的现有投影的编码时，创建替换伙伴实例投影。

增量设计

创建和部署全面的数据库设计之后，数据库可能会随着时间以各种方式发生更改。您可以考虑定期使用 Database Designer 创建增量设计，以应对这些更改。涉及增量设计的更改可能会包括：

重要数据的添加或更新
您定期运行的新查询或修改后的查询
一个或多个查询的性能问题
架构更改

优化目标

Database Designer 可以为以下三个目标之一优化设计：

加载：针对负载进行优化的设计可以最大限度减小数据库大小，但这可能会降低查询性能。
查询：针对查询性能进行了优化的设计。这些设计通常倾向于快速执行查询而不是负载优化，因此会导致更大的存储空间。
余额：在数据库大小和查询性能之间实现平衡的设计。

一个完全优化的查询具有的优化率为 0.99。优化率是在 Database Designer 生成的设计中实现的查询好处与在理想计划中实现的查询好处的比率。优化比例在 designer.log 的 OptRatio 参数中设置。

设计表

Database Designer 需要一个或多个包含适量示例数据（大约 10 GB）的表，以创建最佳设计。具有大量数据的设计表将对 Database Designer 性能产生不利影响。数据太少的设计表则会导致 Database Designer 无法创建优化设计。如果设计表没有数据，则 Database Designer 将忽略它。

注意

如果在表添加到设计之后将其删除，Database Designer 将无法构建或部署设计。

设计查询

针对查询性能优化的数据库设计需要一组具有代表性的查询，或设计查询。对于增量设计，设计查询为必需项，全面设计则为可选项。您将在作为输入提供给 Database Designer 的 SQL 文件中列出设计查询。当您向设计中添加查询以及当查询再次构建设计时，Database Designer 会检查查询的有效性。如果查询无效，Database Designer 会将其忽略。

如果您使用管理控制台创建数据库设计，则可从输入文件或系统表 QUERY_REQUESTS 中提交查询。有关详细信息，请参阅手动创建设计。

设计查询的最大数量取决于设计类型：对于全面设计，最大查询次数 ≤200 次；对于增量设计，最大查询次数 ≤100 次。或者，您可以为设计查询分配权重，表示其相对重要性。Database Designer 使用这些权重在设计中确定查询的优先级。

分段投影和未分段的投影

创建全面设计时，Database Designer 会基于数据统计信息和查询来创建投影。它还会查看提交的设计表，进而决定是应该对投影进行分段（在群集节点之间分布），还是不分段（在所有群集节点上复制）。

默认情况下，Database Designer 仅建议分段投影。您可以启用 Database Designer 以建议未分段投影。在这种情况下，Database Designer 建议在部署到多节点群集时对大型表使用分段超投影，而对较小表建议使用未分段超投影。

Database Designer 使用以下算法来确定是否建议未分段投影。假设最大行计数等于包含最大行数的设计表中的行数，如果满足以下任何条件，则 Database Designer 建议使用未分段投影：

最大行计数 < 1,000,000，并且表中的行数 ≥ 最大行计数的 10%
最大行计数 ≥ 10,000,000，并且表中的行数 ≥ 最大行计数的 1%
表中的行数 ≤ 100,000

Database Designer 不会在以下对象上对投影进行分段：

单节点群集
LONG VARCHAR 和 LONG VARBINARY 列

有关详细信息，请参阅使用投影的高可用性。

统计信息分析

默认情况下，Database Designer 在设计表添加到设计时分析其统计信息。准确的统计信息可帮助 Database Designer 优化压缩和查询性能。

分析统计信息需要花费一些时间和资源。如果您确定设计表统计信息为最新信息，则可指定跳过此步骤，避免因此而产生的开销。

有关详细信息，请参阅收集统计信息。

4.6 - 构建设计

创建设计表并将数据加载到其中，然后指定希望运行 Database Designer 在创建物理架构时使用的参数之后，引导运行 Database Designer 创建构建设计所需的脚本。

注意

如果 Database Designer 正在构建数据库设计，您将无法停止正在运行的数据库。

当您构建数据库设计时，Vertica 会生成两个脚本：

部署脚本：design-name_deploy.sql — 包含一些 SQL 语句，用于为您正在部署的设计创建投影、部署设计以及删除未使用的投影。当部署脚本运行时，它会创建经过优化的设计。有关如何运行此脚本和部署设计的详细信息，请参阅部署设计。
设计脚本：design-name_design.sql — 包含 Database Designer 用来创建设计的 CREATE PROJECTION 语句。查看此脚本，确保您对设计感到满意。

设计脚本是部署脚本的一个子集。它作为部署脚本创建的投影的 DDL 备份。

使用管理控制台创建设计时：

如果将大量查询提交到设计中并立即构建该设计，那么计时问题可能会导致在开始部署前无法加载查询。如果发生这种情况，可以看到以下错误之一：
- No queries to optimize for
- No tables to design projections for
要解决此计时问题，可能需要重置设计，请检查查询 (Queries) 选项卡，确保已加载查询，然后再重新构建设计。可以在以下部分找到详细说明：
- 使用向导创建设计
- 手动创建设计
部署完成后脚本会被删除。要在构建完设计之后，部署完成之前保存部署脚本的副本，请转到输出 (Output) 窗口，然后将 SQL 语句复制并粘贴到一个文件中。

4.7 - 重置设计

在以下情况下必须重置设计：

您构建了一个设计，但未创建构建设计中描述的输出脚本。
您构建了一个设计，但 Database Designer 无法完成设计，因为未加载它期望的查询。

重置某个设计会丢弃上一次 Database Designer 构建的所有运行特定信息，但会保留其配置（设计类型、优化目标、K-safety 等）以及表和查询。

重置某个设计后，查看该设计以了解您需要做出哪些更改。例如，您可以修复错误，更改参数，或者检查或添加更多表或查询。然后，您可以重新构建该设计。

您只能在管理控制台中或者通过使用 DESIGNER_RESET_DESIGN 函数来重置设计。

4.8 - 部署设计

运行 Database Designer 生成部署脚本后，Vertica 建议您先在非生产服务器上测试设计，然后再将其部署到生产服务器。

设计和部署过程均在后台运行。如果您需要通宵运行一个大型设计，这非常有用。由于无需活动的 SSH 会话，因此即使会话终止，设计/部署操作仍会继续无中断运行。

注意

如果 Database Designer 正在构建或部署数据库设计，则您无法停止正在运行的数据库。

Database Designer 作为后台进程运行。多个用户可以同时运行 Database Designer，他们互相之间不会出现干扰，也不会用尽群集的所有资源。但是，如果多个用户同时在同一个表上部署设计，Database Designer 可能无法完成部署。为避免出现问题，请考虑以下操作：

安排可能冲突的 Database Designer 进程在晚间按顺序运行，以便无并发问题。
避免安排 Database Designer 同时在同一组表上运行。

可通两种方法部署设计：

4.8.1 - 使用 Database Designer 部署设计

Micro Focus 建议您在使用示例数据加载表之后立即运行 Database Designer 并部署优化投影，因为 Database Designer 提供针对当前数据库状态优化的投影。

如果您选择允许 Database Designer 在全面设计期间自动部署脚本且正在运行管理工具，Database Designer 会创建数据库当前设计的备份脚本。该脚本可帮助您重新创建可能已被新设计删除的投影的设计。备份脚本位于您在设计过程中指定的输出目录中。

如果您选择不让 Database Designer 自动运行部署脚本（例如，要维持预先存在的部署中的投影），则可以稍后手动运行部署脚本。请参阅手动部署设计。

要在运行 Database Designer 的同时部署设计，请执行下列操作之一：

在管理控制台中，选择设计并单击部署设计 (Deploy Design)。
在管理工具中，选择设计选项 (Design Options) 窗口中的部署设计 (Deploy Design)。

如果通过编程方式运行 Database Designer，请使用 DESIGNER_RUN_POPULATE_DESIGN_AND_DEPLOY 并将 deploy 参数设置为“true”。

部署完设计后，查询 DEPLOY_STATUS 系统表以查看部署所采取的步骤：

vmartdb=> SELECT * FROM V_MONITOR.DEPLOY_STATUS;

4.8.2 - 手动部署设计

如果您选择不让 Database Designer 在设计时间部署您的设计，您可以使用部署脚本稍后部署该设计。

确保目标数据库包含与运行 Database Designer 的数据库相同的表和投影。该数据库还应包含示例数据。
要将投影部署到测试或生产环境，请按如下所述使用元命令 \i 在 vsql 中执行部署脚本，其中 design‑name 是数据库设计的名称：
```
=> \i design-name_deploy.sql
```
对于 K-safe 数据库，调用 Vertica 元函数 GET_PROJECTIONS 在新预测表上。检查输出，验证所有投影是否有足够的伙伴被识别为安全。
如果您为已包含数据的表创建投影，请调用 REFRESH 或 START_REFRESH 更新新投影。否则，这些投影不可用于查询处理。
调用 MAKE_AHM_NOW，将 Ancient History Mark (AHM) 设置为最近的时期。
对于不再需要的投影，请调用 DROP PROJECTION，否则将浪费磁盘空间并降低加载速度。
对于所有数据库投影，请调用 ANALYZE_STATISTICS：
```
=> SELECT ANALYZE_STATISTICS ('');
```
此函数从用于存储投影的所有节点中收集和聚合数据样本及存储信息，然后将统计信息写入到编录中。

4.9 - 如何创建设计

有三种方法可以使用 Database Designer 创建设计：

从管理控制台中打开数据库并选择窗口底部的设计 (Design) 页面。

有关使用管理控制台创建设计的详细信息，请参阅在管理控制台中创建数据库设计
通过编程方式使用关于通过编程方式运行 Database Designer 中所述的步骤。要通过编程方式运行 Database Designer，您必须是 DBADMIN 或已被授予 DBDUSER 角色并已启用该角色。
从管理工具菜单中，选择配置 Menu &gt (Configuration Menu &gt) > 运行 Database Designer (Run Database Designer)。您必须是 DBADMIN 用户才能从管理工具中运行 Database Designer。

有关使用管理工具创建设计的详细信息，请参阅使用管理工具创建设计。

下表显示了 Database Designer 在每种工具中可以具有的功能：

4.9.1 - 使用管理工具创建设计

要使用管理工具界面为数据库创建优化设计，您必须是 DBADMIN 用户。请遵循以下步骤：

以 dbadmin 用户身份登录，然后启动管理工具。
在主菜单中，启动要为其创建设计的数据库。该数据库必须正在运行，然后您才能为其创建设计。
在主菜单上，选择配置菜单 (Configuration Menu)，然后单击确定 (OK)。
在“配置菜单 (Configuration Menu)”上，选择运行 Database Designer (Run Database Designer)，然后单击确定 (OK)。
在选择要设计的数据库 (Select a database to design) 窗口中，输入您正在为其创建设计的数据库的名称，然后单击确定 (OK)。
在输入 Database Designer 输出的目录 (Enter the directory for Database Designer output) 窗口中，输入用于包含设计脚本、部署脚本、备份脚本和日志文件的目录的完整路径，然后单击确定 (OK)。

有关脚本的信息，请参阅构建设计。
在 Database Designer 窗口中，输入设计的名称，然后单击确定 (OK)。
在设计类型 (Design Type) 窗口中，选择要创建的设计类型，然后单击确定 (OK)。

有关详细信息，请参阅设计类型。
选择要添加到查询搜索路径的架构 (Select schema(s) to add to query search path) 窗口列出了所选数据库中的所有架构。选择包含您希望 Database Designer 在创建设计时考虑的代表性数据的架构，然后单击确定 (OK)。

有关选择要提交到 Database Designer 的架构和表的详细信息，请参阅设计含示例数据的表。
在优化目标 (Optimization Objectives) 窗口中，选择您想要的数据库优化目标：
- 使用查询进行优化
- 更新统计信息
- 部署设计
最后一个窗口汇总了您做出的选择并为您提供了两个选项：
- 继续 (Proceed) 构建设计，并且如果您已指定立即部署设计，则部署设计。如果未指定部署，可以查看设计和部署脚本，然后手动部署设计，如手动部署设计中所述。
- 取消 (Cancel) 设计并根据需要返回以更改某些参数。
创建设计可能需要较长时间。要从管理工具窗口中取消正在运行的设计，请输入 Ctrl+C。

要为 VMart 示例数据库创建设计，请参阅入门中的使用 Database Designer 创建完整的设计。

4.10 - 通过编程方式运行 Database Designer

Vertica 提供了一组元函数，支持通过编程方式访问 Database Designer 功能。通过编程方式运行 Database Designer 以执行以下任务：

优化您所拥有的表的性能。
无需超级用户或 DBADMIN 干预，即可创建或更新设计。
添加单独的查询和表，或者向设计中添加数据，然后重新运行 Database Designer 以根据此新信息更新设计。
自定义设计。
使用最近执行的查询设置数据库以定期自动运行 Database Designer。
为每个设计查询分配一个查询权重，用以指示该查询在创建设计时的重要性。为经常运行的查询分配更高的权重，以便 Database Designer 在创建设计时优先处理这些查询。

有关 Database Designer 函数的更多详细信息，请参阅Database Designer 函数类别。

4.10.1 - Database Designer 函数类别

Database Designer 函数通常按以下顺序执行以下操作：

创建设计。
设置设计属性。
填充设计。
创建设计和部署脚本。
获取设计数据。
清理。

重要

您也可以使用元函数 DESIGNER_SINGLE_RUN，它通过一次调用涵盖上述所有步骤。元函数将迭代指定时间跨度内的所有查询，并返回部署就绪的设计。

有关详细信息，请参阅以编程方式运行 Database Designer 的工作流程。有关所需权限的信息，请参阅运行 Database Designer 函数的权限

当心

在现有架构上运行 Database Designer 函数之前，请通过调用 EXPORT_CATALOG 来备份当前设计。

DESIGNER_CREATE_DESIGN 指示 Database Designer 创建设计。

设置设计属性

以下函数可让您指定设计属性：

DESIGNER_SET_DESIGN_TYPE：指定设计是全面设计，还是增量设计。
DESIGNER_DESIGN_PROJECTION_ENCODINGS：在指定投影中分析编码，并创建用于实施编码建议的脚本。
DESIGNER_SET_DESIGN_KSAFETY：为全面设计设置 K-safety 值。
DESIGNER_SET_OPTIMIZATION_OBJECTIVE：指定是否针对查询或加载性能优化设计。
DESIGNER_SET_PROPOSE_UNSEGMENTED_PROJECTIONS：允许设计中包含未分段的投影。

填充设计

以下函数可用来向 Database Designer 设计中添加表和查询：

DESIGNER_ADD_DESIGN_TABLES：将指定表添加到设计中。
DESIGNER_ADD_DESIGN_QUERY、DESIGNER_ADD_DESIGN_QUERIES、DESIGNER_ADD_DESIGN_QUERIES_FROM_RESULTS：将查询添加到设计并对其加权。

创建设计和部署脚本

以下函数将填充 Database Designer 工作区，并创建设计和部署脚本。您还可以分析统计信息，自动部署设计，以及在部署之后删除工作区：

DESIGNER_RUN_POPULATE_DESIGN_AND_DEPLOY：填充设计并创建设计和部署脚本。
DESIGNER_WAIT_FOR_DESIGN：等待当前正在运行的设计完成。

重置设计

DESIGNER_RESET_DESIGN 会丢弃上一次 Database Designer 构建或部署的指定设计的所有运行特定信息，但会保留其配置。

获取设计数据

下列函数将显示有关 Database Designer 所创建的投影和脚本的信息：

DESIGNER_OUTPUT_ALL_DESIGN_PROJECTIONS：发送到用于定义设计投影的标准输出 DDL 语句。
DESIGNER_OUTPUT_DEPLOYMENT_SCRIPT：将设计的部署脚本发送到标准输出。

清理

以下函数将取消任何正在运行的 Database Designer 操作或者删除 Database Designer 设计及其所有内容：

DESIGNER_CANCEL_POPULATE_DESIGN：如果指定设计当前正在运行，取消对指定设计的填充和部署操作。
DESIGNER_DROP_DESIGN：移除与指定设计及其所有内容相关联的架构。
DESIGNER_DROP_ALL_DESIGNS：移除所有与当前用户关联的 Database Designer 相关的架构。

4.10.2 - 以编程方式运行 Database Designer 的工作流程

以下示例显示了通过以编程方式运行 Database Designer 来创建设计的步骤。

重要

在现有架构上运行 Database Designer 函数之前，请通过调用函数 EXPORT_CATALOG 来备份当前设计。

在运行此示例之前，您应具有 DBDUSER 角色，并且您应使用 SET ROLE DBDUSER 命令启用此角色：

在公共架构中创建一个表：

=> CREATE TABLE T(
   x INT,
   y INT,
   z INT,
   u INT,
   v INT,
   w INT PRIMARY KEY
   );

将数据添加到表：

\! perl -e 'for ($i=0; $i<100000; ++$i)   {printf("%d, %d, %d, %d, %d, %d\n", $i/10000, $i/100, $i/10, $i/2, $i, $i);}'
   | vsql -c "COPY T FROM STDIN DELIMITER ',' DIRECT;"

在公共架构中创建第二个表：

=> CREATE TABLE T2(
   x INT,
   y INT,
   z INT,
   u INT,
   v INT,
   w INT PRIMARY KEY
   );

将 T1 表中的数据复制到 T2 表，并提交更改：

=> INSERT /*+DIRECT*/ INTO T2 SELECT * FROM T;
=> COMMIT;

创建新设计：
```
=> SELECT DESIGNER_CREATE_DESIGN('my_design');
```
此命令将信息添加到 V_MONITOR 架构中的 DESIGNS 系统表。

将公共架构中的表添加到设计：

=> SELECT DESIGNER_ADD_DESIGN_TABLES('my_design', 'public.t');
=> SELECT DESIGNER_ADD_DESIGN_TABLES('my_design', 'public.t2');

这些命令将信息添加到 DESIGN_TABLES 系统表。

在 /tmp/examples 中或在具有 READ 和 WRITE 权限的其他目录中创建一个名为 queries.txt 的文件。将以下两个查询添加到此文件，然后保存它。Database Designer 使用以下查询来创建设计：
```
SELECT DISTINCT T2.u FROM T JOIN T2 ON T.z=T2.z-1 WHERE T2.u > 0;
SELECT DISTINCT w FROM T;
```

将查询文件添加到设计，并显示结果，即已接受查询、非设计查询和不可优化查询的数量：

=> SELECT DESIGNER_ADD_DESIGN_QUERIES
     ('my_design',
     '/tmp/examples/queries.txt',
     'true'
     );

结果显示接受了两个查询：

Number of accepted queries                      =2
Number of queries referencing non-design tables =0
Number of unsupported queries                   =0
Number of illegal queries                       =0

DESIGNER_ADD_DESIGN_QUERIES 函数会填充 DESIGN_QUERIES 系统表。

将设计类型设置为 comprehensive。（这是默认值。）全面设计将为所有设计表创建一个初始或替换设计：
```
=> SELECT DESIGNER_SET_DESIGN_TYPE('my_design', 'comprehensive');
```
将优化目标设置为 query。此设置创建了一个主要用于提高查询性能的设计，它可能会推荐其他投影。这些投影会使数据库存储占用空间更大：
```
=> SELECT DESIGNER_SET_OPTIMIZATION_OBJECTIVE('my_design', 'query');
```
创建设计，然后将设计和部署脚本保存到 /tmp/examples 或具有 READ 和 WRITE 权限的其他目录。以下命令：
- 会分析统计信息
- 不会部署设计。
- 在部署之后，不会删除设计。
- 遇到错误时会停止。
```
=> SELECT DESIGNER_RUN_POPULATE_DESIGN_AND_DEPLOY
   ('my_design',
    '/tmp/examples/my_design_projections.sql',
    '/tmp/examples/my_design_deploy.sql',
    'True',
    'False',
    'False',
    'False'
    );
```
此命令将信息添加到以下系统表：

检查已运行的 Database Designer 的状态，以查看 Database Designer 推荐了哪些投影。在 deployment_projection_name 列中：

rep 表示复制的投影

super 表示超投影

deployment_status 列为 pending，因为设计尚未部署。

对于此示例，Database Designer 推荐了四种投影：

=> \x
Expanded display is on.
=> SELECT * FROM OUTPUT_DEPLOYMENT_STATUS;
-[ RECORD 1 ]--------------+-----------------------------
deployment_id              | 45035996273795970
deployment_projection_id   | 1
deployment_projection_name | T_DBD_1_rep_my_design
deployment_status          | pending
error_message              | N/A
-[ RECORD 2 ]--------------+-----------------------------
deployment_id              | 45035996273795970
deployment_projection_id   | 2
deployment_projection_name | T2_DBD_2_rep_my_design
deployment_status          | pending
error_message              | N/A
-[ RECORD 3 ]--------------+-----------------------------
deployment_id              | 45035996273795970
deployment_projection_id   | 3
deployment_projection_name | T_super
deployment_status          | pending
error_message              | N/A
-[ RECORD 4 ]--------------+-----------------------------
deployment_id              | 45035996273795970
deployment_projection_id   | 4
deployment_projection_name | T2_super
deployment_status          | pending
error_message              | N/A

查看 /tmp/examples/my_design_deploy.sql 脚本，以了解在运行部署脚本时如何创建投影。在此示例中，脚本也会向列分配编码方案 RLE 和 COMMONDELTA_COMP（如合适）。

从保存设计的目录中部署设计。

=> \i /tmp/examples/my_design_deploy.sql

现在，设计已部署，可以删除设计：
```
=> SELECT DESIGNER_DROP_DESIGN('my_design');
```

4.10.3 - 运行 Database Designer 函数的权限

具有 DBDUSER 角色的非 DBADMIN 用户可以运行 Database Designer 函数。使用户能够运行这些函数需要两个步骤：

DBADMIN 或超级用户授予用户 DBDUSER 角色：
```
=> GRANT DBDUSER TO username;
```
在 DBADMIN 撤销此角色之前，此角色一直存在。
在 DBDUSER 能够运行 Database Designer 函数之前，必须出现以下情况之一：
- 该用户启用 DBDUSER 角色：
```
=> SET ROLE DBDUSER;
```
- 超级用户将用户的默认角色设置为 DBDUSER：
```
=> ALTER USER username DEFAULT ROLE DBDUSER;
```

DBDUSER 常规限制

对于 DBDUSER，以下限制适用：

您可以将设计的 K-safety 设置为小于或等于系统 K-safety 的值。您无法更改系统 K-safety。
您不能显式更改 Ancient History Mark (AHM)，即便在设计部署期间同样如此。

设计依赖项和权限

单个设计任务可能具有需要特定权限的依赖项：

4.10.4 - Database Designer 用户的资源池

当您授予用户 DBDUSER 角色时，请确保将资源池与该用户相关联以在 Database Designer 运行期间管理资源。这允许多个用户可以同时运行 Database Designer，他们互相之间不会出现干扰，也不会用尽群集的所有资源。

注意

当用户运行 Database Designer 时，执行主要包含在用户的资源池中。但是，Vertica 也可能使用其他系统资源池来执行不太密集的任务。

4.11 - 创建自定义设计

Vertica 强烈建议您使用由 Database Designer 生成的物理架构设计，因为该软件可提供 K-safety、卓越的查询性能以及存储空间的有效使用。如果任何查询未能按照预期高效运行，可考虑使用 Database Designer 增量设计流程来优化该查询的数据库设计。

如果 Database Designer 创建的投影仍然不能满足您的需求，您可以从头开始或者根据 Database Designer 创建的投影设计来编写自定义投影。

如果您不熟悉如何编写自定义投影，可以从修改 Database Designer 生成的现有设计开始入手。

4.11.1 - 自定义设计流程

要创建自定义设计或自定义现有设计：

规划新的设计或修改现有设计。请参阅规划您的设计。
创建或修改投影。有关详细信息，请参阅设计基础知识和CREATE PROJECTION。
将投影部署到一个测试环境。请参阅写入并部署自定义投影。
根据需要测试并修改投影。
敲定设计后，将投影部署到生产环境。

4.11.2 - 规划您的设计

对于熟悉 SQL 的任何人来说，用于创建设计的语法是非常简单的。然而，对于任何成功的项目而言，成功的设计需要一些初始规划。在创建第一个设计前：

熟悉标准设计要求并将您的设计规划为包括这些要求。请参阅设计要求。
确定您需要将多少个投影包括在设计中。请参阅确定要使用的投影数量。
确定要用于列的压缩和编码类型。请参阅体系结构。
确定是否希望数据库具有 K-safe。Vertica 建议所有生产数据库都应至少将 K-safety 设置为 1 (K=1)。有效的 K-safe 值为 0、1 和 2。请参阅K-safety 设计。

4.11.2.1 - 设计要求

物理架构设计是包含 CREATE PROJECTION 语句的脚本。这些语句确定包括在投影中的列及其优化方式。

如果您开始时使用 Database Designer，它将自动创建满足所有基础设计要求的设计。如果您打算手动创建或修改设计，请注意所有设计必须满足以下要求：

对于客户端应用程序所使用的数据库中的每个表，每个设计必须至少为其创建一个超投影。这些投影提供全面覆盖，用户可利用该覆盖范围根据需要执行临时查询。它们可以包含联接，而且通常被配置为通过排序顺序、压缩和编码最大限度提高性能。
查询特定的投影为可选项。如果您对超投影所提供的性能满意，则无需创建其他投影。但是，可通过优化特定查询工作负载来最大限度提高性能。
Vertica 建议所有生产数据库都应至少将 K-safety 设置为一 (K=1) 以支持高可用性和高恢复性。（K-safety 可以设置为 0、1 或 2。）请参阅使用投影的高可用性和 K-safety 设计。
如果节点数超过 20 但表为小型表，Vertica 建议您不要创建复制的投影。如果创建复制的投影，编录会变得非常大，而且性能可能会降低。相反，请考虑对这些投影分段。

4.11.2.2 - 确定要使用的投影数量

在许多情况下，由一组超投影（及其伙伴实例）组成的设计可通过压缩和编码提供令人满意的性能。当已使用投影的排序顺序最大限度提高一个或多个查询谓语（WHERE 子句）的性能时，情况尤其如此。

但是，您可能希望添加其他查询特定投影以提高运行缓慢、经常使用或作为业务关键报告的一部分运行的查询的性能。您创建的其他投影（及其伙伴实例）的数量应由以下项目决定：

组织需求
群集中每个节点上的可用磁盘空间量
将数据加载到数据库中的可用时间量

随着针对特定查询而优化的投影数量的增加，这些查询的性能得到提高。但是，已用磁盘空间量和加载数据所需的时间量也会增加。因此，应创建和测试设计以确定您的数据库配置的最佳投影数量。平均而言，选择实施查询特定投影的组织可通过添加几个查询特定投影来实现最佳性能。

4.11.2.3 - K-safety 设计

Vertica 建议所有生产数据库都应至少将 K-safety 设置为 1 (K=1)。生产数据库的有效 K-safety 值为 1 和 2。非生产数据库不必为 K-safe，可将该值设置为 0。

K-safe 数据库必须至少包含三个节点，如下表所示：

1: 3+
2: 5+

注意

Vertica 仅支持 K-safety 级别 1 和 2。

仅当物理架构设计满足某些冗余要求时，才能将 K-safety 设置为 1 或 2。请参阅K-safe 物理架构设计的要求。

使用 Database Designer

要创建具有 K-safe 状态的设计，Vertica 建议您使用 Database Designer。使用 Database Designer 创建投影时，建议使用满足 K-safe 设计要求的投影定义并用 K-safety 级别加以标记。Database Designer 会创建一个脚本，该脚本使用 MARK_DESIGN_KSAFE 函数将物理架构的 K-safety 设置为 1。例如：

=> \i VMart_Schema_design_opt_1.sql

CREATE PROJECTION
CREATE PROJECTION
mark_design_ksafe
----------------------
Marked design 1-safe
(1 row)

默认情况下，当数据库的 K-safety 大于 0 时，Vertica 会创建 K-safe 超投影。

监控 K-safety

监控表可以通过编程方式访问，以启用外部操作，例如警报。通过查询 SYSTEM 表内 DESIGNED_FAULT_TOLERANCE 和 CURRENT_FAULT_TOLERANCE 列中的设置，可以监控 K-safety 级别。

K-safety 丢失

当群集中的 K 个节点出现故障时，数据库将继续运行，但性能会受到影响。如果故障节点的数据无法从群集中另一个正常工作的节点中获取，那么后续节点故障可能会导致数据库关闭。

另请参阅

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

4.11.2.3.1 - K-safe 物理架构设计的要求

Database Designer 使用值为 1 的 K-safety 为至少包含三个节点的群集自动生成设计。（如果群集具有一个或两个节点，它将使用值为 0 的 K-safety 生成设计。）您可以修改为三节点（或更大）群集创建的设计，而且 K-safe 要求已设置完毕。

如果您创建自定义投影，物理架构设计必须满足以下要求才能在出现故障时成功恢复数据库：

分段投影必须在所有节点上均分段。请参考分段设计和为 K-safety 安全设计分段投影。
复制的投影必须在所有节点上均得到复制。请参阅为 K‑Safety 设计未分段投影。
分段投影必须具有 K+1 个伙伴实例投影 — 具有相同列数和分段条件的投影，其中对应的分段放置在不同节点上。

可使用 MARK_DESIGN_KSAFE 函数确定您的架构设计是否满足 K-safety 的要求。

4.11.2.3.2 - 无 K-safety 的物理架构设计的要求

如果您使用 Database Designer 生成一个您可以修改的全面设计并且您不希望设计具有 K-safe，请将 K-safety 级别设置为 0（零）。

如果您想要从头开始，请执行以下操作为一个不具有 K-safety (K=0) 的有效数据库建立最低投影要求：

为逻辑架构中的每个表至少定义一个超投影。
复制（定义一个完全相同的副本）每个节点上的每个维度表超投影。

4.11.2.3.3 - 为 K-safety 安全设计分段投影

投影必须符合数据库 K-safety 要求。通常，您必须为每个分段投影创建伙伴实例投影，其中伙伴实例投影的数量为 K+1。因此，如果系统 K-safety 设置为 1，则必须通过一个伙伴实例复制每个投影分段；如果 K-safety 设置为 2，则必须通过两个伙伴实例复制每个分段。

自动创建伙伴实例投影

通过包括 SEGMENTED BY ... ALL NODES，可以使用 CREATE PROJECTION 自动创建满足 K-safety 所需的伙伴实例投影数量。如果 CREATE PROJECTION 指定 K-safety ( KSAFE=n)，Vertica 将使用该设置；如果语句省略 KSAFE，Vertica 将使用系统 K-safety。

在以下示例中，CREATE PROJECTION 为表 ttt 创建分段投影 ttt_p1。由于系统 K‑safety 设置为 1，因此 Vertica 需要每个分段投影拥有一个伙伴实例投影。由于“CREATE PROJECTION”语句省略“KSAFE”，因此 Vertica 使用系统 K‑safety 并创建两个伙伴实例投影：“ttt_p1_b0”和“ttt_p1_b1”：

=> SELECT mark_design_ksafe(1);

  mark_design_ksafe
----------------------
 Marked design 1-safe
(1 row)

=> CREATE TABLE ttt (a int, b int);
WARNING 6978:  Table "ttt" will include privileges from schema "public"
CREATE TABLE

=> CREATE PROJECTION ttt_p1 as SELECT * FROM ttt SEGMENTED BY HASH(a) ALL NODES;
CREATE PROJECTION

=> SELECT projection_name from projections WHERE anchor_table_name='ttt';
 projection_name
-----------------
 ttt_p1_b0
 ttt_p1_b1
(2 rows)

通过将后缀 _bn 附加到投影基本名（例如 ttt_p1_b0），Vertica 自动为伙伴实例投影命名。

手动创建伙伴实例投影

如果在单个节点上创建投影并且系统 K-safety 大于 0，则必须手动创建 K-safety 所需的伙伴实例数量。例如，可以在单个节点上为表 xxx 创建投影 xxx_p1，如下所示：

=> CREATE TABLE xxx (a int, b int);
WARNING 6978:  Table "xxx" will include privileges from schema "public"
CREATE TABLE

=> CREATE PROJECTION xxx_p1 AS SELECT * FROM xxx SEGMENTED BY HASH(a) NODES v_vmart_node0001;
CREATE PROJECTION

由于 K-safety 设置为 1，此投影的单个实例不是 K-safe。若尝试将数据插入到它的锚表 xxx，则会返回如下错误：

=> INSERT INTO xxx VALUES (1, 2);
ERROR 3586:  Insufficient projections to answer query
DETAIL:  No projections that satisfy K-safety found for table xxx
HINT:  Define buddy projections for table xxx

为了符合 K-safety，您必须为投影 xxx_p1 创建一个伙伴实例投影。例如：

=> CREATE PROJECTION xxx_p1_buddy AS SELECT * FROM xxx SEGMENTED BY HASH(a) NODES v_vmart_node0002;
CREATE PROJECTION

表 xxx 现在符合 K-safety 并接受 DML 语句（例如 INSERT）：

VMart=> INSERT INTO xxx VALUES (1, 2);
 OUTPUT
--------
      1
(1 row)

另请参阅

有关分段投影和伙伴实例的一般信息，请参阅分段投影。有关 K-safety 设计的信息，请参阅K-safety 设计和分段设计。

4.11.2.3.4 - 为 K‑Safety 设计未分段投影

在许多情况下，维度表相对较小，因此您无需将它们分段。相应地，您应该设计一个 K-safe 数据库，以便可以复制其维度表的投影并且无需在所有群集节点上进行分段。您可以使用包括关键字 UNSEGMENTED ALL NODES 的 CREATE PROJECTION 语句创建这些投影。这些关键字用于指定在所有群集节点上创建投影的相同实例。

以下示例展示了如何为表 store.store_dimension 创建未分段投影：


=> CREATE PROJECTION store.store_dimension_proj (storekey, name, city, state)
             AS SELECT store_key, store_name, store_city, store_state
             FROM store.store_dimension
             UNSEGMENTED ALL NODES;
CREATE PROJECTION

Vertica 使用相同的名称来标识未分段投影的所有实例 — 在此示例中为 store.store_dimension_proj。关键字 ALL NODES 指定在所有节点上复制投影：


=> \dj store.store_dimension_proj
                         List of projections
 Schema |         Name         |  Owner  |       Node       | Comment
--------+----------------------+---------+------------------+---------
 store  | store_dimension_proj | dbadmin | v_vmart_node0001 |
 store  | store_dimension_proj | dbadmin | v_vmart_node0002 |
 store  | store_dimension_proj | dbadmin | v_vmart_node0003 |
(3 rows)

有关投影名称约定的详细信息，请参阅投影命名。

4.11.2.4 - 分段设计

可使用哈希分段对投影分段。哈希分段可基于内置的哈希函数对投影进行分段。该内置哈希函数可使多个节点中的数据实现正态分布，从而优化查询的执行。在投影中，要进行哈希的数据由一列或多列值组成，每一列都包含大量唯一值，并且值的分布偏移程度在可接受的范围内。满足标准的主键列非常适合进行哈希分段。

注意

有关在投影中使用哈希分段的详细信息，请参阅《SQL 参考手册》中的CREATE PROJECTION。

分段投影时，确定哪些列用于对投影分段。选择具有大量唯一数据值和在数据分布中可接受的偏离的一个或多个列。主键列是哈希分段的绝佳选择。这些列在查询中所用的所有表上必须唯一。

4.11.3 - 设计基础知识

尽管您可以从头开始编写自定义投影，但 Vertica 建议您使用 Database Designer 创建设计来作为起点。这样可确保您获得满足基本要求的投影。

4.11.3.1 - 写入并部署自定义投影

在编写自定义投影之前，请仔细查看规划您的设计中的主题。不遵循这些注意事项可能会生成无法正常工作的投影。

要手动修改或创建投影：

使用 CREATE PROJECTION 语句编写脚本以创建所需的投影。
使用元命令 \i 在 vsql 中运行脚本。

注意
您必须加载一个具有逻辑架构的数据库。
对于 K-safe 数据库，调用 Vertica 元函数 GET_PROJECTIONS 在新预测表上。检查输出，验证所有投影是否有足够的伙伴被识别为安全。
如果您为已包含数据的表创建投影，请调用 REFRESH 或 START_REFRESH 更新新投影。否则，这些投影不可用于查询处理。
调用 MAKE_AHM_NOW，将 Ancient History Mark (AHM) 设置为最近的时期。
对于不再需要的投影，请调用 DROP PROJECTION，否则将浪费磁盘空间并降低加载速度。
对于所有数据库投影，请调用 ANALYZE_STATISTICS：
```
=> SELECT ANALYZE_STATISTICS ('');
```
此函数从用于存储投影的所有节点中收集和聚合数据样本及存储信息，然后将统计信息写入到编录中。

4.11.3.2 - 设计超级投影

超投影需要满足以下要求：

它们必须包含表中的每个列。
对于 K-safe 设计，必须在数据库群集内的所有节点上复制超投影（适用于维度表），或者与伙伴投影进行配对并跨越所有节点进行分段（适用于很大的表和中等的表）。有关投影及其存储方式的概述，请参阅投影和使用投影的高可用性。有关设计细节，请参阅K-safety 设计。

要实现最大可用性，超投影需要最大限度降低存储要求，同时最大限度提升查询性能。为了实现这一目标，超投影中列的排序顺序以存储要求和常用查询为基础。

4.11.3.3 - 排序顺序的优势

列排序顺序是将存储空间要求降至最低和最大限度提高查询性能的重要因素。

将存储空间要求降至最低

最小化存储不但可以节省物理资源，而且还可以减少磁盘 I/O，以显著提高性能。通过在排序顺序中优先考虑低基数列，可以最大程度地减少投影存储。这会减少 Vertica 检索查询结果时所存储和访问的行数。

确定投影排序列后，分析其数据并选择效率最高的编码方法。Vertica 优化器使用运行长度编码 (RLE) 为列提供首选项，因此请确保在适当的情况下使用它。运行长度编码将相同值的序列（运行）替换为包含值和出现次数的单个对。因此，它特别适合用于运行长度较大的低基数列。

最大限度提高查询性能

可通过列排序顺序提高查询性能，方法如下：

排序顺序应尽可能地使用最低基数确定列的优先级。
请勿在 LONG VARBINARY 和 LONG VARCHAR 类型的列上排序投影。

另请参阅

选择排序顺序：最佳实践

4.11.3.4 - 选择排序顺序：最佳实践

选择投影的排序顺序时，Vertica 具有多条建议，可以帮助您实现最大查询性能，如以下示例中所示。

组合使用 RLE 和排序顺序

当处理低基数列中的谓词时，组合使用 RLE 和排序可最大程度减少存储要求，同时实现最大查询性能。

假设您具有一个包含以下值和编码类型的 students 表：

您可能具有类似如下所示的查询：

SELECT name FROM studentsWHERE gender = 'M' AND pass_fail = 'P' AND class = 'senior';

最快的数据访问方式是先处理非重复值数量最少的低基数列，然后再处理高基数列。对于对 gender、class、pass_fail 和 name 具有相同限制的查询，以下排序顺序可最大程度减少存储要求，同时实现最大查询性能。如下所示指定投影的 ORDER BY 子句：

ORDER BY students.gender, students.pass_fail, students.class, students.name

在本示例中，gender 列由两个 RLE 条目表示，pass_fail 列由四个条目表示，而 class 列由 16 个条目表示，而不考虑 students 表的基数。Vertica 可有效地查找一组满足所有谓词的行，从而大幅减少了在排序顺序早期出现的 RLE 编码列搜索工作。因此，如果您在局部谓词中使用低基数列（如上例所示），请尽早将这些列按照非重复基数的递增顺序（即按照每列中非重复值数量的递增顺序）放入投影排序顺序中。

如果先使用 student.class 排序此表，则可以提高仅对 student.class 列存在限制的查询的性能，并改善 student.class 列（包含非重复值数量最多的列）的压缩性能，但其他列也不会压缩。确定哪个投影更好取决于工作负载中的特定查询及其相对重要性。

随着列基数的增加，通过压缩节省的存储空间会降低；但是，随着在该列中存储值所需字节数的增加，通过压缩节省的存储空间也会增加。

充分发挥 RLE 优势

为了充分发挥 RLE 编码的优势，请仅在列的平均运行长度大于 10（排序时）时使用该编码。例如，假设您具有包含以下列的表，各列按基数由低到高的顺序排列：

address.country, address.region, address.state, address.city, address.zipcode

zipcode 列可能在具有相同 zip 代码的行中没有 10 个排序条目，因此对该列执行运行长度编码很可能没有优势，而且可能会导致压缩性能变差。但在排序的运行长度中可能有超过 10 个国家/地区，因此对该国家/地区列应用 RLE 可以提高性能。

先放置基数较低的列以实现函数依赖项

一般而言，在联接顺序中先放置用于局部谓词（如上例所示）的列可使谓词求值更加高效。另外，如果通过基数较高的列来唯一确定基数较低的列（如仅 city_id 唯一确定 state_id），则在排序顺序中先放置基数较低、通过函数确定的列总比先放置基数较高的列好。

例如，在以下排序顺序中，customer_info 表中的 Area_Code 列排在 Number 列之前。

ORDER BY = customer_info.Area_Code, customer_info.Number, customer_info.Address

在查询中，先放置 Area_Code 列，以便仅扫描 Number 列中以 978 开头的值。

=> SELECT AddressFROM customer_info WHERE Area_Code='978' AND Number='9780123457';

合并联接排序

处理联接时，Vertica 优化器会从两种算法中进行选择：

合并联接 — 如果两个输入都按联接列预先排序，优化器会选择合并联接，因为这种算法更快而且使用的内存更少。
哈希联接 — 利用哈希联接算法，Vertica 会使用较小的（内部）联结表在内存中构建联接列的哈希表。哈希联接没有排序要求，但却会消耗更多内存，因为 Vertica 会构建一个包含内部表值的哈希表。如果投影未存储在联接列上，则优化器会选择一种哈希联接。

如果两个输入都预先排序，合并联接不必执行任何预处理，因而可以更快地执行联接。Vertica 使用的术语“排序-合并联接”是指在合并联接之前必须对至少一个输入排序的情况。只有当外部输入端已按联接列排序时，Vertica 才会排序内部输入端。

为了使 Vertica 查询优化器能够为特定联接选择使用有效的合并联接，请在联接的两端创建投影，并在相应投影中先放置联接列。如果两个表都非常大，内存中无法容纳任何一个表，那么这样做将非常重要。如果预期内存中可以同时容纳某个表要联接到的所有表，那么合并联接的优势比哈希联接要小很多，很可能并不值得为任何一个联接列创建投影。

在重要查询中按列排序

如果您有一个重要查询，并且您会定期运行该查询，那么将该查询 WHERE 子句或 GROUP BY 子句中指定的列先放入排序顺序中可以为您节省时间。

如果该查询使用高基数列（如社会保险号），则将该列先放入投影的排序顺序中可能会牺牲存储空间，但您的最重要查询将得到优化。

按大小排序基数相等的列

如果有两个基数相等的列，则在排序顺序中先放置较大的列。例如，CHAR(20) 列占用 20 字节，但 INTEGER 列占用 8 字节。通过将 CHAR(20) 列放在 INTEGER 列前面，可以更好地压缩投影。

按非重复基数由低到高的顺序，先排序外键列

假设您有一个事实表，排序顺序中的前四列组成了另一个表的外键。为了获得最佳压缩效果，我们为事实表选择一个排序顺序，使其先显示外键，并以非重复基数的递增顺序排列。在设计事实表的投影时，还可应用其他因素，如按时间维度（若存在）分区。

在以下示例中，表 inventory 用于存储库存数据，product_key 和 warehouse_key 是 product_dimension 和 warehouse_dimension 表的外键：

=> CREATE TABLE inventory (
 date_key INTEGER NOT NULL,
 product_key INTEGER NOT NULL,
 warehouse_key INTEGER NOT NULL,
 ...
);
=> ALTER TABLE inventory
   ADD CONSTRAINT fk_inventory_warehouse FOREIGN KEY(warehouse_key)
   REFERENCES warehouse_dimension(warehouse_key);
ALTER TABLE inventory
   ADD CONSTRAINT fk_inventory_product FOREIGN KEY(product_key)
   REFERENCES product_dimension(product_key);

库存表应当先按 warehouse_key 排序，然后再按 product_key 排序，因为 warehouse_key 列的基数很可能低于 product_key 的基数。

4.11.3.5 - 确定列访问速度的优先级

如果您测量和设置群集内的存储位置的性能，Vertica 将使用此信息确定在哪里基于列的排名来存储列。有关详细信息，请参阅设置存储性能。

如何对列排名

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

排序顺序中的列具有最高优先级（编号 &gt；1000）。
排序顺序中最后一列的排序编号为 1001。
排序顺序中倒数第二的列排序编号为 1002，以此类推，直到排序顺序中的第一列，其排序编号为 1000 + 排序列数。
剩余列的排序编号在 1000–1 之间，从 1000 开始，每列减一。

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

覆盖默认列排名

通过手动覆盖这些列的默认排名，您可以修改将哪些列存储在快速磁盘上。要完成此操作，请设置列列表中的 ACCESSRANK 关键字。确保使用一个当前尚未用于另一个列的整数。例如，如果您要为某列提供最快速的访问排名，可使用一个明显高于 1000 + 排序列数量之和的数字。这样一来，您便可以随着时间的推移输入更多列，而不会跌入到您设置的访问排名中。

以下示例将列 store_key 的访问等级设置为 1500：

CREATE PROJECTION retail_sales_fact_p (
     store_key ENCODING RLE ACCESSRANK 1500,
     pos_transaction_number ENCODING RLE,
     sales_dollar_amount,
     cost_dollar_amount )
AS SELECT
     store_key,
     pos_transaction_number,
     sales_dollar_amount,
     cost_dollar_amount
FROM store.store_sales_fact
ORDER BY store_key
SEGMENTED BY HASH(pos_transaction_number) ALL NODES;