Elegir entre MySQL vs PostgreSQL es una decisión la cual muchos deben hacer cuando a bases de datos relacionales de fuente abierta se refiere. Ambos servidores son soluciones comprobadas al paso del tiempo y que compiten fuertemente con la base de datos de software propietario. MySQL ha sido durante mucho tiempo la más rápida pero es la que cuenta con menos funciones de los dos sistemas de bases de datos, mientras que PostgreSQL se supone que es un sistema de base de datos más denso, la cual a menudo se describe como la versión de código abierto de Oracle.
MySQL ha sido popular entre diversos proyectos de software debido a su velocidad y facilidad de uso, mientras que PostgreSQL es utilizada mayormente por desarrolladores que provienen de un Oracle u otro SQL Server.
Estas hipótesis, sin embargo, son en su mayoría obsoletas e incorrectas. MySQL ha recorrido un largo camino en la adición de funcionalidades avanzadas, mientras que PostgreSQL ha mejorado enormemente su velocidad en los últimos lanzamientos.
Muchos, sin embargo, no son conscientes de la convergencia y todavía se aferran a los estereotipos basados en MySQL 4.1 y PostgreSQL 7.4.
Además, la comparación de velocidad es principalmente entre los motores de MyISAM y PostgreSQL. Si la comparación se realiza entre las últimas versiones de InnoDB y PostgreSQL, PostgreSQL es a menudo más rápido.
Los Sistemas de bases de datos pueden ser optimizados de acuerdo con el entorno en el que corren. Por lo tanto, es muy difícil dar una comparación precisa en el rendimiento, sin prestar atención a la configuración y el medio ambiente. PostgreSQL así como MySQL emplean diversas tecnologías para mejorar el rendimiento en el nivel básico:
MySQL comenzó su desarrollo con un enfoque en la velocidad, mientras que PostgreSQL comenzó a desarrollar con un enfoque sobre las características y normas. Por lo tanto, MySQL es a menudo considerado como el más rápido de los dos. La configuración por defecto de PostgreSQL fue diseñada para ejecutarse en sistemas con poca memoria.
El motor MyISAM de MySQL funciona más rápido que PostgreSQL sobre los queries simples y cuando la concurrencia es baja o sigue ciertos patrones (por ejemplo, los inserts se realizan en tablas optimizadas y sin bloqueos, count (*) es muy rápido).
El costo de la velocidad del motor MyISAM viene de no brindar soporte a las transacciones, < strong > llaves foráneas, </strong > y no ofrece durabilidad garantizada en los datos.
PostgreSQL puede comprimir y descomprimir sus datos sobre la marcha con un rápido sistema de compresión para encajar más datos en un espacio de disco asignado. La ventaja de los < strong > datos comprimidos </strong >, además de ahorrar espacio en disco, es que la lectura de datos tarda menos IO, por lo que lee datos con mayor rapidez.
Hasta la versión 5.1 de MySQL sus motores de almacenamiento de alto rendimiento no soportan compresión sobre la marcha.
La versión de MySQL 6.0 tendrá soporte de compresión sobre la marcha con su nuevo motor de almacenamiento Falcón:
Los datos almacenados en las tablas de Falcón están comprimidos en el disco, pero se almacena en un formato sin comprimir en la memoria. La compresión se produce automáticamente cuando los datos se guardan al disco.
— MySQL AB , 12.6.6.6. – Compresión de datos
Con InnoDB instalado a traví©s del plug-in, MySQL 5.1 soporta compresión sobre la marcha de tablas InnoDB:
A partir de esta versión del plug-in de InnoDB, se puede utilizar los atributos ROW_FORMAT=COMPRESSED o KEY_BLOCK_SIZE en los comandos CREATE TABLE y ALTER TABLE para solicitar a InnoDB comprimir cada página a 1K, 2K, 4K, 8K, o de 16K bytes.
— InnoBASE OY , 3.2. Especificación de compresión
El motor MyISAM de MySQL soporta compresión del índice el cual utiliza por defecto en cierta medida. Una mejor compresión puede ser adquirida mediante el uso de la opción PACK_KEYS. Otros motores de almacenamiento estables en MySQL al momento no tienen esta característica, por lo que sus índices utilizan más espacio.
Las tablas en el motor MyISAM pueden ser empacados con myisampack lo que las convierte en solo lectura, pero ahorra mucho espacio. MySQL también soporta compresión a nivel de protocolo de red la cual es una opción que puede ser activada por el cliente si el servidor lo permite. Esto comprime todo desde y hacia el servidor.
MySQL soporta compresión sobre la marcha desde la versión 5.0 con el motor de almacenamiento ARCHIVE. Archive es un motor de almacenamiento de escribir una vez, leer muchas, diseñado para los datos históricos. Comprime los datos hasta un 90%. No soporta índices. Sin embargo, en la versión 5.1 puede ser utilizado con particionado.
La ventaja en velocidad de PostgreSQL sobre MySQL se puede ver drásticamente en un ambiente de grandes procesadores multi-core.
[1] Incluso los desarrolladores de MySQL han admitido que el uso actual de tecnología de procesadores con múltiples núcleos de MySQL no está a la par.
[2] Los recientes parches de Google y Percona son una promesa para cerrar la brecha.
PostgreSQL proporciona características que pueden conducir a un rendimiento más rápido en algunos queries:
MySQL también soporta la indexación parcial utilizando el motor InnoDB, pero no con el motor MyISAM. Incluso cuando se utiliza el motor InnoDB, sin embargo, las tablas del sistema utiliza el motor MyISAM.
Si bien es cierto que con una instalación por defecto de MySQL, este por lo regular le gana a PostgreSQL en muchos parámetros de rendimiento, benchmarks pasados mostrando un mayor rendimiento de MySQL ante PostgreSQL tienden a sufrir una serie de problemas:
PostgreSQL escala mucho mejor, tanto en tí©rminos de la utilización de un hardware de alto rendimiento, y al hacer frente a la concurrencia. MySQL, por otra parte, se centra en tecnologías comunes de bajo rendimiento y el uso de hardware básico.
PostgreSQL soporta una completa API asincrónica para el uso de las aplicaciones cliente. Según se informa, aumenta el rendimiento hasta en un 40% en algunos casos. MySQL carece de soporte Async, aunque algunos controladores se han creado para tratar de superar esta deficiencia (perl ruby).
PostgreSQL COUNT(*) es muy lento porque en lugar de contar las filas utilizando un índice de exploración, debe de recorrer toda la tabla secuencialmente. PostgreSQL implementa COUNT(*) de esta manera debido a la forma en la cual el MVCC (sistema de concurrencia del PostgreSQL) almacena la visibilidad de las transacciones en la fila de datos y no en el índice.
El motor MyISAM en MySQL utiliza un índice para COUNT(*) y también un cache de la cuenta y por lo tanto, es mucho más rápido:
La razón MySQL tiene cuenta rápidamente, es porque están en cachí©. Esto funciona porque en MySQL se utilizan INSERTs con número de serie, pero las DBs de grado superior son transaccionales, y PostgreSQL utiliza MVCC, por lo que el almacenamiento en cachí© de la cuenta de filas produce resultados inexactos.
— Bad CTK , PostgreSQL Count() lento Solución
El motor InnoDB en MySQL funciona de modo similar a PostgreSQL y comparable con la velocidad [3].
íACID (Atomicidad, Coherencia, Aislamiento y Durabilidad), este modelo se utiliza para evaluar la integridad de los datos a traví©s de los sistemas de gestión de bases de datos. La mayoría de sistemas de bases de datos cumplen con el estándar ACID mediante el uso de las transacciones.
PostgreSQL es plenamente compatible con ACID, mientras que el motor de almacenamiento InnoDB de MySQL proporciona cumplimento de ACID a nivel del motor:
MySQL Server (version 3.23-max y todas las versiones 4.0 y superiores) soportan las transacciones con los motores de almacenamiento transaccionales InnoDB y BDB.
InnoDB proporciona pleno cumplimiento de ACID.
MySQL Cluster también es un motor de almacenamiento de transacciones seguro.
– MySQL AB, MySQL 5.0 Manuel de Referencia :: 1.8.5.2 Transacciones y operaciones atómicas
Para utilizar el motor compatible con ACID en MySQL por defecto, basta con establecer default-storage-engine=innodb en su archivo de configuración.
Innobase Oy, la empresa que desarrolló InnoDB, fue adquirida por Oracle en octubre de 2005. Oracle y MySQL AB firmaron un contrato para extender la concesión de licencias para el motor InnoDB en 2006, pero algunos temen que esa licencia cuando finaliza el período la competencia comercial entre Oracle (propietario del motor de almacenamiento InnoDB) y Sun (que compró MySQL AB en febrero de 2008) puede conducir a la futura concesión de licencias y costos para los usuarios de MySQL.
MySQL y PostgreSQL tienen un impresionante conjunto de características que aumentan la integridad de los datos, funcionalidad y rendimiento. Las características incluidas en una base de datos pueden ayudar a mejorar el rendimiento, la facilidad de uso, la funcionalidad, o la estabilidad.
Un “gotcha” es una característica o función que funciona como se ha publicado – pero no como se esperaba.
MySQL tiene más “gotchas”[4] que PostgreSQL [5].
MySQL soporta declaraciones INSERT IGNORE y REPLACE las cuales insertan si una fila existe de lo contrario no hace nada o reemplaza la fila actual, respectivamente. PostgreSQL no soporta ninguna de estas declaraciones y sugiere el uso de procedimientos almacenados para evitar la falta de estas declaraciones. Sin embargo, existen grandes deficiencias:
Sólo puede insertar un valor único a la vez. Esta es una limitación importante de rendimiento, y también sufre problemas de concurrencia. INSERT IGNORE y REPLACE manejan varios valores e inserta mucho mejor.
Tanto MySQL y PostgreSQL soporta Not-Null, Unique, Llave primaria y llaves foráneas. Sin embargo MySQL no soporta comprobación de limitación (Check constraint) mientras que PostgreSQL lo ha soportado durante mucho tiempo.
Tablas InnoDB soportan la comprobación de llaves foráneas … Para otros motores de almacenamiento, MySQL Server analiza y hace caso omiso de FOREIGN KEY y REFERENCES en la sintaxis de CREATE TABLE.
Tanto MySQL y PostgreSQL soporta procedimientos almacenados. El primer lenguaje de consulta para PostgreSQL, PL/PgSQL, es similar a la de Oracle PL/SQL. PostgreSQL también soporta procedimientos almacenados en muchos otros lenguajes, entre ellos Python, Perl, TCL, Java y C – en particular la norma ISO SQL:2003 PSM.
MySQL sigue el SQL:2003 para la sintaxis de rutinas almacenadas, que también es utilizado por IBM DB2.
Tanto MySQL y PostgreSQL soporta triggers. Un disparador PostgreSQL puede ejecutar cualquier función definida por el usuario desde cualquiera de sus lenguajes de procedimiento, no sólo PL/pgsql.
Los triggers de MySQL son activados solamente por comandos SQL. Estos no son activados por cambios en las tablas realizados por APIs que no transmiten las declaraciones de SQL al servidor MySQL, en particular, no son activadas por las actualizaciones hechas utilizando el NDB API.
— MySQL AB , MySQL 5.1 Reference Manual :: 19 Triggers
PostgreSQL también soporta las “reglas”, que permiten operar en el árbol de sintaxis de la consulta, y puede hacer algunas operaciones más simplificadas que tradicionalmente son realizadas por disparadores.
La sintaxis para la definición de los disparadores en PostgreSQL no es tan sencilla como en MySQL. En PostgreSQL es necesario una definición de una función con la devolución del tipo de datos específico.
La replicación es la capacidad de un sistema de gestión de base de datos de duplicar sus datos almacenados a efectos de brindar copias de seguridad y una manera de prevenir la inactividad de la base de datos de inactividad. Ambos PostgreSQL y MySQL soporta replicación:
PostgreSQL es modular por su diseño, y la replicación no está en el núcleo. Hay varios paquetes que permiten la replicación en PostgreSQL:
Es un error común pensar que estos “paquetes de terceros” de alguna manera son menos bien integrados. Slony, por ejemplo, fue diseñado y construido por Jan Weick, un miembro del equipo del núcleo de PostgreSQL, y tiene otros miembros de la comunidad PostgreSQL que participan en su diseño continuo y mantenimiento.
Sin embargo, Slony es considerablemente más lento y utiliza más recursos que MySQL y su replicación incorporada, ya que utiliza SQL y triggers en lugar de un registro binario de envío para replicar los datos a traví©s de los servidores.
Lo cual lo puede hacer menos adecuado para grandes instalaciones de clusters con necesidades de alto rendimiento. Recientemente, el equipo del núcleo de PostgreSQL anunció que la replicación básica se ha previsto como parte de la liberación 8.4.
MySQL brinda soporte para replicación [6]. A partir de la versión 5.1, MySQL soporta dos formas de replicación; replicación basada en declaración (SBR) y replicación basada en la fila (RBR). SBR recolecta las consultas SQL que realizan cambios a la base de datos en un registro binario a los cuales los servidores esclavos se conectan para copiar sus cambios.
A diferencia RBR registra los cambios incrementales a las filas en el registro binario que luego son aplicados a los esclavos. Algunos motores de almacenamiento, tales como NDB y Falcón sólo soportan la replicación usando este nuevo formato basado en la fila [7].
PostgreSQL no tiene un tipo de dato entero sin signo, pero tiene mucho más soporte de tipos de datos en varios aspectos: el cumplimiento de las normas, la lógica fundamental del tipo de datos BOOLEAN, mecanismos de tipo de datos definidos por el usuario, tipo nativos y contribuidos.
Arrays de cualquier tipo básico nativo o definidos, tipo enum, o tipo compuestos se pueden crear. Los arrays de dominios no son soportados todavía [8].
Tanto MySQL y PostgreSQL soporta subconsultas, pero en MySQL algunas formas pueden ser un gran impacto en el rendimiento. Esto será corregido en la versión 6.0 [9]
Mí©todos avanzados de indexación permiten a los sistemas de bases de datos optimizar las consultas para lograr un mayor rendimiento.
Un índice parcial es un índice construido sobre un subconjunto de una tabla, el subconjunto se define por una expresión condicional (llamado el predicado del índice parcial). El índice contiene entradas de la tabla sólo aquellos registros que satisfacen el predicado. Los índices parciales son una función especializada, pero hay varias situaciones en las que son útiles.
Una de las principales razones para la utilización de un índice parcial es evitar la indexación de los valores comunes. Ya que una consulta en busca de un valor común (uno que representa más de unos pocos por ciento de todas las filas de tabla) no utilizara el índice de todos modos, no hay ningún motivo para mantener esas filas en el índice en absoluto.
Esto reduce el tamaño del índice, lo que acelerará las consultas que sí utilizan el índice. Así mismo, acelerará muchas de las operaciones de actualización de la tabla porque el índice no necesita ser actualizado en todos los casos.
— PostgreSQL , PostgreSQL 8.2.6 Documentación: Capítulo 11. íindices
MySQL soporta prefijo de índices: El prefijo de los índices cubre los primeros N caracteres de una cadena de la columna, con lo que el índice se vuelve mucho menor en tamaño que una que abarca toda la anchura de la columna, y aún así proporcionar un buen desempeño.
Con PostgreSQL, el prefijo de los índices son un caso particular de los índices de Expresión (ví©ase más adelante).
PostgreSQL soporta la capacidad de combinar varios índices en el tiempo de consulta utilizando los índices de mapa de bits.
PostgreSQL le permite crear índices basados en las expresiones (que pueden incluir llamadas a funciones inmutables). Esto es muy útil cuando usted tiene una tabla con datos relativamente estables (no una gran cantidad de inserciones / actualizaciones) y a menudo se ejecuta una consulta que implica una costosa operación.
PostgreSQL soporta la capacidad de crear índices sin bloqueo de la tabla para escritura.
MySQL soporta varios tipos de particionamiento horizontal.
PostgreSQL sólo es compatible con particionado RANGE y LIST. Particionamiento HASH es soportado a traví©s de funciones inmutable. Particionado compuesto también es soportado.
Motores de almacenamiento de datos tienen en cuenta el medio que se está utilizando (para la mayoría de los propósitos, las bases de datos se almacenan en los discos para proporcionar la persistencia de datos) para maximizar el rendimiento de lectura/escritura.
PostgreSQL soporta un motor, por defecto su sistema de almacenamiento Postgres (Postgres Storage System). Hay una serie de formas de aumentar el rendimiento de PostgreSQL.
Para los datos no críticos, puede poner su directorio de almacenamiento en un disco RAM LINK. [15] Esto, por supuesto, plantea la pregunta, de por qué usted quiere ponerlo en una base de datos de todos modos. Hay DSMSes (Sistemas de Gestión de flujo de datos – Data Stream Management Systems) diseñados específicamente para manejar los datos transitorios en una forma muy eficiente.
MySQL 5.1 soporta nativamente 9 motores de almacenamiento [16]:
Sin embargo, los motores federated y blackhole no son realmente motores de “almacenamiento”, (por ejemplo, “blackhole” no almacena nada).
InnoDB es desarrollado por la empresa externa InnoBase, que ha sido adquirida por Oracle. Conserva su lugar en las distribuciones estándar de MySQL como el principal motor transaccional. MySQL tiene previsto introducir nuevos motores de nombre María y Falcon en una próxima versión 6.x. [17] [18]
Entre las nuevas características figuran la recuperación. Se espera reemplazar y completar los motores MyISAM y InnoDB, respectivamente.
There are several externally-developed storage engines, some of the most popular are:
Hay varios motores de almacenamiento desarrollados externamente, algunos de los más populares son:
MySQL tiene motores de almacenamiento a la medida y de la comunidad en desarrollo:
En algunas distribuciones, el motor de almacenamiento por defecto es MyISAM, que no es seguro para las transacciones. Ajustar los valores para configurar el motor transaccional como InnoDB, es sin embargo, trivial.
PostgreSQL viene con un estilo de licencia BSD, que se inscribe en la definición de Software Libre y Open Source, y se ajusta tanto a la Debian Free Software Guidelines y al estándar Copyfree.
El código fuente de MySQL está disponible bajo los tí©rminos de la Licencia Pública General de GNU, que también se inscribe en las definiciones de Software Libre y Open Source y se ajusta a la Debian Free Software Guidelines (pero no a la Copyfree Standard).
también está disponible bajo un acuerdo de licencia de propietaria, que es normalmente destinado a ser utilizados por aquellos que desean incorporar código de MySQL sin tener que liberar el código fuente para toda la aplicación.
En tí©rminos prácticos, esto significa que MySQL se puede distribuir con o sin código fuente, como PostgreSQL, pero para no distribuir el código fuente en el caso de MySQL se requiere el pago de MySQL AB para una licencia comercial de MySQL.
Incluso la biblioteca cliente de MySQL es GPL (no LGPL), lo que significa que el uso (y, por tanto, enlace a) la biblioteca cliente de MySQL el programa en sí debe ser GPL o debe tener una licencia comercial de MySQL AB.
PostgreSQL no es controlada por una sola empresa, sino que se basa en una comunidad global de desarrolladores y empresas para desarrollarlo.
MySQL es propiedad y está patrocinado por una sola empresa con fines de lucro, la empresa sueca MySQL AB, que posee los derechos de autor a la mayoría del código.
El 16 de enero de 2008 MySQL AB anunció un acuerdo para ser adquirida por Sun Microsystems, por aproximadamente US $1 mil millones. [La adquisición (se espera que) cierre en el tercer o cuarto trimestre del año fiscal de Sun que terminó el 30 de junio de 2008.]
MySQL es PRODUCTO open-source.
Postgres es un proyecto de código abierto.
— Greg Sabino Mullane , Postgres no esta a la venta
La comunidad de MySQL es apoyada en parte por el Community Relations Team de la empresa. MySQL AB ha patrocinado una Conferencia y Expo anual de usuarios desde el año 2003.
El hecho de que el modelo de negocios de MySQL AB se basa en el suministro de la instalación, configuración, migración, y la concesión de licencias especiales de soporte a la DBMS MySQL probablemente contribuye a la falta de enlaces a terceros y recursos de la comunidad en la página de soporte oficial.
Algunos creen que esto crea una relación política entre la empresa y la comunidad de usuarios del software de fuente abierta, aunque la evidencia parece sugerir que la relación es casi inexistente, más que hostil.
Con una mayor proporción de los desarrolladores a los usuarios, la comunidad PostgreSQL tiende a compensar un menor número de usuarios con una mayor densidad de los conocimientos en el soporte a la comunidad.
La falta de apoyo institucional de una empresa como MySQL AB (ahora una subsidiaria de Sun), PostgreSQL se beneficia de una serie de empresas independientes en todo el mundo cuyos modelos de negocio giran alrededor del suministro de la instalación, configuración, migración y soporte a la base de datos de código abierto.
Cuando el estándar ANSI SQL fue escrito, su autor explicó que la pronunciación adecuada de SQL es “ess queue ell” (ell proceso de colas). Los nombres de ambos MySQL y PostgreSQL reflejan la pronunciación especificada por el autor del estándar SQL.
MySQL se pronuncia “my ess queue ell”.
Dado que MySQL es un proyecto de software propiedad de una empresa, MySQL AB tiene un control completo sobre el nombre del proyecto. Como resultado de esto, y el deseo de una identidad de marca, el nombre MySQL es probable que se mantenga intacto.
PostgreSQL se pronuncia “post gress queue ell”, formada por la combinación de Postgres (el nombre original del sistema de gestión de bases de datos a partir de la cual PostgreSQL es descendiente) con SQL. PostgreSQL es un verdadero portmanteau, en el sentido de que no sólo combina la ortografía y la pronunciación de dos palabras, sino también su significado: es el DBMS Postgres actualizado para el uso de SQL.
MySQL es muy popular entre los diversos paquetes de desarrollo de código abierto.
El motor MyISAM es a menudo el único motor de base de datos incluidos con los proveedores de hospedaje. Muchos desarrolladores web utilizan MySQL. Por lo tanto, MySQL se hizo muy popular en el desarrollo web, MySQL se llama a sí mismo “La base de datos de fuente abierta más popular del mundo “, una reclamación que pueden ser falsa dado el amplio despliegue de otros DBM es de fuente abierta tales como SQLite.
Por lo tanto, MySQL es estereotipada como “más fácil” para el uso que PostgreSQL, debido a su popularidad.
Via | MySQL: Como buscar y reemplazar texto en todas las tablas de una base de datos.
En el ámbito de la informática y la cadena de bloques, el conocimiento teórico a…
El emergente dominio de las criptomonedas ha cautivado la imaginación colectiva por su potencial para…
En el siempre evolucionante mundo de las criptomonedas, el capital de riesgo (VC) ha encontrado…
?? Resumen video : Gareth Soloway Bitcoin, prepárate para lo que viene Introducción El mercado…
En marzo de 2023, el mundo financiero se vio sacudido por el repentino colapso de…
A medida que Bitcoin continúa ganando popularidad y reconocimiento, aumenta la necesidad de escalabilidad y…