Exercício - Tabelas de metadados do coordenador de consultas para compreender a distribuição de dados
Neste exercício, você usa o portal do Azure e as tabelas de metadados no nó coordenador para examinar como as tabelas são distribuídas entre nós de trabalho no cluster.
Importante
Este exercício depende do banco de dados do Azure Cosmos DB para PostgreSQL e das tabelas distribuídas criadas na Unidade 3 deste módulo.
Conectar-se ao banco de dados usando psql no Azure Cloud Shell
Navegue até o recurso do Azure Cosmos DB for PostgreSQL no portal do Azure.
No menu de navegação à esquerda, selecione Cadeias de conexão em Configurações e copie a cadeia de conexão rotulada psql.
Cole a cadeia de conexão em um editor de texto, como o Bloco de Notas.exe e substitua o
{your_password}
token pela senha atribuída ao usuário ao criar ocitus
cluster. Copie a cadeia de conexão atualizada para uso abaixo.Na página Cadeias de conexão no portal do Azure, abra uma caixa de diálogo do Azure Cloud Shell selecionando o ícone do Cloud Shell na barra de ferramentas do portal do Azure.
O Cloud Shell será aberto como um painel incorporado na parte inferior da janela do navegador.
Se necessário, selecione Bash como o ambiente na janela do Cloud Shell.
Agora, use o
psql
utilitário de linha de comando para se conectar ao seu banco de dados. Cole sua cadeia de conexão atualizada (aquela que contém sua senha correta) no prompt no Cloud Shell e execute o comando, que deve ser semelhante ao seguinte comando:psql "host=c.learn-cosmosdb-postgresql.postgres.database.azure.com port=5432 dbname=citus user=citus password=P@ssword.123! sslmode=require"
Examine os nós no cluster
Ao provisionar o banco de dados na Unidade 3, você instruiu o Azure a criar um cluster com dois nós de trabalho e um nó coordenador. Você pode usar alguns métodos para exibir detalhes sobre os nós no cluster.
Primeiro, você pode usar o portal do Azure. No painel Portal do Azure da janela do navegador, selecione Visão geral no menu de navegação à esquerda.
Na página Visão geral, os tamanhos dos nós coordenador e trabalhador são realçados na área Essentials e a guia Nós, onde mais detalhes sobre cada nó são exibidos, é realçada.
O portal do Azure fornece detalhes de alto nível sobre nós no cluster. A área Essentials da página Visão geral fornece detalhes sobre os tamanhos dos nós coordenador e de trabalho. Selecionar um desses painéis levará você para a página Escala, onde você pode alterar a configuração do cluster.
Além disso, a guia Nós abaixo da área Essentials mostra um detalhamento dos nós, com os nós de trabalho aparecendo abaixo do nó coordenador. Aqui, você pode visualizar o status de seus nós e a zona de disponibilidade e o nome de domínio totalmente qualificado para cada um.
Em seguida, use
psql
no Cloud Shell para examinar seus nós. No painel Cloud Shell na parte inferior da janela do navegador, execute a seguinte consulta na tabela de metadados do nó de trabalho (pg_dist_node
) para examinar informações mais detalhadas do nó:SELECT * FROM pg_dist_node;
Se a largura da janela do navegador for mais estreita do que os resultados da consulta, isso pode resultar em quebra automática de linhas e dificultar a visualização. Para fornecer uma exibição mais limpa, execute este comando SQL para habilitar a exibição expandida, que dinamiza os resultados de consultas amplas:
\x
Agora, execute a mesma consulta acima na
pg_dist_node
tabela:SELECT * FROM pg_dist_node;
O
\x
comando fornece uma visão mais limpa dos resultados para inspeção:-[ RECORD 1 ]----+----------------------------------------------------------------- nodeid | 2 groupid | 2 nodename | private-w1.learn-cosmosdb-postgresql.postgres.database.azure.com nodeport | 5432 noderack | default hasmetadata | t isactive | t noderole | primary nodecluster | default metadatasynced | t shouldhaveshards | t -[ RECORD 2 ]----+----------------------------------------------------------------- nodeid | 3 groupid | 3 nodename | private-w0.learn-cosmosdb-postgresql.postgres.database.azure.com nodeport | 5432 noderack | default hasmetadata | t isactive | t noderole | primary nodecluster | default metadatasynced | t shouldhaveshards | t -[ RECORD 3 ]----+----------------------------------------------------------------- nodeid | 4 groupid | 0 nodename | private-c.learn-cosmosdb-postgresql.postgres.database.azure.com nodeport | 5432 noderack | default hasmetadata | t isactive | t noderole | primary nodecluster | default metadatasynced | t shouldhaveshards | f
Consultar a tabela de metadados do nó de trabalho fornece muito mais informações sobre nós de cluster do que você pode ver no portal do Azure. Nomes de nó e números de porta podem ser usados para se conectar diretamente aos nós, o que é uma prática comum ao executar a otimização de consulta. Como alternativa, você pode recuperar cadeias de conexão para cada nó em seu cluster na página Cadeias de conexão do recurso Azure Cosmos DB para PostgreSQL no portal do Azure. Na página Cadeias de conexão, você pode selecionar o nó desejado na lista suspensa Mostrar cadeias de conexão para e, em seguida, copiar a cadeia de conexão apropriada, que pode ser usada para se conectar diretamente a nós individuais.
Inspecionar a distribuição da tabela
Para ver como as tabelas são distribuídas entre fragmentos, você pode usar a citus_tables
exibição.
Execute a seguinte consulta no modo de exibição para saber mais sobre as tabelas no
citus_tables
banco de dados do Woodgrove:SELECT * FROM citus_tables;
-[ RECORD 1 ]-------+------------------ table_name | payment_events citus_table_type | distributed distribution_column | user_id colocation_id | 1 table_size | 26 MB shard_count | 32 table_owner | citus access_method | heap -[ RECORD 2 ]-------+------------------ table_name | payment_merchants citus_table_type | reference distribution_column | <none> colocation_id | 2 table_size | 18 MB shard_count | 1 table_owner | citus access_method | heap -[ RECORD 3 ]-------+------------------ table_name | payment_users citus_table_type | distributed distribution_column | user_id colocation_id | 1 table_size | 44 MB shard_count | 32 table_owner | citus access_method | heap
A partir dos resultados, você pode ver que cada tabela distribuída está espalhada por 32 fragmentos, enquanto a tabela de referência está em um único fragmento
payment_merchants
. Você também pode ver o tamanho de cada tabela, o que pode ajudá-lo a decidir quando definir uma tabela como uma tabela de referência em vez de uma tabela distribuída. Embora não haja diretrizes definidas sobre os limites de tamanho de uma tabela de referência, é importante prestar atenção aos tamanhos, porque tabelas maiores não são bons candidatos para definir como tabelas de referência. Com base no tamanho menor da tabela, ela funcionará como uma tabela depayment_merchant
referência. No entanto, você deve ter cuidado de experimentá-lo para mesas que podem ficar muito grandes.Em seguida, observe alguns registros da tabela de estilhaços,
pg_dist_shard
para visualizar informações sobre ospayment_events
fragmentos individuais da tabela. Primeiro, desative a exibição expandida usando o\x
comando.\x
SELECT * FROM pg_dist_shard WHERE logicalrelid = 'payment_events'::regclass LIMIT 5;
logicalrelid | shardid | shardstorage | shardminvalue | shardmaxvalue ----------------+---------+--------------+---------------+--------------- payment_events | 102232 | t | -2147483648 | -2013265921 payment_events | 102233 | t | -2013265920 | -1879048193 payment_events | 102234 | t | -1879048192 | -1744830465 payment_events | 102235 | t | -1744830464 | -1610612737 payment_events | 102236 | t | -1610612736 | -1476395009
A
pg_dist_shard
tabela fornece informações sobre fragmentos individuais, incluindo o intervalo de hash de estilhaços, que o coordenador usa para determinar o fragmento correto para e a partir do qual os dados devem ser gravados e lidos.
Inspecionar a distribuição de dados
Agora, veja como os dados do evento foram distribuídos entre fragmentos consultando a citus_shards
exibição.
Execute esta consulta SQL para examinar os tamanhos de dados dos primeiros 10 fragmentos da
payment_events
tabela:SELECT shardid, shard_name, shard_size FROM citus_shards WHERE table_name = 'payment_users'::regclass LIMIT 10;
Você verá resultados semelhantes à seguinte saída:
shardid | shard_name | shard_size ---------+-----------------------+------------ 102040 | payment_events_102040 | 770048 102041 | payment_events_102041 | 614400 102042 | payment_events_102042 | 647168 102043 | payment_events_102043 | 622592 102044 | payment_events_102044 | 638976 102045 | payment_events_102045 | 638976 102046 | payment_events_102046 | 598016 102047 | payment_events_102047 | 622592 102048 | payment_events_102048 | 729088 102049 | payment_events_102049 | 630784
Observe que, embora alguns dos fragmentos tenham o mesmo tamanho, há alguma variabilidade nos tamanhos de dados. Essas diferenças ocorrem porque o número de eventos para cada único
user_id
não é perfeitamente igual.Para determinar se essas diferenças são distorcidas o suficiente para exigir a execução do rebalanceador de estilhaços, navegue até sua instância do Azure Cosmos DB para PostgreSQL no portal do Azure e selecione Rebalanceador de estilhaço no menu de navegação à esquerda.
Com base na mensagem Rebalanceamento não recomendada no momento exibida, as pequenas diferenças nos tamanhos de dados de estilhaços ainda não são algo que exija o rebalanceamento dos fragmentos no cluster.
Neste exercício, você usou o portal do Azure e consultas em tabelas e exibições de metadados do coordenador para descobrir informações detalhadas sobre seu banco de dados distribuído.
No Cloud Shell, execute o seguinte comando para se desconectar do banco de dados:
\q
Você pode manter o Cloud Shell aberto e passar para a Unidade 6: Entender a execução de consultas distribuídas.