sql - AWS Redshift 列限制？

Question

我一直在为一个新应用程序对 AWS Redshift 进行一些负载测试，我注意到它的每个表的列限制为 1600。更糟糕的是，查询会随着表中列数的增加而变慢。

这里没有任何意义的是，Redshift 应该是一个列存储数据库，理论上不应该有来自未在特定 where 子句中选择的列的 I/O 命中。

更具体地说，当 TableName 为 1600 列时，我发现下面的查询比如果 TableName 为 1000 列且行数相同时要慢得多。随着列数的减少，性能会提高。

SELECT COUNT(1) FROM TableName
WHERE ColumnName LIKE '%foo%'

我的三个问题是:

这是怎么回事？如果 Redshift 声称是列存储，为什么会有这个限制？

有关解决此限制的任何建议？多个较小表的连接似乎最终接近单个表的性能。我还没有尝试过旋转数据。

有没有人对没有上述限制的快速、实时性能、水平可扩展的列存储数据库提出建议？我们所做的只是用简单的 where 限制对大约 10M(行)x 2500(列)数据进行计数。

Answer 1

我无法准确解释为什么它变慢了这么多，但我可以证实我们也经历过同样的事情。

我认为部分问题在于 Redshift 每个节点每列至少存储 1MB。拥有大量列会产生大量磁盘搜索事件和 I/O 开销。

1MB 块是有问题的，因为其中大部分将是空白空间，但仍会从磁盘中读取

拥有大量块意味着列数据不会靠得很近，因此 Redshift 必须做更多的工作才能找到它们。

另外，(我突然想到)我怀疑 Redshift 的 MVCC 控件会增加很多开销。它试图确保您在查询执行时获得一致的读取，并且可能需要记下 全部 查询中表的块，甚至是未使用的列的块。 Why is an implicit table lock being released prior to end of transaction in RedShift?

FWIW，我们的专栏几乎都是 BOOLEAN我们已经有了 非常将它们(位掩码)压缩为 INT/BIGINT 并使用按位函数访问值的结果很好。一个示例表从 1400 列(~200GB)变为~60 列(~25GB)，查询时间提高了 10 倍以上(30-40 秒缩短到 1-2 秒)。