¿Cuándo consideras sharding de base de datos?

Respuesta directa

Qué debe cubrir una buena respuesta

Cómo funciona

El sharding divide una base de datos lógica entre instancias independientes por una clave de shard, y es el último recurso porque convierte cosas simples en difíciles: joins entre shards, transacciones entre shards, restricciones de unicidad y consultas globales necesitan soluciones a nivel de aplicación. Antes de hacerlo, las opciones son una instancia mayor, réplicas de lectura, caché, archivar datos fríos y particionar dentro de una instancia. Cuando hace falta, la clave debe ser estable y estar presente en casi todas las consultas, como tenant o cliente, distribuir la carga de forma uniforme y evitar claves calientes; el enrutado vive en una biblioteca o proxy, el rebalanceo se planifica desde el primer día y los informes entre shards pasan por un almacén analítico aparte.

Ejemplo

Un SaaS multi-tenant con un tenant al 40 por ciento del tráfico hizo sharding por ID de tenant con los mayores en shards dedicados y el resto distribuidos por hash; cada consulta ya llevaba el ID de tenant, así que la capa de enrutado no tuvo ambigüedad. Los informes globales pasaron a un warehouse alimentado por captura de cambios. La migración se hizo por tenant tras un flag de enrutado, y las herramientas de rebalanceo se construyeron antes de que se llenara el primer shard.

Errores frecuentes

• Hacer sharding antes de probar particionado, réplicas y archivado.
• Elegir una clave ausente en la mayoría de consultas, de modo que cada solicitud se abre a todos los shards.
• Hacer sharding por un valor que concentra la carga en un shard, como la fecha.

Una estructura útil para responder

Responde desde tu propia experiencia.

No memorices un guion: usa solo ejemplos que puedas explicar con honestidad en preguntas posteriores.