Início / coding / Perguntas / 79303458
Accepted
Oleg Pro
Asked: 2024-12-23 23:03:42 +0800 CST

Sharding por shardId padrão no Citus

  • 772

Eu tenho o Citus que executo no docker-compose, peguei o yaml do site oficial e o executei inicialmente em 2 nós

 docker-compose -p citus up --scale worker=2 -d

Depois adiciono a tabela

CREATE TABLE IF NOT EXISTS messages (
                        text TEXT NOT NULL,
                       "from" CHARACTER VARYING NOT NULL,
                       "to" CHARACTER VARYING NOT NULL,
                       "shardId" CHARACTER VARYING NOT NULL
                  );

Eu chamo então um SELECT create_distributed_table('messages', 'shardId'); shardId que é um valor hash das variáveis ​​'from' e 'to' que variam de 0 a 31, até agora está tudo bem, vejo que cada chat tem seu próprio shard.

Mas então, quando tentei refragmentar meu cluster

set POSTGRES_PASSWORD=pass && docker-compose -p citus up --scale worker=5 -d

e reequilibrar dados por meio de nós

SELECT citus_rebalance_start();

Recebi o erro de que não posso rebalancear a tabela sem um pk, então adicionei um pk(id) e então recebi o erro de que não posso colocar um valor create_distributed_table sendo um pk ou sob restrição exclusiva

  SELECT create_distributed_table('messages', 'shardId');

ERRO: não é possível criar restrição em "mensagens" DETALHE: Relações distribuídas não podem ter restrições UNIQUE, EXCLUDE ou PRIMARY KEY que não incluam a coluna de partição (com um operador de igualdade se EXCLUDE).

Então estou em um beco sem saída. O que posso fazer para manipular a chave no método create_distributed_table?

postgresql

1 respostas

  1. Best Answer

    Supondo que você fez algo assim:
    demo at db<>fiddle

    alter table messages 
  add column id int generated always as identity
 ,add constraint pk primary key(id);

    Sua situação se assemelha à de uma tentativa de particionamento - tem o mesmo requisito

    create table messages_partitioned(like messages including all)
  partition by list("shardId");

    Ele até mesmo formula esse requisito de forma semelhante:

    ERROR:  unique constraint on partitioned table must include all partitioning columns
DETAIL:  PRIMARY KEY constraint on table "messages_partitioned" lacks column "shardId" which is part of the partition key.

    Como parece que você só adicionou idpara satisfazer os requisitos de rebalanceamento do Citus, você pode simplesmente trocar a chave primária por uma chave primária composta - dê a ela dois campos e certifique-se shardIdde que um deles seja:

    alter table messages 
  drop constraint pk
 ,add constraint pk primary key(id,"shardId");

    Agora, tanto o sharding quanto o particionamento funcionam bem. Aqui está mais sobre isso, do Capítulo 5. Definição de Dados: 5.12. Particionamento de Tabelas, 5.12.2.3. Limitações :

    • Para criar uma restrição de chave primária ou exclusiva em uma tabela particionada, as chaves de partição não devem incluir nenhuma expressão ou chamada de função e as colunas da restrição devem incluir todas as colunas da chave de partição . Essa limitação existe porque os índices individuais que compõem a restrição só podem impor diretamente a exclusividade dentro de suas próprias partições; portanto, a própria estrutura da partição deve garantir que não haja duplicatas em partições diferentes.

    • Da mesma forma, uma restrição de exclusão deve incluir todas as colunas da chave de partição . Além disso, a restrição deve comparar essas colunas para igualdade (não, por exemplo, &&). Novamente, essa limitação decorre da incapacidade de impor restrições de partição cruzada. A restrição pode incluir colunas adicionais que não fazem parte da chave de partição e pode compará-las com quaisquer operadores que você desejar.

    Há também uma entrada no FAQ do Citus :

    Em quais situações as restrições de exclusividade são suportadas em tabelas distribuídas?

    O Citus é capaz de impor uma chave primária ou restrição de exclusividade somente quando as colunas restritas contêm a coluna de distribuição . Em particular, isso significa que se uma única coluna constitui a chave primária, então ela também tem que ser a coluna de distribuição.

    Essa restrição permite que o Citus localize uma verificação de exclusividade para um único fragmento e deixe que o PostgreSQL no nó de trabalho faça a verificação com eficiência.

    Citus laso menciona o PK composto acima em seu documento sobre gerenciamento de cluster :

    Caso contrário, você pode adicionar uma chave primária?

    Adicione uma chave primária à tabela. Se a chave desejada for a coluna de distribuição, então é bem fácil, basta adicionar a restrição. Caso contrário, uma chave primária com uma coluna de não distribuição deve ser composta e conter a coluna de distribuição também.

    • 0

relate perguntas