Esta edição da série de podcasts de vídeo do The New Stack, Makers, foi publicada pela primeira vez em novembro. Para saber mais sobre como a Amazon Web Services oferece suporte ao código aberto, confira este episódio do nosso podcast de vídeo, gravado na KubeCon + CloudNativeCon North America.
BILBAO, ESPANHA — Quando o PostgreSQL começou, seus usos eram relativamente específicos, disse Jonathan Katz, da Amazon Web Services, neste episódio de The New Stack Makers.
Hoje, seus usos são generalizados em aplicativos e cargas de trabalho, disse Katz, principal gerente de produto e líder técnico da Amazon RDS e membro da equipe principal da Amazon Web Services no projeto Postgres.
“Quando começou, era bastante nicho”, disse Katz sobre o PostgreSQL, neste episódio On the Road de The New Stack Makers, gravado no Open Source Summit na Europa. “Havia outros sistemas de banco de dados relacionais, tanto de código aberto quanto comerciais.”
Katz passou mais da metade de sua vida trabalhando no Postgres. Seu primeiro envolvimento veio escrevendo SQL e participando de grupos e eventos de usuários. Trabalhou no gerenciamento de lançamento do site e ajudou na organização de eventos.
“Quando me envolvi no projeto, eu era desenvolvedor de aplicativos, apenas escrevia SQL”, disse Katz. “E eu pensei, ‘Oh, legal, as pessoas se envolvem no Postgres, porque escrevem SQL.'”
Bem, as pessoas se envolvem no Postgres porque adoram detalhes internos do banco de dados. “Havia tantos desenvolvedores talentosos trabalhando nisso. Achei que poderia ser mais útil trabalhando no trabalho não relacionado ao desenvolvimento”, disse Katz.
“Tinha experiência em organizar eventos. Na faculdade, organizei eventos de startups. E tentei levar isso para as comunidades de código aberto. Ajudei a organizar o grupo de usuários locais da cidade de Nova York e, finalmente, começamos a organizar um evento anual em torno disso. E foi aí que comecei na comunidade. Porque, embora grande parte da comunidade Postgres opere em listas de e-mail, grande parte do brainstorming e da construção de conexões ocorre nos eventos. Não há substituto para isso.”
O Postgres surgiu de pesquisas acadêmicas na Universidade da Califórnia em Berkeley em meados da década de 1980, criado inicialmente por Michael Stonebraker, pesquisador de banco de dados em Berkeley. Em 1994, o projeto tornou-se oficialmente PostgreSQL e foi lançado como um projeto de código aberto.
Em meados da década de 1990, a era dos bancos de dados proprietários emergiu com players como Oracle (Oracle DB), IBM DB2 e Microsoft SQL. As versões de código aberto que apareceram incluíam MySQL, MariaDB e SQLite.
Hoje, os desenvolvedores usam o PostgreSQL para cargas de trabalho escaláveis. Katz citou um exemplo em que um cliente armazenou mais de 40 terabytes de documentos JSON em um banco de dados Postgres.
Lançado recentemente, o PostgreSQL 16 inclui replicação lógica de servidores standby. E isso ajuda na escalabilidade.
“Se você conseguir descarregar esse trabalho para um modo de espera, que normalmente é menos ocupado, poderá afastar parte desse tráfego do seu primário, e os efeitos poderão escalar ainda mais o seu primário”, disse Katz.
Katz disse que a meticulosidade da comunidade Postgres e o tempo que leva nos projetos levam a recursos mais estáveis e confiáveis.
“Se você olhar para todas as diferentes organizações e indivíduos que contribuem para o Postgres, embora possa não ser uma característica deles, eles estão ativos no design e na revisão e trabalhando para poder comprometê-lo no projeto”, disse Katz.
A E/S direta é um recurso de longo prazo em desenvolvimento, disse Katz. Levará anos para ser implementado. É um problema complexo. PostgreSQL usa Linux para gravar dados em disco usando assíncrono. Agora, fsync, de acordo com Open Groups, “deve solicitar que todos os dados para o descritor de arquivo aberto nomeado por Campos deve ser transferido para o dispositivo de armazenamento associado ao arquivo descrito por Campos. A natureza da transferência é definida pela implementação. O fsync() A função não retornará até que o sistema tenha concluído essa ação ou até que um erro seja detectado.”
As compensações de desempenho tornam-se o problema – há uma camada extra para trabalhar entre o PostgreSQL e o sistema de arquivos ao usar fsync como camada extra. IO direto pode significar menos saltos, latência reduzida e gravação aprimorada em disco.
Mas algumas compensações precisam ser resolvidas e por que levará anos para serem resolvidas.
“Assim que o Direct I/O estiver ativado, isso permitirá um trabalho adicional em torno do desempenho da gravação de dados no disco”, disse Katz.
A AWS criou o Amazon RDS no PostgreSQL para facilitar aos desenvolvedores o desenvolvimento de aplicativos em vez de tarefas operacionais como implantação, backups e monitoramento. Com o suporte, o Amazon RDS oferece suporte a versões do PostgreSQL. Por exemplo, o Amazon RDS oferece suporte ao PostgreSQL 13, 14, 15 e 16.
O Amazon RDS for PostgreSQL fornece tarefas operacionais gerenciadas, como implantação, backups, monitoramento, etc.
“Há muitos recursos diferentes no serviço gerenciado que podem ajudar nas operações comerciais comuns”, disse Katz. “Portanto, alta disponibilidade, backups automatizados contínuos, monitoramento e coisas que simplificam o gerenciamento diário. E para mim, com minha experiência como desenvolvedor de aplicativos, o que é bom nisso é que grande parte do trabalho operacional é feito pelo serviço gerenciado.”
Do Debian à IA de código aberto
Integrando um Data Warehouse e um Data Lake
Status do WebAssembly na computação
Powertools para AWS Lambda cresce com a ajuda de voluntários
Como ser um aliado melhor em comunidades de código aberto
Desenvolvimento de código aberto ameaçado na Europa
YOUTUBE.COM/THENEWSTACK
A tecnologia avança rápido, não perca um episódio. Inscreva-se em nosso canal no YouTube para transmitir todos os nossos podcasts, entrevistas, demonstrações e muito mais.
SE INSCREVER
