MySQL vs Postgresql (fue Re: debian de 32 o 64??)

[Aldrin Martoq]

On Jun 15, 2010, at 10:23 AM, Ricardo Munoz wrote:
> El 14 de junio de 2010 18:09, Alvaro Herrera <alvherre en alvh.no-ip.org>escribió:
>> Excerpts from Javier Garay's message of lun jun 14 16:04:41 -0400 2010:
>>> MySQL es más rapido que Postgres
>> Esto no es cierto en general, sólo en casos específicos (que son de
>> juguete)
> correcto. el fuerte de MySQL efectivamente son sus tablas MyISAM "de
> juguete" que permiten al motor de BD no gastar tiempo en revisar si hay
> alguna transaccion pendiente por cada SELECT que se ejecuta.

Los niveles en que funciona bien myisam son tan pobres que da lo mismo que cosa uses. Si quieres pon SQLite o Microsoft Access  y funcionará igual de bien y en una gran cantidad de casos. También es muy probable que nunca tengas problemas. Ese no es el punto y me imagino que es lo que quería ejemplificar Álvaro: Windows también funciona en muchos casos, pero no es eso de lo que estamos hablando.

El punto es que usualmente SI requieres cosas como integridad referencial y/o que el sistema escale bien. Y hacer eso en postgresql no es mas difícil que hacerlo con mysql, entonces ¿por qué no partir con postgresql? De hecho, he encontrado que hacerlo con mysql es mucho mas difícil pues el sistema está pensado para usarse al estilo de MS Access. Por ejemplo, en la configuración inicial si ocurre un error se ignora silenciosamente... tal vez por eso la gente lo encuentra fácil de usar, pero para yo encuentro esto horrible.

Para mí, es un tema de estrategia y costos: cuesta LO MISMO partir con cualquiera de los dos (sin integridad referencial si quieres), la velocidad es la misma para ambos a esos niveles, pero si debes escalar o necesitas usar más características de bases de datos en mysql te saldrá mucho mas caro.


> lo anterior sumado a la funcionalidad nativa de replicacion (superior a las
> opciones de Postgres) hace que sea facil montar muchos nodos de solo lectura
> (para los SELECT) y algunos nodos para las escrituras (UPDATE, INSERT,
> DELETE) con tablas InnoDB,

En replicación yo no encontré que las opciones de postgresql sean inferiores, repito lo único que no era factible en postgresql era un cluster con ndbcluster. Lo único malo es que no está integrado en la base de datos, pues la mayoría son proyectos externos... es tan complejo como dejar mysql afinado para comportarse como una base de datos relacional.


Ahora, replicación es un medio que puede tener muchos fines, yo creo que lo mejor para la mayoría de los listeros es usar replicación para respaldos en línea (log shipping) mas que para balanceo de carga. Si tienen problemas de rendimiento, es mas barato que intentes primero acelerar la aplicación, por ejemplo usando memcache.


> la integridad referencial se maneja en la
> aplicacion.

Si estas en los niveles en que no puedes usar una base de datos, mejor que uses otra cosa derechamente y te olvidas de las ventajas de una base de datos real. Por ejemplo, en vez de tener una base de datos gigante puedes crear subsistemas en que cada uno tenga su propio base de datos y cada uno con servicios y niveles definidos (ej: sistema de usuarios, sistema de facturas, etc). Eso es lo que hacen los sitios grandes como twitter en todo caso.


> este esquema lo usan/usaron sitios con alto trafico como Flickr, Facebook,
> Twitter, etc.

En mi opinión,  esos sitios partieron con mysql y se quedaron "con el cachito". Ni modo pues, a entrar a picar cada vez que el sistema explotaba... y ellos tiene recursos para hacer este tipo de cosas. Para el resto de los normales les sugiero que usen algo mas barato de desarrollar y mantener tanto en el corto como en el largo plazo.


>> Si lo usas para un blog, un foro web, o un motor de búsqueda, no hay
>> problema.  Pero no te recomiendo que lo uses para una tienda online.
> y que tiene de especial una tienda online? en todo caso, nada impide que
> alguien use distintos motores de BD en una misma aplicacion, una para el
> "frontend" (MySQL) y otra para el "backend" (idealmente Postgres, aunque
> generalmente es Oracle, DB2, etc.)


Aquí comparto la misma visión pero a la inversa: ¿qué les hace pensar que mi foro o blog no son importantes? No conozco sistema, incluso el más insignificante, en que la data es lo más importante. Como anécdota, hace un buen tiempo se corrompió la base de datos de SVN (que estaba basado en berkley v/s CVS que eran archivos planos, algo fácil de corregir) y gasté un montón de tiempo tratando de restaurarla. Al final me dí por vencido y perdí la data no mas, por suerte tenía en mi estación la mayoría de los proyectos y los volví a subir a un repositorio nuevo. Por supuesto, perdimos toda la información de cambios, que es el motivo de tener un sistema de versiones. GIT en cambio está diseñado para evitar pérdida de datos (y otros más); para Torvalds la data es muy importante.

La mayoría clasifica los sistemas por importancia y que la base de datos que uses da lo mismo (incluso la gente postgresql, como ven), pero yo no conozco sistema en que la data sea lo más importante.


Aldrin Martoq
http://aldrin.martoq.cl/