Exercício - Tabelas de metadados do coordenador de consultas para compreender a distribuição de dados

Concluído

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

  1. Navegue até o recurso do Azure Cosmos DB for PostgreSQL no portal do Azure.

  2. No menu de navegação à esquerda, selecione Cadeias de conexão em Configurações e copie a cadeia de conexão rotulada psql.

    Screenshot of the Connection strings page of the Azure Cosmos DB Cluster resource. On the Connection strings page, the copy to clipboard button to the right of the psql connection string is highlighted.

  3. 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 o citus cluster. Copie a cadeia de conexão atualizada para uso abaixo.

  4. 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.

    Screenshot of the Cloud Shell icon on the Azure portal toolbar and a Cloud Shell dialog is open at the bottom of the browser window.

    O Cloud Shell será aberto como um painel incorporado na parte inferior da janela do navegador.

  5. Se necessário, selecione Bash como o ambiente na janela do Cloud Shell.

    Screenshot of the welcome page of Azure Cloud Shell with a prompt to choose an environment between Bash or PowerShell. Bash is highlighted.

  6. 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.

  1. 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.

    Screenshot of the Overview pane in the Azure portal.

    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.

  2. 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;
    
  3. 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
    
  4. 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.

    Screenshot of the Connection strings page of the Azure Cosmos DB for PostgreSQL resource is selected in the Azure portal. On the Connection strings page, the 'Show connection strings for' drop-down list is highlighted and a worked node is selected and highlighted. The psql connection string's copy to clipboard button is highlighted.

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.

  1. 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 de payment_merchant referência. No entanto, você deve ter cuidado de experimentá-lo para mesas que podem ficar muito grandes.

  2. Em seguida, observe alguns registros da tabela de estilhaços, pg_dist_shardpara visualizar informações sobre os payment_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.

  1. 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.

  2. 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.

    Screenshot of the Shard rebalancer menu item, and the Shard rebalancer page for the database is displayed in the Azure portal.

    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.

  3. 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.