如何在 redshift 中实现行级版本控制？答案

【问题标题】：How to achieve row level versioning in redshift?如何在 redshift 中实现行级版本控制？
【发布时间】：2017-02-22 14:40:13
【问题描述】：

我正在使用 AWS Redshift 执行分析查询。查询进行一些计算并更新键的值。该结果被导出到队列系统以供异步客户端使用。但是，由于排队系统不保证顺序，我需要一种机制来确定顺序。我需要像“update_version”列这样的东西，它在每次更新操作中都会增加。这类似于optimistic locking。

如何在 redshift 中实现这一点？

一种方法是使用时间戳，但它不可靠，因为时间戳是从集群中的各个节点获取的，并且容易出现clock skew。

我不需要全局排序。

注意：请不要建议使用有序队列，因为有不同的挑战超出了这个问题的范围。

【问题讨论】：

如果两个进程同时更新一个键的值，为什么一个比另一个更正确？换句话说，如果您的队列工作人员丢弃了任何比最近处理的消息更早的新消息，时钟偏差会产生什么不同？
此外，即使给定数据点的值可能分布在多个节点上，也只有选择运行更新查询的工作节点上的时钟才会计算在内。对于给定更新，各个节点存储中的所有时间戳值都是相同的。

标签： amazon-web-services database-design versioning amazon-redshift

【解决方案1】：

您可以执行以下操作之一：

运行UPDATE my _table SET update_version = update_version+1;
运行INSERT INTO my_table SELECT *, update_version = N FROM my_table;

UPDATE 对您的表更具破坏性（现有数据范围变得越来越未排序）但更易于查询。 INSERT 的破坏性较小（新数据附加到未排序的区域，现有数据不受影响），但如果您只需要查找当前值，则更难查询。

如果您想使用UPDATE 策略但您关心历史记录，您应该考虑使用my_table_history 表，您在执行更新之前将当前行值写入。

【讨论】：