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.