Re: [OFF-TOPIC] UBer cambia Postgres por MySQL

On Thu, 4 Aug 2016 18:59:18 +0000
Edwin Quijada <listas_quijada(at)hotmail(dot)com> wrote:

> He leido este articulo sobre como Uber cambio a Mysql desde
> postgres , Alvaro y Jaime me gustaria oir su opinion acerca de lso
> puntos que ellos enumeran aqui para el cambio de
> PG.<https://eng.uber.com/mysql-migration/>
>
>
> <https://eng.uber.com/mysql-migration/>
>
>
> <https://eng.uber.com/mysql-migration/>
>
> https://eng.uber.com/mysql-migration/
>
> [http://eng.uber.com/wp-content/uploads/2016/07/MySQL_Index_Property_Header_facebook.png]<https://eng.uber.com/mysql-migration/
> >
>
> Why Uber Engineering Switched from Postgres to
> MySQL<https://eng.uber.com/mysql-migration/> eng.uber.com
> Uber Engineering explains the technical reasoning behind its switch
> in database technologies, from Postgres to MySQL.

El principal problema creo yo, al margen del bug de la versión no actualizada de postgres que usaban, es como han montado la arquitectura de su aplicación: Usan una tabla para almacenar datos globales.

Este es un error en cualquier desarrollo que implique procesamiento paralelo/concurrente/distribuido de cualquier tipo, ya sea multithread, multiprocess, multifiber, rpc, webservice, etc. Ya a finales de los 80 cuando empezaron a ser populares las aplicaciones multithread, cuando dos o mas hilos intentaban modificar una variable global, el acceso a esta debia ser serializado mediante locks, sems, monitors y todos esos algoritmos desarrollados en los 60 y 70. Al final perderemos mas tiempo gestionando los accesos a los datos y esperando a que esten disponibles, que usando dichos datos. Si sacamos dichas variables globales de nuestra aplicación y las metemos en una base de datos, el "marrón", el "problema", se lo pasamos al SGBD, pero éste sigue existiendo. La solución que muchos desarrolladores desde los 90 (y antes también) adoptaron fue repensar como desarrollar sus aplicaciones para:

a) minimizar el número de variables globales o eliminarlas por completo,
b) hacerlas de sólo lectura o constantes,
c) desarrollar nuevos algoritmos/arquitecturas que no requieran el uso de variables globales,
d) hacer programación parecida a funcional usando lenguajes que no lo son (paso del estado de los datos como parametros a las funciones)
e) hacer sus funciones reentrantes.

Si cambias Postgresql por Mysql, por que este ultimo permite hacer una serializacion a tus datos globales más rápida, creo que este sería un buen resumen, no solucionas el problema, simplemente pones el nivel de tps o carga un poco mas alto para que no aparezca, pero tarde o temprano les aparecerá de nuevo.

La literatura sobre esto es amplia y extensa. En mi experiencia muchos programadores de C y similares cuando desarrollan aplicaciones paralelas/concurrentes/distribuidas tienen esto en cuenta, los que solo saben php, javscript, java, c# y demás lenguajes new-age no, estan acostumbrados a "pasar el marrón". Cuando doy charlas sobre esto, siempre pongo una seccion sobre el rfc 1925.

Saludos

--- ---
Eduardo Morras <emorrasg(at)yahoo(dot)es>

-
Enviado a la lista de correo pgsql-es-ayuda (pgsql-es-ayuda(at)postgresql(dot)org)
Para cambiar tu suscripción:
http://www.postgresql.org/mailpref/pgsql-es-ayuda