在Redshift中创建大型VARCHAR值有缺点吗？

源数据保持为持续变得越来越大的字段投掷值。现在我正在使用VARCHAR（200），但我可能会去VARCHAR(400)。使用大数字有什么不利吗？在Redshift中创建大型VARCHAR值有缺点吗？

来源

2015-05-14 simplycoding

你是什么意思“下行”？如果不使列的大小足够大，那么存在一个非常大的缺点 - 您无法使用它来存储要在其中存储的值。

至于额外的开销，你不必担心。一个varchar()类型基本上只占用该值所需的存储空间，另外还有一个小长度的开销。另外，“400”不是那么大的数字，特别是与“200”相比时。

因此，如果您需要400个字节来存储该值，请更改表以存储它。改变值的长度可能会有开销。我不确定RedShift是否会因为类型改变而感到需要复制数据。但是，对性能的影响应该可以忽略不计。

来源

2015-05-15 01:10:23

我只是假设，以为会有额外的开销来分配的空间变化量为字段 – simplycoding

不要为了方便而使用最大列大小。

取而代之的是，考虑一下您可能存储在VARCHAR列中的最大值，并相应地调整列的大小。由于Amazon Redshift非常有效地压缩列数据，因此创建比所需大得多的列对数据表大小的影响最小。但是，在处理复杂查询期间，中间查询结果可能需要存储在临时表中。由于临时表未进行压缩，因此不必要的大型列会占用过多的内存和临时磁盘空间，这会影响查询性能。

http://docs.aws.amazon.com/redshift/latest/dg/c_best-practices-smallest-column-size.html

来源

2015-05-19 07:59:45

。。该文档没有意义。 'VARCHAR（）'仅为正在存储的值使用空间，外加固定的少量开销（http://docs.aws.amazon.com/redshift/latest/dg/r_Character_types.html）。无论值是否未压缩，RedShift都不应该将填充的varchar值长于实际长度。 –

那么这些文档是由数据库维护人员编写的，所以我想这是有原因的。更重要的是，我已经测试过它，它有助于改善。如果我不得不猜测，我怀疑在查询处理时，当列被“重新实现”为行时，数据库会为潜在的巨大列分配额外的RAM。 –

在Redshift中创建大型VARCHAR值有缺点吗？

回答

相关问题