Facebook, Digg y muchos otros utilizan una técnica denominada Sharding para escalar.
El Sharding es una técnica que consiste en particionar los datos de tu base de datos horizontalmente agrupándolos de algún modo que tenga sentido y que permita un direccionamiento más rápido. Una agrupación típica puede ser por id por ejemplo: "los usuarios del 1 al millón están en esta base de datos"; o por nombre "los usuarios cuyo nombre va de la A a la E" están en esta base de datos".
Típicamente estos shards, agrupaciones o segmentos estarán localizados en tablas en diferentes bases de datos y localizaciones físicas. El Sharding no tiene por qué estar basado únicamente en una tabla y una columna, puede ser a nivel de todas las tablas. Por ejemplo podríamos decir "todos los datos de usuarios cuyo perfil está en los Estados Unidos los redirigimos a la base de datos del servidor en Estados Unidos, y todos los de Asia van a la base de datos de Asia".
El Sharding como tal mejora la escalabilidad y el rendimiento al agrupar menos datos en tablas más pequeñas por lo que los accesos serán mucho más rápidos. En caso de tener múltiples servidores en múltiples localizaciones, el basar el Sharding en la localización geográfica permite también disminuir considerablemente la latencia.
¿Cuándo se necesita hacer Sharding? Principalmente cuando el volumen de datos comienza a ser inmanejable. A tablas más grandes, más lentos son los accesos. No es lo mismo acceder a una tabla de diez mil usuarios que a una tabla de diez millones de usuarios. También comentan en el blog del que hablaré en breve que es bueno hacer Sharding cuando el volumen de escrituras es demasiado grande para un único servidor. En bases de datos, escrituras=bloqueos, bloqueos=contención de recursos, contención de recursos=mala experiencia de usuario, a parte del problema con la sincronización con slaves.
Todo esto viene a cuento de que en el blog de rendimiento de MySQL nos advierten de por qué no deberíamos hacer Sharding prematuramente. El problema principal es que Sharding se ha convertido en una palabra de moda. A fin de cuentas, si Facebook lo hace, ¿por qué no lo voy a hacer yo? Pues porque yo no tengo 120 millones de usuarios activos, ¿quizás?
Mi opinión es que en general estoy de acuerdo con el no hacer Sharding desde el principio, pero sólo si este va a impactar en la estructura de la base de datos. Es decir, dividir los usuarios de la A-E, la F-M, ... etc. a bote pronto parece como una mala decisión, al menos sin saber si vamos a tener cien usuarios o cien mil.
Pero planificar para Sharding no siempre tiene por que ser una mala decisión. En Java por ejemplo hay herramientas que nos lo facilitan. En general, el particionar por aplicación o por país además no son decisiones demasiado relevantes y que no tienen porque impactar el desarrollo en sobremanera, al tiempo que en el futuro facilitan enormemente la escalabilidad del servicio. Eso sí, hay que tener claro que a mayor número de shards mayor mantenimiento. No es lo mismo actualizar un índice en una tabla que hacerlo en cinco, especialmente porque al hacerlo en cinco es más fácil el dejarse uno olvidado.
Shashikant01 
