Nota
O acesso a esta página requer autorização. Pode tentar iniciar sessão ou alterar os diretórios.
O acesso a esta página requer autorização. Pode tentar alterar os diretórios.
Um cluster tem cinco tipos de tabelas. Cada tipo armazena dados de forma diferente nos nós e serve propósitos distintos.
Tabelas Distribuídas
O primeiro tipo, e mais comum, são as tabelas distribuídas. Parecem tabelas normais para instruções SQL, mas estão particionadas horizontalmente entre nós de trabalho. Este particionamento significa que as linhas das tabelas são armazenadas em diferentes nós, em tabelas de fragmentos denominadas shards.
Clusters elásticos executam não só SQL, mas também instruções DDL (Data Definition Language) em todo o cluster. Quando mudas o esquema de uma tabela distribuída, a alteração desencadeia-se para atualizar todos os shards da tabela entre os trabalhadores. É necessário realizar essas operações através de uma ligação através da porta 5432.
Coluna distribuída
Os clusters elásticos usam fragmentação algorítmica para atribuir linhas a fragmentos. A atribuição é feita deterministicamente com base no valor de uma coluna de tabela chamada coluna de distribuição. O administrador do cluster deve designar essa coluna ao distribuir uma tabela. Fazer a escolha certa é importante para o desempenho e a funcionalidade.
Quadros de referência
Uma tabela de referência é um tipo de tabela distribuída cujo conteúdo inteiro reside num único fragmento. O cluster replica o fragmento em cada trabalhador. As consultas em qualquer trabalhador podem acessar as informações de referência localmente, sem a sobrecarga de rede de solicitar linhas de outro nó. As tabelas de referência não têm uma coluna de distribuição porque não é necessário distinguir fragmentos separados por linha.
As tabelas de referência são normalmente pequenas e armazenam dados relevantes para as consultas executadas em qualquer nó de trabalho. Um exemplo são valores enumerados, como status de pedidos ou categorias de produtos.
Tabelas locais
Quando usas um cluster elástico, cada nó é uma base de dados PostgreSQL normal. Você pode criar tabelas comuns sobre eles e optar por não fragmentá-los.
Um bom candidato para tabelas locais são tabelas administrativas pequenas que não participam nas consultas de junção. Um exemplo é uma users tabela para entrada e autenticação de aplicativos. Esse tipo de tabela só é útil quando você não planeja balancear a carga de sua conexão entre um cluster elástico usando a porta 7432 ou 8432.
Tabelas gerenciadas localmente
Os clusters elásticos podem adicionar automaticamente tabelas locais aos metadados se existir uma referência de chave estrangeira entre uma tabela local e uma tabela de referência. Além disso, pode criar manualmente tabelas geridas localmente ao executar a citus_add_local_table_to_metadata função em tabelas locais normais. As tabelas presentes nos metadados são consideradas tabelas gerenciadas e podem ser consultadas a partir de qualquer nó. O Citus sabe rotear para o nó para obter dados da tabela gerenciada local. Essas tabelas são exibidas como locais na vista citus_tables.
Tabelas de esquema
Quando se utiliza fragmentação baseada em esquemas, o sistema associa automaticamente esquemas distribuídos a grupos individuais de colocation. Quando crias tabelas nesses esquemas, o sistema converte-as automaticamente em tabelas distribuídas colocalizadas sem uma chave de fragmento. Estas tabelas são tabelas de esquema e aparecem como schema na vista citus_tables.