Modelo de Dados Escalável no eXtreme Scale

A amostra Northwind da Microsoft utiliza a tabela Detalhes do Pedido para estabelecer uma associação muitos-para-muitos entre Pedidos e Produtos.

Object to relational mapping specifications (ORMs), como ADO.NET Entity Framework e Java Persistence API (JPA), podem mapear as tabelas e os relacionamentos utilizando entidades. No entanto, esta arquitetura não é escalada. Tudo deve estar localizado na mesma máquina ou em um cluster de máquinas caro para uma boa execução.

Figura 1. Diagrama do Esquema da Amostra Northwind do Microsoft SQL Server
Diagrama do esquema da amostra Northwind do Microsoft SQL Server: Os clientes criam uma ou mais ordens. As ordens contêm produtos, que podem pertencer às categorias.

Para criar uma versão escalável da amostra, as entidades devem ser modeladas de forma que cada entidade ou grupo de entidades relacionadas possa ser particionado com base em uma única chave. Ao criar partições em uma única chave, os pedidos podem ser espalhados entre vários servidores independentes. Para atingir essa configuração, as entidades foram divididas em duas árvores: a árvore Cliente e Ordem e a árvore Produto e Categoria. Neste modelo, cada árvore pode ser particionada de forma independente e, portanto, pode crescer a taxas diferentes, aumentando a escalabilidade.

Figura 2. Diagrama do Esquema de Entidade Cliente e Ordem
Diagrama do esquema de entidade Cliente e Ordem: Os clientes fazem ordens e cada ordem tem seus detalhes.

Por exemplo, Order e Product têm números inteiros separados exclusivos como chaves. De fato, as tabelas Order e Product são realmente independentes uma da outra. Por exemplo, considere o efeito do tamanho de um catálogo, o número de produtos vendidos, com o número total de pedidos. Intuitivamente, pode parecer que ter muitos produtos implica também em ter muitas ordens, mas este não é necessariamente o caso. Se isso fosse verdade, você poderia facilmente aumentar as vendas incluindo mais produtos em seu catálogo. Orders e Products têm suas próprias tabelas independentes. É possível estender mais este conceito para que as ordens e os produtos tenham, cada um, suas próprias grades de dados separadas. Com grades de dados independente, é possível controlar o número de partições e servidores, além do tamanho de cada grade de dados separadamente para que seu aplicativo possa escalar. Se dobrar o tamanho de seu catálogo, a grade dados de produtos deverá ser dobrada, mas a grade de ordens pode permanecer inalterada. O contrário é verdade para um pico de pedidos ou pico de pedidos esperado.

No esquema, um Customer tem zero ou mais Orders, e um Order tem itens de linha (OrderDetail), cada um com um produto específico. Um Produto é identificado pelo ID (a chave do Produto) em cada OrderDetail. Uma única grade de dados armazena Clients, Orders e OrderDetails com o Client como a entidade raiz da grade de dados. É possível recuperar os Clientes pelo ID, mas é necessário obter as Ordens que começam com o ID do Cliente. Então, o ID do cliente é incluído na Ordem como parte de sua chave. Da mesma forma, o ID do cliente e o ID da ordem fazem parte do ID do OrderDetail.

Figura 3. Diagrama do Esquema de Entidade Categoria e Produto
Diagrama do esquema de entidade Categoria e Produto: Cada produto pertence a uma categoria.

No esquema Category e Product, Category é a raiz do esquema. Com este esquema, os clientes podem consultar os produtos por categoria. Consulte Recuperando e Atualizando Dados com o REST para obter detalhes adicionais sobre as principais associações e sua importância.