Em minhas publicações sobre modelagem de dados de valor-chave com o Couchbase, as principais preocupações eram:
- * Quando incorporar dados e quando fazer referência
- * criação de índices secundários
- * design principal.
Em um mundo N1QL, ainda estamos pensando em coisas semelhantes e, nesta postagem, examinarei duas delas:
- * Como representar tipos de documentos
- * Modelagem de relações entre documentos.
Fundamentalmente, ainda é uma história de fazer as compensações certas para que você possa criar um modelo de dados físicos que representa de forma mais eficiente seu modelo lógico. Tudo o que foi alterado foram alguns detalhes de implementação.
Não fazer nada
Em primeiro lugar, vale a pena dizer que você pode consultar dados JSON existentes sem precisar fazer nenhuma alteração. O N1QL não exigirá que você remodele todo o seu banco de dados existente.
No entanto, você pode fazer alterações em seu modelo que tornarão o N1QL mais eficiente e suas consultas mais fáceis de escrever. E se estiver começando do zero, é melhor considerar a capacidade de consulta do N1QL desde o início.
Tipos de documentos
Uma das partes mais importantes da modelagem de dados de valor-chave é o design da chave. Em um mundo de valores-chave, a chave tem uma enorme responsabilidade: ela deve informar o que está sendo armazenado e deve ser fácil de encontrar novamente.
Por exemplo, as chaves dos registros de clientes podem ter o seguinte formato:
* cust::nameo registro principal do cliente* cust::name::paymentos detalhes de pagamento do cliente
Com a consulta avançada, a função do nome da chave muda. Em vez de solicitar diretamente a chave, você solicitará os dados que deseja. Essas duas responsabilidades - descrever o que você está armazenando e facilitar a localização dos dados - são transferidas para o próprio documento como um tipo de documento.
É aqui que encontramos uma das grandes diferenças práticas entre o N1QL e o SQL: O FROM faz menos trabalho no N1QL atualmente. O escopo de um bucket do Couchbase é muito diferente do escopo de uma tabela relacional típica.
O SQL FROM restringe o escopo da nossa consulta aos dados que nos interessam. O N1QL FROM informa ao mecanismo de consulta qual compartimento deve ser examinado. Como um bucket típico contém todos os dados de um aplicativo, precisamos de outra maneira de distinguir os tipos de documentos.
Um cliente
Vamos dar uma olhada em um cliente. Aqui está um registro simples:
{
"name": "Alan Partridge",
"email": "alan@example.com",
"localização": "Norwich",
"phone": "+44-1603-619-331",
"docInfo":
{
"type": "customer",
"created": "2015-10-22T10:17:24.731Z",
"schemaVersion": "1.2.3"
}
}
O tipo entra em ação para restringir o escopo da nossa consulta N1QL:
SELECT * FROM default WHERE type = customer;
Usando o tipo podemos criar índices que contenham apenas os documentos de um tipo específico. Por exemplo:
CREATE INDEX customers ON default WHERE type=customer;
É provável que seus esquemas de documentos já especifiquem um tipo, principalmente se você estiver usando exibições do Couchbase. De qualquer forma, ao criar um documento, você deve especificar seu tipo no corpo do documento.
Em iterações futuras do Couchbase e do N1QL, poderemos ver o namespacing abaixo do nível do bucket, mas os tipos sempre nos darão uma maneira de baixo custo de diferenciar os documentos.
Relações entre documentos
A questão da Quando incorporar e quando encaminhar continua sendo importante ao modelar para o N1QL. A diferença é que o N1QL lida com esses relacionamentos para você por meio de JOINs.
As uniões N1QL podem ocorrer entre:
- * documentos em diferentes compartimentos
- * documentos no mesmo bucket
Em ambos os casos, o JOIN corresponde a um valor no documento do lado esquerdo com o nome da chave de um documento do lado direito. Portanto, se um documento contiver o nome da chave de outro documento, você poderá fazer o JOIN desses dois documentos.
Vamos adicionar a compra mais recente de nosso cliente fictício ao perfil:
{ lastPurchase: "prod::drivinggloves" }
O valor aqui também é o nome da chave de um documento do produto em outro local do nosso bucket.
Portanto, para retornar o nome do cliente e o preço de sua última compra para cada cliente que mora em Norwuch, usaríamos a seguinte N1QL:
SELECT r.name, a.price FROM default r JOIN padrão a ON KEYS r.lastPurchase WHERE r.location = "Norwich";
O resultado seria algo parecido com:
{
"requestID": "a2284985-541f-491d-b921-4c248f154293",
"assinatura":
{
"name": "json",
"price": "json" },
"resultados":
[
{"name": "Alan Partridge",
"price": "9.99"
}
],
"status": "success",
"métricas":
{
"elapsedTime": "5.223111ms",
"executionTime": "5.124029ms",
"resultCount": 1,
"resultSize": 77
}
}
Com o N1QL, podemos produzir relações de um para um, de um para muitos e de muitos para muitos entre os documentos. Portanto, embora os documentos incorporados fossem anteriormente uma grande parte da forma como modelávamos nossos dados para o Couchbase, com o N1QL eles se tornaram fáceis para nós, desenvolvedores.
Em resumo
Os dois principais pontos a serem considerados nesta postagem são:
- seus documentos devem ter um tipo que suas consultas possam usar para restringir o escopo
- Os JOINs dependem da chave primária do documento do lado direito que aparece no corpo do documento do lado esquerdo.
Em última análise, não é preciso mudar muita coisa nos seus dados JSON para que você possa usar o N1QL. À medida que você se aprofundar mais no N1QL, sem dúvida encontrará formas de documentos que funcionam melhor do que outras. Se for o caso, compartilhe-as conosco na seção Fóruns do Couchbase!
