스크립트
00:00:00Parece que todos aqueles desenvolvedores que dizem “ah, mano, usa Postgres pra tudo” estão ainda mais
00:00:04certos com o próximo lançamento do Postgres 19, que inclui suporte nativo a consultas em grafo
00:00:10e esse é um recurso muito legal. Então, no vídeo de hoje, quero cobrir todas as principais novidades
00:00:16do Postgres 19 e também dar uma olhada mais profunda nas consultas em grafo especificamente, porque acho que
00:00:21isso pode mudar fundamentalmente a forma como projetamos nossas consultas e usamos o Postgres.
00:00:30Então, a primeira novidade é algo chamado on conflict do select. Se você quiser inserir uma linha apenas se ela
00:00:35ainda não existir e, de qualquer forma, quiser retornar essa linha como resultado, normalmente você precisaria
00:00:40de duas consultas para isso: um insert e um select, e esse é um fluxo de trabalho muito comum. Então, aqui no exemplo,
00:00:45dizemos que vamos inserir na tabela users o email e o nome, e depois fornecemos esses valores, e então no
00:00:50final dizemos on conflict para email do nothing returning star. O do nothing não te retorna nada quando a linha
00:00:56já existe, então você complementa com um select, mas juntos isso não é atômico. Com o 19, você pode fazer isso
00:01:03com apenas uma consulta. Insert into users fornecendo o email e o nome, e então dizemos on conflict email do select
00:01:11returning star. E se você quiser modificar na mesma consulta, podemos dizer insert into users e depois fornecemos
00:01:16os valores novamente on conflict para o email do select for update returning id and name. E como é uma única
00:01:23instrução, ela é atômica: você a insere ou a seleciona todas as vezes, e como este é um caso de uso
00:01:29muito comum, vai ser extremamente útil. Então o próximo assunto são os grafos, mas se você está curtiu isso, então
00:01:34por que não se inscrever no Better Stack para ficar por dentro das novidades em tecnologia. Agora, como eu disse antes, este
00:01:39é o principal recurso na minha opinião. Então digamos que você tenha o esquema normal de uma loja: você tem clientes,
00:01:44pedidos e produtos, além das duas tabelas de junção que conectam tudo isso, e você quer saber qual
00:01:50produto um determinado cliente comprou. Em SQL, isso é uma cadeia de joins em todas as cinco tabelas, e isso é
00:01:56relativamente simples aqui, mas fica bem feio rapidamente para relacionamentos mais complexos. Bem, agora nós
00:02:02podemos consultar tudo isso como um grafo, de modo que aquela sintaxe complexa de join agora se torna uma nova sintaxe de grafo. E
00:02:08com joins complexos em particular, você vai ver um benefício muito grande aqui. Então estamos dentro do nosso visualizador
00:02:14de banco de dados aqui e você pode ver que temos todas as nossas tabelas: produtos, pedidos, eventos,
00:02:20temos clientes também e depois temos as tabelas pivô para conectar todos esses dados. Então temos itens do pedido
00:02:25e pedidos de clientes, e agora vamos tentar executar uma consulta em todas essas tabelas. Então digamos, por exemplo,
00:02:30que eu tenho esta usuária aqui chamada Alice, e quero descobrir todas as coisas que a Alice pediu. Para fazer
00:02:35isso, eu teria que passar por várias consultas de join diferentes para conectar todas essas tabelas. Então eu executaria esta
00:02:41consulta que tem quatro instruções de join separadas nela, e embora isso não seja necessariamente difícil
00:02:46de escrever, é muito feio. Mas se executarmos isso, podemos ver todas as coisas que a Alice
00:02:51pediu: o teclado mecânico e o mouse ergonômico. Mas agora podemos usar a sintaxe de grafo para simplificar massivamente
00:02:57isso. Então vamos substituir tudo isso pela nova sintaxe de grafo e executar novamente, e você
00:03:03pode ver que obtemos os mesmos resultados. E se alinharmos tudo isso, começa a ficar mais fácil de ler, então você pode ver
00:03:07que estamos indo apenas de clientes para pedidos de clientes, para pedidos, para itens de pedidos e para produtos. Então você
00:03:13pode basicamente seguir esse fluxo simples para percorrer todo o grafo, o que, na minha opinião, é muito, muito
00:03:19mais fácil de ler. Se você quiser selecionar várias colunas também, podemos fazer isso: temos a mesma
00:03:23consulta em grafo na parte superior aqui, mas podemos definir colunas na parte inferior e selecionar todas as
00:03:27colunas que queremos exibir. Ao executar isso, obtemos os resultados na parte inferior. Ora, nada disso
00:03:32vai funcionar a menos que tenhamos criado o grafo em primeiro lugar, então a consulta que usei para
00:03:37gerar esse grafo está aqui: dizemos create property graph e damos a ele um nome, my shop, e depois
00:03:42descrevemos as tabelas de vértices, que serão clientes, pedidos e produtos, ou seja, estas são as
00:03:47coisas que realmente armazenam os dados, e então temos as tabelas de arestas, que são os elementos que
00:03:52efetivamente fazem as conexões, ou seja, as tabelas pivô. No nosso caso, seriam pedidos de clientes e itens
00:03:57do pedido, e a sintaxe para isso é super simples: dizemos que para pedidos de clientes a origem são os clientes e o
00:04:02destino são os pedidos, e para itens do pedido a origem são os pedidos e o destino são os produtos. Com
00:04:08isso configurado, o Postgres agora saberá, toda vez que executarmos uma consulta em grafo, como esses relacionamentos
00:04:14estão definidos. Para isso funcionar, você precisa criar um grafo, mas isso não cria novas tabelas nem nada,
00:04:19você apenas aponta para as cinco tabelas que você já tem: as três que realmente armazenam os dados se tornam
00:04:23vértices e as duas tabelas de junção se tornam as arestas. Funciona muito mais como uma visão (view), então o seu esquema anterior
00:04:29permanece completamente inalterado, você apenas ganha essa funcionalidade adicional por cima. Então aqui vamos
00:04:35dizer create property graph, vamos chamá-lo de my shop e começar a descrever como esse relacionamento
00:04:40realmente funciona, e é aqui que fazemos todo o trabalho para o grafo, o que significa que as consultas
00:04:45podem ser muito, muito mais enxutas do que a respectiva sintaxe de join. Então, isso é um substituto para o Neo4j? Bem, se você quer um
00:04:52banco de dados de grafos porque precisa de armazenamento e desempenho de percurso em grafos, então não, um banco de dados de grafos
00:04:58especializado ainda é provavelmente a melhor escolha. Mas se você quer isso porque escrever joins de 10 tabelas
00:05:03em SQL é penoso e feio, então isso certamente vai te beneficiar e será muito mais agradável
00:05:09em comparação. O terceiro novo recurso é o repack, e este trata de recuperar espaço em disco. O Postgres
00:05:15nunca atualiza uma linha no mesmo lugar, ele grava uma nova versão e deixa a antiga para trás, e o vacuum apenas
00:05:21marca esse espaço morto como reutilizável, de modo que o uso do seu disco nunca diminui de fato. O repack reescreve a tabela inteira
00:05:27em um arquivo novo, sem nenhum espaço desperdiçado, e é isso que devolve o espaço para
00:05:33o sistema operacional. Na verdade, você já podia fazer isso com o vacuum full, mas isso bloqueia a tabela
00:05:38durante toda a reescrita, então para qualquer coisa massiva você simplesmente nunca executa isso, e é por isso que as pessoas instalavam
00:05:42extensões como o pg_repack. Mas agora temos isso integrado diretamente ao Postgres: use a palavra-chave concurrently com
00:05:49isso e ela mantém a tabela legível e gravável enquanto o repack trabalha. Uma coisa a observar aqui, no entanto:
00:05:54você precisa de espaço em disco livre suficiente para uma segunda cópia da tabela e de todos os seus índices, então você precisa
00:06:00desse espaço livre para poder recuperar mais espaço. Portanto, este não é um substituto exato para o pg_repack, mas para
00:06:06uma tabela normal, ele cumpre o papel sem a extensão. Certo, agora vamos fazer uma rodada rápida
00:06:11com os recursos restantes da versão 19. O primeiro são as dicas de consulta (query hints): o Postgres decide como executar sua
00:06:17consulta e pode mudar de ideia ao longo do tempo, então uma consulta que esteve boa por um ano de repente fica lenta
00:06:22e nada mudou no seu código. Um novo módulo chamado pg_plan_advice permite capturar o plano enquanto ele
00:06:28ainda está rápido e fixá-lo para que permaneça sempre assim. O JIT agora está desativado por padrão: o Postgres compila consultas pesadas
00:06:36em código de máquina, mas decidia quando valia a pena com base na estimativa de custo do planejador, e as notas de lançamento
00:06:41dizem que esse cálculo de custo era na verdade pouco confiável, então ele acionava o JIT em consultas que não
00:06:46precisavam dele. Além disso, o vacuum agora pode limpar seus índices com vários workers em paralelo, gastando menos tempo
00:06:52fazendo o vacuum em uma tabela grande, embora você precise ativar isso manualmente. Sabe quando você adiciona uma coluna para
00:06:58fazer um select e depois precisa adicionar a mesma coluna no group by também? Ele faz tudo isso por você,
00:07:03e a palavra-chave copy agora pode exportar diretamente para JSON, então se você vinha despejando CSV e convertendo
00:07:09depois, pode parar de fazer isso. Então esse é o Postgres 19 Beta 2, lançado em julho, e a versão final
00:07:15é esperada por volta de setembro ou outubro, então se você está rodando algo mais antigo, vale a pena baixar o beta
00:07:21e testar com ele agora. E se você quiser ver mais sobre o Postgres, pode conferir
00:07:25uma análise do PG Durable, que coloca fluxos de trabalho duráveis diretamente dentro do Postgres. Eu sou o Warren,
00:07:31do Better Stack, obrigado por assistir e nos vemos no próximo!