PostgreSQL vs MySQL: PostgreSQL como alternativa.

PostgreSQL: una
alternativa a MySQL
Arturo Espinosa
Una introducción comparativa aUna introducción comparativa a
PostgreSQL para quienes conocíanPostgreSQL para quienes conocían
MySQL sólo porque "allí estaba".MySQL sólo porque "allí estaba".

PostgreSQL VS MySQL,
Pelea pactada a 8 rounds.
Guerras de proyectos hay muchas:
● Emacs VS VI
● Firefox VS Chrome
● Linux VS FreeBSD
● KDE VS GNOME
● Apache VS el mundo
etc.

Emacs VS VI
¿Qué nos enseña Emacs VS VI?
● VI: rápido pero monolítico.
Emacs: extensible pero lento.
(EMACS: Eight Megabytes And Constantly
Swapping)
●Emacs gana contra VI porque como
usuarios queremos crecer y que nuestras
herramientas crezcan con nosotros.

PostgreSQL VS MySQL
(9.4) (5.7)
Si no hay competencia, hay incompetencia.
Verifiquen que usen las últimas versiones.Verifiquen que usen las últimas versiones.
●En esta guerra, todos hemos salido
favorecidos.
●Tanto PostgreSQL como MySQL han
mejorado mucho en los últimos años:
●PostgreSQL en velocidad y replicación.
●MySQL en estandarización y estabilidad.

PostgreSQL VS MySQL
Round 1: Licenciamiento
FIGHT!FIGHT!
●PostgreSQL: licencia MIT (software libre
y se pueden distribuir versiones
modificadas sin requerir el código).
●MySQL: GPL, o una licencia comercial.
Esto incluyendo la biblioteca cliente
(libmysqlclient): si quieres vender o
distribuir un sistema que se conecte a
MySQL con el cliente oficial, debes pagar
a ORACLE o liberar tu código como GPL
o compatible.

PostgreSQL VS MySQL
Round 2: Desarrollo
Postgres wins.Postgres wins.
●PostgreSQL es un PROYECTO de
software libre: ecosistema de hackers
tanto independientes como empresas.
●MySQL es un PRODUCTO open-source
auspiciado por ORACLE. MySQL e
InnoDB y otros nombres son marcas
registradas (por eso MariaDB y XtraDB,
cuya existencia se debe a la hermeticidad
de ORACLE para aceptar parches).

PostgreSQL VS MySQL
Round 3: Almacenamiento
Pg: monolítico. MySQL: modular.
No usen MyISAM en MySQL, cuidado!No usen MyISAM en MySQL, cuidado!
●PostgreSQL: sin opciones de módulos, pero
mayor integración entre SQL y el almacén.
●No hay una opción dentro del DBM para
limitar el almacenamiento (usar quotas).
●MySQL: MyISAM, InnoDB y Cluster NDB.
●MyISAM es el más usado, pero no es ACID
ni MVCC. Veloz, pero limitado y riesgoso.
●InnoDB es la opción para MySQL, pero no
todos los proveedores lo instalan.

Problemas de almacenaje
con MySQL
La modularidad tiene sus desventajas
●InnoDB no soporta el lanzamiento de
triggers durante acciones en cascada con
llaves foráneas:
Los triggers se procesan en la capa SQL
mientras las llaves foráneas en la capa de
almacenaje (InnoDB), y estas capas no se
hablan para este caso de cascada con FK.
Un diseño por capas puede no ser la
mejor opción, o requiere de una
implementación cuidadosa.

Problemas de almacenaje
con MySQL: MyISAM
Húyanle a MyISAM como al diablo mismo.
Sin InnoDB, están fritos con MySQLSin InnoDB, están fritos con MySQL
●No es transaccional: operaciones complejas
no pueden ser atomizadas ni hay rollback.
●No es estable: si se truena la BD, el
almacenaje se corrompe y hay que
recuperarlo y verificar coherencia de datos.
●No es consistente: no hay garantía de que
bajo concurrencia, se entreguen datos
coherentes.
●No soporta llaves foráneas y sólo se puede
bloquear a nivel de tabla, pésimo para
escritura altamente concurrente.

MySQL Cluster con NDB,
una cosa bonita: Round 4
Alta escalabilidad y disponibilidad.
PostgreSQL no tiene solución parecidaPostgreSQL no tiene solución parecida
●Replicación síncrona garantiza la
disponibilidad de datos, aún cuando se
pierdan nodos del cluster.
●Replicación asíncrona limita el daño
ocasionado por una falla total.
●Alta eficiencia al mantener índices y
opcionalmente datos en memoria. Sólo se
usa el disco para guardar logs secuenciales
y una segunda etapa sincroniza memoria
con disco.MySQLwins. Perfect!MySQLwins. Perfect!

PostgreSQL VS MySQL
Round 5: Replicación
Empate: ambas BD hacen un buen trabajo.
●PostgreSQL: v9.1 ya soporta replicación
síncrona nativa, para por ejemplo clusters
master-slave con esclavos para lectura.
●MySQL: usar el nuevo método (mysql >5.1)
de log binario diferencial por registro (RBR).
El método de replicación por sentencia
(SBR) daba resultados inconsistentes para
funciones no determinísticas (NOW,
RANDOM, etc) y ha sido abandonado.
●MySQL: se puede usar NDB adicionalmente,
pero hay que migrar.

PostgreSQL VS MySQL
Round 6: Tipos de datos
PostgreSQL se lleva este round de lejos.
●PostgreSQL: tipos estandar (ie boolean,
money, date/time), DOMAINS, enums
dinámicos, direcciones IP, arreglos de
cualquier tipo y XML y JSON nativos con
indexación. Además, tipos complejos y tipos
definidos por el usuario en C.
●MySQL: faltan muchos tipos: ver
documentación en línea, Cap. 11. Enums y
Sets tienen que ser declarados en cada
lugar donde se usan (no hay CREATE
TYPE). Sin arreglos ni JSON, etc.
PostgreSQLwins.
PostgreSQLwins.
FATALITY
FATALITY

PostgreSQL VS MySQL
Round 7: SQL Avanzado
MySQL PostgreSQL
Subquerys C C
JOIN C C
Índices Avanzados C C
Particiones C C
WITH (CTEs) D C
Analytic D C
Secuencias D C
Profiling C D
PostgreSQLwins.PostgreSQLwins.

PostgreSQL VS MySQL:
Round Final
Últimos embates:
●MySQL no soporta CONSTRAINTs diferidos.
●Los stored procedures de MySQL tienen
limitaciones y el lenguaje no es maduro.
PostgreSQL soporta múltiples lenguajes y
plpgsql, que irónicamente está basado en el
plsql de Óracle, por lo que la migración es
sencilla.
●MySQL no soporta funciones como valores
por default para columnas (excepto NOW).
●Los triggers de PostgreSQL son más
flexibles y poderosos, y siguen el
comportamiento estandar.

Round Final
Últimos embates:
●MySQL cuenta con una herramienta gráfica
integral para diseño y administración:
MySQL Workbench, que funciona muy bien.
PostgreSQL tiene algunas opciones, pero no
son tan completas (pgModeler, Open
System Architect). PgAdmin es SW oficial,
provee ejecución de querys y DDL.
●Ambas bases de datos cuentan con una
excelente comunidad de entusiastas y
soporte profesional de paga (Percona,
Enterprise DB y Oracle, por supuesto).

Conclusiones
Convergencia hacia un mismo destino.
●Los usuarios del software libre definen su
destino, y ambas BD son usadas desde
estudiantes hasta las empresas más
importantes del mundo. Ambas BD han
tenido que adaptarse a las necesidades en
desempeño y características del amplio
mercado.
●Hoy por hoy PostgreSQL permite explotar
más la capa de BD, tener diseños con mayor
protección y normalización y enviar querys
más complejos. El desarrollador tiene más
oportunidad de crecimiento con Postgres.

Conclusiones
Convergencia hacia un mismo destino.
●PostgreSQL es más formal y su ruta es
hacia la eficiencia, manteniendo y
mejorando funcionalidad ya establecida. La
teoría de BD es muy formal y vale la pena
pagar el costo de un buen comienzo.
PostgreSQL inicia como proyecto académico
y se mantiene firme como proyecto libre.
●MySQL comenzó por la eficiencia y la
aplicación pragmática. Al formalizar sus
conceptos viene arrastrando más bagaje
producto de decisiones tempranas. MySQL
AB fue adquirida por Oracle, y sus políticas
frenan un poco el avance de la comunidad.

Referencia
Muchas gracias, aquí algunas fuentes:
●http://www.slideshare.net/arturoea1
●WikiVS.com
●Documentación de MySQL 5.7:
●5.1.7, Server SQL Modes
●D.1, Restrictions on Stored Programs
●11, Data types
●14.5.6, InnoDB and FK constraints
●PostgreSQL:
●what I learnt: Data and Analytics
●http://solaimurugan.blogspot.mx/2010/09/analytic-fun
●Apéndice D, Unsupported Features

PostgreSQL vs MySQL: PostgreSQL como alternativa.

Recomendados

Más contenido relacionado

La actualidad más candente (20)

Similar a PostgreSQL vs MySQL: PostgreSQL como alternativa. (20)

Último (20)

PostgreSQL vs MySQL: PostgreSQL como alternativa.