设计是用于优化查询性能的物理存储计划。Vertica 中的数据以物理方式存储在投影中。最初使用 INSERT、COPY（或 COPY LOCAL）将数据加载到某个表中时，Vertica 会为该表创建一个默认的 超投影。该超投影可确保所有数据均可用于查询。但是，这些超投影可能不会优化数据库性能，这导致查询性能较低、数据压缩较慢。
要提高性能，请为 Vertica 数据库创建一个设计以优化查询性能和数据压缩。您可以通过多种方式创建设计：
使用 Database Designer，这是一种建议用于设计以获得最佳性能的工具。
使用 Database Designer 创建初始设计，然后手动对其进行修改。
Database Designer 可帮助您将花费在手动数据库优化上的时间降至最低。也可以使用 Database Designer 按照要求以增量方式重新设计数据库，比如工作负载随时间的变化。
Database Designer 作为后台进程运行。如果您需要通宵运行一个大型设计，这非常有用。由于无需活动的 SSH 会话，因此设计和部署操作会在会话结束时继续无中断运行。
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 建议先在非生产服务器上测试设计，然后再将该设计部署到生产服务器。
Database Designer 生成的设计可包括以下建议：
以相同的顺序对 伙伴实例投影排序，这样可显著提高加载、恢复和站点节点性能。所有伙伴实例投影均具有相同的基本名，因此可将其标识为一个组。
对于全面设计，接受的查询数不受限制。
标识类似设计查询并为其分配一个签名。
对于具有相同签名的查询，Database Designer 会根据此签名具有的查询数为这些查询加权，然后再在创建设计时考虑加权的查询。
建议创建投影时在群集上均匀分布数据，以便将数据偏离降至最低。
考虑使用 UPDATE、DELETE 和 SELECT 语句，以生成质量更高的设计。
默认情况下，只有具有 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 时，其执行操作通常会限制在该用户的资源池内，但不太密集的任务可能会使用系统资源。
如上文所述，已授予 DBDUSER 角色和所需权限的用户也可以在管理控制台上运行 Database Designer：
以超级用户身份登录管理控制台。
单击 MC 设置 (MC Settings)。
单击用户管理 (User Management)。
指定 MC 用户
要创建 MC 用户，请单击 添加 (Add)。
要使用现有的 MC 用户，请选择该用户并单击 编辑 (Edit)。
单击数据库访问级别 (DB access level) 窗口旁边的添加 (Add)。
在添加权限 (Add Permissions) 窗口中：
从选择数据库 (Choose a database) 下拉列表中，选择要为其创建设计的数据库。
在 数据库用户名 (Database username) 字段中，输入您先前创建的 dbd-user 用户名。
在数据库密码字段中，输入数据库密码。
在限制访问 (Restrict access) 下拉列表中，选择此用户具有的 MC 用户级别。
单击确定 (OK) 以保存更改。
退出 MC 超级用户帐户。
现在，MC 用户已映射到 dbd-user。以 MC 用户身份登录，然后使用 Database Designer 为数据库创建优化设计。
对于 DBDUSER，以下约束适用：
设计必须将 K-safety 设置为等于系统 K-safety。如果设计因缺少足够的表伙伴实例投影而违反 K-safety，则设计不会完成。
只有部署设计完成之后，才可显式推进 Ancient History Mark (AHM)（例如，调用 MAKE_AHM_NOW）。
创建设计时，会自动获得处理该设计的权限。其他任务可能需要额外的权限：
对于设计表架构的 USAGE
对于设计表的 OWNER
对于查询文件所在存储位置的读取权限
文件中所有查询的 EXECUTE 权限
对于用户查询的 EXECUTE 权限
从用户查询结果中获取的每个设计查询的 EXECUTE 权限
对于设计脚本存储位置的 WRITE 权限
对于部署脚本存储位置的 WRITE 权限
当您运行 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 日志。
默认情况下，不会记录优化器提出并且 Database Designer 部署的投影的相关信息。
要启用 Database Designer 日志记录，请输入以下命令：
=> ALTER DATABASE DEFAULT SET DBDLogInternalDesignProcess = 1;
要禁用 Database Designer 日志记录，请输入以下命令：
=> ALTER DATABASE DEFAULT SET DBDLogInternalDesignProcess = 0;
您可以在两个数据收集器表中找到 Database Designer 考虑和部署的投影的相关数据：
DC_DESIGN_PROJECTION_CANDIDATES
DC_DESIGN_QUERY_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 表列出所有设计查询的计划特征。
可能的特征包括：
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 日志示例数据。
在以下示例中，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
在运行 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 的 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 优化压缩和查询性能。
分析统计信息需要花费一些时间和资源。如果您确定设计表统计信息为最新信息，则可指定跳过此步骤，避免因此而产生的开销。
有关详细信息，请参阅收集统计信息。
创建设计表并将数据加载到其中，然后指定希望运行 Database Designer 在创建物理架构时使用的参数之后，引导运行 Database Designer 创建构建设计所需的脚本。
当您构建数据库设计时，Vertica 会生成两个脚本：
部署脚本：design-name_deploy.sql — 包含一些 SQL 语句，用于为您正在部署的设计创建投影、部署设计以及删除未使用的投影。当部署脚本运行时，它会创建经过优化的设计。有关如何运行此脚本和部署设计的详细信息，请参阅部署设计。
设计脚本：design-name_design.sql — 包含 Database Designer 用来创建设计的 CREATE PROJECTION 语句。查看此脚本，确保您对设计感到满意。
设计脚本是部署脚本的一个子集。它作为部署脚本创建的投影的 DDL 备份。
使用管理控制台创建设计时：
在以下情况下必须重置设计：
您构建了一个设计，但未创建构建设计中描述的输出脚本。
您构建了一个设计，但 Database Designer 无法完成设计，因为未加载它期望的查询。
重置某个设计会丢弃上一次 Database Designer 构建的所有运行特定信息，但会保留其配置（设计类型、优化目标、K-safety 等）以及表和查询。
重置某个设计后，查看该设计以了解您需要做出哪些更改。例如，您可以修复错误，更改参数，或者检查或添加更多表或查询。然后，您可以重新构建该设计。
您只能在管理控制台中或者通过使用 DESIGNER_RESET_DESIGN 函数来重置设计。
运行 Database Designer 生成部署脚本后，Vertica 建议您先在非生产服务器上测试设计，然后再将其部署到生产服务器。
设计和部署过程均在后台运行。如果您需要通宵运行一个大型设计，这非常有用。由于无需活动的 SSH 会话，因此即使会话终止，设计/部署操作仍会继续无中断运行。
Database Designer 作为后台进程运行。多个用户可以同时运行 Database Designer，他们互相之间不会出现干扰，也不会用尽群集的所有资源。但是，如果多个用户同时在同一个表上部署设计，Database Designer 可能无法完成部署。为避免出现问题，请考虑以下操作：
安排可能冲突的 Database Designer 进程在晚间按顺序运行，以便无并发问题。
避免安排 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;
如果您选择不让 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 ('');
此函数从用于存储投影的所有节点中收集和聚合数据样本及存储信息，然后将统计信息写入到编录中。
有三种方法可以使用 Database Designer 创建设计：
从管理控制台中打开数据库并选择窗口底部的设计 (Design) 页面。
有关使用管理控制台创建设计的详细信息，请参阅 在管理控制台中创建数据库设计
通过编程方式使用关于通过编程方式运行 Database Designer 中所述的步骤。要通过编程方式运行 Database Designer，您必须是 DBADMIN 或已被授予 DBDUSER 角色并已启用该角色。
从管理工具菜单中，选择配置 Menu > (Configuration Menu >) > 运行 Database Designer (Run Database Designer)。您必须是 DBADMIN 用户才能从管理工具 中运行 Database Designer。
有关使用管理工具创建设计的详细信息，请参阅 使用管理工具创建设计。
下表显示了 Database Designer 在每种工具中可以具有的功能：
要使用管理工具界面为数据库创建优化设计，您必须是 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 创建完整的设计。
Vertica 提供了一组元函数，支持通过编程方式访问 Database Designer 功能。通过编程方式运行 Database Designer 以执行以下任务：
优化您所拥有的表的性能。
无需超级用户或 DBADMIN 干预，即可创建或更新设计。
添加单独的查询和表，或者向设计中添加数据，然后重新运行 Database Designer 以根据此新信息更新设计。
自定义设计。
使用最近执行的查询设置数据库以定期自动运行 Database Designer。
为每个设计查询分配一个查询权重，用以指示该查询在创建设计时的重要性。为经常运行的查询分配更高的权重，以便 Database Designer 在创建设计时优先处理这些查询。
有关 Database Designer 函数的更多详细信息，请参阅Database Designer 函数类别。
Database Designer 函数通常按以下顺序执行以下操作：
有关详细信息，请参阅 以编程方式运行 Database Designer 的工作流程。有关所需权限的信息，请参阅 运行 Database Designer 函数的权限
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 相关的架构。
以下示例显示了通过以编程方式运行 Database Designer 来创建设计的步骤。
在运行此示例之前，您应具有 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');
具有 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，以下限制适用：
您可以将设计的 K-safety 设置为小于或等于系统 K-safety 的值。您无法更改系统 K-safety。
您不能显式更改 Ancient History Mark (AHM)，即便在设计部署期间同样如此。
单个设计任务可能具有需要特定权限的依赖项：
当您授予用户 DBDUSER 角色时，请确保将资源池与该用户相关联以在 Database Designer 运行期间管理资源。这允许多个用户可以同时运行 Database Designer，他们互相之间不会出现干扰，也不会用尽群集的所有资源。
Vertica 强烈建议您使用由 Database Designer 生成的物理架构设计，因为该软件可提供 K-safety、卓越的查询性能以及存储空间的有效使用。如果任何查询未能按照预期高效运行，可考虑使用 Database Designer 增量设计流程来优化该查询的数据库设计。
如果 Database Designer 创建的投影仍然不能满足您的需求，您可以从头开始或者根据 Database Designer 创建的投影设计来编写自定义投影。
如果您不熟悉如何编写自定义投影，可以从修改 Database Designer 生成的现有设计开始入手。
要创建自定义设计或自定义现有设计：
规划新的设计或修改现有设计。请参阅规划您的设计。
创建或修改投影。有关详细信息，请参阅设计基础知识和CREATE PROJECTION。
将投影部署到一个测试环境。请参阅写入并部署自定义投影。
根据需要测试并修改投影。
敲定设计后，将投影部署到生产环境。
对于熟悉 SQL 的任何人来说，用于创建设计的语法是非常简单的。然而，对于任何成功的项目而言，成功的设计需要一些初始规划。在创建第一个设计前：
熟悉标准设计要求并将您的设计规划为包括这些要求。请参阅设计要求。
确定您需要将多少个投影包括在设计中。请参阅确定要使用的投影数量。
确定要用于列的压缩和编码类型。请参阅体系结构。
确定是否希望数据库具有 K-safe。Vertica 建议所有生产数据库都应至少将 K-safety 设置为 1 (K=1)。有效的 K-safe 值为 0、1 和 2。请参阅K-safety 设计。
物理架构设计是包含 CREATE PROJECTION 语句的脚本。这些语句确定包括在投影中的列及其优化方式。
如果您开始时使用 Database Designer，它将自动创建满足所有基础设计要求的设计。如果您打算手动创建或修改设计，请注意所有设计必须满足以下要求：
对于客户端应用程序所使用的数据库中的每个表，每个设计必须至少为其创建一个超投影。这些投影提供全面覆盖，用户可利用该覆盖范围根据需要执行临时查询。它们可以包含联接，而且通常被配置为通过排序顺序、压缩和编码最大限度提高性能。
查询特定的投影为可选项。如果您对超投影所提供的性能满意，则无需创建其他投影。但是，可通过优化特定查询工作负载来最大限度提高性能。
Vertica 建议所有生产数据库都应至少将 K-safety 设置为一 (K=1) 以支持高可用性和高恢复性。（K-safety 可以设置为 0、1 或 2。）请参阅使用投影的高可用性和 K-safety 设计。
如果节点数超过 20 但表为小型表，Vertica 建议您不要创建复制的投影。如果创建复制的投影，编录会变得非常大，而且性能可能会降低。相反，请考虑对这些投影分段。
在许多情况下，由一组超投影（及其伙伴实例）组成的设计可通过压缩和编码提供令人满意的性能。当已使用投影的排序顺序最大限度提高一个或多个查询谓语（WHERE 子句）的性能时，情况尤其如此。
但是，您可能希望添加其他查询特定投影以提高运行缓慢、经常使用或作为业务关键报告的一部分运行的查询的性能。您创建的其他投影（及其伙伴实例）的数量应由以下项目决定：
组织需求
群集中每个节点上的可用磁盘空间量
将数据加载到数据库中的可用时间量
随着针对特定查询而优化的投影数量的增加，这些查询的性能得到提高。但是，已用磁盘空间量和加载数据所需的时间量也会增加。因此，应创建和测试设计以确定您的数据库配置的最佳投影数量。平均而言，选择实施查询特定投影的组织可通过添加几个查询特定投影来实现最佳性能。
Vertica 建议所有生产数据库都应至少将 K-safety 设置为 1 (K=1)。生产数据库的有效 K-safety 值为 1 和 2。非生产数据库不必为 K-safe，可将该值设置为 0。
K-safe 数据库必须至少包含三个节点，如下表所示：
仅当物理架构设计满足某些冗余要求时，才能将 K-safety 设置为 1 或 2。请参阅K-safe 物理架构设计的要求。
要创建具有 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 超投影。
监控表可以通过编程方式访问，以启用外部操作，例如警报。通过查询
SYSTEM 表内 DESIGNED_FAULT_TOLERANCE 和 CURRENT_FAULT_TOLERANCE 列中的设置，可以监控 K-safety 级别。
当群集中的 K 个节点出现故障时，数据库将继续运行，但性能会受到影响。如果故障节点的数据无法从群集中另一个正常工作的节点中获取，那么后续节点故障可能会导致数据库关闭。
Database Designer 使用值为 1 的 K-safety 为至少包含三个节点的群集自动生成设计。（如果群集具有一个或两个节点，它将使用值为 0 的 K-safety 生成设计。）您可以修改为三节点（或更大）群集创建的设计，而且 K-safe 要求已设置完毕。
如果您创建自定义投影，物理架构设计必须满足以下要求才能在出现故障时成功恢复数据库：
分段投影必须在所有节点上均 分段。请参考分段设计和为 K-safety 安全设计分段投影。
复制的投影必须在所有节点上均得到复制。请参阅为 K‑Safety 设计未分段投影。
分段投影必须具有 K+1 个 伙伴实例投影 — 具有相同列数和分段条件的投影，其中对应的分段放置在不同节点上。
可使用
MARK_DESIGN_KSAFE 函数确定您的架构设计是否满足 K-safety 的要求。
如果您使用 Database Designer 生成一个您可以修改的全面设计并且您不希望设计具有 K-safe，请将 K-safety 级别设置为 0（零）。
如果您想要从头开始，请执行以下操作为一个不具有 K-safety (K=0) 的有效数据库建立最低投影要求：
投影必须符合数据库 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 设计和分段设计。
在许多情况下，维度表相对较小，因此您无需将它们分段。相应地，您应该设计一个 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)
有关投影名称约定的详细信息，请参阅投影命名。
可使用哈希分段对投影分段。哈希分段可基于内置的哈希函数对投影进行分段。该内置哈希函数可使多个节点中的数据实现正态分布，从而优化查询的执行。在投影中，要进行哈希的数据由一列或多列值组成，每一列都包含大量唯一值，并且值的分布偏移程度在可接受的范围内。满足标准的主键列非常适合进行哈希分段。
分段投影时，确定哪些列用于对投影分段。选择具有大量唯一数据值和在数据分布中可接受的偏离的一个或多个列。主键列是哈希分段的绝佳选择。这些列在查询中所用的所有表上必须唯一。
尽管您可以从头开始编写自定义投影，但 Vertica 建议您使用 Database Designer 创建设计来作为起点。这样可确保您获得满足基本要求的投影。
在编写自定义投影之前，请仔细查看规划您的设计中的主题。不遵循这些注意事项可能会生成无法正常工作的投影。
要手动修改或创建投影：
使用
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 ('');
此函数从用于存储投影的所有节点中收集和聚合数据样本及存储信息，然后将统计信息写入到编录中。
超投影需要满足以下要求：
它们必须包含表中的每个列。
对于 K-safe 设计，必须在数据库群集内的所有节点上复制超投影（适用于维度表），或者与伙伴投影进行配对并跨越所有节点进行分段（适用于很大的表和中等的表）。有关投影及其存储方式的概述，请参阅投影和使用投影的高可用性。有关设计细节，请参阅K-safety 设计。
要实现最大可用性，超投影需要最大限度降低存储要求，同时最大限度提升查询性能。为了实现这一目标，超投影中列的排序顺序以存储要求和常用查询为基础。
列排序顺序是将存储空间要求降至最低和最大限度提高查询性能的重要因素。
最小化存储不但可以节省物理资源，而且还可以减少磁盘 I/O，以显著提高性能。通过在排序顺序中优先考虑低基数列，可以最大程度地减少投影存储。这会减少 Vertica 检索查询结果时所存储和访问的行数。
确定投影排序列后，分析其数据并选择效率最高的编码方法。Vertica 优化器使用运行长度编码 (RLE) 为列提供首选项，因此请确保在适当的情况下使用它。运行长度编码将相同值的序列（运行）替换为包含值和出现次数的单个对。因此，它特别适合用于运行长度较大的低基数列。
可通过列排序顺序提高查询性能，方法如下：
排序顺序应尽可能地使用最低基数确定列的优先级。
请勿在 LONG VARBINARY 和 LONG VARCHAR 类型的列上排序投影。
选择投影的排序顺序时，Vertica 具有多条建议，可以帮助您实现最大查询性能，如以下示例中所示。
当处理低基数列中的谓词时，组合使用 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 编码的优势，请仅在列的平均运行长度大于 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 的基数。
如果您测量和设置群集内的存储位置的性能，Vertica 将使用此信息确定在哪里基于列的排名来存储列。有关详细信息，请参阅设置存储性能。
Vertica 将投影排序顺序中包含的列存储在最快的可用存储位置。未包含在投影排序顺序中的列将存储在稍慢的磁盘中。每个投影的列按如下方式排序：
排序顺序中的列具有最高优先级（编号 >；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;