Cuando una tabla crece demasiado, índices dejan de funcionar y even El mejor índice es inútil si la tabla tiene 100 millones de filas y cada query toca todas.
Particionamiento: divide la tabla en piezas más pequeñas
Particionamiento divide una tabla grande en múltiples tablas más pequeñas basadas en un criterio: por rango de fechas, por ID módulo, por país, etc.
El beneficio es que queries tocan menos datos. El costo es que la lógica se complica un poco.
- Range partitioning: por fecha (datos 2023, 2024).
- Hash partitioning: por ID módulo para dispersión.
- List partitioning: por categoría explícita.
Sharding: cuando particionamiento no es suficiente
Sharding es particionamiento que cruza múltiples servidores de base de datos. Si una tabla es demasiado para una máquina, distribuyes piezas en múltiples máquinas.
El costo es complejidad operacional: routing correctos, rebalancing cuando crece, etc. Pero el beneficio es que prácticamente no hay límite de escala.
- Define clave de shard (usuario ID, tenant ID).
- Distribuye datos según esa clave.
- Ruta queries a shard correcto.
Archivado: mueve datos viejos a almacenamiento más barato
No todo lo que existe se consulta frecuentemente. Datos de hace dos años probablemente se leen casi nunca. Puedes archinarlos a almacenamiento más barato (S3, archive database) y reducir tamaño de tabla en caliente.
Eso mejora performance de queries en lo que importa (datos recientes) sin perder datos.
- Identifica qué datos envejecen.
- Define política de archivado (después de 90 días).
- Mueve a cold storage, mantén índice en caliente.
Cuidado: escalabilidad no es solo base de datos
Antes de partir la base de datos, asegúrate que tu aplicación puede manejar múltiples shards. Eso es cambio de arquitectura serio.
Muchos equipos optimizan índices, agregan caché y otras soluciones mucho antes de necesitar sharding real.
El mejor sharding es el que nunca haces. Optimiza índices, caché y queries primero. Escala arquitectura solo cuando realmente es necesario.
Monitoreo de crecimiento
Antes de crecer fuera de control, monitorea tamaño de tabla y velocidad de crecimiento. Eso te permite planificar escalabilidad proactivamente en lugar de reactivamente.
Si sabes que creces 1GB por mes, puedes planificar sharding para cuando llegues a 500GB.