puede ejecutar el comando ANALYZE COMPRESSION en una tabla que ya tenga datos y utilizar los resultados para seleccionar las codificaciones de compresión.
Primeros pasos en la arquitectura no transaccional
Manejo de Big Data con Reptiit en Amazon AWS
Data Warehouse y Modelo Dimensional en Amazon Repsheet
Bases de Datos Columnares: Eficiencia en Consultas Analíticas
Procesamiento de Datos con Repsheet y Clústeres SQL
Configura tu entorno de trabajo para Redshift
Configuración de IAM y S3 en AWS para Repsheet
Configuración de Clúster en Amazon Repsheet para Big Data
Conexión y Configuración de Repsheet con Clientes Externos
Carga de Datos a Redshift desde Amazon S3: Paso a Paso
Cómo diseñar tu base de datos para mejorar su desempeño
Compresión de Datos en Repsheet: Algoritmos y Aplicaciones
Algoritmos de Compresión de Datos: Musley y Otros Métodos Eficientes
Compresión de Datos en SQL: Evaluación y Comparación de Algoritmos
Compresión de Datos en Repsheet: Optimización y Análisis
Algoritmos de Distribución de Datos en Repsheet
Distribución de Datos en Tablas SQL con Repsheet
Llaves de Ordenamiento en Bases de Datos: Compuesta vs. Intercalada
Pruebas de Algoritmos de Ordenamiento en SQL con AWS S3 y Redshift
Consultas SQL y Algoritmos de Ordenamiento Avanzados
Optimización de Datos en Data Warehouses con Repsheet
Manejo de Tipos de Datos en Amazon Redshift
Optimización de Bases de Datos en Modelos Dimensionales
Manipular enormes cantidades de datos
Carga Masiva de Datos en Repshit con el Comando COPY
Cargar datos JSON a Redshift usando el comando Copy
Parámetros Comunes del Comando COPY en Amazon Redshift
Carga Masiva de Datos sin Delimitador en RedSheet
Inserción de Datos en Repsheet sin Archivos Planos
Actualización Eficiente de Datos en Repsheet con Tablas Auxiliares
Optimización de Bases de Datos con Analyze y Vacuum en Repsheet
Optimización de Bases de Datos: Estadísticas y Limpieza de Tablas
Buenas prácticas para diseñar y ejecutar consultas en tu base de datos
Buenas prácticas de SQL en bases de datos columnares
Optimización de Consultas SQL con Plan de Ejecución y Llaves de Ordenamiento
Análisis de comportamiento y descarga de datos con Redshift
Exportación de Datos desde Repsheet a Amazon S3 con Unload
Tablas útiles para administración en Repsheet
Conclusiones
Gestión de Datos y Consultas en Repsheat
No tienes acceso a esta clase
¡Continúa aprendiendo! Únete y comienza a potenciar tu carrera
El algoritmo Musley es una herramienta poderosa en la comprensión de datos, especialmente útil cuando la mayoría de los datos en una columna tiene valores significativamente más bajos que el dato máximo. Este algoritmo es ideal en situaciones donde se ha creado una columna de gran tamaño debido a unos pocos datos que lo requieren, mientras la mayoría son bastante pequeños en comparación. Musley tiene tres variantes o "sabores": de ocho, doce y treinta y dos bits, y se aplica a tipos de datos numéricos.
Elegir el tipo correcto de codificación Musley requiere un buen entendimiento de los datos para maximizar la eficiencia.
RoundLink es una técnica ideal para datos categóricos con pequeñas distribuciones, donde los valores únicos son limitados. En estos casos, aunque el orden de los datos no es esencial, la compresión se beneficia de la repetición consecutiva de categorías como, por ejemplo, las suscripciones en una plataforma.
Esta forma de compresión puede reducir dramáticamente el tamaño de los datos almacenados, de 50 bytes a solo 32 bytes en el ejemplo dado.
El text 255 y text 32,000 son algoritmos específicos para la compresión de texto en bases de datos. Si en una columna existen patrones comunes o ciertas palabras se repiten frecuentemente, estas herramientas pueden ser muy efectivas.
Estos algoritmos son particularmente valiosos cuando se manejan direcciones o cualquier tipo de texto con palabras predecibles como 'calle', 'carrera' o 'edificio'.
La codificación estándar es es una técnica versátil que se aplica tanto a datos numéricos como textuales, buscando reducir su tamaño sin comprometer la integridad o calidad. Esta técnica es ampliamente utilizada en la actualidad debido a su capacidad para disminuir el tamaño de las bases de datos de manera efectiva, facilitando el manejo y procesamiento de grandes cantidades de información.
Para seleccionar la mejor estrategia de codificación y compresión, es esencial comprender en profundidad los datos y el negocio al que sirven:
Este conocimiento no solo optimiza la compresión de datos, sino que también informa decisiones arquitectónicas para gestionar eficazmente la información en sistemas complejos.
Aportes 14
Preguntas 0
puede ejecutar el comando ANALYZE COMPRESSION en una tabla que ya tenga datos y utilizar los resultados para seleccionar las codificaciones de compresión.
Un pequeño resumen del final:
ID: Como el incremento por cada ID es de uno puedo comprimir cada registro en 1 byte.
Nombre: Es mejor dejar la data limpia. La compresión para estos datos tan variables puede que me genere problemas.
Género: Bytedict(diccionario de bytes) para decir hombre es 0, mujer 1 y desconocido 2. O text255, porque va a encontrar palabras muy frecuentes: Hombre , mujer o cualquier otro género.
País: Hay menos de 256 país o posiblemente la empresa contacta con cierta cantidad de países menores a 256. y también deben haber 255 palabras muy frecuentes.
Ciudades: En este caso si puede existir más de 256 ciudades entonces no podemos usar bytedict. Pero si se puede usar text255 porque van a existir ciudades muy repetitivas.
Suscripcion_promo: Si se repiten los registros y son repetitivos el runlength puede ayudar. Es igual que las suscripciones de Platzi, Expert, Expert+, Basic.
Fecha_creacion : Los registros pueden ser muy recurrentes o no. Pero la diferencia de registro en registro puede ser lo suficiente para que el delta32K funcione.
Como Data scientist o ingeniero de dato debemos conocer los datos , como se mueven y el negocio. La arquitectura va muy ligada a eso.
En el side uno dice “mejores” en vez de “menores” 😛
Mostly encoding
Encoding Compressed storage size Range of values that can be compressed (values outside the range are stored raw)
MOSTLY8 1 byte (8 bits) -128 to 127
MOSTLY16 2 bytes (16 bits) -32768 to 32767
MOSTLY32 4 bytes (32 bits) -2147483648 to +2147483647
Fuente: Link
Toda la base de datos tiene que estar compresa de la misma forma?
Sigo con la duda que en cuales casos es mejor con comprimir columnas que usar normalización 😦.
Por ejemplo con la codificación Runlength, siento que se podría resolver el mismo problema creando una tabla planes y haciendo referencia a los id en las otras tablas.
MOSTLY16 2 bytes (16 bits) De -32768 a 32767
me gusta por el tema columnar la facilidad en poder realizar este tipo de compresión.
Me encantan los algoritmos de compresión son muy ingeniosos
¿Tenemos un curso de estos en Platzi?
INTERESANTE
¿Quieres ver más aportes, preguntas y respuestas de la comunidad?