Redshift中text255与bytedict编码的差异及text255优势解析

text255相对bytedict的优势 #

虽然AWS文档明确两者功能接近，仅唯一值支持数量有20个的差距（text255最多235个，bytedict最多255个），但text255仍有几个实用优势：

• 兼容性更广泛：作为Redshift更早推出的字典编码，部分旧版客户端驱动、第三方数据集成工具对text255的适配更成熟，不会出现罕见的编码解析问题。
• 细微的性能优化：text255的编码/解码逻辑专门针对短字符串（长度≤255）做了精简，在高并发查询场景下，解压字符串的路径更直接，会带来极细微的性能提升（日常场景下几乎感知不到，但在超大规模数据集上可能体现）。
• 字典元数据更轻量：text255的字典存储结构比bytedict略简化，当唯一值数量较少时（比如你例子里的10个日本地区值），字典的额外存储开销会比bytedict少几个字节（可忽略，但对极致压缩场景有意义）。

关于text255“按单词压缩”的误解 #

你注意到的text255文档里的“words”表述，是术语定义的问题，它并不是按自然语言单词拆分压缩，这里的“words”就是指列的唯一字符串值，和bytedict的“column values”是同一个意思。

它的运作逻辑和bytedict完全一致：

1. 扫描列的所有唯一值，生成一个映射字典（每个唯一值对应一个1字节的编码）
2. 存储数据时，每行用对应的1字节编码代替原字符串
3. 查询时，引擎会自动将编码反向映射为原字符串，再执行过滤、关联等操作

以你的日本地区列为例，无论是text255还是bytedict，都会把10个地区值映射为10个1字节编码，每行仅占1字节，字典额外存储约80字节，存储和查询表现几乎无差异。

适用场景总结 #

• 当唯一值数量≤235时，优先选text255，兼容性和细微性能优势更实用；
• 当唯一值数量在236-255之间时，只能用bytedict；
• 当唯一值数量超过255时，这两种编码都不适用，建议选择LZO或ZSTD等通用压缩编码。

内容的提问来源于stack exchange，提问作者Woody1193