Modelo de datos escalable de eXtreme Scale

El ejemplo Northwind de Microsoft utiliza la tabla Order Detail para establecer una asociación de muchos a muchos entre Orders y Products.

Las especificaciones de correlación de objeto a relacional (ORM) como ADO.NET Entity Framework y Java Persistence API (JPA) puede correlacionar las tablas y las relaciones utilizando entidades. No obstante, esta arquitectura no se escala. Todo debe encontrarse en la misma máquina, o en un clúster de máquinas caro, para que funcione bien.

Figura 1. Diagrama del esquema de ejemplo Northwind de Microsoft SQL Server
Diagrama del esquema de ejemplo Northwind de Microsoft SQL Server: los clientes crean uno o varios pedidos. Los pedidos contienen productos, que pueden pertenecer a categorías.

A fin de crear una versión escalable del ejemplo, las entidades se deben modelar de modo que cada entidad o grupo de entidades relacionadas se pueda particionar basándose en una sola clave. Mediante la creación de particiones en una sola clave, las solicitudes se pueden distribuir entre varios servidores independientes. Para conseguir esta configuración, las entidades se han dividido en dos árboles: el árbol de clientes y pedidos (Customer and Order) y el árbol de productos y categorías (Product and Category). En este modelo, cada árbol se puede dividir independientemente y, por lo tanto, puede crecer a ritmos diferentes, con lo que aumenta la escalabilidad.

Figura 2. Diagrama del esquema de entidades Customer y Order
Diagrama del esquema de entidades Customer y Order: los clientes realizan pedidos y cada pedido tiene detalles del pedido.

Por ejemplo, tanto Order como Product tienen enteros exclusivos distintos como claves. De hecho, las tablas Order y Product son realmente independientes entre sí. Por ejemplo, considere el efecto del tamaño de un catálogo, el número de productos que vende, con el número total de pedidos. Intuitivamente, podría parecer que tener muchos productos también implica tener muchos pedidos, pero esto no es necesariamente así. Si esto fuera verdad, podría aumentar fácilmente las ventas con el simple hecho de añadir más productos a su catálogo. Los pedidos y los productos tienen sus propias tablas independientes. Puede ampliar aún más este concepto de modo que los pedidos y los productos tengan sus propias cuadrículas de datos distintas. Con cuadrículas de datos independientes, puede controlar el número de particiones y servidores, además del tamaño de cada cuadrícula por separado de modo que la aplicación se pueda escalar. Si dobla el tamaño de su catálogo, debe doblar la cuadrícula de datos de productos, pero la cuadrícula de pedidos puede permanecer inalterada. Y lo contrario es aplicable a una oleada de pedidos o a una oleada de pedidos prevista.

En el esquema, un cliente tiene cero o más pedidos y un pedido tiene elementos de línea (OrderDetail), cada uno con un producto específico. Un producto se identifica mediante el ID (la clave de producto) en cada OrderDetail. Una sola cuadrícula de datos almacena clientes, pedidos y detalles del pedido con Customer como entidad raíz de la cuadrícula de datos. Puede recuperar clientes por ID, pero deberá obtener los pedidos a partir del ID de cliente. Por lo tanto, el ID de cliente se añade al pedido como parte de su clave. Del mismo modo, el ID de cliente y el ID de pedido forman parte del ID de detalle del pedido (OrderDetail).

Figura 3. Diagrama del esquema de entidades Category y Product
Diagrama del esquema de entidades Category y Product: cada producto pertenece a una categoría.

En el esquema de categorías y productos, la categoría es la raíz del esquema. Con este esquema, los clientes pueden consultar productos por categoría. Consulte Recuperación y actualización de datos con REST para obtener detalles adicionales sobre las asociaciones de claves y su importancia.