Es una técnica para partir la DB, ya sea que la distribuya completamente de manera geográfica en el mundo o que al menos la tenga en diferentes servidores en mi zona para hacer los Queries a diferentes servers para optimizar los tiempos.

Shard = Los Pedazos de una ventana rota.

Usemos la Analogía

de la Pizza:

1. Tengo una Pizza entera que generalmente no me puedo acabar yo solo.

• El servidor no puede con esas peticiones.
• No tengo la capacidad de atender en un servidor (En una sola maquina) todas las peticiones que hago a mi DB.
• Tal vez son muchos Datos, hago social media, que necesito hacer hasta millones de Queries por segundo.

1. Entonces Partimos la Pizza en pedazos.

• Dividimos la Data en pedazos para que no esté concentrada en un solo lugar (servidor).

1. Llamo a 8 amigos y cada uno se come un pedazo.

• Ponemos 8 servidores para la Data, y cada uno va a atender una serie de peticiones diferentes.

Dividir la Data por algun

criterio que me sea util:

• Si voy a consultar por región geográfica me conviene dividir los Shards.

• Un sistema que este consultando Datos ya basados en archivos de Datos donde puedo guardar Datos de hace 5 años (Data Warehouse) y otra DB donde estén consultando los informes nuevos.

• Me conviene dividirlo por mes, donde hay un reporte que este haciendo todo lo de enero y me conviene poner en un Shard todo lo de enero y otro Shard lo de Febrero etc, depende de mí caso de uso.

La técnica siempre es la misma, es partir una serie de Tuplas y ponerlas en diferentes lugares para que sea mucho más fácil de manejar las peticiones.

El criterio a tomar para la partición de la BD depende de tu caso de uso. Puedes partir por tablas, por registros, por fechas, por lugares geográficos, por llaves foráneas, etc.

Es una gran herramienta, pero no aplica todo el tiempo.

PROBLEMAS

1. Joins entre Shards Cuando debo traer poquitos de Data de cada Shard no es nada optimo y se vuelve super tedioso.
2. Baja Elasticidad No puedo alterar fácilmente la estructura de Datos, y puede que en algunas fechas hay muchos datos. Ahí entra que puedo hacer Shards dentro de un Shard y se puede volver super complejo.
3. Reemplaza PK Si mi concepto es por fecha, y tengo la partición por fecha y yo quiero extraer del id 1 al id 100 pues están repartidos en diferentes Shards y debo ir Shard por Shard tratando de recolectar toda la info. Entonces el id deja de ser única y ya no me sirve de nada tener ese tipo de índice o Llave Primaria, más bien me sirve tener como PK el criterio por el cual estoy haciendo Sharding que en este caso es la Fecha. Los beneficios de una PK pues ya no los tendría.