DP-900: entender y usar partición horizontal (sharding) para datos no relacionales

Te enseñaré la habilidad de elegir y usar una partition key (partición horizontal / sharding) en bases de datos no relacionales en Azure — esencial para el DP‑900 y para construir aplicaciones escalables. Saber esto te ayuda a optimizar rendimiento, costes y escalabilidad en servicios como Azure Cosmos DB.

Qué necesitas saber

La partición horizontal (sharding) consiste en dividir una colección de documentos o ítems en varias particiones físicas, en función de un valor de clave (partition key). En los servicios NoSQL de Azure, como Azure Cosmos DB, cada ítem se almacena en una partición lógica determinada por la partition key; el servicio gestionará las particiones físicas detrás, permitiendo escalabilidad y paralelismo.

Ejemplo: una aplicación de comercio electrónico puede usar "tenantId" o "customerId" como partition key. Un documento de pedido puede tener la siguiente forma:

{
  "orderId": "A123",
  "customerId": "C789",
  "items": [...],
  "total": 79.90
}

Si la partition key es customerId, todos los pedidos del mismo cliente quedan en la misma partición lógica — útil para consultas frecuentes por cliente y para transacciones locales. La elección de la partition key afecta el throughput (RU/s), la latencia y el coste.

Cómo funciona y puntos clave

Propiedades y decisiones principales que debes conocer:

• Cardinalidad: la partition key ideal tiene alta cardinalidad (muchos valores distintos) para distribuir uniformemente los datos entre particiones.
• Uniformidad de carga: además de la cardinalidad, los valores de la partition key deben generar carga similar — evita claves que concentren el tráfico en un pequeño conjunto (hot partitions).
• Consultas y transacciones: elige una partition key que soporte los patrones de consulta. Las consultas que filtran por la partition key son más rápidas y económicas; las operaciones multi‑ítem atómicas normalmente están limitadas a una única partition key.
• Inmutabilidad: idealmente, la partition key es inmutable (no cambies el valor del documento), porque mover datos entre particiones tiene coste y limitaciones.

Decisión práctica: valora el volumen de ítems por valor, la frecuencia de lectura/escritura por valor y la necesidad de transacciones locales. Si tienes usuarios con gran número de registros, evita usar un valor con demasiados ítems que cause hot partitions.

En la práctica — configuración en Azure Cosmos DB (ejemplo conceptual)

Pasos simplificados para crear una colección con partition key (concepto aplicable a otros servicios NoSQL):

1. Identifica el patrón de acceso: ¿qué filtros son los más comunes? ¿por cliente, por región, por producto?
2. Elige la partition key candidata (ej.: /customerId o /regionId).
3. Crea la cuenta/colección especificando la partition key. En el portal de Azure o vía ARM/CLI, defines la ruta (path) de la partition key.
4. Prueba con cargas representativas: mide latencia, RU/s y distribución de particiones.
5. Ajusta si detectas hot partitions — puede ser necesaria una nueva modelación (ej.: combinar valores: customerId_regionId) o usar hashing del id.

Ejemplo conceptual de creación vía JSON (simplificado, no es un comando real):

{
  "id": "orders",
  "partitionKey": {
    "paths": ["/customerId"],
    "kind": "Hash"
  }
}

Nota: en el portal/CLI de Azure especificas la partition key al crear la colección; después es difícil cambiarla sin recrear la colección y migrar datos.

Errores comunes

• Elegir una partition key con baja cardinalidad (ej.: "status" con valores como "open/closed"): causa particiones desequilibradas y hot partitions.
• Elegir una clave que concentre tráfico (ej.: usar una fecha cuando la mayor parte del tráfico ocurre en las fechas más recientes), creando picos y degradación del rendimiento.
• Cambiar con frecuencia la partition key o usar claves mutables: obliga a migraciones complejas y aumenta el coste operativo.

Cómo practicar

Practica en el portal de Azure o con la cuenta gratuita: crea una cuenta Cosmos DB, prueba colecciones con diferentes partition keys y usa herramientas de carga para observar RU/s, latencia y distribución de particiones. Para la preparación del examen, realiza el Practice Assessment OFICIAL y gratuito de Microsoft para DP‑900 y sigue la study guide gratuita en el sitio de Microsoft. Esos recursos oficiales te ayudan a medir conocimientos sin usar material prohibido.

En resumen

• Partition key (sharding) divide los datos horizontalmente; es vital para la escalabilidad en NoSQL como Azure Cosmos DB.
• Elige una clave con alta cardinalidad y distribución de carga equilibrada; considera los patrones de consulta y la necesidad de transacciones locales.
• Evita claves mutables o con concentración de tráfico (hot partitions) y prueba con cargas reales antes de producción.
• Practica con el portal/CLI de Azure y usa el Practice Assessment y la study guide oficiales y gratuitos de Microsoft para preparar el DP‑900.