← Volver a la Base de conocimientos← Pregunta anteriorSiguiente pregunta →
ProgramaciónArquitecto de datos

Explique cómo implementar una distribución de carga eficiente (sharding/partitioning) en SQL para escalar tablas grandes. ¿Cuáles son las diferencias entre particionado y sharding, y qué trampas existen?

Supere entrevistas con el asistente de IA Hintsage

Respuesta

La distribución de grandes volúmenes de datos se logra de dos maneras principales:

  1. Particionado (partitioning): División lógica de una tabla dentro de una base de datos en segmentos (partition) según una clave, normalmente una fecha o un rango de valores. Esto permite realizar operaciones rápidamente sobre sectores individuales, acelera la búsqueda y facilita el mantenimiento.

  2. Sharding (sharding): División física de los datos en varias bases de datos/servidores según un algoritmo determinado, la tabla se duplica en diferentes clústeres, cada uno de los cuales contiene su propio segmento de datos.

Las ventajas del partitioning son que no se requiere mantener una lógica de negocio separada para la ruta de las consultas, todo ocurre de manera "transparente" para la aplicación; las desventajas son que se limita a las capacidades de un solo SGBD.

El sharding permite escalado horizontal (el límite depende solo del número de servidores), pero requiere una sincronización compleja, enrutamiento y manejo de consultas "entre shards".

Ejemplo (PostgreSQL, range-partitioning):

-- Tabla base particionada
CREATE TABLE orders (
  id SERIAL PRIMARY KEY,
  customer_id INT,
  order_date DATE
) PARTITION BY RANGE (order_date);

CREATE TABLE orders_2023 PARTITION OF orders
  FOR VALUES FROM ('2023-01-01') TO ('2024-01-01');

Pregunta capciosa

Pregunta: ¿Se pueden mover "al vuelo" filas entre particiones sin bloquear la tabla principal?

Respuesta: En la mayoría de los SGBD, mover una fila entre particiones es equivalente a eliminarla e insertarla, tales operaciones pueden bloquear filas e incluso la tabla misma, especialmente si se involucran disparadores o claves externas. Esto debe considerarse al realizar "migraciones" masivas de datos entre secciones.

Ejemplo:

-- ALTER TABLE ... MOVE PARTITION, generalmente requiere atención adicional a los bloqueos. Mejor hacerlo en momentos de baja carga.

Ejemplos de errores reales debido al desconocimiento de los matices del tema

Historia 1: En un proyecto, generaron informes analíticos de todas las particiones a la vez, sin tener en cuenta que una tabla particionada con miles de secciones creaba planes de ejecución gigantescos. Como resultado, un aumento abrupto en el tiempo de ejecución y carga en el servidor. Solución: aumentar el número de particiones que correspondan a los ejes comerciales reales de la consulta y optimizar los planes de escaneo.

Historia 2: Al agregar sharding, no se tuvo en cuenta la no unicidad del identificador entre shards. A menudo ocurrían conflictos de claves durante la agregación entre shards.

Historia 3: La archivación automática de particiones "obsoletas" las eliminaba sin verificar nuevamente las relaciones externas, lo que llevó a la pérdida de conexión con otras tablas y a la pérdida de parte de los datos "vivos". Después de esto, toda la lógica de eliminación de particiones se reescribió con múltiples pruebas de conectividad.