Aprendendo a administrar o PostgreSQL: por onde começar

Momento nostalgia 

(Pule esta parte se você quiser ir direto ao assunto)

Os primeiros artigos deste site datam lá dos idos de 2004, uma época em que havia uma efervescência em torno do conceito de “Software Livre”, que depois acabou definhando em favor do conceito de “Código Aberto”. Naquela época, as pessoas acompanhavam diariamente as postagens do BR Linux (que existe desde 1996). Eventos pipocavam para todos os lados, como o FISL e o CONISLI, que traziam milhares de pessoas de todo o país para assistir. A décima edição do FISL, em Porto Alegre, chegou a trazer mais de 10 mil pessoas, um feito e tanto. 

O site do Savepoint mudou de endereço algumas vezes de lá para cá, trocou de ferramenta, de hospedagem etc. Algumas postagens se perderam, outras foram apagadas deliberadamente, e hoje a primeira postagem do site é justamente a “Carta de Santo André”, um documento redigido no “I Fórum Regional de Software Livre do ABCD”, do qual tivemos a honra de participar e ajudar a organizar. 

O projeto

Em 2006, escrevemos um artigo que fez muito sucesso na época e foi um dos mais populares neste site: “10 dicas para começar a usar o PostgreSQL”. Embora boa parte das ideias permaneçam válidas, muito tempo se passou, e a nossa experiência com o PostgreSQL já soma mais de 20 anos… então resolvemos reeditar este artigo. Na verdade, queremos fazer um pouco mais que isso. Vamos oferecer aqui um tutorial, passo a passo, para você aprender a brincar/trabalhar/se aventurar/sofrer/ficar milionário/mudar o mundo usando o PostgreSQL.

A ideia é focar mais no trabalho de administração do PostgreSQL, o que pode ajudar não apenas quem quer se tornar um DBA (DataBase Administrator) PostgreSQL, mas também quem trabalha como administrador de sistemas ou desenvolvedor e, eventualmente, tenha que cuidar de um servidor PostgreSQL.

Este artigo é apenas o nosso ponto de partida. Nosso objetivo é escrever um artigo por semana e, se tudo der certo, em breve teremos praticamente um manual sobre como administrar o PostgreSQL. Poderíamos fazer tudo isso em vídeo, podcast, vender um curso numa plataforma digital ou seja lá o que for, mas resolvemos utilizar o suporte do texto e abrir todo o conteúdo aqui, sem enrolação, sem cadastro, sem burocracia. E fazemos assim por alguns bons motivos:

  • Somos preguiçosos: fazer vídeo, editar etc. e tal dá trabalho pra caramba. E pelas nossas contas, temos uma longa jornada pela frente. Serão algumas dezenas de artigos, isso dá muito trabalho, e manter o ritmo de uma postagem por semana é um desafio razoável. Tanto que já começamos bem antes desta primeira postagem, estamos escrevendo desde janeiro e começamos a postar só agora em maio;
  • Queremos que mais pessoas aprendam a mexer com o PostgreSQL: acreditamos no compartilhamento do conhecimento. O formato aberto ajuda o Google a indexar o conteúdo e torná-lo mais popular. Acreditamos no círculo virtuoso, em que mais pessoas utilizando o PostgreSQL vai beneficiar a sociedade como um todo, no bom e velho espírito hacker que acompanha a comunidade de Software Livre até hoje;
  • Nossa intenção não é ganhar dinheiro vendendo cursos: como escrevemos na descrição do site, acreditamos no modelo de mentoria, em aprender fazendo, lidando com problemas reais;
  • É muito mais fácil acompanhar textos do que vídeos: você não precisa parar o vídeo para digerir um conceito ou anotar alguma coisa. Você lê no seu ritmo e pode copiar e colar os exemplos a qualquer momento diretamente do site (esperamos que você faça isso muitas vezes e teste por si mesmo).

A última coisa que gostaríamos de comentar antes de ir direto ao assunto é que esta série de artigos está sendo escrita, neste momento, por três pessoas, não apenas uma. E por isso estamos sempre adotando a terceira pessoa do plural. A maioria dos artigos está sendo escrita pela Ludmila, que entrou na equipe da Savepoint em janeiro de 2024. Conforme ela vai estudando um pouco mais sobre PostgreSQL, ela vai escrevendo novos artigos sobre o assunto. Um artigo ou outro será escrito pelo Fábio, mas na verdade ambos escrevem coisas juntos e dão pitacos no texto um do outro. Por fim, temos a Carol, que revisa todo o nosso trabalho antes de publicarmos e dá umas dicas para não passarmos vergonha aqui na internet e irmos melhorando a qualidade do que escrevemos com o tempo.

Mãos à obra!

Então chega de enrolação e vamos iniciar com 10 dicas para você começar a aprender a administrar o PostgreSQL:

  1. Aprenda inglês 

Isso mesmo, não adianta me xingar. Precisa aprender a ler em inglês. E você vai fazer isso praticamente todos os dias se pretender ser um profissional minimamente qualificado em informática. Essa era a primeira dica lá atrás em 2006 e continua sendo a nossa primeira dica. Tecnologia é um troço que avança muito rápido. Todo ano sai uma versão nova do PostgreSQL, e você precisa ir se atualizando. Ninguém tem pique de traduzir a documentação para várias línguas (já tentaram, mas a maioria desistiu, inclusive os brasileiros). Os conceitos mais genéricos e os livros clássicos você vai encontrar em português. Mas quando quiser se aprofundar, vai descobrir que está tudo em inglês mesmo. 

  1. Conheça seu itinerário

Tem um site ótimo que recomendamos: o Roadmap, que dá uma noção de passos para aprender uma tecnologia ou seguir uma carreira em TI. Eles têm um modelo só para quem quer aprender a Administrar o PostgreSQL. Foi bem interessante notar que, depois de rascunhar os artigos para o nosso projeto, boa parte dos tópicos que selecionamos está contemplada nesse mapa. No entanto, gostaríamos de destacar algumas questões importantes. Há várias carreiras associadas à ideia de bancos de dados, que não obrigatoriamente envolvem a carreira de DBA ou Administrador de bancos de dados. 

  • Administrador de dados: este ninguém lembra mais, mas era o guardião do modelo de dados de antigamente, que lidava com enormes diagramas entidade-relacionamento, o DER, quando as pessoas desenhavam os bancos de dados sem olhar diretamente para as classes da aplicação, em outros tempos; 
  • Engenheiro de dados: este é o cara do flow! A pessoa que passa a vida brincando de ETL (Extrair, Transformar e Carregar), ou seja, trazendo dados de várias fontes para juntar tudo em um Data Lake, Data Warehouse, Data Mart ou seja lá qual for o buzzword do momento, para alguém consumir esses dados e apresentar para o chefe;
  • Cientista de dados e/ou Analista de dados: sabemos que não é exatamente a mesma coisa, mas é parecido. Aqui estão as pessoas que pegam os dados bonitinhos que o Engenheiro de dados arrumou (se essa pessoa realmente existir, senão ele mesmo vai ter que botar a mão na massa) e vão vira-los do avesso em busca de tendências, descobertas e viagens astrais. Gosto de pensar que profissionais dessa área se dão muito bem quando têm outras carreiras que se misturam com TI, como medicina, economia, ciências sociais etc.;
  • Desenvolvedor, programador etc.: alguém tem que popular esse banco de dados, certo? Os dados vêm de algum lugar e esse lugar (na maioria das vezes) é uma aplicação. E por mais que os frameworks e ORMs sejam cada vez mais poderosos, o desenvolvedor deveria conhecer uma boa dose da linguagem SQL. Afinal, a inteligência artificial forte ainda está longe de chegar lá, e essas ferramentas fazem coisas tenebrosas quando precisam ir além de telinhas de cadastro e operações CRUD habituais. Ok, existem ferramentas que até se esforçam para fazer um trabalho melhor, mas vira e mexe alguém vai ter que sujar as mãos de SQL para fazer algo mais eficiente. O mundo agradece!

Cada uma dessas carreiras tem características próprias. O DBA tem suas peculiaridades. Mesmo com o avanço da nuvem e os serviços gerenciados de bancos de dados conhecidos como DBaaS (Database as a Service) ou PaaS (Plataform as a Service), o DBA continua sendo uma função importante para ajustar bem o banco de dados e evitar o caos antes que a empresa pare. Então respire fundo e avalie se este é o caminho que você deseja seguir. O DBA é o sujeito que fica lá espremido entre o Desenvolvedor, o Engenheiro de dados e o Administrador de sistemas.

  1. Aprenda mais sobre hardware

É sério isso? Em 2024, com as nuvens dominando tudo e todos, você acha que é preciso estudar mais sobre uma camada que está cada vez mais virtualizada? Sim. Até o momento sim. Pode ser que um dia isso mude, mas entender um pouco mais sobre hardware é fundamental para compreender o comportamento de um banco de dados. Para avaliar o desempenho de um banco de dados, você precisa minimamente saber qual é o hardware que está embaixo do capô. CPU, memória, discos e rede são componentes que serão avaliados o tempo todo, e você precisa ter noção do que está comparando em cada cenário. Todo DBA deve ter bons conhecimentos nessa área, especialmente sobre discos. Discos, storages, controladoras, RAIDs físico e lógico e, depois, entrando na parte de SO, a coisa continua com particionamento, LVM, sistemas de arquivos etc. Sim, com as nuvens as coisas mudaram um pouco, e agora você tem que aprender como funciona cada block storage, de cada fornecedor de nuvem. Tá fácil viu?!

  1. Aprenda mais sobre Linux

Assim como é importante aprender sobre hardware, aprender sobre Linux também é fundamental. O Linux é de longe o sistema operacional mais utilizado em servidores. O PostgreSQL não nasceu em Linux (nasceu no FreeBSD e ainda tem muita gente que roda o PostgreSQL nele) e funciona praticamente em qualquer sistema operacional que dê conta de um banco de dados, seja Unix, Windows, MacOS etc. No entanto, o Linux é a plataforma que veio para ficar e não deve sumir tão cedo. Lide com isso!

  1. Aprenda e goste de SQL

Não sei se precisa explicar muito. Talvez há uns anos atrás, lá no final dos anos 90, você tenha acreditado que os bancos de dados orientados a objeto iriam dominar o mercado (alguém aí lembra do Caché?), depois veio a onda do NoSQL, e outras ondas virão. Os bancos de dados relacionais não são a única opção, nem dão conta de necessidades específicas, mas vieram para ficar, desde os anos 70. Então é importante aprender sobre modelagem de dados do ponto de vista relacional e linguagem SQL. Ponto-final. Se você não gosta…

  1. Aprenda a olhar debaixo do capô

Trabalhar como DBA, em geral, é aprender a lidar com três aspectos do banco de dados: desempenho, segurança e custo. E se você mora no Brasil, o custo importa muito. Se você quer um ambiente rápido, seguro e de baixo custo, vai ter que abrir a tampa do capô e entender como as coisas funcionam lá embaixo. Isso significa aprender a fazer as coisas manualmente e entender quando utilizar uma ferramenta simplifica a sua vida e quando isso não é uma boa ideia. Significa também aprender a fazer tudo o que você faz numa ferramenta gráfica usando o terminal, lá no shell do Linux, ou usando o psql. Pode parecer assustador, mas muita gente acha bem divertido!

  1. Conheça a documentação oficial do PostgreSQL 

Parece um tanto cafona dizer isso, eu sei. Acontece que temos tantas fontes de informação, tantos fóruns, blogs, vídeos no YouTube e se bobear até no TikTok demonstrando como funciona A ou B, que você pode ter preguiça de olhar na documentação oficial. Talvez você até prefira perguntar diretamente para uma ferramenta de Inteligência Artificial, como um ChatGPT da vida. Está valendo, nada contra, mesmo porque a documentação pode ser meio áspera quando o assunto é completamente novo para você. No entanto, a documentação é uma fonte de referência imprescindível. Você nunca deve confiar apenas em uma fonte que não seja a documentação oficial da versão correta do PostgreSQL que você está utilizando. Lembre-se: a documentação é a sua fonte primária para entender como o PostgreSQL funciona. Todos os anos surgem novas versões do PostgreSQL, com novas funcionalidades e mudanças de comportamento em alguma coisa que já existe. É muito provável que a sua busca pela internet não leve isso em consideração e você esteja lendo um artigo sobre algo que não funciona mais assim. É por isso que colocamos links para a documentação em todos os nossos artigos. Assim, você pode conferir mais detalhes sobre o assunto, verificar se alguma coisa mudou entre a data da nossa publicação e a data em que você está lendo este artigo e pode até encontrar algum erro no nosso texto.

  1. Conheça a comunidade de PostgreSQL

O PostgreSQL é um banco de dados de código aberto. Existem outros bancos de dados com código aberto por aí, com maior ou menor sucesso. No entanto, vale lembrar que nem todos os projetos de código aberto funcionam da mesma forma. Josh Berkus, um dos “Hackers Eméritos” do PostgreSQL, escreveu um artigo anos atrás, que traduzimos aqui, listando 5 tipos de projetos de código aberto. Ocorre justamente que alguns projetos são controlados firmemente por uma pessoa ou por uma empresa. Já o PostgreSQL é 100% controlado por uma comunidade. Ele não pode ser comprado ou vendido. Todo o processo acontece publicamente sob regras claramente definidas. Você pode acompanhar ou participar do desenvolvimento se quiser, com código, testes e outras tarefas como organização de eventos, apoio em infraestrutura, divulgação, tradução etc. Como toda comunidade, ela tem problemas e virtudes. Participar da comunidade do PostgreSQL é uma aventura que recomendamos enfaticamente. Tudo começa com uma visita demorada ao site oficial em postgresql.org. E talvez você goste de conhecer mais alguns links aqui e ali:

  1. Descubra o seu jeito de aprender

Cada um tem o seu jeito de aprender. Tem gente que gosta de colocar a mão na massa o mais cedo possível e ir fuçando, para depois estudar mais a teoria, ou ler a documentação dos pontos específicos. Há aqueles que gostam de criar um projeto pessoal, para desenvolver e ir estudando conforme as dificuldades aparecem. Há quem prefira comprar um bom livro como referência, ler tudo e só depois começar a brincar. Há toda uma nova geração de pessoas que se acostumaram a estudar vendo vídeos na internet. Temos cursos de todos os tipos por aí. A Savepoint oferece mentoria para empresas e pessoas também. Os artigos que vamos apresentar aqui podem ser lidos numa ordem lógica, ou você pode consultar um artigo específico para lidar com um assunto determinado que você precisa tratar no momento. Sem problemas, é com você. Mas é importante lembrar mais uma vez que, independentemente da fonte que você utilizar, sempre consulte, como base de referência, a documentação oficial para a versão exata do PostgreSQL que você está usando. Vamos deixar aqui mais alguns links com boas fontes de informação para você estudar (sim, todos em inglês):

  1. Amplie os seus horizontes

A carreira de DBA sempre foi considerada uma carreira nobre em TI. Hoje em dia, já existem alguns cursos de nível superior ou mesmo de pós-graduação dedicados à área, mas hoje o banco de dados deixou de ser uma peça central para dar lugar a uma complexidade maior. O que antes era trabalho de um único profissional, atualmente já se ampliou para funções mais específicas como o Cientista de dados e o Engenheiro de dados. O DBA ainda é vital e importante, mas ele agora faz parte de um cenário mais amplo, e muitas coisas estão mudando rapidamente. Respire fundo e pense nos horizontes que você pode precisar se envolver dentro dessa área:

  • A Lei Geral de Proteção de Dados (a nossa LGPD), e inúmeras outras legislações internacionais ou específicas para cada área de atuação, impõe novos desafios para o DBA. Quem pode acessar o que e quando? Como testar a aplicação com dados factíveis, sem expor dados reais? Temos todo um processo de embaralhamento, mascaramento ou encriptação de dados, sendo mais uma tarefa delicada para lidar no dia a dia. E cada coluna de cada tabela pode ter um requisito diferente nesse aspecto. Só aí já tem diversão para todo mundo!;
  • Os servidores estão migrando para a nuvem. No começo, eram os data centers que ofereciam um lugar para você hospedar o seu servidor, o “colocation data center”, depois vieram os fornecedores de nuvem com o IaaS ou infraestrutura como serviço, em que você pode alugar uma máquina inteira, já com o sistema operacional instalado, ou uma máquina virtual e hospedar os seus serviços. Cada vez mais as pessoas estão adotando uma nova onda que é o PaaS ou Plataforma como serviço para banco de dados, alguns também chamam de DBaaS ou Banco de dados como serviço. Nele, você aluga um banco de dados já instalado e configurado pronto para rodar, com backup, monitoramento e opções de alta disponibilidade. A última onda é rodar seus bancos de dados em containers, utilizando operadores Kubernetes e bancos de dados serverless. Se bobear, quando você estiver lendo este artigo, já é capaz de as coisas terem ido ainda mais longe! E, sim, a camada de armazenamento (estamos falando de discos ou seja lá o que vai aparecer por baixo do capô) continua sendo um ponto sensível nesse processo;
  • Novos tipos de armazenamento estruturado surgem com bancos NoSQL ou bancos mais especializados em tarefas específicas como Data Science, Data Lake, Data Warehouse, Time Series, Cache etc.;
  • A área de dados está cada vez mais abrangente. A explosão de dados cunhou a onda do Big Data, com bases gigantescas, cargas de dados monstruosas e aplicações em tempo real. A onda dos dados semiestruturados também veio para ficar, assim como novos formatos de documentos armazenados em bancos de dados, primeiro com o XML, depois com o JSON. Outros formatos vêm ganhando popularidade, como o TOML, o CSON e o YAML. Será que vão inventar esses novos tipos em bancos de dados para eles também?
  • Grandes projetos têm grandes equipes e dividir o trabalho delas fica mais fácil quebrando monólitos em microsserviços, em que cada parte da aplicação tem seu microsserviço com o seu correspondente banco de dados. Assim, ao invés de um único banco de dados centralizado, é comum termos vários bancos menores independentes. E como cada serviço é especializado, vale a pena utilizar um banco de dados especializado para cada situação. É aí que falamos em “persistência poliglota”, com vários tipos de bancos de dados convivendo lado a lado. O PostgreSQL e os bancos de dados relacionais continuam sendo provavelmente a peça mais importante do jogo, mas há várias situações em que outras soluções vão atender melhor em casos específicos, como em dados hierárquicos, por exemplo;
  • E a turminha do DevOps? Sim, demorou, mas isso bateu lá na turma de DBAs. Deploy e gestão de configuração agora têm que ser um trabalho muito mais automatizado e controlado. Nada de processos manuais, sujeitos a falhas. Hoje em dia, saber lidar com ferramentas como Terraform, Ansible e a CLI de alguns provedores de nuvem virou requisito para a maioria dos DBAs. Agora junte isso com a nuvem, microsserviços, big data, e vá vendo onde isso vai dar. 

Respire fundo. Você não precisa aprender tudo isso de uma hora para outra. Os desafios vão aparecer aos poucos, e você vai aprender coisas novas diante de cada um deles. Algumas coisas vamos dar uma olhada nos próximos artigos, outras são muito específicas ou complexas para abordar numa simples série de textos. O importante é que você tenha a mente aberta para as novidades que vão surgindo e esteja sempre disposto a aprender coisas novas. Afinal, você escolheu trabalhar com TI, não foi?

Nos vemos nos próximos capítulos…

Bom, por enquanto é isso. Vamos começar a publicar regularmente nossos artigos, uma vez por semana. Fique atento ao nosso site ou às redes sociais que iremos avisar a cada artigo publicado!

Espero que você aprecie essa jornada, tanto quanto nós estamos curtindo criar esse material para você. Dúvidas, sugestões, críticas e comentários são sempre bem-vindos, e como estamos na internet e não publicando em papel… a qualquer hora podemos corrigir ou melhorar alguma coisa aqui e ali.

Compartilhe

Você pode gostar

pg_hba.conf

Introdução O arquivo pg_hba.conf (PostgreSQL Host-Based Authentication) é uma peça fundamental na configuração de segurança de qualquer instância PostgreSQL. Ele define as regras de autenticação

Tuning de SO (no Linux)

Introdução Tuning refere-se ao processo de ajustar e otimizar o desempenho de um sistema, software ou aplicação. A otimização do sistema operacional é uma etapa

plugins premium WordPress