PostgreSQL vs MySQL

posgresmysql

Uno de los errores más comunes al momento de seleccionar un RDBMS libre es basarse en la popularidad, lo que “todos usan” o que “todos sugieren” por las razones que “todos comentan”, en vez de realizar un análisis personal. Pues bien, como han sido tantos los casos que he visto, me he dado a la tarea de escribir este breve post que deseo ayude en la selección del RBMS que realmente necesitas.

Percepción.

Por años, se ha tenido la percepción de que MySQL es más rápido y fácil de usar que PostgreSQL. A PostgreSQL se le percibe como un RDBMS más poderoso, más enfocado en integridad de datos, y más estricto en cumplir con las especificaciones SQL y que por lo tanto más lento y difícil de usar. Sin embargo, ambos han tenido un crecimiento diferente, por ejemplo, MySQL (hasta su versión 5.1) había sido fragmentado en proyectos como Drizzle, Percona, MariaDB y OurDelta, mientras que PostgreSQL (hasta su versión 8.3) se ha mantenido en un único esfuerzo, enfocándose en mejorar su desempeño y escalabilidad.

PostgreSQL.

PostgreSQL se desempeña mejor especialmente en ambientes con altas cargas de usuario y consultas complejas y donde la integridad de los datos es muy importante. Además de proveer mecanismos de autenticado como LDAP y Kerberos, y una vez autenticado, toda la comunicación puede realizarse utilizando SSL para ambientes donde que requiere ese nivel de seguridad.

Al agregar y modificar datos, PostgreSQL hace cumplir un número de reglas definidas por el usuario para asegurar la calidad de los datos en base a las reglas de negocio. Estas van de simples comprobaciones de reglas (check constraints) a comprobaciones de llaves foráneas (foreing key checks). Una vez almacenados los datos, proporciona un sistema de respaldos en linea que trabaja en conjunto con un mecanismo PITR (Point-In-Time Recovery) donde se puede ver una tabla en el estado en el que se encontraba en cierta fecha, proporcionando así un método flexible para la rápida recuperación de datos.

Otra ventaja importante de PostgreSQL es la capacidad de su arquitectura para soportar módulos agregados (add-on), por ejemplo PostGIS, un módulo que provee funcionalidad para el manejo de información geoespacial. Además de su capacidad de interpretar diferentes lenguajes de procedimiento almacenado (stored procedures languages), lo que permite a los desarrolladores escribir código usando el lenguaje de programación que se adapta a sus necesidades y requerimientos, por ejemplo, un trigger que necesita ejecutar procesos complejos de texto puede ser escrito en Perl, aprovechando así, su avanzado manejo de expresiones regulares.

MySQL.

MySQL tiene la reputación de ser la base de datos libre, más rápida y fácil de usar. Fue diseñada para proveer un veloz Método de Acceso Secuencial Indexado, conocido como ISAM (Indexed Sequential Access Method). Este tipo de carga de datos, caracterizado por la ejecución de consultas cortas, combinado con técnicas como el cacheo de consultas, ayudan a mejorar el desempeño de MySQL. Este enfoque en desempeño, ha dado como resultado características como el MySQL Cluster, que le permite a la base de datos escalar en recursos más allá de un solo servidor físico.

Al igual que PostgreSQL permite extensiones o módulos externos para añadir funcionalidad, específicamente motores de almacenamiento. MyISAM es el motor por defecto, provee buen desempeño en ambientes de lectura de datos. Así mismo cuenta con el motor de almacenamiento InnoDB, que provee la robustez requerida en transacciones en ambientes de intensa escritura.

Adicionalmente existen motores de almacenamiento de terceros como Brighthouse y DB2 que agregan más funcionalidades a MySQL. Esta flexibilidad permite a los administradores seleccionar el motor de almacenamiento de acuerdo a las necesidades individuales en cada tabla. Por ejemplo en una tabla de países donde se realizan más consultas se puede utilizar MyISAM y en una tabla de ventas que requiere intensa escritura y aseguramiento de datos se puede utilizar InnoDB.

MyISAM, como ya vimos es excelente para consultas simples. Sin embargo, es más vulnerable a corrupción de datos que otros motores, y después de una fatalidad puede tomar mucho tiempo reparar las tablas, proceso que se debe realizar con la base de datos “apagada”, lo que en un ambiente productivo en línea puede resultar fatal. Lo que es más, no soporta llaves foráneas ni transacciones, que le darían la Atomicidad, Consistencia, Aislamiento y Durabilidad, también conocidas como propiedades ACID (Atomicity, Consistency, Isolation and Durability), que todo RDBMS procura tener. Adicionalmente, debido a que MyISAM utiliza archivos de texto para el almacenado de datos, realiza un bloqueo (locking) de las las tablas al escribir, por lo que tiene problemas con las consultas y actualizaciones (updates) concurrentes.

La integración de InnoDB como motor de almacenamiento, trajo mejoras a MySQL proveyendo un mejor mecanismo de recuperación de datos y habilitando transacciones compatibles con las propiedades ACID. Sin embargo, este motor no es tán rápido como MyISAM ni tan poderoso como PostgreSQL.

Conclusión.

Selecciona el RDBMS de acuerdo a los requerimiento del proyecto, si tu operación requiere velocidad, MySQL con MyISAM es lo mejor, solo no olvides los riegos que usarlo conlleva. Si tus operaciones son críticas y no puedes darte el lujo de arriesgar ni un byte, requieres precisión, y la robustez de un RDBMS transaccional, no lo pienses y usa PostgreSQL. En conclusión, como en todo, utiliza aquello que se adapta a tus necesidades y no aquello que está de moda.

Basilio Briceño

DevOps evangelist, SoftwareLibre activist, sometimes speaker & eclectic metalhead.

4 comments

  1. Granados   •  

    Excelente artículo Basilio, no sabia esa desventaja que tenia MyISAM con respecto a InnoDB, se aprende algo bueno todos los dias :D

  2. rodrigo   •  

    Buen analisis

  3. MIGUEL   •  

    Hola muy buenos articulos….
    tengo algunas preguntas que no se si me puedas ayudar

    Cuando podemos considerar “base de datos robusta”?
    Cuando deberiamos considerar armar un cluster de BD?
    Realmente es significante el tema de velocidad de respuesta?… entiendo que para procesar grandes volumenes de información… quiza si sea relevante… pero en la mayoria de los casos no es así… si tengo un proyecto de gran escala donde voy a manejar volumenes grandes de información… generalmente esos proyectos cuentan con SQL SERVER u ORACLE…

    En mi caso concreto, cuento con querys muy simples…pero mucha concurrencia….

    gracias y de nuevo… q buenos posts!

  4. David   •  

    Excelente artículo, gracias por la investigación y la información.

Leave a Reply

Your email address will not be published. Required fields are marked *

You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>