Amazon Redshift - 复制 - 数据加载与查询性能问题

Posted 2023-03-30

【中文标题】Amazon Redshift - 复制 - 数据加载与查询性能问题

【英文标题】：Amazon Redshift - Replication - Data load Vs Query Performance Issues

【发布时间】：2017-03-15 09:10:00

【问题描述】：

我们正在将我们的数据仓库从 Oracle 迁移到 Redshift。 目前我们有两个 Oracle 数据库实例——一个 DW 实例（主）全天从不同来源获取数据，另一个 DW（辅助）实例从主 DW 复制数据。所有报告平台都指向辅助 DW 实例。我们如何在 Redshift 中解决这个问题？我们是否需要有两个 Redshift 实例，一个从另一个复制？如果我们只有一个 Redshift 实例，数据加载开销会影响查询性能。会不会有表锁问题？

感谢您的建议。谢谢。

【参考方案1】：

这实际上取决于您的报告平台需要以多快的速度访问全天加载的数据。如果它可以等待，那么在安静的时间批量加载是有意义的。我怀疑您在当前设置中使用复制，因此您需要尽快加载数据并使其可用。

在这种情况下，使用 Redshift 的工作负载管理 (WLM) 设置是有意义的。这允许您指定多个工作负载组，并为每个工作负载分配并发级别和集群资源分配。使用此模型，您可以隔离资源，以确保您的报告工具和最终用户的查询性能得到一致的资源分配，同时仍将集群的查询队列和资源的一部分专用于您的数据加载。

这也将消除使用两个单独的数据库实例来处理加载和提供数据的需要。

有关 Redshift 中 WLM 的更多详细信息，请参见此处：http://docs.aws.amazon.com/redshift/latest/dg/cm-c-implementing-workload-management.html

【参考方案2】：

永远不要从同一个实例读取和写入。甚至在 Redshift 中也没有。即使在一般情况下，任何强制您在同一台机器上读写的系统都反映了糟糕的设计。

由于您正在讨论 Amazon Redshift，我可以非常轻松地假设您拥有分析数据。 （具有列式架构的 Redshift 针对读取而不是写入进行了优化。因此，如果您碰巧在 Redshift 上存储事务数据，我建议您重新考虑您的决定。

在设计任何关于分析数据的基础设施之前，我们应该始终考虑：

会很庞大。 并且在不久的将来会进一步扩展。

当您进行扩展时，从同一台机器读取和写入将是灾难性的。不要忘记锁。 Delete / Truncate 将在桌子上保留Exclusive Locks。如果碰巧其他进程用户已经获得了这个锁，那么即使对该表的写入也会失败，从而弄乱数据。

以上原因可能足以说明为什么不使用单个仓库来读取/写入数据。

遵循以下模型，整洁干净，不会干扰，并确保您不会遇到一致性和锁定等问题：

 +
 |
 |
 |  DS 1     +------------+            +------------+
 +---------> |            |            |            |
             |            | AGGREGATES |            |     reads
    DS 2     |   DW 1     +----------> |    DW 2    | +----------->
+----------> |            |            |            |
             |            |            |            |
+----------> +------------+            +------------+
|... DS n
|
+
where DS : Data Source , DW : Data Warehouse

从 DW 1 迁移数据 --> DW 2 将完全取决于您必须引用数据的频率。