刚刚测试了AWS Redshift,并在插入时发现了一些重复数据,我希望这些数据在键列中的重复时会失败,阅读文档显示主键约束没有“强制”。
任何人都想出了如何防止主键重复(根据“传统”期望)。
感谢所有 Redshift 先驱!
刚刚测试了AWS Redshift,并在插入时发现了一些重复数据,我希望这些数据在键列中的重复时会失败,阅读文档显示主键约束没有“强制”。
任何人都想出了如何防止主键重复(根据“传统”期望)。
感谢所有 Redshift 先驱!
我在创建记录时分配 UUID。如果记录本质上是唯一的,我使用类型 4 UUID(随机),如果不是,我使用类型 5(SHA-1 哈希),使用自然键作为输入。
然后,您可以非常轻松地按照AWS 的此说明执行 UPSERT。如果您的输入有重复,您应该能够通过在临时表中发出类似于以下内容的 SQL 来进行清理:
CREATE TABLE cleaned AS
SELECT
pk_field,
field_1,
field_2,
...
FROM (
SELECT
ROW_NUMBER() OVER (PARTITION BY pk_field order by pk_field) AS r,
t.*
from table1 t
) x
where x.r = 1
如果添加标识列用作 rowid 为时已晚(ALTER
不允许您IDENTITY
在 Redshift 中添加列),您可以这样做:
DISTINCT
摆脱欺骗)这是一个示例:(假设id
是您检查欺骗的关键,并且data_table
是您的桌子)
CREATE TEMP TABLE delete_dupe_row_list AS
SELECT t.id FROM data_table t WHERE t.id IS NOT NULL GROUP BY t.id HAVING COUNT(t.id)>1;
CREATE TEMP TABLE delete_dupe_rows AS
SELECT DISTINCT d.* FROM data_table d JOIN delete_dupe_row_list l ON l.id=d.id;
START TRANSACTION;
DELETE FROM data_table USING delete_dupe_row_list l WHERE l.id=data_table.id;
INSERT INTO data_table SELECT * FROM delete_dupe_rows;
COMMIT;
DROP TABLE delete_dupe_rows;
DROP TABLE delete_dupe_row_list;
确认,他们不强制执行:
唯一性、主键和外键约束仅供参考;它们不是由 Amazon Redshift 强制执行的。尽管如此,主键和外键被用作计划提示,如果您的 ETL 过程或应用程序中的某些其他过程强制执行它们的完整性,则应声明它们。
例如,查询计划器在某些统计计算中使用主键和外键,以推断影响子查询去相关技术的唯一性和引用关系,对大量连接进行排序,并消除冗余连接。
规划器利用这些键关系,但它假定 Amazon Redshift 表中的所有键在加载时都是有效的。如果您的应用程序允许无效的外键或主键,某些查询可能会返回不正确的结果。例如,如果主键不唯一,则 SELECT DISTINCT 查询可能会返回重复的行。如果您怀疑表的有效性,请不要为表定义键约束。另一方面,当您知道它们是有效的时,您应该始终声明主键和外键以及唯一性约束。
Amazon Redshift 确实强制执行 NOT NULL 列约束。
http://docs.aws.amazon.com/redshift/latest/dg/t_Defining_constraints.html
一种快速而肮脏的方法是使用 group by
select max(<column_a>), max(<column_a>), <pk_column1>, <pk_column2>
from <table_name>
group by <pk_column1>, <pk_column2>
是的,你不能那样做。目前,我认为您应该只插入带有额外时间戳列的重复数据(基本上是重复的键)。所以它将包含该特定行的所有版本,因为更新也是一个插入,当您查询 Redshift 时,请确保选择最新的。
我正在使用 IDENTITY 自动增加我的主键。
这是我在 AWS 论坛上提出的一个问题:
https://forums.aws.amazon.com/message.jspa?messageID=450157#450157