Exemplo 1: Criando uma Tabela Sem Esquema

Você tem várias opções para armazenar informações sobre padrões de navegação na tabela. Uma opção é definir uma tabela que usa um ID de cookie como uma chave e mantém os dados de segmentação do público-alvo como um único campo JSON.

// schema less, data is stored in a JSON field
CREATE TABLE audience_info (
       cookie_id LONG,
       audience_data JSON,
       PRIMARY KEY(cookie_id))

Nesse caso, a tabela audience_info pode conter um objeto JSON como:

{
  "cookie_id": "",
  "audience_data": {
    "ipaddr" : "10.0.00.xxx",
    "audience_segment: {
       "sports_lover" : "2018-11-30",
       "book_reader" :  "2018-12-01"
    }
  }
}

Seu aplicativo terá um campo-chave e um campo de dados para essa tabela. Você tem flexibilidade no que optou por armazenar informações no campo audience_data. Portanto, você pode alterar facilmente os tipos de informações disponíveis.

Exemplo 2: Criando uma Tabela de Esquema Fixo

Você pode armazenar informações sobre padrões de navegação criando sua tabela com campos mais declarados explicitamente:

// fixed schema, data is stored in typed fields.
CREATE TABLE audience_info(
       cookie_id LONG,
       ipaddr STRING,
       audience_segment RECORD(sports_lover TIMESTAMP(9),
                               book_reader TIMESTAMP(9)),
       PRIMARY KEY(cookie_id));

Neste exemplo, sua tabela tem um campo-chave e dois campos de dados. Seus dados são mais compactos e você pode garantir que todos os campos de dados sejam precisos.

Exemplo 3: Criando uma Tabela Híbrida

Você pode armazenar informações sobre padrões de navegação usando campos de dados tipados e JSON em sua tabela.

// mixed, data is stored in both typed and JSON fields.
CREATE TABLE audience_info (
       cookie_id LONG,
       ipaddr STRING,
       audience_segment JSON,
       PRIMARY KEY(cookie_id));

Chaves Primárias

Você deve designar uma ou mais colunas de chave primária ao criar a tabela. Uma chave primária identifica exclusivamente cada linha da tabela. Para operações CRUD simples, o Oracle NoSQL Database Cloud Service usa a chave primária para recuperar uma linha específica para ler ou modificar. Por exemplo, considere que uma tabela tenha os seguintes campos:

• productName

• productType

• productLine

Com base na sua experiência, você sabe que o nome do produto é importante, bem como exclusivo, para cada linha. Portanto, defina productName como a chave primária. Portanto, você recupera linhas de interesse com base no productName. Nesse caso, use uma instrução como essa para definir a tabela.

/* Create a new table called users. */
CREATE TABLE if not exists myProducts 
(
  productName STRING,
  productType STRING,
  productLine INTEGER,
  PRIMARY KEY (productName)
)";

Chaves de Partição

A principal finalidade das chaves de partição é distribuir dados no cluster do Oracle NoSQL Database Cloud Service para aumentar a eficiência e posicionar os registros que compartilham a chave de partição localmente para fácil referência e acesso. Os registros que compartilham a chave de partição são armazenados no mesmo local físico e podem ser acessados de forma atômica e eficiente.

O seu design de chave Primária e de chave de Partição tem implicações no escalonamento e na obtenção do throughput provisionado. Por exemplo, quando os registros compartilham as chaves de partição, você pode excluir várias linhas de tabela em uma operação atômica ou recuperar um subconjunto de linhas de sua tabela em uma única operação atômica. Além de permitir a escalabilidade, as chaves de partição bem projetadas podem melhorar o desempenho, exigindo menos ciclos para inserir dados ou obter dados de um único shard.

Por exemplo, suponha que você designe três campos de chave primária:

PRIMARY KEY (productName, productType, productLine)

Como você sabe que frequentemente o aplicativo faz consultas usando as colunas productName e productType, a especificação desses campos como chaves de partição é apropriada. A designação de chave de partição garante que todas as linhas dessas duas colunas sejam armazenadas no mesmo shard. Se esses dois campos não forem chaves de partição, as colunas consultadas com mais frequência poderão ser armazenadas em qualquer shard. Logo, a localização de todas as linhas de ambos os campos requer a varredura de todo o armazenamento de dados, em vez de um shard.

Fatores importantes a serem considerados ao se escolher uma chave de partição

• Cardinalidade: campos de baixa cardinalidade, como país de origem do usuário, agrupam registros em alguns shards. Por sua vez, esses shards exigem rebalanceamento frequente de dados, aumentando a probabilidade de problemas de hot shard. Em vez disso, cada chave de partição deve ter uma cardinalidade alta, em que a chave de partição pode expressar uma fatia uniforme de registros no conjunto de dados. Por exemplo, os números de identidade como customerID, userID ou productID são bons candidatos para uma chave de partição.

• Atomicidade: Somente objetos que compartilham a chave de partição podem participar de uma transação. Se você precisar de transações de ACID que abrangem vários registros, escolha uma chave de partição que permita atender a essa necessidade.

Quais são as melhores práticas a serem seguidas?

• Distribuição uniforme de chaves de partição: Quando as chaves de partição são distribuídas uniformemente, nenhum shard único limita a capacidade do sistema.

• Isolamento de Consulta: As consultas devem ser direcionadas a um shard específico para maximizar a eficiência e o desempenho. Se as consultas não estiverem isoladas em um único shard, a consulta será aplicada a todos os shards, o que é menos eficiente e aumenta a latência da consulta.

Consulte Criando Tabelas e Índices para saber como designar chaves primárias e de partição usando o objeto TableRequest.