Archivo para la categoría ‘Bases de datos

El concepto del “Sharding” ha ido ganando popularidad en los últimos años debido a al enorme crecimiento del volumen de datos manejado por diferentes sitios web que para solucionar sus problemas de escalabilidad recurrieron a esta técnica (Ej: Digg, Facebook, Amazon, Skype, Friendster), resumiento esta técnica consiste en particionar los datos de la base de datos de manera horizontal agrupándolos de manera que tenga cierta consistencia y haciendo que el acceso a los datos sean mucho más rápido. El término en cuestión fue acuñado por ingenieros de Google y consiguió mucha popularidad con el anuncio de Big Table.

¿Cuándo es necesario recurrir al Sharding?

Sólo se necesita Sharding cuando el volumen de datos comienza a ser inmanejable ya que en grandes tablas los accesos son lentos y no es lo mismo acceder a tablas con millones de registros que tablas con miles de registros.

El Sharding mejora de manera ostensible el rendimiento al agrupar menos datos en tablas más pequeñas proporcionando accesos mucho más rápidos, si se realiza un Sharding por localización geográfica ademas de aumentar el rendimiento conseguiremos una mejora en la latencia de transmisión de datos.

El principal problema es que en cualquier proyecto web cuando el volumen de transacciones y el tamaño de la base de datos crece de manera lineal nos encontramos con el problema de que en estructuras básicas los tiempos de respuesta tienden a crecer de manera logarítmica. Dicho de otra manera el crecimiento de las transacciones de base de datos y el tamaño de las mismas tiene un enorme impacto en los tiempos de respuesta.

El rendimiento y la escalabilidad de cualquier base de datos depende de tres componentes básicos:
- CPU
- Memoria
- Disco

Cada uno de estos elementos introducidos en un único servidor puede escalar hasta un punto determinado, sin embargo si separamos los datos en diferentes nodos conseguiriamos escapar del límite inherente de esos tres componentes básicos.

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.

Las bases de datos son un componente indespensable en el desarrollo de páginas web, a menudo los desarrolladores se pueden decantar por diferentes lenguajes de programación (PHP, Python, Ruby on Rails, etc) pero al final casi todos utilizan MySql como elemento principal e indispensable para el manejo de los datos.

Personalmente pienso que es relativamente fácil escribir código funcional en pocas horas y unirlo a un buen diseño que en conjunto formen una aplicación útil, sin embargo este tipo de combinaciones tienden a no escalar bien debido a su alta dependencia a la base de datos, por ello en la gran mayoría de ocasiones nos vendría bien invertir tiempo en el análisis y optimización de la estructura de datos que estemos utilizando.

Estos son algunos de los errores más comunes que se suelen cometer en MySql.

Usar MyISAM en lugar de InnoDB

Son los dos motores de base de datos más famosos y el uso de uno u otro es una decisión bastante importante.

MyISAM es usada por defecto pero no por ello es la mejor opción, si estamos pensando en un proyecto experimental es una buena opción, sin embargo en la mayoría de ocasiones no es la mejor solución, vamos a citar alguna de las claves por las que es más recomendado el uso de InnoDB.

1. MyISAM no soporta las claves foráneas
2. Integridad de datos
3. En MyISAM con cada escritura se bloquea la tabla entera por lo que en cada “INSERT” o “UPDATE” estaremos bloqueando la tabla, a pequeña escala no se suele notar pero a medida que la exigencia de la base de datos sea mayor la disminución de rendimiento es considerable.

No filtrar la entrada de datos

Nunca debes confiar en el usuario en cuánto a la entrada de datos se refiere, para ello hay que asegurarse de filtrar y limpiar los datos en el lado del servidor y de esa manera evitar errores inesperados y posibles ataques de SQL injection.

No usar UTF-8

UTF-8 nos soluciona muchos problemas en cuanto a internacionalización de aplicaciones se refiere.

Filtrar datos con PHP en lugar de con MySQL

Cuando eres nuevo en MySQL a menudo tratas de solucionar problemas a la hora de sacar y filtrar datos con PHP esto es un grave error ya que es bastante más lento, puede que tengas que perder tiempo en investigar pero seguro que a ese problema que tienes hay una solución con MySQL.

Un ejemplo simple sería sacar la media de un valor en una tabla de la base de datos, si no sabes de MySQL seguramente trates de obtener el total en PHP y dividas las suma por el número de filas que has sacado de la tabla, esto en MySQL se puede hacer fácilmente con el uso de la función AVG().

Recuerda que en casi todos los casos será más efectiva una buena consulta con MySQL.

No optimizar las consultas

Cómo hemos comentado anteriormente la gran mayoría de errores a la hora de escalar un proyecto se encuentran en la base de datos, por ello es muy importante tomar un tiempo en la optimización de consultas, la elección de los índices, el tamaño de los campos y los filtros que vas a utilizar son preguntas necesarias a la hora de enfrentarte a una consulta.

Uso erróneo de tipo de datos

Hay un gran número de tipo de datos, a pequeña escala seguramente de igual una mala elección pero a medida que nuestra base de datos crece si el tipo de datos escogido es erróneo los problemas que vamos a tener van a ser grandes. Por eso antes de usar un DATETIME piensa si en ese caso específico sería más recomendable el uso de un DATE, o siel valor de un campo sabes que no va a sobrepasar cierta cantidad de cifras mira si te interesa utilizar un TINYINT en lugar de un INTEGER.

Usar * en las consultas SELECT

En muy pocos casos se tiene que recurrir al uso del * en las consultas SELECT, por varios motivos, el primer y principal motivo es que estás seguramente recogiendo más datos de los que necesitas, otro motivo es que realmente no sabes con exactitud que campos estás recuperando de la base de datos y si la consulta tiene algún JOIN la cosa se complica considerablemente.

Lo más recomendable es no recurrir nunca a este recurso salvo en casos excepcionales y tratar en todo momento exactamente los datos que necesitas.

Esta lista de errores la he sacado de una entrada en SitePoint Blogs: Top 10 MySQL Mistakes Made By PHP Developers


Esta es la lista de las mejores webs 2.0 segun alexaholic, esta lista tiene la característica que se puede ordenar por columnas mediante el uso de sorttable, solo hay que clickear en el título de la columna que deseamos ordenar.

Con cada click se va alternando entre orden descendente y ascendente, los enlaces de cada una de las webs nos dirigen a su gráfica alexa de los seis ultimos meses.