Con respecto a "Dinámico" , el formato no comprimido de Barracuda, muy poco ha cambiado de compacto, principalmente en cómo se almacenan los blobs (y cualquier campo muy dinámico) . Nunca he tenido ningún problema con compact vs dynamic, por lo que puedo recomendar con seguridad la dinámica de Barracuda. Recuerde que Barracuda también admite viejos formatos de fila redundantes y compactos .
El artículo que está mencionando es probablemente demasiado antiguo (5.1) y, como Peter Z., CEO de Percona, menciona en los comentarios, puede ser un poco engañoso. Eso no significa que la compresión no pueda ser una gran ganancia dependiendo de las cargas de trabajo. Sin embargo, le recomendaría que lo pruebe en versiones> = 5.6, ya que tanto Facebook como Oracle han realizado muchas mejoras al respecto.
Como materiales de referencia más recientes, le recomendaría:
En particular, me gustan los materiales de Facebook, ya que son de terceros (sin necesidad de una agenda) y tienen una de las implementaciones de MySQL más grandes del mundo. Como puede ver, han tenido configuraciones muy exitosas que combinan tecnología SSD con compresión.
¿Te beneficiará? Eso dependerá de su carga de trabajo, conjunto de trabajo y configuración (IOPS, memoria) . Dependiendo de si está vinculado a IO, CPU o memoria, la compresión puede afectar negativamente en algunos casos, al agregar CPU adicional, los requisitos de memoria (las páginas comprimidas y sin comprimir se almacenan en el grupo de búferes InnoDB) o generar demasiados errores de compresión, aumentando la latencia También depende del tipo de datos: la compresión puede ayudar mucho con grandes blobs de texto, pero puede ser inútil con datos ya comprimidos.
En mi experiencia, en la práctica, hay personas para las cuales la compresión fue el santo grial del rendimiento y están muy contentas con ella, pero en otros casos, tuvimos que volver a los datos sin comprimir ya que no se obtuvo ganancia. Si bien una carga de trabajo de escritura muy pesada puede parecer un mal entorno para la compresión, si en su caso particular no está vinculado a la CPU y a la memoria, pero atado a iops, puede ser útil.
En general, es muy difícil predecir los resultados, por lo general, debe configurar un entorno de prueba para la evaluación comparativa y luego descubrir por qué obtiene mejores o peores resultados (y de esa manera puede jugar con diferentes tamaños de bloque, etc.). Barracuda es completamente seguro. La compresión puede o no ser para ti. Y siempre puede experimentar con otros métodos de compresión como la compresión de blobs del lado del cliente (por ejemplo, si termina vinculado a la CPU) u otros motores de terceros como RocksDB y TokuDB , en los que la compresión es una gran prioridad, ya que está enfocada en rendimiento para conjuntos de datos más grandes de lo que InnoDB puede manejar.
En pocas palabras: las principales razones para usar Barracuda son el manejo de BLOB, la innodb_large_prefixcompatibilidad (índices grandes) y la compresión. Dinámico, en MySQL 8.0 ahora es el formato de archivo predeterminado.
