Linkedin Instagram

Blog

  • Um pouco sobre a história dos bancos de dados – Parte II

    Os anos 80 foram realmente incríveis, não?

    Na primeira parte falamos sobre as origens dos bancos de dados, passando pelas décadas de 60 e 70. Agora vamos continuar nossa saga pelos anos 80 e 90.

    dBase

    Na década de 80, com o lançamento do IBM PC, os microcomputadores deixam de ser brinquedos e entram em cena como uma alternativa de baixo custo para a informatização de empresas. Assim, surge ainda em 1979 o dBASE. Longe de ter a sofisticação dos bancos de dados relacionais, eles atenderam bem às demandas menores e tiveram muitas outras iniciativas baseadas nele como o Clipper, o FoxPro e toda uma família de clones conhecida como xBase.

    Teradata

    Também em 1979, foi lançado o Teradata, um banco de dados que praticamente criou o conceito de DataWarehouse. O Teradata era vendido como um banco de dados integrado com o hardware e utiliza a arquitetura de cluster do tipo “Shared Nothing” para escalar sua capacidade horizontalmente. Em 2011, o Teradata incorpora capacidades de Big Data com recursos de MapReduce por exemplo.

    O padrão SQL

    Na década de 90, os bancos de dados relacionais passam a povoar os microcomputadores em Unix e Windows também. Nesta época, os bancos de dados no estilo dBase começam a perder popularidade, enquanto os bancos de dados relacionais passam a dominar o mercado. O padrão SQL criado pela IBM é consolidado no ANSI SQL em 1986 e no padrão ISO SQL em 1987. Depois disso, várias versões do padrão ISO SQL são lançados: SQL-89, SQL-92, SQL-99, SQL-2003, SQL-2006, SQL-2008, SQL-2011 e SQL-2016. Nenhum banco de dados relacional incorpora plenamente todo o padrão, nem mesmo o SQL-99 é adotado plenamente, mas nos anos recentes é observado que um número maior de bancos de dados tem sido mais mais aderentes ao padrão.

    Sybase

    Em 1984, o Sybase é criado a partir da experiência com o Ingres. Em 1988, é feita uma parceria com a Microsoft para lançar uma versão do Sybase para o OS/2. Em 1993, a parceria com a Microsoft é desfeita e a Microsoft passa a vender a sua própria versão para o Windows, o MS SQL Server. Em 1996, o nome do banco de dados é trocado para ” Adaptive Server Enterprise” e em 2010 a SAP compra o Sybase. O Sybase teve grande destaque na década de 90 e voltou a se destacar com a aquisição pela SAP que tem utilizado o Sybase em seu ERP.

    MS SQL Server

    As primeiras versões do SQL Server nada mais eram que versões do Sybase portadas para o OS/2, um sistema operacional desenvolvido pela IBM e Microsoft para substituir o Windows, que acabou não vingando. Depois vieram as versões para o Windows NT. Com o rompimento com a Sybase em 1996, o MS SQL Server 6.0 foi a primeira versão lançada sem a mão da Sybase. Nas próximas versões, o código original passa a ser gradualmente reescrito até que no SQL Server 2005, o código original do Sybase já havia sido quase totalmente substituído. O SQL Server cresceu junto com a popularidade das versões do Windows para servidores se tornando o 3º maior banco de dados, logo atrás do Oracle e do MySQL. Recentemente a Microsoft anunciou que as novas versões do MS SQL Server irão rodar também em Linux, algo impensável nos anos 2000, uma vez que a Microsoft foi uma grande opositora ao Linux no passado. O sucesso da Azure, serviço de nuvem da Microsoft também tem ajudado a alavancar o SQL Server no mercado.

    PostgreSQL

    Após sair da universidade de Berkeley em 1982 para tentar comercializar uma versão proprietária do Ingres, o Sr. Michael Stonebraker volta à universidade em 1985 para criar uma versão “post-ingres”. Ele queria reescrever o Ingres do zero, procurando soluções para novos problemas encontrados nos bancos de dados da década de 80. Assim em 1986, nasceu o Postgres, com várias características novas, com destaque para a flexibilidade e capacidade de extensão. Em 1989, foi lançada a primeira versão do Postgres que continuou a ser desenvolvido em Berkeley até 1994, quando a universidade de Berkeley publica o código fonte na internet utilizando a licença livre BSD. O Sr. Michael Stonebraker sai novamente de Berkeley e cria o Illustra, uma versão proprietária do Postgres que em 1997 é comprada pela Informix, que por sua vez foi comprada pela IBM em 2001.

    Em 1994, dois alunos graduados em Berkeley adicionam a linguagem SQL ao Postgres que passa a ser chamado depois de PostgreSQL (embora ainda seja oficialmente aceito o nome anterior, Postgres). A Partir de 1996, ele passa a ser mantido por uma comunidade de desenvolvedores independentes conhecida como PGDG ou PostgreSQL Global Development Group. Devido ao tipo de licenciamento do Postgres, dezenas de versões proprietárias foram criadas com o tempo, mas a versão livre mantida pelo PGDG continua sendo a mais utilizada, sendo hoje o 4º maior banco de dados.

    Arquitetura Client/Server

    Até meados da década de 80, a maior parte das aplicações e bancos de dados rodavam em um único computador, um mainframe ou um mini computador. Com o desenvolvimento dos microcomputadores, surgiram cada vez mais aplicações onde o banco de dados residia num computador de porte maior (como um UNIX ou depois um Windows Server) e a aplicação era distribuída em vários microcomputadores. Os bancos de dados relacionais, ao contrário do dBase, eram bastante eficientes neste tipo de arquitetura. Aplicações em MS Visual Basic e Delphi se alastraram em grande volume. Nessa época, os 3 maiores bancos de dados do mercado eram o Oracle, Sybase e Informix.

    MySQL

    Em 1993, o Sr. David Hughes queria um banco de dados para uma aplicação de monitoramento de rede. Ele queria utilizar um banco de dados relacional com a linguagem SQL. Eles tentaram criar uma interface SQL para o Postgres, que na época ainda usava o QUEL e o chamaram de miniSQL ou mSQL. Mas o Postgres era muito complexo e pesado para a tarefa que eles tinham em mente. Então eles criaram uma versão mais simples de um banco de dados que implementava apenas uma parte do SQL, feito para funcionar em hardwares bastante simples. O mSQL teve grande importância nos primórdios da WWW pois era simples, leve e rápido. Ele foi muito utilizado entre 1994 e 1997, quando foi superado pelo MySQL.

    O MySQL foi criado em 1994 com a primeira versão lançada em 1995. Foi baseado no mSQL e manteve a mesma API, permitindo uma fácil migração do mSQL para o MySQL. O MySQL, teve enorme impacto na internet. A arquitetura LAMP (Linux, Apache, MySQL e PHP), foi o motor da “Internet 2.0”. Com o tempo foram sendo incorporadas novas funcionalidades SQL no MySQL, além de outros Storage Engines,  característica peculiar do MySQL. Em 2008, a MySQL AB, companhia que criou o MySQL foi comprada pela SUN Microsystems. Em 2010, a Oracle compra a SUN. Após MySQL AB ser comprada pela SUN começaram a surgir novos forks do MySQL, movimento que se intensificou quando a Oracle comprou a SUN. Os forks mais conhecidos do MySQL hoje são o MariaDB, Percona Server e mais recentemente o Aurora da Amazon. A Oracle possui hoje os dois maiores bancos de dados do planeta, o Oracle Database e o MySQL.

    O bancos de dados Objeto-Relacional

    Na década de 90, as linguagens orientadas ao objeto como o Java da Sun começaram a fazer muito sucesso. Enquanto a Sun guiava o mercado rumo à internet com seus servidores Sparc e Sistema Operacional Solaris, outras linguagens como PHP, depois ASP, Python e Ruby espalharam a “Internet 2.0” ou a Internet dinâmica, com sites nas quais suas páginas são construídas dinamicamente com base nas informações dos seus bancos de dados. Apesar deste florescimento, os bancos de dados relacionais surgiram na era da programação estruturada. A ligação entre tabelas relacionais nos bancos de dados e objetos nas linguagens se tornou um problema que dificultou a vida dos programadores. Uma das soluções encontradas foi a criação de uma infinidade de ferramentas de ORM (Object Relational Mapping), como o famoso Hibernate. O problema das ferramentas de ORM é que elas funcionam muito bem para telas simples e operações CRUD, mas são um desastre em relatórios e transações complexas.
    A outra solução encontrada foi a criação de bancos de dados que estendem a teoria relacional criada por Codd e criam formas mais naturais de armazenar objetos. O primeiro banco de dados a fazer isso foi o Postgres, já no seu projeto inicial em 1986. Tempos depois, os demais grandes bancos de dados relacionais também criaram extensões objeto-relacionais. Em 1999, é lançado o ISO SQL::1999 que define um padrão para estas extensões objeto-relacionais.

    Houve também iniciativas mais ousadas criando bancos de dados puramente orientados a objetos. O banco de dados que teve maior sucesso nisso foi o InterSystems Caché. Com o tempo, os bancos de dados orientados ao objeto não fizeram tanto sucesso, seja por falta de uma teoria mais robusta para lhes darem sustentação, seja por falta de padronização ou por fim, por não apresentarem um desempenho semelhante aos bancos de dados relacionais. Ainda assim, em situações que manipulam dados complexos, eles encontraram um nicho de mercado.

    Os testes de performance TPC

    No começo da década de 90, os bancos de dados relacionais estavam com seu desenvolvimento a pleno vapor e passaram a estabelecer uma hegemonia global no mercado de bancos de dados. No entanto, cada fornecedor sempre alegou ser melhor que os demais. Os departamentos de marketing sempre foram muito criativos em estabelecer métricas muitas vezes obscuras nas quais o seu produto sempre aparece como líder de mercado. Ao fim e ao cabo, duas métricas poderiam ser facilmente verificáveis entre cada fornecedor: preço e desempenho.

    Infelizmente, a história não é tão simples assim. Os custos de manutenção de um banco de dados podem envolver diferentes custos de licenciamento, suporte, compra de hardware, etc. Pior que isso é comparar o desempenho dos diferentes bancos de dados com um conjunto de operações idênticas que se assemelhem com a carga que um banco de dados recebe no dia-a-dia. Por fim, ainda existe um detalhe delicado: a licença de uso da maioria dos bancos de dados comerciais não permite que você publique o resultado de testes de performance sem a autorização do seu fornecedor. Tudo isso torna muito complicada a tarefa de escolher qual banco de dados suporta determinada carga e qual o custo para suportar esta carga.

    O Transaction Processing Performance Council, ou simplesmente TPC, foi criado com a intenção resolver esta bagunça.  Criaram um teste padrão chamado TPC-A para medir a performance em bases OLTP imitando uma transação bancária. Depois, vieram novas versões com o TPC-B e o TPC-C. A última versão de testes em com carga OLTP foi o TPC-E, um teste mais complexo e completo para os dias atuais. Infelizmente, apenas encontramos testes do MS SQL Server com o TPC-E, portanto não é possível comparar estes testes com outros fornecedores. Também criaram testes para outros tipos de carga como sistemas web, o já aposentado TPC-W, e o TPC-H para datawarehouse, entre outros. Até o começo dos anos 2010 a maioria dos grandes bancos de dados comerciais possuíam testes publicados no site do TPC e eram um recurso valioso para comparar preço e performance de bancos de dados.

    Um dos problemas do TPC era que os bancos de dados livres nunca publicaram um único teste no TPC. Os custos para realizar os testes são muito altos e não temos nenhum teste com MySQL, PostgreSQL ou Firebird por exemplo. Outro problema é que no começo em meados de 2010, alguns fornecedores como a Oracle deixaram de publicar testes no TPC. O último teste com Oracle disponível é um TPC-H de 2014 utilizando Oracle 11G. Portanto, hoje em dia, ficamos sem parâmetros de comparação para preço e desempenho. Acreditar nos dados publicados pelos fornecedores em geral é acreditar em contos de fada…

    Continua na Parte III

  • Um pouco sobre a história dos bancos de dados – Parte I

    Porque a história importa sim!

    Era uma vez um professor de informática que dizia que falar sobre a história da informática era irrelevante e iria passar rápido pela matéria. Só estava fazendo isso porque estava no currículo. É claro que eu tive de discordar. Conhecer a história nos dá uma compreensão melhor de como chegamos até aqui. As coisas nem sempre foram iguais. Muita gente esquece que as coisas mudam, olhar tudo em perspectiva nos faz entender melhor o mundo onde vivemos. Tem gente que se esquece, por exemplo que a prova de que a terra não é plana não veio de uma conspiração da NASA e sim da primeira circunavegação em 1521. Ou que os primeiros computadores surgiram na II Guerra Mundial. Se temos mais de 80 anos do surgimento do ENIAC, muita coisa mudou de lá para cá e alguns episódios curiosos nos fazem entender como chegamos aqui e nos dão algumas pistas do que pode acontecer num futuro não muito distante.

    Os primeiros computadores

    Trabalhar com grandes volumes de informações é um problema da civilização moderna. Organizar um conjunto de livros numa biblioteca ou o estoque de produtos de uma grande loja envolve catalogar, armazenar e ordenar um grande volume de informações. E chega um momento que um grande arquivo de metal não dá mais conta do recado.
    Foi assim que algumas tecnologias modernas surgiram. A grande IBM surgiu com máquinas para processar o censo populacional dos EUA.
    O uso dos bancos de dados em computadores teve que esperar um bocado. No começo, os primeiros computadores eletrônicos  da década de 40 (houve algumas tentativas de computadores mecânicos e também eletromecânicos antes) como o Z3 na Alemanha, o Colossus na Inglaterra e o  ENIAC  nos EUA ainda utilizavam válvulas, tinham uma memória RAM muito limitada e não havia armazenamento em meios magnéticos da forma que conhecemos hoje, sejam fitas ou discos. O que havia nesta época eram os cartões perfurados e alguns tambores magnéticos. Sendo assim, trabalhar com grandes volumes de dados ainda era algo muito complicado.

    Os primeiros bancos de dados

    No final da década de 50 a IBM lançou os primeiros discos rígidos do mercado. Para se ter uma ideia, os discos do IBM 350 RAMAC tinham o tamanho de duas geladeiras, pesava quase uma tonelada, tinham capacidade útil de menos de 4MB e uma durabilidade de 3 mil horas de uso. O desenvolvimento dos discos rígidos na IBM foi inicialmente tímido, uma vez que ela estava ganhando muito dinheiro vendendo sistemas com cartões perfurados ainda. Ao mesmo tempo, na década de 60 os mainframes e também os “mini computadores” conquistaram o mundo dos negócios em grandes empresas e no governo. Logo surgiu uma grande demanda pelos discos rígidos e eles se tornaram mais rápidos, menores, com maior capacidade, mais confiáveis e mais baratos.

    COBOL

    Da mesma forma, no final da década de 50 surgiu a primeira linguagem de programação voltada para o o mundo dos negócios: o COBOL. O COBOL trabalhava com dados num formato posicional, onde os dados eram numerados numa tabela na qual cada campo ocupava um número fixo de caracteres. O COBOL teve enorme impacto na informática apesar das críticas. A sua forma de trabalhar com dados permitiu que aplicações trabalhassem com um grande volume para a época, mas todo o trabalho no controle dos dados era feito diretamente pela aplicação escrita em COBOL, não havia um sistema gerenciador de banco de dados.
    O IDS (Integrated Data Store) foi o primeiro sistema gerenciador de banco de dados escrito para o COBOL criado em 1964 e utiliza assim como nos programas em COBOL o esquema de armazenamento em rede. Os bancos de dados em rede feitos para COBOL foram muito populares em mainframes e mini computadores até meados da década de 80.

    IBM IMS

    No final da década de 60, a IBM novamente entra no jogo para atender uma demanda da NASA, o banco de dados de partes e peças do projeto Apollo. Para isso, cria o IBM IMS (Information Management System) em 1966, com um esquema de armazenamento hierárquico, diferente do COBOL. O IMS tem longa vida dentro da IBM. A última versão do IMS foi lançada em 2015, ou seja, mais de 51 anos depois e continua sendo utilizado até hoje.

    Nascem os bancos de dados relacionais

    Enquanto a IBM estava investindo no IMS,  em 1970 um de seus funcionários, o Sr. Edgar F. Codd, publica um documento intitulado “A Relational Model of Data for Large Shared Data Banks” descrevendo a teoria relacional. A IBM não deu muita bola para o trabalho do Sr. Codd. No entanto, algumas pessoas de outros escritórios da IBM gostaram das ideias e criaram os protótipos IBM IS1 entre 1970 e 1972, o IBM PRTV em 1973 e ainda o IBM BS12 em 1978 (este último chegou a entrar em produção por alguns anos). Fora da IBM, também surgiram outras experiências como o Ingres em 1973 e o MRDS em 1976.

    IBM Db2

    No entanto, foi em 1974 que a IBM cria um projeto chamado System R, para testar as ideias de Codd, no escritório de San José, Califórnia, onde o Sr. Codd trabalhava. Por incrível que pareça, o projeto não foi fiel às ideias do modelo relacional e foi deste projeto que surgiu a linguagem SQL. Isso foi motivo de muitas críticas à linguagem SQL, por ela não ser estritamente relacional. O System R foi comercializado pela primeira vez em 1977. Em 1981, foi lançado como IBM SQL/DS mas só em 1983 foi lançado o Database2 ou IBM Db2.  O Db2 é até hoje o principal banco de dados em mainframes e utilizado principalmente por grandes instituições financeiras para bases transacionais de alta concorrência.

    Ingres

    É claro que a IBM demorou muito para lançar o Db2. E é claro, também, que o peso de tudo que a IBM lança no mercado tinha um peso enorme. O Ingres, criado nos laboratórios da universidade de Berkeley em 1973, criou a linguagem QUEL, baseado os trabalhos de Codd. Os próprios desenvolvedores do System R admitem que o QUEL era superior em vários aspectos em relação ao SQL. Mas o padrão de mercado se tornou a linguagem SQL e o QUEL, mesmo lançado 10 anos antes do DB2, não conseguiu superar o SQL. Apesar disso, como era um projeto com licença de software livre (a licença BSD da universidade de Berkeley), vários outros bancos de dados foram criados na década de 80 baseados no Ingres, entre eles o Sybase e o SQL Server. Em 1980, a Relational Technology, Incorporated (RTI) é criada para comercializar o Ingres. Em 1990 a ASK compra a empresa que por sua vez é comprada pela Computer Associates em 1994. Em 2006, o Ingres tem o código fonte aberto pela Computer Associates e em 2011 é comprada pela Actian Corporation.

    Oracle

    A Oracle, começou os trabalhos na mesma época, mas derivou seu banco de dados diretamente dos trabalhos do Ingres e do System R. A ideia era fazer uma versão compatível com o System R, mas não foi possível, pois a IBM escondeu alguns detalhes da implementação como os códigos de erro. Apesar de lançar sua primeira versão 5 anos depois do Ingres, utilizaram a linguagem SQL que futuramente se tornaria a linguagem padrão para os bancos de dados relacionais. A primeira versão (chamada de v2, por uma questão de marketing) foi lançada em 1979, mas foi só em 1983 com o lançamento da v3 e a reescrita do Oracle na linguagem C que ele começa a se tornar viável e ganhar o mercado, junto com uma campanha agressiva de marketing, claro. Na metade da década de 80, a Oracle derruba o seu maior competidor o Ingres. Em 1992, com a versão 7 a Oracle assume contornos mais conhecidos na maioria dos bancos de dados relacionais atuais com a implementação do PL/SQL, gatilhos, Foreign Keys, particionamento de tabelas e as consultas paralelizadas.

    Em 2008 a Oracle firma uma parceria com a HP e lança o Exadata, integrando o hardware e software num único produto com alta performance e inovações na relação entre storage e banco de dados. Em 2010 a Oracle compra a Sun e passa a desenvolver o Exadata sozinha, sem a HP. Em 2013 a Oracle cria sua própria nuvem, porém ainda se encontra muito atrás dos seus principais competidores: Amazon, Azure e Google.

    Hoje, o valor de mercado da Oracle é maior que o da própria IBM, sendo considerada a 6ª maior companhia de TI do planeta. Vale à pena lembrar que na década de 70 a IBM era disparada a maior companhia de TI do planeta.

     

    Até breve…

    • Na parte II iremos explorar um pouco dos anos 80 e 90, onde vamos comentar o padrão SQL, o surgimento do Teradata, dBase, Sybase, MS SQL Server, Postgres, MySQL, testes TPC e até sobre bancos de dados orientados a objeto.
    • Na parte III vamos entrar no novo milênio com bases NoSQL e vamos especular um pouco sobre o futuro.

    Observação: Para quem não sabe, a imagem no início do texto, é da unidade de discos do IBM RAMAC 350.

    Atualização: Fiz algumas correções em 26/10/2017, agradeço aos comentários!

     

  • Removendo registros idênticos no PostgreSQL

    Eu sei, em teoria toda tabela deveria ter uma chave primaria e registros jamais poderiam ser duplicados. Mas a vida é uma caixinha de surpresas…. em algumas situações bem peculiares, você pode precisar de uma tabela sem uma PK, como numa área intermediária para a carga de dados. Estes dias a pergunta aparecer na lista do PGBR e eu resolvi mostrar aqui a solução:

    
postgres=# create table teste (t integer);
CREATE TABLE
postgres=# INSERT INTO teste VALUES (1), (2), (2), (3), (4);
INSERT 0 5
postgres=# SELECT * FROM teste;
t
---
1
2
2
3
4
(5 rows)

    Note que os registros de número ‘2’ são idênticos e não temos como diferecia-los olhando apenas para os dados. A única diferença entre eles é o local onde estão armazenados no disco. E o campo que informa onde eles estão fisicamente armazenados se chama CTID, e ele tem um tipo de dados peculiar que é o TID. Um TID é um par de valores que representam o bloco onde e a posição do bloco onde o registro se encontra:

    
postgres=# SELECT ctid, * FROM teste;
ctid | t
-------+---
(0,1) | 1
(0,2) | 2
(0,3) | 2
(0,4) | 3
(0,5) | 4
(5 rows)

postgres=# DELETE FROM teste WHERE ctid = '(0,2)'::tid;
DELETE 1
postgres=# SELECT * FROM teste;
t
---
1
2
3

  • PGConf Brasil 2017

    De 10 a 14 de julho de 2017 vai rolar o primeiro PGConf.Brasil. Um evento focado em PostgreSQL, com 5 palestras, uma por dia, com temas extremamente relevantes para a área.

    Inscreva-se para ter acesso aos 5 dias de palestras incríveis online: https://goo.gl/forms/GG0lS8v3403Z8iTI2

    PALESTRANTES:

    • 10/07: Flavio Gurgel com “Como detectar e corrigir índices corrompidos“
    • 11/07: Bruce Momjian com “Postgres Window Magic“
    • 12/07: Euler Taveira com “Replicação Lógica no PostgreSQL 10“
    • 13/07: Matheus Oliveira com “PostgreSQL no mundo de micro-serviços, a experiência do iFood“
    • 14/07: Álvaro Hernández com “Migrating off of MongoDB to PostgreSQL“

  • Postgres News

    2017 está sendo um ano de grande destaque bombar na comunidade PostgreSQL em todo o planeta e no Brasil não é diferente. Vamos às notícias:

    1. Em janeiro de 2017, o PostgreSQL é eleito em 3º lugar nos destaques do DB-Engines como “Database of The Year“. O PostgreSQL se mantém em 4º no ranking como o banco de dados relacional com uma forte e estável curva de crescimento no ranking.
    2. Depois de ir ao PGConf.Ru em 2016, parece que não consigo mais ver os eventos de PostgreSQL do mesmo jeito. O PGBR foi citado em 2011 como o maior evento de PostgreSQL do planeta, mas agora as coisas chegaram num novo patamar. Não somos mais um bando de nerds aficcionados por tecnologia, o universo se expandiu. Temos empresas de gente grande e eventos enormes rolando em todo o planeta, acompanhe alguns na página de eventos em  https://wiki.postgresql.org/wiki/Events.
    3. Este ano será lançada a versão 10 do PostgreSQL com novas e aguardadas funcionalidades como O particionamento declarativo e a replicação lógica. Acompanhe as novidades no “Programa de Índio” especial sobre o assunto no canal da Timbira, que vai ao ar no dia 14/06.
    4. De 10 a 14 de Julho teremos o PGConf.Brasil com 5 palestras On-Line. O evento organizado pela Timbira é gratuito, só se inscrever no site.
    5. Dias 14, 15 e 16 de Setembro teremos a sétima edição do PGBR, o maior evento de PostgreSQL do Brasil,  em Porto Alegre. As inscrições e a chamada de trabalhos estão abertas!
    6. Novos forks do PostgreSQL surgiram, além da versão famosa do EnterpriseDB, temos também versões próprias do postgres da Postgres Professional e da 2ndQuadrant. Olhando estas versões comercias você pode ver algumas funcionalidades que em breve deverão estar no core do PostgreSQL;
    7. Acha ainda que os forks são um problema? Então saiba que os forks tem esse hábito de voltar para a nave mãe:
      • A Citus Data transformou o CitusDB em uma extensão livre do PostgreSQL;
      • O Bizgres, criado pela Greenplum em 2005, comprado pela EMC em 2010 agora é Pivotal Greenplum baseado no Greenplum Database, 100% open source.
    8. A saga do projeto Postgres-XC que começou na NTT em 2010 parece que enfim está tendo um final feliz com o Postgres-XL com a 2ndQuadrant. Sim, o projeto ganhou fôlego e parece maduro finalmente.
    9. Um projeto que eu vira e mexe fico de olho é o PG-Strom, e se você se interessa por Big Data deveria acompanhar de perto também. Agora, além de utilizar GPU a partir de Foreign Data Wrapper, o projeto conta com complementos interessantes como o PL/GPU e o SSD-to-GPU. Não espere, vai lá e olhe de perto o que o Sr. KaiGai Kohei anda aprontando nas suas horas vagas lá na NEC.
    10. É claro que com tudo isso, a Timbira também cresceu! Como reflexo disso gostaria de destacar:
      • A Timbira inaugurou seu canal no Youtube, com palestras, debates, tutoriais e outros vídeos relacionados ao bancos de dados. Acompanhe o canal e fique atento!
      • Para quem não percebeu, a Timbira está com uma nova identidade visual, e uma presença mais marcante na Internet, com novo site, página no Twtter, Facebook, Instagram, etc.
      • Além do material on-line, o nosso material físico mudou também: cartões de visita, chaveiros, banner, folder, adesivos e novas ideias que ainda vem por aí. Vejam as fotos do stand da Timbira no DBA Brasil 2.0!

    Enfim, muito trabalho pela frente e muito o que comemorar também. Parece que o PostgreSQL está ganhando o reconhecimento que realmente merece no mercado. O resultado é visível em todos os lugares onde vamos. Mérito de todos que acreditaram e contribuem todos os dias para o banco de dados livre mais avançado do mundo!

     

  • SQL = papel & tinta

    Hoje eu me deparei com uma pessoa que perguntava sobre uma ferramenta para ajudar a escrever consultas SQL graficamente. Estava quase respondendo o cara quando lembrei que um dia eu já fui assim.

    O primeiro banco de dados relacional com qual eu já trabalhei foi o Access 2.0. Sim senhores, eu já fiz isso, há muito tempo atrás. E havia uma coisa que eu gostava muito nele que era uma ferramenta gráfica para construir consultas. Você arrastava as tabelas lá, depois os campos e ia colocando propriedades aqui e ali. Eu realmente gostava daquilo, parecia tudo mais simples para mim. Usar SQL puro me parecia muito complexo e desnecessário. Mas as minhas consultas foram ficando mais complexas com o tempo. E eu comecei a brigar com o Access que não entendia o que eu queria fazer. Ele não entendia o que eu queria ou não tinha opções suficientes. Quando eu comecei a trabalhar com PostgreSQL, eu portei meus primeiros sistemas do Access para ele e tive que escrever minhas consultas em SQL.
    Mas o PostgreSQL tem o psql, um cliente em modo texto simples, mas muito poderoso. Ele herda a tradição do shell do Unix de utilizar uma biblioteca conhecida como readline, coisa que o Oracle ignorou por motivos pra lá de obscuros no SQL*Plus. Uma vez que você se acostuma com o readline no shell, passa a imaginar que toda a linha de comando deveria ser assim. E pode ser. O PostgreSQL e o MySQL usam e funciona muito bem. O fato é que em pouco tempo eu passei a escrever SQL bem mais rápido do que eu fazia minhas consultas no Access. Com um bom editor de texto, recortar, colar, copiar e mover se torna muito mais rápido do que arrastar as coisas com o mouse. Também passei rapidamente a fazer coisas mais complexas e eficientes também. O lema do SQL é dizer “WHAT NOT HOW”. Cada consulta SQL antigamente significava todo um programa escrito só para realizar aquela operação. Hoje o otimizador de consultas executa este programa dinamicamente para você. Mas você ainda tem que aprender a comunicar o que quer para o banco de dados. Escrever e estruturar o raciocínio ainda é um exercício de escrita. Saber escrever é tão importante quanto conhecer algoritmos. No caso do SQL você não se preocupa mais com o HOW, apenas com o WHAT. Claro que tive que estudar um também. Recomendo sempre os livros do Joe Celko para quem quer e deve ir além. Alguns clássicos nunca morrem.

    Quando você aprende a escrever SQL de forma organizada, passa a entender melhor como o banco de dados funciona. Existe uma linha de raciocínio que você segue em geral:

    • Escrevo o FROM e digo quais tabelas vão fazer parte da minha consulta, qua a origem das informações envolvidas;
    • Depois escrevo o WHERE e digo quais registros dessas tabelas deverão ser retornados;
    • Após o SELECT digo quais campos vão aparecer no resultado;
    • Somente depois coloco coisas como GROUP BY, HAVING, LIMIT  outras cláusulas, sempre revisando as três etapas anteriores.

    E vejam como a arquitetura do seu banco de dados começa a ser uma preocupação:

    • Quando escrevo o FROM, penso no tamanho das tabelas e as ligações (JOINs) entre elas;
    • Quando escrevo o WHERE, penso nos índices existentes nas tabelas e seletividade dos dados que estou trazendo;
    • Quando escrevo o SELECT, penso na apresentação dos dados para a aplicação, se preciso formatar, calcular  ou agrupar alguns dados.

    Esse tipo de preocupação faz toda a diferença, não apenas para o DBA, mas para o programador também. Não sou radicalmente contra o uso de ferramentas de ORM, nem de bancos NoSQL, mas aprender SQL ainda é um exercício importante de lógica e de arquitetura da sua aplicação. Portanto, pegue papel & tinta ou seu melhor editor de textos…. e mãos à obra!

     

  • DatabaseCast 75: O papel do DBA na nuvem

    No final de 2016 eu fui dar duas palestras no Interopmix e recebi o agradável convite de participar de um DatabaseCast especial, gravado com as pessoas do evento.

    O tópico é quente e bem atual, com a guerra dos grandes provedores da Cloud com Amazon, Azure, Google e o novo azarão, a Oracle! Se o futuro está na Cloud eu não posso afirmar, mas cada vez mais temos clientes que nascem e migram para a Cloud. Bancos de dados na nuvem são um desafio interessante, pois muito do que se fala sobre como novidade não se aplicam a bancos de dados. Então é um caminho que tem muita nova no caminho e muita bobagem também.

    Foi uma honra gravar novamente com os Srs. Wagner Crivelini e Mauro Pichiliani. Também uma grande responsabilidade em gravar ao lado de grandes nomes como Alex Zaballa e Ricardo Portilho.

    Vejam o podcast e deixem seus comentários, até a próxima.

  • Sobre certificações em TI

    O colega Fábio Prado me pediu minha opinião sobre certificações, para ajudar num artigo dele sobre o assunto…. então resolvi deixar registrado por aqui. Quem me conhece sabe que sou uma pessoa de opiniões fortes, tanto na forma quanto no conteúdo. Então vou tentar fazer um esforço de escrever de forma um pouco mais racional, para não acharem que se trata apenas de torcida organizada sobre o assunto.

    Eu tomei contato com as certificações pela primeira vez na década de 90, quando estavam em alta as certificações da Novell. Já nesta época tirar uma certificação era sinônimo de reconhecimento profissional e investimento em termos de tempo e dinheiro. Tirar uma certificação lhe daria credibilidade no mercado, mas lhe custaria tempo para estudar e dinheiro para pagar cursos oficiais, provas e livros. A primeira coisa que fica claro é que as certificações são uma fonte de receita fácil para quem vende um produto. Vender certificação pode incluir a venda de livros oficiais, pagar para fazer a prova e até mesmo te obrigar a fazer um curso oficial para obter o tal certificado, que no final é um pedaço de papel, como o diploma da faculdade.

    Em 2016 participei de um debate sobre a regulamentação do mercado de TI. Minha opinião sobre o assunto é semelhante a da SBC (Sociedade Brasileira de Computação):  Não contribui com o mercado, não contribui com o profissional, não contribui com as instituições de ensino, mas pode contribuir com um pequeno grupo de pessoas interessadas em criar umas um conselho regulador e cobrar taxas para que os profissionais exerçam sua profissão. Assim como você não precisa de um diploma de jornalismo para trabalhar como jornalista, você não precisa de um diploma para trabalhar com informática. Isso não significa que os cursos de jornalismo ou de informática deixaram de existir, não é mesmo? A mesma lógica se aplica às certificações, mas de formas diferentes.

    Existem diversos tipos de certificação. Então seria uma boa ideia separar cada uma delas. Existem certificações voltadas para profissionais que estão iniciando sua carreira no mercado de informática. Uma vez dei um curso para pessoas que queriam tirar certificação Oracle.  Nenhum deles tinha experiência prática como DBA e nem estava interessado em aprender do começo. Além da experiência, a  bibliografia deles no assunto era nula ou quase nula. Ou seja, eles queriam apenas passar na prova. E como profissional e educador, isso me incomodou profundamente, nunca mais dei um curso desse tipo. Estas provas em geral são apenas um questionário preenchido num computador com uma duração definida. Existem provas que você pode até mesmo fazer em casa no seu computador. Eu já tirei certificação Oracle assim. Estudei uma tarde e fiz a prova à noite. Passei fácil e não precisei colar.

    O que uma prova assim diz sobre a minha pessoa?

    • Eu tenho bons conhecimentos sobre o assunto ou
    • Eu tenho uma boa capacidade de memorização ou
    • Eu tive acesso à uma boa “cola”

    Certificações para iniciantes podem ser uma porta de entrada para o mercado de trabalho. Quando o mercado de trabalho está fraco, sobram candidatos e as empresas costumam colocar a certificação como um pré requisito para a vaga. Quando o mercado está aquecido, achar um bom profissional é mais difícil e estas regras são mais flexíveis. O problema é que ao contratar o profissional que tem mais certificações, que fez cursos oficiais e coisa e tal, você pode estar perdendo os melhores profissionais, os autodidatas, os que tem experiência prática mas não tem certificação, etc. E para o profissional, significa ter um custo enorme a mais para ingressar no mercado. Agora se você não é autodidata e quer fazer um curso para aprender sobre determinada tecnologia, existem excelentes opções, mais baratas e melhores que os cursos oficiais daquela tecnologia. Eles não em o “selo” do fornecedor, mas são ministrados por profissionais reconhecidos, como por exemplo os cursos do próprio Fábio Prado ou do Ricardo Portilho, falando aqui sobre Oracle.

    Na Timbira temos uma boa tradição em cursos também. Como não existe certificação para PostgreSQL, os cursos são focados em problemas reais dos nossos clientes. Muitas vezes fazemos cursos sob medida para um cliente, para atacar um problema real que ele tem. Fazemos também o que chamamos de “Cursotoria”, uma consultoria misturada com treinamento que dá ao cliente um resultado concreto e onde todos os participantes se envolvem mais energicamente.

    Existem certificações mais avançadas e no estilo “hands on”. Ou seja, te dão um terminal com uma situação problema e você tem um tempo limitado para resolve-lo. São certificações muito mais confiáveis em termos de metodologia, as pessoas que passam nestes exames realmente tem que ter mais conhecimento e experiência. Em geral as pessoas que passam nestas provas são profissionais já reconhecidos no mercado e que podem pagar caro pelo custo deste tipo de certificação. Em alguns casos você só pode fazer a prova nos EUA por exemplo. Se o profissional já é experiente, uma certificação não amplia muito a sua empregabilidade. Profissionais de alto nível são raros no mercado e a maioria já está bem empregada, com ou sem certificação.

    Na comunidade de PostgreSQL houve uma longa discussão se deveríamos ou não criar uma certificação oficial. Após pesar os prós e contras, a comunidade decidiu em não criar, ou pelo menos não focar esforços nisso. Existe muita coisa importante para fazer em prol do PostgreSQL e certificação não é uma delas no momento. A avaliação da maioria é que ter um produto com boa qualidade é o que faz ele competitivo no mercado e tem muita coisa no roadmap pela frente. Divulgação e ações de advocacy também são importantes e precisam melhorar, mas as certificações não tem sido uma barreira para o crescimento até o momento. Pelo menos essa é a percepção que eu tenho acompanhando a comunidade internacional.

    Existe um cenário onde eu concordo que a certificação tem seu valor. Em órgãos públicos, contratar empresas para prestar serviço é um grande desafio. Há tempos atrás a Caixa Econômica Federal fez uma licitação onde a empresa que prestaria suporte em PostgreSQL tinha que comprovar que possui profissionais que atuaram no desenvolvimento do PostgreSQL nos últimos anos. Hoje, quase todos os desenvolvedores ativos do PostgreSQL no Brasil estão na Timbira. É complicado fazer uma licitação onde o critério elimina a concorrência. Por isso outras empresas não adotaram este tipo de edital. A maioria prefere exigir que as empresas tenham profissionais certificados em determinada tecnologia. Isso afasta as empresas pernetas que ganham licitações com um preço muito baixo e sem profissionais qualificados. Realmente licitações públicas são um problema sério no Brasil. Este é um caso onde a certificação pode ajudar. Mas ainda acho que isso é uma forma crua de contornar um problema maior: o modelo de licitação pública que é ruim e dificilmente pune as empresas ruins. Os certificados de capacidade técnica em licitações também são fornecidos pelo Zé da esquina e falsificados sem o menor pudor. Se os maus fornecedores fossem punidos com mais rigor, os picaretas sumiriam. É um assunto longo e extenso que não diz respeito ao tema aqui discutido, nem tenho tanto conhecimento assim para entrar nesta seara. O ponto é que as certificações podem ser uma muleta válida neste tipo de situação. Veja que isso não inclui a contratação direta de profissionais, que deve ser feita por concurso público, onde as certificações não fazem a menor diferença, pois a prova do concurso pode ser moldada às expectativas do contratante com muito mais assertividade.

    As certificações podem sim ser um bom guia de estudos. Mas ainda acredito que a bibliografia hoje disponível pode lhe guiar muito melhor. Acredito que as certificações tem um certo fetiche para os profissionais. Ser reconhecido e alcançar um objetivo lhe confere algum status e dá uma sensação de realização que é importante para o ser humano. Eu gosto de ter este tipo de realização de outra forma, enfrentando outros desafios. Você pode não ter desafios reais no seu trabalho, mas pode criar seus próprios desafios e metas pessoais. Montar um laboratório e tentar atingir um objetivo prático ainda é na minha opinião a melhor forma de aprender. Foi assim que eu comecei com banco de dados, catalogando os discos do meu pai num banco de dados. É assim que faço até hoje com meu laboratório em casa. É assim que consigo compartilhar boa parte do conhecimento que tenho acumulado nestes anos como profissional de informática.

     

     

     

     

    , ,
    , ,

  • Pesquisa "Uso do PostgreSQL no Brasil 2016"

    Após 5 anos do lançamento desta pesquisa em 2011, chegou a hora de ver o que mudou nesse período. Em 2011 estávamos nos tempos do 9.0, maravilhados com o novo Standby do PostgreSQL. No final de 2016 já vemos que muita coisa melhorou. Então convidamos você a preencher nosso questionário e dizer como estão suas bases PostgreSQL em produção. O resultado da pesquisa será divulgado num podcast no começo de 2017.

    Contamos com a sua participação! Preencha o questionário aqui.

    ,

  • Programa de índio: "Postgres nas nuvens"

    Nesta quarta-feira 14/12/16 estaremos ao vivo gravando mais um Programa de índio com convidados especiais:

    • Carlos Eduardo Smanioto
    • Diogo Biazus
    • Fábio Telles Rodriguez
    • Matheus Oliveira
    • Sebastian Webber

    Desta vez o tema serão os bancos de dados na nuvem, particularmente (mas não somente) o PostgreSQL.

    Anote aí:14/12/16 às 21h no Youtube!

    ,

Fale conosco

receba novidades

plugins premium WordPress