我一直在为一个新的应用程序做一些AWS Redshift的负载测试,我注意到它的每个表的列限制为1600.更糟糕的是,随着表中列数的增加,查询速度会变慢.
这里没有任何意义的是Redshift应该是一个列存储数据库,理论上不应该是来自未在特定where子句中选择的列的I / O命中.
更具体地说,当TableName是1600列时,我发现下面的查询比TableName例如1000列和相同行数要慢得多.随着列数的减少,性能提高.
SELECT COUNT(1) FROM TableName WHERE ColumnName LIKE '%foo%'
我的三个问题是：
>这是什么交易？如果Redshift声称是一个专栏店,为什么会有这个限制？
>有关解决此限制的任何建议吗？多个较小表的连接似乎最终接近单个表的性能.我还没有尝试过旋转数据.
>有没有人建议快速,实时的性能,水平可扩展的列存储数据库没有上述限制？我们所做的只是对大约10M(行)×2500(列)数据的限制进行简单计数查询.
解决方法
我无法准确解释为什么它减速太多,但我可以证实我们经历过同样的事情.
我认为部分问题是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 cols(~200GB)到~60 cols(~25GB),查询时间提高了10倍以上(30-40下降到1-2秒).
