提高效率的红移表设计

Posted 2023-03-31

【中文标题】提高效率的红移表设计

【英文标题】：Redshift table design for efficiency

【发布时间】：2016-08-11 18:52:42

【问题描述】：

我有一个带有单个 dc1.large 节点的 redshift 集群。我已经将数据写入其中，每天大约有 5000 万条记录，格式为时间戳、用户 ID 和项目 ID。项目ID（varchar）唯一，用户ID（varchar）不唯一，时间戳（timestamp）不唯一。

在我的大约 110m 条记录的 redshift 数据库中，如果我有一个没有排序键的表，则搜索单个项目 ID 大约需要 30 秒。

如果我有一个带有项目 ID 排序键的表，我会得到一个大约 14-16 秒的单个项目 ID 搜索时间。

如果我有一个包含所有三列的交错排序键的表，则单个项目 ID 搜索时间仍然是 14-16 秒。

我希望实现的是能够以秒为单位查询数千或数万个项目 ID 的记录。

查询看起来像

select count(*) from rs_table where itemid = 'id123';

或

select count(*) from rs_table where itemid in ('id123','id124','id125');

此查询在 541 毫秒内返回

select count(*) from rs_table;

AWS 文档表明，第一次运行查询时有一个编译时间，但我认为这不是我所看到的（如果是这样，那就不太理想了，因为每个独特的集合10,000 个 ID 可能永远不会再以完全相同的顺序查询。

我不得不假设我在排序键设计、查询或两者的某种组合上做错了——对于大约 10g 的表空间，像 redshift 这样的东西不应该花这么长时间来查询，对吧？

【参考方案1】：

乔希，

我们可能需要一些额外的信息才能给你一个好的推荐。

这里有一些事情要开始考虑。

您的大多数查询是否都按照上述方式记录查找？ 您的分发密钥是什么？ 您是否将此表与其他大型事实表连接起来？ 如果您每天加载 50M 条记录，而您的数据库中只有 110M 条记录 表，这是否意味着您只存储 2 天？ 您是否每天进行大量删除然后再加载 50M 条记录？ 您是否在加载后运行 ANALYZE？ 如果您删除了大量记录，是否运行了 VACUUM？

如果您的所有查询都与您描述的查询相似，您为什么要使用 Redshift？对于您描述的查询类型，Amazon DynamoDB 或 MongoDB（甚至 Cassandra）将是很好的数据库选择。

如果您运行分析工作负载，Redshift 是一个出色的平台。如果您对“记录查找”更感兴趣，NoSQL 选项以及 mysql 或 MariaDB 可能会为您提供更好的性能。

此外，如果这是一个开发/测试环境，并且您在没有运行 VACUUM 的情况下加载和删除了大量数据，您会发现性能显着下降。

【讨论】：

大多数是记录查询，是的 - 也可能基于用户 ID 进行选择。我没有选择特定的分发键。不会进行任何连接。数据是测试红移/系统实用性的样本，我们正在研究存储数月的数据。当前没有运行特定的删除计划。我们一直在流式传输数据，没有运行分析。有人建议我红移，但根据你所说的，这听起来可能是一个糟糕的建议——我也会去看看 Dynamo，谢谢！