Anterior

Seguinte

Alterar andaimes em um ambiente distribuído

Concluído

E se os desenvolvedores do Woodgrove Bank criassem seu banco de dados distribuído começando com seu design relacional? Suponha que esse banco de dados foi criado no Azure Cosmos DB para PostgreSQL.

No diagrama, o campo event_type de payment_events agora está event_type_id, com uma relação de chave estrangeira com uma nova tabela chamada event_types. A tabela event_types contém o nome e event_type_id, com o event_type_id como chave primária. A tabela payment_events também tem uma relação de chave estrangeira com uma nova tabela chamada payment_merchants. A tabela payment_merchants tem merchant_id, nome e url. O merchant_id é a chave primária para payment_merchants.

Em um ambiente não distribuído, essas relações funcionam. No entanto, se os desenvolvedores já carregaram essa estrutura no banco de dados, há algum trabalho necessário para distribuir tabelas. As consultas DDL (linguagem de definição de dados) aplicam-se em um ambiente distribuído e há funções para ajudar a atualizar as tabelas distribuídas.

Lidar com alterações DDL gerais

No ambiente distribuído, as consultas DDL são colocadas em cascata entre os nós de trabalho. De consultas ALTER a consultas DROP, o Azure Cosmos DB para PostgreSQL suporta a maioria das DDL padrão usadas no PostgreSQL. Quando restrições estrangeiras são suportadas, elas também são aplicadas na DDL. Neste exemplo, o Azure Cosmos DB para PostgreSQL não descartará a event_types tabela até que os relacionamentos com ela sejam cortados.

A relação entre payment_events e payment_merchants precisa ser dissolvida, porque a relação não funciona para o ambiente distribuído. user_id é a coluna de distribuição do payment_events, e não faz sentido adicionar a user_id coluna à payment_merchants tabela. payment_merchants pode fazer mais sentido como tabela de referência. Se for esse o caso, esta relação de chave estrangeira pode ser readicionada mesmo depois payment_events de ter sido distribuída.

O Azure Cosmos DB para PostgreSQL propagará essas alterações entre os nós de trabalho para tabelas distribuídas. No entanto, ALTER TABLE não funciona com a coluna de distribuição. As colunas de distribuição precisam ser mantidas usando funções auxiliares. A execução de ALTER TABLE em uma coluna de distribuição retorna o seguinte erro:

ERROR: cannot execute ALTER TABLE command involving partition column

Atualizar a coluna de distribuição de uma tabela distribuída

No Woodgrove Bank, os desenvolvedores estavam ansiosos para tornar a chave primária a coluna de distribuição na payment_events mesa. No entanto, ao discutir a situação com você, eles percebem que precisam mudar a coluna de distribuição. A user_id coluna faz mais sentido como a coluna de distribuição para que os dados possam ser colocalizados com a payment_users tabela.

Você pode usar a função para alterar a alter_distributed_table() coluna de distribuição de uma tabela distribuída. Para este efeito, esta função usa dois parâmetros: o nome da tabela distribuída e o parâmetro nomeado de distribution_column.

Colocalizar tabelas

Faz sentido colocalizar dados relacionados ao consultar dados. Por exemplo, como os usuários estão consultando frequentemente seus eventos, faz sentido colocalizar os dados e payment_users por payment_eventsuser_id. O Azure Cosmos DB para PostgreSQL irá colocalizar implicitamente tabelas com colunas de distribuição do mesmo tipo de dados. Esse comportamento pode ter problemas de desempenho e cenários de colocation não intencionais, portanto, há duas coisas a observar ao definir relações de colocation:

• A colocation pode ser especificada como parte da distribuição chamando a create_distributed_table() função com o colocate_with parâmetro.
• Colocation pode ser alterado com a ajuda da update_distributed_table_colocation() função usando o colocate_with parâmetro.

Suponha que os desenvolvedores distribuíram a tabela e merchant_id esqueceram de especificar quando colocate_with distribuíram a payment_merchants tabela. Use update_distributed_table_colocation() para remover o colocation. Aqui está um exemplo de consulta que remove um colocation:

SELECT update_distributed_table_colocation('payment_merchants',colocate_with=>'none');

Converter de uma tabela distribuída em tabela de referência

E se a payment_merchants tabela fosse colocalizada no merchant_id, e então os desenvolvedores percebessem que na verdade é uma tabela menor e melhor como uma tabela de referência? Como a tabela pode ser convertida em uma tabela de referência, a relação de chave estrangeira entre payment_events e payment_merchants também pode ser recriada.

Para alterar uma tabela de uma tabela distribuída para uma tabela de referência, há duas coisas que têm de acontecer:

1. Desdistribua a tabela com a undistribute_table() função. Esta operação moverá todos os dados dos nós distribuídos para o nó coordenador. Esta operação falhará se não houver espaço no nó coordenador.

2. Altere a tabela de uma tabela local para uma tabela de referência, seguindo o mesmo padrão usado para criar a event_types tabela.

Depois de converter a tabela, você pode adicionar a relação de chave estrangeira à payment_events tabela via ALTER TABLE.

Continuar