Personalmente creo haber tenido mucha suerte ya que por una cosa o por otra he participado en varios proyectos que manejan grandes bases de datos, actualmente con Resultados de fútbol y BeSoccer trabajo a diario con un gran volumen de datos que me ayuda a ir cogiendo experiencia a la hora de afrontar el planteamiento de nuevas funcionalidades o mejoras para el proyecto.

A mi manera de ver lo más importante es llegar a comprender que el problema al final se reduce en conocer perfectamente la tecnología utilizada y cuáles son sus ventajas y desventajas.

Un ejemplo claro está en el uso de MySQL, seguro que alguna vez has escuchado aquello de que MySQL no es recomendado para ser utilizado con grandes tablas. Pero realmente MySQL no es lento con grandes tablas sino que para conseguir un gran rendimiento con MySQL es necesario diseñar la base de datos siendo consciente de lo que puede y no puede hacer el motor de base de datos, tampoco digo con esto que MySQL es mejor que Oracle o PostgreSQL sino que lo que funciona y es eficaz en una no tiene porque serlo en las otras.

Claves en la escalabilidad de MySQL

Veamos algunas de las posibles claves a la hora de mejorar la escalabilidad de una base de datos MySQL:

1. Motor de base de datos
Acertar en la elección del motor de base de datos (MyISAM ó InnoDB)

Cómo comentamos hace unos días hay que ser conscientes de las ventajas y desventajas de cada uno de ellos.

2. Buffers
Cuando no hay memoria suficiente para el manejo de la base de datos notaremos un descenso gradual del rendimiento, la solución sería asegurarnos que tenemos memoria suficiente para el volumen de datos que estamos utilizando.

3. Índices
Es muy sencillo comprender la importancia de los índices, sin un índice, MySql tiene que iniciar una búsqueda por el primer registro y leer toda la tabla para encontrar los registros relevantes.

4. Consultas lentas
Si los anteriores puntos no nos dan la solución probablemente nos tengamos que centrar en la optimización de las consultas, una tarea complicada con la que podemos ahorrar mucho tiempo si conseguimos desde el principio detectar las consultas lentas (slow queries).

Si ninguno de estos puntos soluciona nuestro problema de escalabilidad tendremos que intentarlo con alguno de las siguientes soluciones que son algo más complicadas.

Llegado a este punto en el que necesitamos escalar nuestra base de datos y ninguna de las anteriores soluciones ya nos sirven tendremos que decidir entre:

Escalar verticalmente

Añadir más recursos a un nodo del sistema para mejorar el rendimiento de la base de datos, se trataría de hacer una inversión en hardware.

Pros:
Casi todos los sistemas escalan bien verticalmente.
Fácil de implementar
Fácil de administrar

Contras:
Alto coste del hardware

Escalar horizontalmente

Agregar más nodos al sistema. Se puede escalar horizontalmente con mejoras de hardware (agregar nuevas computadoras al sistema) ó con mejoras de software (Replicación de datos ó “Sharding” por ejemplo)

Pros:
Coste lineal

Contras:
Difícil de implementar
Difícil de administrar

Escalar horizontalmente y verticalmente

Se puede optar por está opción, habitualmente se escala de manera verticalmente mientras el presupuesto lo permita y cuando ya aumentan excesivamente los costos se escala horizontalmente.

Conclusiones

Es relativamente difícil llegar a tener problemas con la base de datos y si lo llegamos a tener será una buena noticia porque significa que nuestro proyecto es lo suficientemente grande como para comenzar a buscar solución a unos problemas que de ser solucionados nos van a permitir seguir creciendo.

Escalar verticalmente es relativamente fácil ya que mientras haya dinero para soportar el coste de hardware no tendremos problemas de escalabilidad, el verdadero reto es conseguir escalar de manera horizontal manteniendo controlado el coste de desarrollo, es realmente complicado porque si llegamos a este punto seguramente careceremos de ejemplos prácticos de cómo hacerlo ya que las estructuras de bases de datos pueden ser muy dispares, por ello no hay ningún método infalible.