CREATE TABLE AS SELECT 在 vertica 上性能较差

Question

我们目前正在将 DBMS 迁移到 vertica，但在处理重复项时遇到问题。在 MySQL 中，我们简单地使用了

INSERT IGNORE

。数据输入流中的重复项必须在数据库层进行过滤。 我通过使用一个没有约束的

tableName_import

表来实现这一点，该表将用于存储所有数据。另一个表

tableName_dedup

仅包含没有重复项的数据。

CREATE TABLE IF NOT EXISTS tableName_dedup
AS SELECT column1, column2, ...
FROM (SELECT *, row_number OVER (PARTITION BY column1, column2)
as rownum FROM tableName_import) import
where import.rownum = 1;

tableName_import

表包含大约 150 万个条目和 2GB 数据。

tableName_dedup

表的创建大约需要10分钟。

有没有办法提高性能？

编辑：导入表中有一个

VARCHAR(50000)

列。当我删除此列时，查询将在几秒钟内运行。为什么这一列会使查询速度减慢这么多？

Answer 1

与机器一起工作，而不是对抗它。

INSERT ... IGNORE 是一种非常具体且不直观的子句类型，因此很少有数据库支持它。

MERGE 命令更为常见，您可以省略 WHEN MATCHED THEN UPDATE 子句，如下所示：

MERGE /*+DIRECT*/ 
INTO  d_teas_scd  t 
USING d_teas_stg  s
   ON s.tea_key = t.tea_key
WHEN NOT matched THEN INSERT (
  tea_key
, tea_id
, tea_eff_dt
, tea_end_dt
, tea_name
, tea_price
) VALUES (
  s.tea_key
, s.tea_id
, s.tea_eff_dt
, s.tea_end_dt
, s.tea_name
, s.tea_price
);

如果您想使用 OLAP 函数 - 那么请尝试分析 LIMIT 子句，我认为这是 Vertica 独有的，并且如下：

SELECT
  *
FROM d_teas_scd
LIMIT 1 OVER(PARTITION BY tea_id ORDER BY tea_eff_dt DESC)
;

相当有效率...

祝你好运-

Answer 2

不确定这是否有帮助，但这就是我们处理重复项的方式。

您可以使用 COPY TABLE 函数复制表及其内容。这将复制分区表达式、投影、键等。

完成此操作后，您可以对复制的表进行重复数据删除，然后使用 SWAP_PARTITIONS_BETWEEN_TABLES 函数。

这会将复制表中的分区与您的工作表交换，并且是即时的。然后您所要做的就是删除复制的表。

唯一需要一点时间的是重复数据删除，但您可以执行删除操作，包括 row_number OVER (PARTITION BY column1, column2) 来删除重复项。

编写脚本时需要花费更多时间，但它应该比 CREATE TABLE AS SELECT 快得多。

谢谢

Answer 3

RDBMS 内部使用具有固定列宽的记录数组的内存缓冲区。 Vertica 是一个 RDBMS，工作方式相同，如 Oracle 或 SQLServer 等。

在这个固定长度的内存结构中，如果您知道记录号和字段索引或名称，您可以计算任何记录中任何字段的偏移量。这是对任何记录中任何字段的快速索引。

分配具有固定长度字段的记录数组有缺点 - 对于字符串，您需要具有最大长度的字段。例如，如果表具有数据类型 varchar(10) 的列，则内部内存缓冲区将分配 10 个字节的字段。如果一个表行只有 5 个字符值（例如“short”），则内存中会分配 5 个额外字节。

当您声明列 varchar(50000) 时，您最终会得到非常低效的内部内存结构。例如，如果您实际上仅使用 10 个字符字符串填充很长的 varchar (50000) 字段，则效率极低。内部 Vertica 内存块通常为 128K，最终每个内存块只有 2 条记录。

对于任何 RDBMS，强烈建议不要为 varchar 字段分配额外的长度，因为这会影响性能。

vertica 中最大字段长度过长导致的性能下降比其他 RDBMS 中更为明显。 Vertica 在查询执行期间（重新分段等）通过网络发送内存缓冲区。最大字段长度过大使 Vertica 通过网络发送明显更多的缓冲区，这正是您看到 CREATE TABLE 性能缓慢的原因。

是的，Vertica 可以在磁盘上有效地以编码/压缩形式存储字符串，并且字段最大长度不会影响磁盘上的字段大小。一旦从磁盘读取数据，Vertica 就会对其进行解压缩，并且所有进一步的处理都以与常规 RDBMS 相同的方式完成。 （Vertica 中有一种 RLE 处理对于字符串和其他数据类型更有效，但并不总是发生）。

Vertica 实际上有查询调整技术 - 找到所有超出的最大字段长度，并将其减少到最小值。如果表设计不佳且最大字段长度过大，则可能会带来相当大的查询性能改进。