Amazon Redshift dejará de admitir la creación de nuevas UDF de Python a partir del parche 198. Las UDF de Python existentes seguirán funcionando hasta el 30 de junio de 2026. Para obtener más información, consulte la [publicación del blog](https://aws.amazon.com/blogs/big-data/amazon-redshift-python-user-defined-functions-will-reach-end-of-support-after-june-30-2026/). # Compresión de columnas para reducir el tamaño de los datos almacenados La *compresión* es una operación en el nivel de columna que reduce el tamaño de los datos cuando se almacenan. La compresión mantiene el espacio de almacenamiento y reduce el tamaño de los datos que se leen desde el almacenamiento, lo que reduce la cantidad de E/S del disco y, por consiguiente, mejora el rendimiento de las consultas. ENCODE AUTO es la opción predeterminada para las tablas. Cuando una tabla se establece a ENCODE AUTO, Amazon Redshift administra automáticamente la codificación de compresión para todas las columnas de la tabla. Para obtener más información, consulte [CREATE TABLE](r_CREATE_TABLE_NEW.md) y [ALTER TABLE](r_ALTER_TABLE.md). No obstante, si especifica la codificación de compresión para alguna columna de la tabla, esta ya no tendrá la opción ENCODE AUTO configurada. Amazon Redshift ya no administra automáticamente la codificación de compresión para todas las columnas de la tabla. Al crear una tabla, se puede aplicar de forma manual un tipo de compresión, o *codificación*, a las columnas de esta. O bien, se puede utilizar el comando COPY para analizar y aplicar la compresión automáticamente. Para obtener más información, consulte [Selección del comando COPY para las codificaciones de compresión](c_best-practices-use-auto-compression.md). Para obtener información acerca de la aplicación de la compresión automática, consulte [Carga de tablas con compresión automática](c_Loading_tables_auto_compress.md). **nota** Le recomendamos enfáticamente que use el comando COPY para aplicar la compresión automática. Puede elegir aplicar manualmente las codificaciones de compresión en caso de que la nueva tabla comparta las mismas características de datos que otra tabla. O puede hacerlo si detecta en las pruebas que las codificaciones de compresión aplicadas durante la compresión automática no son las más adecuadas para sus datos. Si selecciona aplicar codificaciones de compresión de forma manual, puede ejecutar el comando [ANALYZE COMPRESSION](r_ANALYZE_COMPRESSION.md) en una tabla que ya tenga datos y utilizar los resultados para seleccionar las codificaciones de compresión. Para aplicar la compresión de forma manual, debe especificar codificaciones de compresión para las columnas individuales como parte de la instrucción CREATE TABLE. La sintaxis es la siguiente. ``` CREATE TABLE table_name (column_name data_type ENCODE encoding-type)[, ...] ``` En este caso, *encoding-type* se obtiene de la tabla de palabras clave de la siguiente sección. Por ejemplo, la siguiente instrucción crea una tabla de dos columnas, la tabla PRODUCT. Cuando se cargan datos a la tabla, la columna PRODUCT\$1ID no se comprime, pero la columna PRODUCT\$1NAME sí, mediante una codificación por diccionario de bytes (BYTEDICT). ``` create table product( product_id int encode raw, product_name char(20) encode bytedict); ``` Puede especificar la codificación para una columna cuando se agrega a una tabla con el comando ALTER TABLE. ``` ALTER TABLE table-name ADD [ COLUMN ] column_name column_type ENCODE encoding-type ``` **Topics** + [Codificaciones de compresión](c_Compression_encodings.md) + [Prueba de las codificaciones de compresión](t_Verifying_data_compression.md) # Codificaciones de compresión Una *codificación de compresión* especifica el tipo de compresión que se aplica a una columna de valores de datos a medida que se agregan filas a una tabla. ENCODE AUTO es la opción predeterminada para las tablas. Cuando una tabla se establece a ENCODE AUTO, Amazon Redshift administra automáticamente la codificación de compresión para todas las columnas de la tabla. Para obtener más información, consulte [CREATE TABLE](r_CREATE_TABLE_NEW.md) y [ALTER TABLE](r_ALTER_TABLE.md). No obstante, si especifica la codificación de compresión para alguna columna de la tabla, esta ya no tendrá la opción ENCODE AUTO configurada. Amazon Redshift ya no administra automáticamente la codificación de compresión para todas las columnas de la tabla. Cuando utilice CREATE TABLE, ENCODE AUTO se deshabilita al especificar la codificación de compresión para cualquier columna de la tabla. Si se deshabilita ENCODE AUTO, Amazon Redshift asigna de forma automática una codificación de compresión a las columnas para las que no se especifica un tipo ENCODE de la siguiente manera: + A las columnas que están definidas como claves de ordenación se les asigna una compresión RAW. + A las columnas que están definidas como tipos de datos BOOLEAN, REAL o DOUBLE PRECISION se les asigna una compresión RAW. + Las columnas que se definen como tipos de datos SMALLINT, INTEGER, BIGINT, DECIMAL, CHAR, VARCHAR, DATE, TIMESTAMP o TIMESTAMPTZ tienen asignada la compresión AZ64. + Las columnas que se definen como tipos de datos CHAR o VARCHAR tienen asignada la compresión LZO. Puede cambiar la codificación de una tabla después de crearla mediante ALTER TABLE. Si deshabilita ENCODE AUTO mediante ALTER TABLE, Amazon Redshift dejará de administrar automáticamente las codificaciones de compresión de las columnas. Todas las columnas mantendrán los tipos de codificación de compresión que tenían cuando deshabilitó ENCODE AUTO hasta que los cambie o vuelva a habilitar ENCODE AUTO. Amazon Redshift admite las siguientes codificaciones de compresión: ------ #### [ Raw ] La codificación raw es la codificación predeterminada para las columnas designadas como claves de ordenación y para las columnas definidas como tipos de datos BOOLEAN, REAL o DOUBLE PRECISION. Con la codificación raw, los datos se almacenan descomprimidos y sin formato. ------ #### [ AZ64 ] AZ64 es un algoritmo codificado de compresión propiedad de Amazon que se ha diseñado para lograr una alta relación de compresión y un procesamiento mejorado de las consultas. En esencia, el algoritmo AZ64 comprime grupos de valores de datos más pequeños y utiliza instrucciones SIMD (una instrucción, varios datos) para realizar un procesamiento en paralelo. Utilice AZ64 para ahorrar una cantidad significativa de almacenamiento y conseguir un buen rendimiento con tipos de datos numéricos, de fecha y de hora. Puede utilizar AZ64 como codificación de compresión para definir columnas con instrucciones CREATE TABLE y ALTER TABLE y los siguientes tipos de datos: + SMALLINT + INTEGER + BIGINT + DECIMAL + DATE + TIMESTAMP + TIMESTAMPTZ ------ #### [ Byte-dictionary ] En la codificación por diccionarios de bytes, se crea un diccionario independiente de valores únicos para cada bloque de los valores de columna del disco. (Un bloque de disco de Amazon Redshift ocupa 1 MB). El diccionario tiene hasta 256 valores de un byte que se almacenan como índices de los valores de datos originales. Si se almacenan más de 256 valores en un mismo bloque, los valores adicionales se graban en un bloque descomprimido sin formato. El proceso se repite para cada bloque del disco. Esta codificación es muy eficaz en columnas de cadenas de cardinalidad baja. Esta codificación es una solución óptima cuando el dominio de los datos de una columna es menor que 256 valores únicos. En las columnas cuyo tipo de datos de cadena (CHAR y VARCHAR) está codificado con BYTEDICT, Amazon Redshift realiza exámenes vectorizados y evaluaciones de predicados que actúan directamente en los datos comprimidos. Estos exámenes utilizan instrucciones de instrucción única y datos múltiples (SIMD) específicas del hardware para el procesamiento paralelo. Esto acelera considerablemente el examen de las columnas de cadenas. La codificación por diccionario de bytes es muy eficaz en cuanto a espacio si una columna CHAR/VARCHAR almacena cadenas largas de caracteres. Supongamos que una tabla tiene una columna COUNTRY con un tipo de datos CHAR(30). A medida que se cargan datos, Amazon Redshift crea un diccionario y rellena la columna COUNTRY con el valor índice. El diccionario tiene los valores únicos indexados y la tabla en sí tiene solo los subscripts de un byte de los valores correspondientes. **nota** Los espacios a la derecha se almacenan en columnas de caracteres de longitud fija. Por lo tanto, en una columna CHAR (30), cada valor comprimido ahorra 29 bytes de almacenamiento cuando utiliza la codificación por diccionario de bytes. En la siguiente tabla, se representa el diccionario para la columna COUNTRY. [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/es_es/redshift/latest/dg/c_Compression_encodings.html) En la siguiente tabla, se representan los valores de la columna COUNTRY. [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/es_es/redshift/latest/dg/c_Compression_encodings.html) El tamaño total comprimido en este ejemplo se calcula de la siguiente manera: hay 6 entradas diferentes almacenadas en el diccionario (6 \$1 30 = 180) y la tabla tiene 10 valores comprimidos de 1 byte para un total de 190 bytes. ------ #### [ Delta ] Las codificaciones Delta son de gran utilidad para las columnas de fecha y hora. La codificación Delta comprime los datos al registrar la diferencia entre los valores que se suceden en la columna. Esta diferencia se registra en un diccionario independiente para cada bloque de valores de columnas del disco. (Un bloque de disco de Amazon Redshift ocupa 1 MB). Por ejemplo, supongamos que la columna contiene 10 valores enteros en secuencia del 1 al 10. El primero se almacena como un valor entero de 4 bytes (más una marca de 1 byte). Los nueve siguientes se almacenan cada uno como un byte con el valor 1, lo que indica que es un valor mayor que el anterior. La codificación Delta tiene dos variaciones: + DELTA registra las diferencias como valores de 1 byte (enteros de 8 bits) + DELTA32K registra las diferencias como valores de 2 bytes (enteros de 16 bits) Si la mayoría de los valores de la columna se pudieran comprimir con un solo byte, la variación de 1 byte resultaría muy eficaz. No obstante, si los deltas son mayores, esta codificación, en el peor de los casos, es de alguna manera menos eficaz que el almacenamiento de los datos sin comprimir. Se aplica una lógica similar a la versión de 16 bits. Si la diferencia entre dos valores supera el rango de 1 byte (DELTA) o el rango de 2 bytes (DELTA32K), se almacena el valor original completo, con una marca de 1 byte al principio. El rango de 1 byte abarca desde -127 hasta 127 y el rango de 2 bytes desde -32K hasta 32K. En la siguiente tabla, se muestra cómo funciona una codificación delta para una columna numérica. [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/es_es/redshift/latest/dg/c_Compression_encodings.html) ------ #### [ LZO ] La codificación LZO proporciona una relación de compresión muy alta con un buen rendimiento. La codificación LZO funciona especialmente bien para las columnas CHAR y VARCHAR que almacenan cadenas de caracteres muy largas. Resulta especialmente adecuada para textos de formato libre, como descripciones de productos, comentarios de usuarios o cadenas JSON. ------ #### [ Mostly ] Las codificaciones mostly son útiles cuando el tipo de datos de una columna es mayor que lo que requieren la mayoría de los valores almacenados. Al especificar una codificación mostly para este tipo de columnas, puede comprimir la mayoría de los valores de la columna a un tamaño de almacenamiento estándar más pequeño. Los valores restantes que no pueden comprimirse se almacenan sin formato. Por ejemplo, puede comprimir una columna de 16 bits, como una columna IT2, a un almacenamiento de 8 bits. Por lo general, las codificaciones mostly funcionan con los siguientes tipos de datos: + SMALLINT/INT2 (16 bits) + INTEGER/INT (32 bits) + BIGINT/INT8 (64 bits) + DECIMAL/NUMERIC (64 bits) Seleccione la variación adecuada de codificación mostly en función del tamaño de los tipos de datos de la columna. Por ejemplo, aplique la codificación MOSTLY8 a una columna definida para valores enteros de 16 bits. No está permitido aplicar MOSTLY16 a una columna con tipos de datos de 16 bits o MOSTLY32 a una columna con tipos de datos de 32 bits. La mayoría de las codificaciones pueden ser menos eficaces que la ausencia de compresión cuando no se puede comprimir un número relativamente elevado de los valores de la columna. Antes de aplicar una de estas codificaciones a una columna, realice la comprobación correspondiente. La *mayoría* de los valores que se vayan a cargar ahora (y que es probable que se carguen más adelante) deberían ajustarse a los rangos que se muestran en la siguiente tabla. [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/es_es/redshift/latest/dg/c_Compression_encodings.html) **nota** Para los valores decimales, omita la coma decimal para determinar si el valor se ajusta al rango. Por ejemplo, 1 234,56 es tratado como 123 456 y se puede comprimir en una columna MOSTLY32. Por ejemplo, la columna VENUEID de la tabla VENUE está definida como una columna de valores enteros sin formato, lo que significa que su valor consume 4 bytes de almacenamiento. No obstante, el rango actual de valores de la columna es de **0** a **309**. Por lo tanto, si se vuelve a crear y a cargar esta tabla con la codificación MOSTLY16 para VENUEID, se reduciría el almacenamiento de cada valor en esa columna a 2 bytes. Si la mayoría de los valores de VENUEID a los que se hace referencia en otra tabla estuvieran en el rango de 0 a 127, podría tener sentido codificar esa columna de clave externa como MOSTLY8. Antes de tomar una decisión, ejecute algunas consultas en los datos de la tabla de referencia para averiguar si la mayoría de los valores están comprendidos en el intervalo de 8 bits, 16 bits o 32 bits. En la siguiente tabla, se muestran los tamaños comprimidos para valores numéricos específicos cuando se utilizan codificaciones MOSTLY8, MOSTLY16 y MOSTLY32: [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/es_es/redshift/latest/dg/c_Compression_encodings.html) ------ #### [ Run length ] La codificación de run length reemplaza un valor que se repite de manera consecutiva por un token que consiste en el valor y un recuento de la cantidad de ocurrencias consecutivas (la longitud de la ejecución). Se crea un diccionario independiente de valores únicos para cada bloque de los valores de columna del disco. (Un bloque de disco de Amazon Redshift ocupa 1 MB). Esta codificación es una opción ideal para una tabla en la que los valores de datos suelen repetirse de manera consecutiva; por ejemplo, cuando la tabla está ordenada según esos valores. Por ejemplo, imagine que una columna de una tabla de grandes dimensiones presenta un dominio previsiblemente pequeño, como una columna COLOR con menos de 10 valores posibles. Es probable que estos valores queden dispuestos en secuencias de gran longitud en toda la tabla, incluso si los datos no están ordenados. No recomendamos aplicar la codificación de run length en ninguna columna que esté designada como clave de ordenación. Los exámenes de rango restringido funcionan mejor cuando los bloques tienen una cantidad similar de filas. Si las columnas de clave de ordenación se comprimen mucho más que otras columnas en la misma consulta, los exámenes de rango restringido podrían tener un rendimiento deficiente. En la siguiente tabla se utiliza el ejemplo de la columna COLOR para mostrar cómo funciona la codificación de run length. [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/es_es/redshift/latest/dg/c_Compression_encodings.html) ------ #### [ Text255 and Text32k ] Las codificaciones text255 y text32k son útiles para comprimir columnas VARCHAR en las que se repiten con frecuencia las mismas palabras. Se crea un diccionario independiente de palabras únicas para cada bloque de los valores de columna del disco. (Un bloque de disco de Amazon Redshift ocupa 1 MB). El diccionario tiene las primeras 245 palabras únicas de la columna. Estas palabras se reemplazan en el disco por un valor índice de un byte, lo que representa uno de 245 valores, y todas las palabras que no están representadas en el diccionario se almacenan sin comprimir. El proceso se repite para cada bloque de 1 MB del disco. Si las palabras indexadas se repiten con frecuencia en la columna, esta arrojará una alta relación de compresión. Para la codificación text32k, se aplica el mismo principio, pero el diccionario para cada bloque no captura una cantidad específica de palabras. En lugar de ello, el diccionario indexa cada palabra única que encuentra hasta que las entradas combinadas alcancen una longitud de 32K, menos alguna sobrecarga. Los valores índices se almacenan en dos bytes. Por ejemplo, veamos el caso de la columna VENUENAME en la tabla VENUE. Palabras como **Arena**, **Center** y **Theatre** son recurrentes en esta columna y es posible que estén dentro de las primeras 245 palabras que se encuentran en cada bloque si se aplica la compresión text255. En tal caso, esta columna se beneficia de la compresión. El motivo de ello es que cada vez que aparezcan esas palabras, ocuparán solo 1 byte de almacenamiento (en lugar de 5, 6 o 7 bytes, respectivamente). ------ #### [ ZSTD ] La codificación zstandard (ZSTD) proporciona una relación de compresión muy alta con un muy buen rendimiento en diferentes conjuntos de datos. La codificación ZSTD funciona especialmente bien para las columnas CHAR y VARCHAR que almacenan una gran variedad de cadenas de caracteres largas y cortas, como descripciones de productos, comentarios de usuarios, registros o cadenas JSON. Mientras que algunos algoritmos, como la codificación Delta o la codificación Mostly pueden, potencialmente, usar más espacio de almacenamiento que si se dejan los datos sin comprimir, es poco probable que ZSTD aumente el uso del disco. ZSTD admite los tipos de datos SMALLINT, INTEGER, BIGINT, DECIMAL, REAL, DOUBLE PRECISION, BOOLEAN, CHAR, VARCHAR, DATE, TIMESTAMP y TIMESTAMPTZ. ------ En la siguiente tabla, se identifican las codificaciones de compresión compatibles y los tipos de datos que admiten codificación. [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/es_es/redshift/latest/dg/c_Compression_encodings.html) # Prueba de las codificaciones de compresión Si decide especificar de forma manual las codificaciones de las columnas, posiblemente quiera probar los diferentes tipos de compresión con sus datos. **nota** Le recomendamos utilizar el comando COPY para cargar los datos siempre que sea posible y permitir que el comando COPY seleccione las codificaciones óptimas según sus datos. También puede utilizar el comando [ANALYZE COMPRESSION](r_ANALYZE_COMPRESSION.md) para ver las codificaciones sugeridas para los datos existentes. Para obtener información acerca de la aplicación de la compresión automática, consulte [Carga de tablas con compresión automática](c_Loading_tables_auto_compress.md). Para que la prueba de compresión de datos sea significativa, debe tener una gran cantidad de filas. Para este ejemplo, se crea una tabla y se insertan filas mediante el uso de una instrucción que selecciona datos de dos tablas, VENUE y LISTING. Se omite la cláusula WHERE que, por lo general, uniría las dos tablas. Como resultado de esto, *cada* fila de la tabla VENUE se une a *todas* las filas de la tabla LISTING, lo que supone un total de más de 32 millones de filas. Esta operación se la conoce como unión cartesiana y, por lo general, no se la recomienda. No obstante, a estos efectos, se trata de un método cómodo para crear muchas filas. Puede omitir este paso si ya tiene una tabla existente con datos que desea probar. Después de tener una tabla con datos de muestra, se crea una tabla con siete columnas. Cada una de ellas cuenta con una codificación de compresión diferente: raw, bytedict, lzo, run length, text255, text32k y zstd. Se rellena cada columna con los mismos datos por medio de la ejecución de un comando INSERT que selecciona los datos de la primera tabla. Si desea probar las codificaciones de compresión, haga lo siguiente: 1. (Opcional) Primero, utilice una unión cartesiana para crear una tabla con una gran cantidad de filas. Omita este paso si desea realizar la prueba con una tabla existente. ``` create table cartesian_venue( venueid smallint not null distkey sortkey, venuename varchar(100), venuecity varchar(30), venuestate char(2), venueseats integer); insert into cartesian_venue select venueid, venuename, venuecity, venuestate, venueseats from venue, listing; ``` 1. Luego, cree una tabla con las codificaciones que desea comparar. ``` create table encodingvenue ( venueraw varchar(100) encode raw, venuebytedict varchar(100) encode bytedict, venuelzo varchar(100) encode lzo, venuerunlength varchar(100) encode runlength, venuetext255 varchar(100) encode text255, venuetext32k varchar(100) encode text32k, venuezstd varchar(100) encode zstd); ``` 1. Inserte los mismos datos en todas las columnas utilizando una instrucción INSERT con una cláusula SELECT. ``` insert into encodingvenue select venuename as venueraw, venuename as venuebytedict, venuename as venuelzo, venuename as venuerunlength, venuename as venuetext32k, venuename as venuetext255, venuename as venuezstd from cartesian_venue; ``` 1. Compruebe la cantidad de filas en la tabla nueva. ``` select count(*) from encodingvenue count ---------- 38884394 (1 row) ``` 1. Consulte la tabla de sistema [STV\$1BLOCKLIST](r_STV_BLOCKLIST.md) para comparar la cantidad de bloques de 1 MB del disco que usa cada columna. La función de agregación MAX devuelve la cantidad máxima de bloques para cada columna. La tabla STV\$1BLOCKLIST incluye detalles de las tres columnas generadas por el sistema. En este ejemplo se utiliza `col < 6` en la cláusula WHERE para excluir las columnas generadas por el sistema. ``` select col, max(blocknum) from stv_blocklist b, stv_tbl_perm p where (b.tbl=p.id) and name ='encodingvenue' and col < 7 group by name, col order by col; ``` La consulta devuelve los siguientes resultados. Las columnas están numeradas a partir del cero. Los resultados pueden tener números diferentes, en función de cómo esté configurado su clúster, pero los tamaños relativos deben ser similares. Puede observar que la codificación BYTEDICT en la segunda columna produjo los mejores resultados para este conjunto de datos. Este enfoque tiene una relación de compresión de más de 20:1. La codificación LZO y ZSTD también produjeron resultados excelentes. Desde luego, los diferentes conjuntos de datos producen resultados distintos. Cuando una columna tiene cadenas de texto más largas, LZO suele producir los mejores resultados de compresión. ``` col | max -----+----- 0 | 203 1 | 10 2 | 22 3 | 204 4 | 56 5 | 72 6 | 20 (7 rows) ``` Si tiene datos en una tabla existente, puede utilizar el comando [ANALYZE COMPRESSION](r_ANALYZE_COMPRESSION.md) para ver las codificaciones sugeridas para la tabla. Por ejemplo, en el siguiente ejemplo, se muestra la codificación recomendada para una copia de la tabla VENUE, CARTESIAN\$1VENUE, que tiene 38 millones de filas. Observe que ANALYZE COMPRESSION recomienda utilizar la codificación LZO para la columna VENUENAME. ANALYZE COMPRESSION selecciona la compresión óptima en función de varios factores, incluido el porcentaje de reducción. En este caso en particular, BYTEDICT proporciona una mejor compresión, pero LZO también produce una compresión mayor que el 90 por ciento. ``` analyze compression cartesian_venue; Table | Column | Encoding | Est_reduction_pct ---------------+------------+----------+------------------ reallybigvenue | venueid | lzo | 97.54 reallybigvenue | venuename | lzo | 91.71 reallybigvenue | venuecity | lzo | 96.01 reallybigvenue | venuestate | lzo | 97.68 reallybigvenue | venueseats | lzo | 98.21 ``` ## Ejemplo El ejemplo siguiente crea una tabla CUSTOMER que tiene columnas con diferentes tipos de datos. Esta instrucción CREATE TABLE muestra una de las combinaciones posibles de codificaciones de compresión para estas columnas. ``` create table customer( custkey int encode delta, custname varchar(30) encode raw, gender varchar(7) encode text255, address varchar(200) encode text255, city varchar(30) encode text255, state char(2) encode raw, zipcode char(5) encode bytedict, start_date date encode delta32k); ``` En la siguiente tabla, se muestran las codificaciones de columnas que se eligieron para la tabla CUSTOMER y se da una explicación de las elecciones: | Columna | Tipo de datos | Codificación | Explicación | | --- | --- | --- | --- | | CUSTKEY | int | delta | CUSTKEY consta de valores enteros únicos consecutivos. Como las diferencias son de un byte, DELTA es una buena opción. | | CUSTNAME | varchar (30) | raw | CUSTNAME tiene un dominio mayor con menos valores repetidos. Es posible que cualquier codificación de compresión sea ineficaz. | | GENDER | varchar (7) | text255 | GENDER es un dominio muy pequeño con mucho valores repetidos. La codificación text255 funciona bien para las columnas VARCHAR, en las que se repiten las mismas palabras. | | ADDRESS | varchar (200) | text255 | ADDRESS es un dominio grande, pero tiene muchas palabras repetidas, como Street, Avenue, North, South, etcétera. Las codificaciones text255 y text 32k son útiles para comprimir columnas VARCHAR en las que se repiten las mismas palabras. La longitud de la columna es corta, por lo que text255 es una buena opción. | | CITY | varchar (30) | text255 | CITY es un dominio grande, con algunos valores repetidos. Algunos nombres de ciudades se utilizan con mucho más frecuencia que otros. Text255 es una buena opción por los mismos motivos que lo es para ADDRESS. | | STATE | char (2) | raw | En los Estados Unidos, STATE es un dominio preciso de 50 valores de dos caracteres. La codificación bytedict generaría cierta compresión, pero como el tamaño de la columna es de solo dos caracteres, es posible que la compresión no compense la sobrecarga de descomprimir los datos. | | ZIPCODE | char (5) | bytedict | ZIPCODE es un dominio conocido de menos de 50 000 valores únicos. Algunos códigos postales se utilizan con mucho más frecuencia que otros. La codificación bytedict es muy eficaz cuando una columna tiene una cantidad limitada de valores únicos. | | START\$1DATE | date | delta32k | Las codificaciones delta son de gran utilidad para las columnas con formato de fecha y hora, en especial si las filas se cargan en el orden de las fechas. |