AnalyticDB:Design de esquema de tabela

DISTRIBUTED BY HASH(column_name, ...)

Como escolher uma chave de distribuição

Selecione uma chave de distribuição com base nos critérios abaixo, em ordem de prioridade:

1. Distribuição uniforme de valores — escolha uma coluna de alta cardinalidade para que as linhas se espalhem uniformemente pelos nós. Boas opções incluem IDs de transação, IDs de dispositivo, IDs de usuário e colunas de incremento automático. Uma distribuição desigual causa distorção de dados e degrada o desempenho de gravação.

2. Colunas de junção — se uma consulta associa duas tabelas em uma coluna específica, use essa coluna como chave de distribuição para ambas. Isso direciona as linhas correspondentes para o mesmo nó e elimina a reorganização de dados entre nós. Por exemplo, para consultar pedidos históricos por cliente, use customer_id como chave de distribuição.

3. Colunas de filtro frequentes — colunas recorrentes em cláusulas WHERE permitem que o AnalyticDB for MySQL leia apenas os shards relevantes e ignore os demais.

4. Menor número possível de campos — cada tabela possui exatamente uma chave de distribuição, mas ela pode abranger várias colunas. Menos colunas na chave de distribuição aumentam sua utilidade para uma variedade maior de consultas.

Comportamento padrão quando nenhuma chave de distribuição é especificada:

• Se a tabela tiver uma chave primária, o AnalyticDB for MySQL a utilizará como chave de distribuição.

• Caso a tabela não tenha chave primária, o sistema adiciona uma coluna __adb_auto_id__ e a utiliza tanto como chave primária quanto como chave de distribuição.

-- Partition by the raw column value
PARTITION BY VALUE(column_name)

-- Partition by day  (e.g., 20210101)
PARTITION BY VALUE(DATE_FORMAT(column_name, '%Y%m%d'))
PARTITION BY VALUE(FROM_UNIXTIME(column_name, '%Y%m%d'))

-- Partition by month  (e.g., 202101)
PARTITION BY VALUE(DATE_FORMAT(column_name, '%Y%m'))
PARTITION BY VALUE(FROM_UNIXTIME(column_name, '%Y%m'))

-- Partition by year  (e.g., 2021)
PARTITION BY VALUE(DATE_FORMAT(column_name, '%Y'))
PARTITION BY VALUE(FROM_UNIXTIME(column_name, '%Y'))

Como escolher uma chave de partição

• Granularidades suportadas: ano, mês, dia ou valor bruto. Não há granularidade mais fina.

• Adequação da granularidade ao volume de dados: uma granularidade muito grossa (por exemplo, particionar por ano em uma tabela que cresce milhões de linhas por dia) cria partições excessivamente grandes e degrada o desempenho de consulta e gravação. Por outro lado, uma granularidade muito fina gera um número excessivo de partições pequenas, resultando no mesmo problema.

• Trate as partições como unidades estáveis: evite designs em que muitas partições históricas sofram atualizações frequentes. Atualizações constantes em várias partições indicam uma escolha inadequada da coluna de partição.

• Defina um ciclo de vida: como o número máximo de partições por tabela é limitado, os dados em uma tabela particionada não podem ser retidos indefinidamente. Sempre defina um valor de LIFECYCLE para evitar atingir esse limite. Para limites de partição, consulte Limites.

Para diagnosticar se a coluna de partição escolhida é adequada, use os Diagnósticos de adequação do campo de distribuição.

PRIMARY KEY (column_name, ...)

Como escolher uma chave primária

• Inclusão obrigatória da chave de distribuição e da chave de partição: a chave primária deve conter todas as colunas da chave de distribuição e da chave de partição. Coloque essas colunas primeiro na definição da chave primária composta.

• Preferência por colunas numéricas: campos de chave primária numéricos melhoram o desempenho de busca em comparação com campos de string.

• Uso do menor número possível de colunas: uma chave primária mais estreita reduz a sobrecarga de índice.

Para detalhes sobre a sintaxe de PRIMARY KEY, consulte CREATE TABLE.

Quando usar um índice clusterizado

Índices clusterizados não se destinam a todas as tabelas. Cada tabela suporta apenas um índice clusterizado, e sua manutenção consome recursos de CPU. Use um índice clusterizado somente quando:

• As consultas filtrarem consistentemente por uma coluna específica ou conjunto de colunas, and

• A melhoria no tempo de resposta da consulta justificar o custo adicional de CPU para manter o índice.

Exemplo: em um sistema de informações estudantis onde cada aluno consulta apenas suas próprias notas, defina o ID do aluno como chave de índice clusterizado. Todas as linhas de um determinado aluno ficam armazenadas contiguamente, permitindo que a consulta leia um único bloco sequencial em vez de varrer toda a tabela.

Para a sintaxe de criação de um índice clusterizado, consulte CREATE TABLE.

CREATE TABLE customer (
  customer_id    bigint    NOT NULL COMMENT 'Customer ID',
  customer_name  varchar   NOT NULL COMMENT 'Customer name',
  phone_num      bigint    NOT NULL COMMENT 'Phone number',
  city_name      varchar   NOT NULL COMMENT 'City',
  sex            int       NOT NULL COMMENT 'Gender',
  id_number      varchar   NOT NULL COMMENT 'ID card number',
  home_address   varchar   NOT NULL COMMENT 'Home address',
  office_address varchar   NOT NULL COMMENT 'Office address',
  age            int       NOT NULL COMMENT 'Age',
  login_time     timestamp NOT NULL COMMENT 'Logon time',
  PRIMARY KEY (login_time, customer_id, phone_num)
)
DISTRIBUTED BY HASH(customer_id)
PARTITION BY VALUE(DATE_FORMAT(login_time, '%Y%m%d')) LIFECYCLE 30
COMMENT 'Customer information table';

SELECT
  partition_id,       -- Partition name
  row_count,          -- Total rows in the partition
  local_data_size,    -- Local storage used by the partition
  index_size,         -- Index size
  pk_size,            -- Primary key index size
  remote_data_size    -- Remote storage used by the partition
FROM information_schema.kepler_partitions
WHERE schema_name = '$DB'
  AND table_name   = '$TABLE'
  AND partition_id > 0;