Otro de mis pequeños proyectos

Trabajando con eficiencia

Muchas veces considero que es una obsesión, pero de lo que estoy seguro es que muchas más veces gano tiempo pensando un poco y haciendo las cosas mejor y más rápidas.

El caso que voy a presentar ahora es lo que yo considero «la forma más rápida de descargarnos un dump de una base de datos». Añadamos como condición que tenemos que usar un protocolo cifrado, en este caso, SSL. Para cualquier de los dos ejemplos que voy a presentar, contamos que tenemos autentificación en el servidor remoto (ahora que sabemos cómo hacerlo).

Empecemos por el final. Cómo se nos ocurrirí­a hacerlo directamente. Básicamente los pasos serí­an estos:

# Nos conectamos al servidor
ssh user@server.com
# Realizamos el dump de la base de datos
mysqldump -u mysqluser -p mysqldb > dump.sql
# Comprimimos los datos para reducir el tamaño de los datos a trasferir
gzip dump.sql
# Volvemos a nuestro ordenador
exit
# Copiamos el fichero a nuestro ordenador
scp user@server.com:dump.sql.gz .

He hecho una prueba con una base de datos pequeña. Si únicamente contabilizamos el tiempo en realizar cada uno de estos comandos y los sumamos (es decir, no tenemos en cuenta ni el ssh inicial ni los tiempos entre comandos, incluí­do si nos vamos a tomar un café mientras hace el volcado o lo comprime), salen los siguientes tiempos:

  • mysqldump: 2.2 segundos
  • gzip: 0.5 segundos
  • scp: 12.2 segundos
  • total método 1: 14.9 segundos

Veamos ahora otra forma. ¿Y cómo es? Pues bien sencilla… ¿y si te digo que puedes agrupar todos los comandos en únicamente uno?

¿Cómo? Pues aprovechando que se pueden ejecutar comandos de forma remota con el comando ssh y que lo que devuelva ese comando, se retorna mediante la consola estándar (stdin). Además, teniendo en cuenta que también podemos llamar a gzip en lí­nea mediante una tuberí­a (denominada en inglés pipe, representada por la barra vertical: |). Si unimos todo esto, nuestro comando queda (ejecutado directamente desde nuestra máquina):

ssh user@server.com "mysqldump -u mysqluser -p mysqldb | gzip" > dump.sql.gz

Si medimos el tiempo que le cuesta a este comando obtenemos para el método 2: 12.0 segundos

La diferencia puede parecer muy pequeña vista así­, pero estamos hablando que es casi un 20% más rápido. Si este proceso (con el primer método) hubiese durado 4 horas (sí­, os aseguro que se puede dar el caso), en algo más de 3 horas lo habrí­ais terminado. Estos datos son muy variables, hay que tener en cuenta muchas cosas, pero que hagáis las pruebas que hagáis, en igualdad de condiciones, este nuevo método es mucho más rápido.

Y os aseguro que si hacéis la prueba con un proceso largo, en el que tendrí­ais que esperar que terminase cada paso para iniciar el siguiente comando, ganaréis mucho tiempo sobre todo entre comando y comando.

La próxima vez que os toque algo como esto, usad este método y tomaros el café (o la comida) que os podréis tomar gracias a no tener que esperar, a mi salud.

Pensad un poco, esto es sólo un ejemplo, ¡hay muchas más opciones!

2 comentarios

  1. javisantana

    según el primer benchmark parece que el problema está realmente en la transmisión. Se me ocurre no enviarlo todo, usar rsync tal que así­:

    ssh user@server.com «mysqldump -u mysqluser -p mysqldb > db_mirror» && rsync -avr -e ssh root@server:/root/db_mirror .

    de esta forma rsync hace el diff y enví­a de una forma segura (y además comprimido)

    o quizás también cifrar (con la misma clave de ssh) en destino y enviar con http u otro protocolo sin encapsular en ssh que en teorí­a deberí­a ser más rápido.

    Habrí­a que ver lo que consume hacer el diff de la BBDD…

  2. tatai

    javisantana, no hay problema en los ejemplos que presento, son opciones para hacer las cosas más rápido. Si bien la red puede ser un factor que cambie los tiempos, ambos métodos que he propuesto son válidos, pero claro, uno es más rápido que el otro, que es el objetivo.

    Con rsync no evitas que la primera vez haya que enviar todo, la segunda vez sí­ que serí­a más rápido aunque es lo que tú comentas, a ver cuánto consume el diff y que son dos pasos en vez de uno, dificil decisión 🙂

    La opción de cifrar en destino y transferir mediante un protoco más ligero, es buena también, aunque personalmente me gusta más la de trasferir los datos encapsulados por ssl ví­a ssh o scp.

    Un saludo!

Deja una respuesta

Tu dirección de correo electrónico no será publicada. Los campos obligatorios están marcados con *