• DBaaS não precisa de DBA?

    Semana passada postei sobre um trabalho da Timbira para uma startup aqui de São José dos Campos numa base RDS da AWS, ou seja, um Database as a Service (DBaaS). A imagem abaixo era para ser auto explicativa.

    Consumo de CPU antes de depois da atuação do DBA

    Acontece que a postagem gerou uma certa polêmica no Facebook, então gostaria de esclarecer alguns pontos.

    O cliente

    • Em horário comercial o consumo de CPU batia 100% com muita frequência e os clientes estavam reclamando constantemente de lentidão no sistema;
    • O Cliente em questão é uma startup. A base já está em produção mas é pequena ainda;
    • A equipe de desenvolvimento é composta em sua maioria por desenvolvedores com pouca experiência. Eles tem feito um bom trabalho, mas não possuem experiência com SQL;
    • Se você conhece o universo de startups, deve saber que projetos que começam pequenos devem ter custos baixos para serem viáveis. Então nesse caso não seria possível iniciar o projeto um custo fixo alto. Começar com o time dos sonhos significa não ter time nenhum;
    • O cliente hoje gasta cerca de USD 300/mês com a instância RDS de produção. Não é pouca coisa, mas ao mesmo tempo não um custo tão alto que justifique facilmente trocar o RDS por uma VM com um DBA para cuidar do banco de dados.

    O que foi feito?

    O cliente não tinha orçamento para fazer um Health Check completo, mas fizemos uma avaliação de algumas coisas importantes:

    • Avaliação da carga no servidor olhando o monitoramento do RDS;
    • Parametrização do banco de dados, instalação do pg_stat_statements;
    • Migração para o PostgreSQL 11;
    • Avaliação das conexões, idle_in_transaction, etc;
    • Avaliação do autovacuum e estatísticas dos objetos;
    • Avaliação das piores consultas no pg_stat_statements;
    • Geração de planos de execução para as piores consultas;
    • Criação de índices para as piores consultas.

    Após esse trabalho, o uso de CPU caiu de 100% para menos de 40%. Sim, a criação dos índices foi a parte que gerou a maior impacto para o cliente e fez a carga diminuir drasticamente. No entanto, até chegar lá, é preciso ver o servidor como um todo.

    Preciso mesmo de um DBA?

    Depende.

    Sempre depende.

    • Se você tem um serviço gerenciado como um RDS, você não precisa de um DBA para fazer o backup, para instalar ou replicar o banco de dados;
    • Se você tem uma equipe de alto nível com muita experiência, essa equipe poderá analisar as consultas da aplicação e criar índices sem a ajuda de um DBA;
    • Se a sua base é pequena ou tem poucos usuários, você pode não ter problemas de performance ou pode escalar por hardware, mas uma hora a conta vai chegar. Um DBA pode lhe ajudar a lidar com momentos de pico, alta concorrência, gargalos, locks, erros, etc. Um desenvolvedor muito experiente ou um administrador, DevOps, ou sysadmin experiente (como queira chamar) pode fazer esse papel eventualmente.
    • Existem um sem número de situações onde um bom DBA pode agregar numa equipe:
      • Parametrização do banco
      • Parametrização de objetos
      • Modelagem
      • Escolha de tipos de dados correta
      • Escolha de arquitetura correta
      • Monitoramento
      • Automatização de deploy em bancos de dados
      • Recuperação de desastres

    Enfim, conheço startups com 2 ou 3 funcionários que contratam os serviços de DBA remoto da Timbira. E conheço equipes grandes sem nenhum DBA. Quando você deve incorporar os serviços de um DBA na sua equipe? Bom, cada equipe tem suas dores. Se você acha que está tudo bem com o banco de dados, dificilmente você irá investir nisso. Ou pode acontecer de você apenas achar que está tudo bem…

    E você, acha que DBaaS não precisa de DBA???

  • Oracle muda licenciamento do SE2

    Em 2015 a Oracle mudou o licenciamento a partir da versão 12.1.0.2 do seu Oracle Database “Standard” ou SE para o SE2. A mudança mais importante afetou quem usa o Real Application Cluster, o RAC. A partir de então só poderiam ser utilizados 2 soquetes de CPU e no máximo 16 threads em todo o cluster. Isso foi uma redução de 50% em relação à versão anterior e deixou muita gente numa situação difícil.

    Agora em 2019 a Oracle muda o licenciamento do SE2 a partir da versão 19c onde o RAC não será mais suportado definitivamente. A Oracle lhe sugere 3 opções:

    • Migrar de Standard (SE2) para Enterprise (EE);
    • Deixar de usar o RAC;
    • Migrar para o Oracle Cloud.

    Vejam o que o pessoal da Oracle diz:

    oracle2

    Fica claro aqui que a Oracle quer empurrar todos os seus clientes menores para a sua nuvem. Parece um passo grande neste sentido. No entanto, parece que algumas pessoas pensam de outra forma…

    oracle3

    E vocês, o que acham???

  • Reta final na chamada de trabalhos do PGConf.Brasil 2019

    Fevereiro tem sido um mês emocionante para o Postgres, muita coisa acontecendo ao mesmo tempo. Depois de ser declarado o “banco de dados do ano” pela segunda vez consecutiva em janeiro, a Microsoft comprou a CitusData, uma solução Open Soruce para Postgres, voltada para BI.

    Inscrições Early Bird


    O nosso PGConf.Brasil, que vai se realizar nos dias 1, 2 e 3 de agosto já está a pleno vapor. Os ingressos “Early Bird” serão vendidos até 28/02. Aqueles que fizerem sua inscrição até lá, vão ganhar um boneco em 3D do mascote do evento:

    Chamada de trabalhos

    Eu sempre digo que a chamada de trabalhos é a alma do evento. Se tivermos boas palestras, teremos um evento bacana, senão, não importa se haverá happy hour, brindes bacanas, patrocinadores, etc. Os palestras são as estrelas do evento, sempre.

    E os eventos de Postgres foram mudando de cara com o tempo. De 2007 para cá, vemos cada vez mais gente experiente vindo aos eventos e cada vez mais desenvolvedores. Em 2018, os desenvolvedores já eram maioria e a tendência é só aumentar.

    Sempre que eu divulgo a chamada de trabalhos de um evento, as pessoas dizem que não tem nenhuma ideia sobre o que palestrar… bom eu tenho sempre dezenas delas… vou citar aqui alguns exemplos:


    • Nuvens e mais núvens… esse assunto rende:
      • Serviços estilo DBaaS: AWS RDS e Aurora, Azure, Google Cloud, Digital Ocean, Heroku, ElephantSQL, EnterpriseDB, Aiven, etc;
      • DBaaS x IaaS;
      • Comparações de desempenho e custo;
      • Ferramentas de migração;
      • Arquiteturas complexas, escalabilidade, HA, etc;
      • Microserviços;
    • DevOps está na onda e os bancos de dados não poderiam fugir dessa:
      • Continuous delivery e Continuous integration;
      • Conteiners? Sim conteiners!
      • Automação de testes;
      • Versionamento;
      • Estratégias de automação;
      • Deploy sem downtime, lenda ou realidade?
      • Como monitorar essa zona toda?
    • Dev Dev Dev:
      • Tipos de dados no Postgres e suas funções maravilhosas;
      • B-Tree, Hash, GiST, SP-GiST, GIN e BRIN: qual tipo de índice usar e quando;
      • Text Search: a vida antes e depois de usar FTS no PostgreSQL;
      • EXPLAIN it again Sr.
      • Como melhorar minhas consultas?
      • Internacionalização:
        • collate e codificação de caracteres;
        • A zona do timezone;
        • Formatos de data, hora, números, etc;
      • Json, jsonb e seus índices maravilhosos;
      • Arrays salvam o dia mais uma vez!
      • Enum, network, geometric e outros tipos de dados que você nem sabia que existiam;
      • Trabalhando com domains;
      • Partitioning like a girl!
      • Locks, Dead Locks e concorrência: Soluções para o caos no trânsito;
      • pg_hba.conf, GRANT, roles e row level security,
      • Criptografia e anonimização de dados;
      • O dilema do SaaS: uma base por cliente, um esquema por cliente ou mistura tudo nas mesmas tabelas?
    • Persistência poliglota:
      • O PostgreSQL como noSQL;
      • Integrações complexas com o universo para o infinito e além;
      • Usos inovadores do FDW;
      • Construindo o seu próprio FDW;
    • HA, replicação, clusters e bases distribuídas geograficamente. Essse saco de gatos envolve um universo inteiro, então nem vou abrir aqui em subitens;
    • Tuning like a boss;
    • BI e Big Data;
    • PostGIS, time series, CitusDB, Greenplum, ToroDB, PG-Strom e outros universos paralelos;
    • Backup em ambientes críticos, uma missão peso pesado!
    • Ferramentas, IDEs e outros bichos;

    Vou parar um pouco por aqui… se quiser alguma outra sugestão, é só chamar!

    Mulheres no PGConf.Brasil

    Em 2018 me questionaram sobre a participação das mulheres no evento. Respondi que 100% das palestras enviadas por mulheres foram aprovadas na chamada de trabalhos. Infelizmente foi apenas uma. Está na hora de mudar isso, certo? Fizemos uma mascote ninja para a nossa campanha de divulgação do evento justamente visando atingir esse público. Bora encarar?

    Por mais mulheres na TI!

  • Sobre as comunidades de TI

    Neste sábado eu participei de um evento bastante inusitado. Sob o convite do Sr. Marcos Sungalia, com quem tive o prazer de trabalhar no inicio da minha carreira, fui num evento chamado de “Oracle Groundbreakers”, com o intuito de ouvir a opinião de várias comunidades de TI e buscar uma proximidade com elas. Foi um evento bastante interessante. Além da oportunidade de rever grandes amigos de varias comunidades, conheci outros mais e sobretudo ouvi um pouco sobre a atuação de diversas delas.

    E depois do churrasco e da cerveja, me veio a ideia de que tem muita gente entrando e querendo construir alguma coisa enquanto há muita gente que já está nessa estrada há um bom tempo como eu. Então achei que seria interessante compartilhar um pouco mais dessa experiência e juntar pessoas de diversas comunidades, não apenas envolvidas com Software Livre, mas de TI em geral.

    Então resolvi criar um grupo no Telegram para juntar essas pessoas e trocar figurinhas. Além de divulgar ações de diversas comunidades, acho que podemos nos ajudar de diversas formas. Já durante o evento vimos pessoas procurando palestrantes, patrocínio, local para fazer eventos, etc e tal. Então a ideia não é criar um fórum técnico, pois cada comunidade já tem o seu, mas criar um ambiente onde pessoas que estão engajadas na organização destas comunidades possam trocar figurinhas livremente, fazer parcerias e ajudar nesse processo de construir comunidades e lideranças.

    Estou aqui me adiantando um pouco em relação ao pessoal da Oracle, que foram as pessoas que deram essa ideia, pois gostaria de criar um ambiente independente de uma empresa específica, como são a maioria das comunidades que eu conheço ou participei.

    Então quem estiver interessado, podem entrar no grupo do Telegram: t.me/lideres_ti_br

  • PostgreSQL: o banco de dados do ano, pelo segundo ano consecutivo!

    Em janeiro de 2018, o DB-Engines (site com o ranking mais respeitável sobre bancos dados que eu conheço) publicou um artigo com os bancos de dados do ano, e o PostgreSQL foi o destaque principal. Com o maior crescimento de popularidade no ano, um aumento de 56 pontos ou 17%,  garantiu um primeiro lugar com folga!

    Só para não confundir… o 1º lugar no ranking continua sendo o Oracle, com MySQL em 2º e SQL Server em 3º. O PostgreSQL ocupa a 4ª posição seguido do MongoDB na 5ª posição. O destaque foi pelo crescimento, não pela posição no ranking.

    Com os dados de dezembro, o PostgreSQL subiu cerca de 74 pontos até agora, ainda sem contar o último mês. Em segundo lugar está o MongoDB que cresceu 48 pontos até agora. Desta forma, a não ser que haja uma mudança radical na tendência, Teremos o PostgreSQL como destaque principal novamente, seguido pelo MongoDB e depois um terceiro lugar disputado entre Redis e Elasticsearch que nos próximos anos devem fazer o DB2 despencar de 6º para 8º lugar no ranking.

    Tendências

    Queda dos líderes: Oracle, MySQL e SQL Server

    Olhando os gráficos de tendências vemos que os 3 líderes do continuam na frente com boa folga para o 4º lugar, mas com uma queda consistente nos últimos anos. O SQL Server se recuperou bem em 2016 com o lançamento da versão em Linux e uma política agressiva de preços para concorrer com o Oracle. Mas é claro que essa política de preços não durou muito, e quem migrou para SQL Server viu a conta chegar salgada logo depois. Em 2018, o Oracle caiu 58 pontos, MySQL caiu 156 pontos e SQL Server caiu 132 pontos. Em 5 anos, o Oracle caiu de 1516 pontos para 1283 pontos (~15%), o MySQL caiu de 1324 para 1161 (~13%) e o SQL Server caiu de 1313 para 1040 (~21%). Todos tiveram quedas acentuadas em 2018.

    O crescimento dos bancos de dados livres

    Eu sei que muita gente ainda diz que não existe substituto para uma base corporativa de grande porte como um Oracle Exadata… mas o mundo está mudando. E sempre mudou. Na década de 80 ninguém imaginaria que a IBM seria destronada e que a Apple viria a ser maior. E vejam, a IBM continua sendo líder entre os supercomputadores, vejam a lista do Top500 por exemplo. Ninguém está dizendo que os líderes não tenham tecnologias fantásticas, um baú cheio de patentes maravilhosas e tudo o mais. Mas se você olhar a comparação entre bancos de dados proprietários X livres… vai ver que em 2019 o jogo vai virar. Há 5 anos a popularidade dos bancos de dados proprietários eram de 64%, contra 36% dos bancos de dados livres. Uma diferença de 29%. Hoje, temos 52% contra 48%, uma diferença de 4%. Em 2019 veremos a mesa virar. 

    E na verdade essa mesa virou faz tempo. O que acontece é que não se troca de banco de dados tão facilmente quanto se troca de sistema operacional. Trocar de SGDB dá muito trabalho. Em geral isso acontece quando:

    • Você vai começar um novo projeto;
    • Você vai modernizar um sistema já existente e vai remodelar toda a arquitetura dele para uma nova plataforma, como em sistemas client/server;
    • O seu SGDB antigo já não atende mais suas necessidades, diante do crescimento das demandas;
    • Quando um novo cliente quer comprar seu sistema, mas exige que ele seja suportado em determinado ambiente;
    • Quando você vê a sua margem de lucro cair frente a outros outros competidores que já usam software livre.

    Mudar um sistema já existente é um trabalho pesado. Na Timbira, ajudamos empresas a migrar para PostgreSQL com muito sucesso. Mas é sempre um trabalho de pelo menos 6 meses. O resultado é bastante encorajador, mas dá trabalho, claro. 

    Em novos projetos, o crescimento do Software Livre é avassalador. A nuvem, os microserviços, a cultura DevOps, estão deixando a indústria de bancos de dados proprietários de cabelos em pé. Não é à toa que vemos o Sr. Larry Ellison (CTO da Oracle) fazendo ataques constantes à AWS. E convenhamos, a Oracle está comendo poeira feio quando o assunto é nuvem.

    Uma coisa que eu sempre digo é: olhem para as startups. Atendemos várias delas, cada vez mais. São ambientes inovadores, descontraídos e onde só sobrevivem aqueles que tomam decisões inteligentes. Afinal, uma grande empresa sobrevive tranquilamente à decisões ruim de seus gestores. Empresas muito pequenas morrem num piscar de olhos. Olhem para as Startups que dão certo. O Skype, antes de ser comprado, usava (ou usa ainda, não sabemos) PostgreSQL. O Instagram: PostgreSQL. Nubank usa PostgreSQL e Datomic. Ifood, PostgreSQL e varias bases NoSQL livres. E por aí vai.

    Say goodbye to Oracle!

    A verdade é que gestores não gostam da Oracle. Ninguém quer ficar na mão do titio Larry. Eles tem uma tecnologia fantástica, verdade. Mas tem uma política de licenciamento, de vendas e de marketing que deixa qualquer gestor no mínimo desconfortável… (era outra palavra, mas me recomendaram usar um eufemismo!). Eles já eram assim na década de 70 quando copiavam o System-R da IBM enquanto vendiam um sistema que ainda não existia (ok, isso era moda na época, a Microsoft também vendeu um SO para a IBM que não tinha).  Eles vão continuar no topo do mercado por um bom tempo. Sistemas grandes e antigos vão levar muito tempo para serem substituídos, assim como o COBOL sobrevive até hoje. Mas a maioria dos novos sistemas não usa Oracle!

    A tentativa desesperada de empurrar clientes para a nuvem da Oracle é um sinal claro de que o barco está fazendo água. Boa parte dos usuários da nuvem da Oracle são pessoas que sofreram ameaças de multas milionárias por causa das armadilhas de licenciamento da Oracle, ou ganharam créditos astronômicos para usar tudo de graça ou quase de graça (e vocês sabem onde vai dar esse negócio de distribuir drogas de graça, né?). Por mais que a Oracle tenha concertado muitas das falhas graves na sua nuvem, a sua fatia nesse mercado é uma piada. Não importa o quanto eles esperneiem. E quando você quer escolher um banco de dados PaaS na nuvem da Oracle, adivinhe? Você só tem bancos de dados da Oracle! Acha que é normal né? Olhe para o lado e veja os líderes na nuvem: AWS e Azure. Ambos oferecem um amplo leque de serviços baseados em diversos bancos de dados, livres ou não. Não é por acaso que AWS e Microsoft investem pesado em PostgreSQL! Alias, ambas foram patrocinadoras do nosso PGConf.Brasil 2018

    Lembram desta piadinha?

    Então… quando perguntarem: “Onde ficam armazenados os dados na nuvem?”. Você poderá responder: “Em bancos de dados livres, meu filho!”

  • PGConf.Brasil 2019 lançado!

    Você sabe que em 2018 fizemos um evento de arromba, certo? Não viu? Bom, você pode olhar o site do PGConf.Brasil 2018 para dar uma espiada. Deixamos também uma Galeria de fotos no Facebook, a grade com descrição de todas as palestras e os slides de cada uma, a avaliação final do evento, incluindo a descrição das despesas e receitas, e por fim algo esperado por muitos, que deve ter passado desapercebido por muita gente… todos os vídeos das palestras disponibilizados para todos! Isso mesmo 45 vídeos completos com todas as palestras do evento. Por último, deixei aqui no blog a minha avaliação pessoal do evento, como sempre faço… há uns 15 anos! 

    Depois disso, a gente fez outra coisa que está virando uma tradição, gravamos um “Papo de índio” falando sobre as novidades do “PostgreSQL 11 lançado em outubro/2018.

    Hoje, 3/12/2018, lançamos oficialmente o PGConf Brasil 2019.

    Temos pronto:

    • Chamada de trabalhos, aberta até o final de fevereiro de 2019;
    • Inscrições no Estilo Early Bird que vai dar de brinde uma miniatura 3D do nosso mascote do PGConf Brasil 2019! 
    • Media Kit pronto para patrocinadores interessados em patrocinar o evento.

    Enfim, o evento já está todo organizado. Só falta arrumar a parte internacional (inscrições e Media Kit) que devem ficar prontos na semana que vem. Uma das novidades importantes do evento serão os 4 Workshops que acontecerão em um dia separado,  1/8/2019:

    • SQL Avançado e Performático, ministrado por Matheus Oliveira;
    • Banco de Dados Espaciais com PostGIS, ministrado por Luis Fernando Bueno;
    • Backup / Restore, ministrado por Jefferson Santos;
    • Replicação, Alta Disponibilidade e Balanceamento de Carga, ministrado por Euler Taveira.

    Os quatro workshops terão duração de 4 horas e acontecerão em salas pequenas, com capacidade de 12 lugares apenas. Então, as vagas devem acabar logo. Na verdade, enquanto estou escrevendo, as vagas já estão sendo preenchidas, sério! Então não bobeie.

  • Sobre o PGConf Brasil 2018

    O começo

    Há um mês, demos início ao PGConf Brasil 2018. Credenciamento, welcome coffee, estandes de patrocinadores, canecas, camisetas, etc e tal. Claro que a história não começa bem aí… começa em 2017, no PGBR2017, organizado pelo Sebastian Webber em Porto Alegre / RS. Fazia um tempo que eu não organizava um grande evento, a brincadeira começou longe, o primeiro evento de Software Livre que organizei foi em 2003 em seguida houve a criação do PSL-ABCD com 3 edições do “Fórum Regional de Software Livre do ABCD” em 2004, 2005 e 2006. Em 2007, começamos a organizar o primeiro evento nacional de PostgreSQL no Brasil. Depois vieram os de 2008, 2009 e em 2011 foi o último grande evento que organizei. O PGBR 2011 foi considerado pelo sr. Magnus Hagander o maior evento de Postgres do planeta. Claro que eu fiquei feliz pacas com o reconhecimento. Mas fiquei exausto também. A comunidade de Postgres na época já não tinha o mesmo pique e eu acabei centralizando a maior parte da organização, assumindo uma carga enorme de trabalho. Em 2013, o Luis Fernando Bueno (e uma equipe incrível junto dele), fez o que muitos acharam uma loucura: levaram o PGBR para Porto Velho / RO. Foi assim que eu passei o bastão e o evento saiu de SP. Foi um sucesso, com uma mobilização local excelente e quem topou viajar até Porto Velho não se arrependeu. Depois foi o Fabrízio de Royes Mello, que assumiu a organização em 20015 em Porto Alegre / RS. Em 2017, Sebastian Webber foi o nosso Kahuna da vez. E foi participando do PGBR2017 – que diga-se de passagem foi um excelente evento –  quando eu tomei coragem para retomar essa história.

    De 2007 para cá muita coisa mudou. Muito da história destes eventos trazem um pouco da minha história pessoal e da minha minha trajetória profissional. Foi no PGBR 2009, em Campinas, que nos reunimos para criar a Timbira, com a ideia de construir a primeira empresa no Brasil focada em PostgreSQL. As pessoas com as quais trabalhamos na Timbira, são as pessoas que conheci e/ou ajudaram a organizar eventos de Software Livre pelo Brasil: Fernando Ike, Euler Taveira, Fabrízio de Royes Mello, Dickson Guedes, Sebastian Webber, Felipe Augusto van de Wiel, Jefferson Alexandre e outros que estão chegando! A decisão de assumir a organização do PGConf Brasil 2018 veio de uma série de fatores que foram amadurecendo e eclodiram em 2017. Vejamos…

    O crescimento do PostgreSQL no Brasil

    Em 2003, quando organizei meu primeiro evento de Software Livre, era um momento de efervescência no país, o Linux estava despontando com novos modelos de negócios, com a possibilidade de incluir mais gente no mercado, compartilhar o conhecimento e remunerar mais os serviços e competência profissional do que papel ( licenças, patentes e certificações). Hoje, a comunidade internacional de PostgreSQL mantem os princípios da ética hacker e ao mesmo tempo incorporando demandas de um mercado corporativo que utiliza bancos de dados em diversos segmentos. Atualmente, grandes empresas usam o PostgreSQL e grandes empresas prestam serviço também. Há 15 anos, nós éramos entusiastas, estávamos começando a trabalhar profissionalmente com Software Livre e sonhávamos em trabalhar em uma das poucas empresas que prestavam serviços em PostgreSQL. Ainda somos entusiastas, mas temos a nossa própria empresa e estamos contratando novos entusiastas!

    A visão do gestor de TI

    Meu trabalho na Timbira tem mudado gradativamente nos últimos anos. Cada vez mais eu me dedico à tarefas como gestor e isso traz consequências no dia-a-dia. Você começa a olhar as coisas num plano maior e se preocupar com outros aspectos. É claro que existe muito o que melhorar no código do Postgres, novas funcionalidades, menos gargalos, mas temos que pensar em outros aspectos não técnicos que são grandes barreiras na expansão do PostgreSQL. Entre eles temos a necessidade de ter uma comunidade mais ativa, com mais profissionais qualificados, divulgação de casos de sucesso, treinamentos, material didático, etc. Continuamos hackeando, mas está na hora de dar mais fôlego para outras questões igualmente importantes.

    Aprender a enxergar as coisas sob a ótica do marketing

    Existem muitas coisas divertidas sob o ponto de vista de um hacker ou mesmo de um nerd que trabalha com informática. Mas nem todas são realmente relevantes para todos. A primeira versão dos cartões de visita da Timbira incluíam uma fingerprint das nossas chaves GPG. Na prática, quase ninguém sabia o que era isso. Ao dar o nosso cartão para um gestor de TI, aquilo não agregava nenhuma informação relevante. Hoje, embora a maioria dos hackers da comunidade internacional ainda utilizem o IRC e listas de discussão por e-mail, muitos usam grupos do WhatsApp, Telegram, Facebook e tem crescido muito o uso do Slack. Trabalhar junto a uma empresa de marketing, no caso a Klavo, ajudou muito a dar um salto de qualidade no evento. Aprendemos muito e certamente estaremos juntos novamente em 2019. A atenção a alguns detalhes foi um diferencial em 2018.

    A política internacional de reconhecimento para eventos que contribuem para a comunidade

    Nós sempre organizamos eventos a partir da comunidade. Nos filiamos à ASL.org e com isso tivemos respaldo jurídico para captar recursos e contratar fornecedores. Mas, a ASL foi diminuindo enquanto o mercado corporativo foi crescendo. Hoje, boa parte dos eventos de Software Livre são organizados por empresas e não apenas por comunidades. Em 2018 resolvemos utilizar a Timbira como organizadora. As diretrizes da comunidade internacional nos deram um caminho seguro para percorrer. Não é pelo fato de uma empresa organizar o evento, que este se tornará uma grande propaganda. E de fato, isso realmente ocorre em outros eventos. Nós tomamos claramente um outro caminho, decidimos adotar todas as recomendações e recebemos o reconhecimento da comunidade internacional por isso. Dentre as exigências, podemos citar:

    • Foco no PostgreSQL e não em outras tecnologias;
    • Adotar um código de conduta que garanta um ambiente saudável e seguro para todos os participantes;
    • Publicar quais são as pessoas que fazem parte da banca avaliadora das palestras;
    • A banca avaliadora deve contar com menos de 50% de pessoas de uma única empresa;
    • Todos os membros da banca avaliadora devem ter o mesmo poder de voto e a suas decisões devem ser soberanas;
    • Os patrocinadores devem ter acesso público ao mesmo plano de captação com os mesmos direitos e deveres;
    • Qualquer patrocinador que atenda os requisitos do plano de captação deve ser aceito sem discriminação;
    • Prover acesso aos registros financeiros do evento, bem como comprovantes aos membros centrais da comunidade de PostgreSQL;
    • Declarar publicamente a destinação de qualquer lucro obtido com a realização do evento, sendo obrigatoriamente revertido em prol da comunidade.

    É claro que se você faz parte da comunidade e está organizando um pequeno evento regional isso não muda muito a sua vida. Mas, se você é uma empresa que ganha dinheiro vendendo serviços relacionados ao PostgreSQL, as coisas mudam bastante. Não há nenhum problema em uma empresa organizar um evento que não tenha esse reconhecimento, inclusive há grandes eventos assim. A principal diferença é que estes não podem usar o nome da comunidade nacional ou internacional para promover seu evento, seus negócios e não precisam ter nenhum compromisso com a comunidade em si.

    Desta forma, tomamos e sempre vamos tomar, o cuidado de preservar os interesses da comunidade. Acreditamos firmemente que ao apoiar o crescimento da comunidade, todos ganham, inclusive a Timbira. Acreditamos firmemente nos princípios da ética hacker, no compartilhamento do conhecimento e na transparência das nossas ações. Temos clareza de que sempre vamos continuar apoiando a comunidade: escrevendo novas funcionalidades, revisando código de outras pessoas, organizando eventos, escrevendo artigos e ajudando pessoas com dúvidas, como sempre fizemos. No entanto, ao invés de utilizar a ASL.org para dar respaldo jurídico e financeiro, estamos utilizando a Timbira.

    A grande verdade

    Ok, é verdade que a gente quer impulsionar a comunidade, gerar conteúdo relevante, compartilhar conhecimento, etc e tal. Mas vamos falar a verdade: juntar essa turma toda para tomar uma cerveja é legal para caraleo! Botar esse monte de malucos no mesmo lugar é algo que só quem participa sabe. Por isso demos uma atenção especial ao happy hour. Trazer os palestrantes internacionais, juntar gente de vários estados diferentes, gente com novos desafios, isso sim é o que me fez retomar tudo isso. A cerveja une as pessoas! E se você não gosta de cerveja não tem problema, participar da confraternização, compartilhar o momento é o que vale. De repente, você não está mais preocupado apenas com o trânsito, com o aumento que não veio ou com as contas para pagar no final do mês. Você está lá, contando suas aventuras com o PostgreSQL e conhecendo as histórias de outras pessoas que você nunca viu na vida. Um grande educador um dia disse que o importante no aprendizado não é a quantidade de momentos em que você se depara com o conhecimento, e sim a qualidade desses momentos. Um evento de troca de conhecimento não seria válido sem encontros como esse, de descontração, sorrisos,  boas histórias para contar e claro, boa cerveja! São esses encontros que a gente leva para a vida e não esquece jamais.

    Blá blá blá… e como foi o evento afinal?

    Foi exaustivo pra variar. A aproximação do evento coincidiu com a chegada de alguns clientes novos e críticos na Timbira, além de problemas de saúde em família. Então foi tudo bem corrido. Eu estava um caco. Para se ter uma ideia, eu não consegui terminar a minha própria palestra em pé. Pelo menos não estava usando muletas e uma bota ortopédica como em 2008. Mas vejamos alguns pontos em particular…

    Sobre a chamada de trabalhos

    Faltando uma semana para encerrar a chamada de trabalhos, havia pouquíssimas propostas de palestras inscritas. A gente já estava pensando em adiar o prazo em uma ou duas semanas. E como sempre, o pessoal (eu me incluo nisso) deixa muita coisa para a última hora. No final houve um recorde de propostas de palestras: 82. A banca avaliadora teve bastante trabalho para escolher tudo, mas quando terminaram… vimos uma grade com mais de 40 palestras de tudo quanto é tipo. A maior grade que já montamos por aqui. Aí eu já sabia que o evento seria phoda. Phoda mesmo! Uma grade assim enche os olhos de qualquer um. Teve gente reclamando que teve dificuldades para escolher o que assistir.

    Sobre o público

    Olhando para o evento em 2011 realizado exatamente no mesmo lugar, tivemos um público menor. Eu diria que tivemos umas 300 pessoas no máximo em 2018, contra umas 380 em 2011. Mas quantidade não é tudo… vejamos algumas informações importantes:

    • Apenas 30% dos inscritos moram em SP, o que significa que a maioria dedicou tempo e dinheiro para se deslocar até o evento. Isso demonstra um grande engajamento. Tivemos inscritos de outros países da América do Sul também;
    • A média de idade dos participantes é de 35 anos e em média 14 anos de experiência no mercado de TI. Haviam pessoas mais novas e inexperientes, mas a maioria do público é bastante qualificada na área;
    • A maioria dos participantes não são DBAs!
      • 39,1% são desenvolvedores;
      • 24,5% são DBAs;
      • 6,6% são gestores;
      • 6% são sysadmins;
      • e…. 12,6% disseram que são Chuck Norris!
    • 72,8% trabalha principalmente com PostgreSQL, 7,9% com Oracle, 7,3% com MS SQL Server e 4,6% com MySQL e similares.

    É pessoal, as coisas mudam. Temos mais gente experiente, mais desenvolvedores, mais gente que trabalha principalmente com PostgreSQL e uma parcela significativa de profissionais ninjas (lembra dos 12,6% que se disseram Chuck Norris?).

    Sobre os pontos positivos

    O evento foi muito bem avaliado. Tivemos 157 avaliações gerais do evento pelo formulário, e quase 500 avaliações de palestras pelo App do evento. Alguns pontos de destaque:

    • As palestras tiveram destaque quanto à qualidade técnica e a pontualidade;
    • Muitas pessoas citaram o domínio e a postura motivada dos palestrantes sobre o assunto;
    • A diversidade de temas abordados na grade também foi muito elogiada;
    • 46% disseram que virão para o PGConf Brasil 2019 e 52,9% disseram que virão dependendo das circunstâncias;
    • A organização do evento recebeu muitos elogios e avaliações muito positivas;
    • Divulgação, site, sistema de inscrição e material promocional tiveram avaliações muito positivas também;
    • Até mesmo o preço da inscrição não sofreu muitas críticas;

    Um dos grandes destaques positivos foi o happy hour, claro. Encomendamos 150 litros de chopp artesanal da cervejaria Moby Dick com uma Blond Ale feita com uma receita exclusiva para o evento. Só quem estava lá experimentou. Quer dizer… ainda fizemos 100 garrafas que foram vendidas a preço de custo no evento. Vira e mexe eu ainda vejo fotos de uma ou outra garrafa sendo aberta lá no grupo do evento no Telegram. Se alguém ainda tiver uma fechada, pode me convidar que eu aceito um copo! A cerveja ficou realmente boa, não é por nada não.

    Sobre os pontos negativos

    Nem tudo são flores, e vários erros foram cometidos, mesmo tendo organizado vários eventos, sempre tem o que melhorar! Entre os itens que sofreram mais críticas temos:

    • A presença feminina entre inscritos e palestrantes foi realmente baixa. Abaixo do normal. Estamos bolando uma estratégia para mudar isso em 2019!
    • O App do evento teve várias sugestões de melhorias;
    • A conservação do hotel gerou uma reunião depois do final do evento com o diretor do estabelecimento, na qual eles se comprometeram a reformar algumas coisas e corrigir algumas falhas até o evento em 2019;
    • Algumas palestras também foram criticadas por serem superficiais. Quando vemos o perfil do nosso público vemos que a demanda por palestras mais avançadas e com maior profundidade é grande. Então tivemos algumas palestras que sofreram este tipo de crítica, embora seja em pequena quantidade, é um ponto de atenção para 2019.
    • Algumas pessoas reclamaram das palestras em inglês ou de não haver tradução. Bom, devo dizer que isso não deverá mudar para 2019… você pode optar por estudar inglês (você sabe que deveria) ou de assistir outra palestra no mesmo horário. O custo da tradução simultânea é muito alto. Muito alto mesmo. Preferimos manter o valor da inscrição baixo e deixar as pessoas assistirem as palestras em inglês;
    • Houve poucas citações, mas alguns reclamaram que palestrantes ficaram fazendo muita propaganda durante a sua palestra. Não tenho como saber em qual foi, mas isso é algo que combatemos fortemente durante toda a organização. O evento é técnico e não comercial. Como exemplo, limitamos a 2 slides na palestra e 5 minutos de tempo para se apresentar e apresentar a empresa na qual trabalha. Talvez tenhamos que ser ainda mais rigorosos em 2019. Se por um lado não pretendemos fazer censura prévia, por outro lado realmente acontece de um palestrante ou outro exagerar;
    • Problemas com o som nos auditórios foi uma reclamação que certamente vamos corrigir em 2019. Colocamos apenas 2 operadores de som para 3 salas grandes. Foi uma economia besta. A qualidade dos cabos também ficou a desejar, algo que prejudicou muito a gravação de áudio de algumas palestras, infelizmente. Isso não pode se repetir de jeito nenhum;
    • Dificuldade de inscrição de estrangeiros. Isso temos que avaliar com o pessoal do Eventize para ver o que é possível fazer. O sistema atualmente pede um CPF válido;
    • Uma reclamação pertinente também foi não ter água disponível o tempo todo no andar dos auditórios. Algumas pessoas reclamaram disso e foi realmente uma mancada besta.

    E valeu a pena?

    Cara, valeu muito. As pessoas fazem toda a diferença. O retorno entre inscritos, palestrantes e patrocinadores foi muito bom. Acho que conseguimos entregar um evento com um bom nível, com uma grade bastante significativa e uma organização que agregou valor para as pessoas. Mas fiquem tranquilos… isso foi um ensaio para o que vamos aprontar em 2019!!!

    O que esperar do PGConf Brasil 2019

    O planejamento para 2019 já começou e se o hotel confirmar as melhorias que pedimos, pode ir reservando aí na agenda: 2 e 3 de agosto de 2019 no Hotel Century Paulista. Enquanto isso, algumas coisas que possivelmente estarão no nosso roadmap:

    • Adicionar um ou dois dias com minicursos de 4 e 8 horas. Fazer uma pesquisa para ver quais temas as pessoas gostariam de ver nos minicursos;
    • Promover um aumento no nível técnico das palestras;
    • Continuar focando o evento também em desenvolvedores e gestores, não apenas em DBAs;
    • Continuar trazendo  grandes palestrantes internacionais;
    • Ampliar as ações no Open Space. O Open Space traz um novo tipo de interação. Devemos apostar em novos formatos de atividades com maior participação do público;
    • Melhorar algumas questões de infra no hotel;
    • Colocar em cada sala um operador de áudio, um microfone de lapela (ajuda para quem vai fazer algo hands on)  e um microfone sem fio;
    • Criar uma equipe de “embaixadores” do PGConf Brasil, com mais pessoas de fora da Timbira. Acho que em 2018 eu centralizei muito a organização, seria bom descentralizar.
    • Criar novos materiais promocionais para divulgar o Postgres pelo país afora (aceitamos sugestões);
    • Incentivar a realização de PGConfs regionais em várias cidades;
    • Promover um bom happy hour com boa cerveja, claro! Talvez tenhamos que aumentar de 150 litros para 200 litros chopp. Quem sabe trazer dois tipos de cervejas diferentes…

    Espere, o PGConf Brasil 2018 ainda não acabou…

    Na verdade ainda temos algumas coisas para fazer antes de começar a organização do evento em 2019:

    • Vamos publicar em breve um relatório com a avaliação geral do evento, incluindo um demonstrativo de gastos;
    • Vamos divulgar para todos os participantes que responderam a pesquisa de avaliação do evento o link com a playlist das 45 palestras que foram gravadas. Sim, gravamos todas as palestras nos 3 auditórios principais e os vídeos já estão no Youtube!
    • Vamos terminar de publicar as fotos do evento na página do Facebook;
    • Vamos fazer uma última reunião de avaliação com os organizadores, aí sim, já dando o pontapé inicial para 2019!

    Na verdade o PGConf é como louça para lavar… não acaba nunca!

    Um grande abraço para todos e vejo vocês no evento em 2019. Ou no Facebook! Ou no Twitter? Ou será no Telegram? Não sei… a gente se vê por aí, certeza!

    Happy Hour do PGConf Brasil 2018 em time lapse

    Vídeo com resumo do PGConf Brasil 2018
  • Desabilitando todos os gatilhos do PostgreSQL

    Uma dica rápida vindo de uma pergunta no Telegram hoje de manhã: Como desativar todos os gatilhos de todas as tabelas de uma vez só?

    A princípio pensei em consultar o INFORMATION SCHEMA para isso com algo como:

    SQL
    SELECT 
      'ALTER TABLE ' || event_object_schema || '.' || event_object_table || 
        ' DISABLE TRIGGER ' || trigger_name || ';' 
    FROM information_schema.triggers
    GROUP BY trigger_name, event_object_schema, event_object_table;

    Funciona, mas você não consegue filtrar apenas os gatilhos que estão habilitados. Então achei melhor partir para o catálogo do postgres logo de uma vez:

    SQL
    SELECT 'ALTER TABLE ' || n.nspname || '.' || c.relname || ' DISABLE TRIGGER ' || t.tgname || ';' 
    FROM
        pg_class c
        JOIN pg_namespace n ON n.oid = c.relnamespace
        JOIN pg_trigger t ON c.oid = t.tgrelid
    WHERE 
        tgenabled = 'O' AND
        NOT tgisinternal;

    Note o cuidado em filtrar aqui o tipo de gatilho. Depois de desabilitar tudo, você provavelmente vai querer habilitar tudo novamente:

    SQL
    SELECT 'ALTER TABLE ' || n.nspname || '.' ||c.relname || ' ENABLE TRIGGER ' || t.tgname || ';' 
    FROM
        pg_class c
        JOIN pg_namespace n ON n.oid = c.relnamespace
        JOIN pg_trigger t ON c.oid = t.tgrelid
    WHERE 
        tgenabled = 'D' AND
        NOT tgisinternal;

    Espero ter ajudado!

  • Proteja o seu banco de dados PostgreSQL

    Segurança é um tema que só quem tem experiência se preocupa. Neste caso, experiência significa que você já foi invadido um dia. E a pergunta nunca é se você será invadido, mas quando. Um cliente me pediu um resumo rápido das medidas de segurança para proteger o seu PostgreSQL. Comecei a enumerar e achei melhor escrever aqui, uma vez que é um assunto que está tirando o sono de muita gente.

    RTFM

    Saiba o que está fazendo, leia a documentação oficial e não apenas em blogs e vídeos no YouTube! Veja se a documentação que você está lendo se refere a versão correta do software que você está utilizando.

    Proteja o seu servidor

    Instalação do servidor: menos é mais

    Instale somente o necessário. Crie um servidor dedicado apenas com o essencial. Tudo que não for absolutamente necessário deve ser removido. Isso inclui serviços de compartilhamento de arquivos, impressão e até a interface gráfica… mesmo que o seu servidor seja em Windows. Além de economizar um pouco de espaço em disco, economizar CPU e memória você abre um número menor de portas no seu servidor e tem menos softwares com possíveis falhas de segurança instalados.

    Mantenha as atualizações de segurança em dia

    Prefira sempre instalar o PostgreSQL empacotado ao invés de compilado. Se estiver utilizando uma distribuição Linux, use o repositório do PGDG. Se for uma distribuição que usa pacotes RPM, utilize o repositório YUM do PGDG, se for uma distribuição que utiliza pacotes DEB utilize o repositório APT do PGDG. Feito isso, faça atualizações de segurança do seu sistema operacional com frequência. Muitas invasões exploram falhas de segurança conhecidas e já corrigidas. Mas você precisa atualizar o seu Sistema Operacional (incluindo o PostgreSQL), senão o trabalho dos desenvolvedores para corrigir as falhas de segurança não adiantam nada.

    Limite o acesso físico

    Cuide do acesso físico ao servidor. Onde seu servidor fica? Lembre-se que qualquer pessoa que tenha acesso físico ao servidor pode para começar tirar ele da tomada… e pode até ser sem querer. Com um pouco de conhecimento a pessoa pode dar um boot num pen drive com um Linux qualquer e ter acesso TOTAL ao seu servidor e fazer o que ele quiser. Portanto, guarde seu servidor em um local seguro. E por mais que você tenha gastado muito dinheiro para compra-lo, não coloque ele numa vitrine para todos contemplarem ele. Servidores devem ficar numa sala escondida onde apenas quem precisa sabe onde fica e pode entrar lá. Trabalhei por anos na Itautec ao lado do CTO do Itaú. Ia jantar lá toda semana e nunca soube em que andar ficam os servidores.

    Limite o acesso privilegiado remoto

    Algumas pessoas provavelmente terão acesso remoto ao servidor. A primeira coisa a fazer é limitar o número de pessoas que vão ter acesso. Quem realmente precisa ter acesso à ele? A segunda é criar usuários únicos para cada uma delas no SO e dar uma senha diferente para cada uma delas. Rastreie a conexão das pessoas no servidor. Se cada um tiver um usuário diferente, você saberá quem se conectou quando. Não confie apenas em senhas para o acesso. Exija que os usuários tenham certificados para poder acessar o servidor.

    Utilize conexões encriptadas com SSL

    Se toda a informação da sua conexão trafegar pela rede pública sem encriptação…. toda a sua preocupação com segurança vai por água a baixo. Então se os seus dados não trafegam numa rede segura e isolada, configure no servidor e clientes para minimizar a chance ter seus dados roubados inadvertidamente, inclusive senhas. Veja na documentação como fazer isso e teste com calma antes de ativar conexões hostssl no pg_hba.conf

    Proteja o IP do servidor

    Seu servidor jamais deve ter um IP válido na Internet. Isso é um erro imperdoável. Para chegar ao servidor você deve primeiro acessar um servidor intermediário, através de um Firewall e ou uma VPN. Jamais deixe seu servidor exposto numa rede pública. O resultado é fatal.

    Limite o acesso das aplicações

    O PostgreSQL possui um mecanismo sofisticado e simples para filtrar as conexões antes de chegarem ao seu banco de dados. Ele se chama pg_hba.conf e possui um capítulo específico na documentação só sobre ele. LEIA. Se você utiliza alguns poucos servidores de aplicação, então você deve limitar o acesso a estes IPs específicos individualmente. Se você tem uma aplicação client/server, limite o acesso a uma faixa de IPs. Jamais libere tudo. Limite também qual usuário ou grupo pode utilizar qual base. Você pode utilizar também as opções sameuser se tiver uma base para cada cliente por exemplo. Se você tem uma aplicação client/server, pode optar também por utilizar uma autenticação via LDAP.

    Cuide das suas senhas

    Cuidar de senhas é uma baita dor de cabeça. O PostgreSQL oferece algumas ferramentas para te ajudar:

    • Senhas fáceis são um problema contra ataques de força bruta. O PostgreSQL possui o módulo do contrib chamado auth_delay para te ajudar a criar um atraso na autenticação, dificultando bastante ataques de força bruta. Não é algo muito elegante mas pode te ajudar se perceber que está sofrendo ataques desse tipo.
    • Outro módulo mais elegante é o uso do módulo passwordcheck. Este faz uma checagem automática toda vez que você criar um usuário com senha ou tentar alterar a senha. Se a senha for considerada fraca o comando dá erro e rejeita a senha. Ele tem um algorítimo próprio para definir as regras sobre o que é uma senha ruim. Você pode alterar o código fonte para mudar as regras se quiser.
    • Utilize outro método de autenticação que não MD5 ou SHA (o SCRAM-SHA-256 for introduzido no PostgreSQL a partir da versão 10). O PostgreSQL fornece varias alternativas como
      • GSSAPI
      • SSPI
      • Ident / Peer
      • LDAP
      • RADIU
      • Certificado SS

    Privilégios: menos é mais

    Você deve criar usuários separados para as suas aplicações e limitar o seu acesso:

    • Jamais, em hipótese alguma utilize um superusuário para a aplicação se conectar no banco de dados. Se alguém conseguir acesso ao banco de dados com um superusuário ele vai poder fazer qualquer coisa. E qualquer coisa não é algo nada divertido aqui.
    • Um usuário deve ser o dono dos seus objetos. Você vai utilizar este usuário apenas para o deploy. A aplicação jamais deve utilizar este usuário. O dono (owner) dos objetos pode criar e destruir qualquer objeto no banco de dados, logo, por uma questão de segurança, deve ficar protegido e longe da aplicação.
    • Se o usuário deve utilizar uma senha para entrar na aplicação e ele tiver uma senha no banco de dados, lembre-se que a senha do banco de dados não pode ser a mesma da aplicação. A coisa mais fácil que existe é o seu usuário instalar um client (pode até ser numa planilha via ODBC) e acessar diretamente o seu banco de dados com o usuário e senha dele. Adivinha o que pode acontecer se o seu usuário sair fazendo UPDATE e DELETE diretamente nas tabelas do sistema? Adicione um sufixo e um prefixo para o nome do usuário no banco de dados, faça a mesma coisa com a senha e depois embaralhe ela com um MD5 ou um SHA, depois crie o usuário no banco de dados. Quando for autenticar o usuário refaça a mesma operação todas as vezes. Não é um método muito seguro, mas ajuda a tirar os usuários comuns mal intencionados (como um funcionário comum que quer pedir demissão) de fazer um estrago.
    • Se todos os usuários da aplicação utilizam o mesmo usuário do banco de dados ou um pequeno grupo de usuários no banco de dados, você vai ter que guardar a senha deste usuário em algum lugar na máquina onde está a aplicação. Jamais guarde isso em um arquivo texto puro. Qualquer um que tiver acesso à máquina vai poder abrir este arquivo e fazer a festa no seu banco de dados. Você pode encriptar um arquivo com uma chave guardada dentro da aplicação. Também pode utilizar outros métodos de autenticação sem senha, utilizando certificados.
    • Como os usuários da aplicação no banco de dados não são donos dos objetos, você vai ter que conceder privilégios em cada tabela/função/visão/sequencia, etc individualmente. Antes de mais nada, dê uma olhada na documentação para aprender como isso funciona direito. Ajustar isso é um trabalho chato e tedioso. Ninguém gosta de fazer isso, mas precisa ser feito. E precisa ser feito no ambiente de desenvolvimento e homologação também. É terrível quando você faz um deploy na produção e a aplicação para de funcionar por falta de um simples GRANT. Isso acontece quando os testes foram feitos com um usuário com mais privilégios que o da produção. Tente dar apenas os privilégios extremamente necessários para cada usuário ou grupo de usuários (role). Se você nunca apaga registros de uma tabela, não dê um GRANT de DELETE nela. Fazer este ajuste fino em cada tabela pode levar muito tempo. As pessoas tendem a dar GRANT em tudo e apertar com bastante força o “botão do FODA-SE”! Resista a tentação. Se você tem centenas ou milhares de objetos para dar GRANT e não tem condições de revisar toda a sua aplicação para isso, revise pelo menos o acesso aos objetos mais sensíveis. A regra nesse caso é: “o cofre não pode ser mais caro que o ouro”. Então avalie o custo de acertar todos os privilégios um por um e avalie o custo de alguém apagar todos os dados em uma tabela com dados críticos.
    • Se você tem uma tabela com dados realmente importantes, você não deveria deixar a sua aplicação fazer SELECT, UPDATE, DELETE diretamente. Ao invés disso, crie visões (views) e funções que filtrem o acesso aos dados para você a sua aplicação. Assim você impede um UPDATE sem WHERE por exemplo ou o acesso à todas as linhas de uma tabela que tem restrições de privacidade.
    • Se você armazena dados realmente sensíveis como números de cartão de crédito (tenho medo de quem armazena esse tipo de coisa…) você deve encriptar as informações nestas colunas. O PostgreSQL tem um módulo do contrib chamado pgcrypto que faz isso. Não é algo trivial de se utilizar. Precisa gastar um tempo para entender como fazer isso. Mas é praticamente a única opção se você realmente precisa armazenar dados assim. Nem o seu DBA deve poder ver as informações nessas colunas!
    • Se você tem restrições severas a quais linhas de uma tabela o seu usuário pode acessar você pode utilizar o políticas de acesso em nível de linha. Não é algo tão complexo mas exige um pouco de planejamento para utilizar. A documentação tem alguns exemplos simples para lhe dar uma ideia de como funciona na prática.

    Proteja a sua aplicação

    O lado da aplicação é um lado frágil da corrente em termos de segurança. Você não pode evitar por exemplo que um servidor web fique exposto à uma rede pública como já fez com o banco de dados. Como está mais vulnerável você deve tomar uma serie de medidas para limitar o estrago o servidor onde a aplicação está seja comprometido. Então além de praticamente adotar os mesmos cuidados que utilizou no seu servidor de banco de dados, o lado da aplicação deve tomar cuidados adicionais.

    Trilhas de auditoria

    Uma forma importante de auditar quem mexeu no meu queijo e ter trilhas de auditoria em tabelas específicas. Saber quem alterou o que e quando é fácil e existem várias extensões prontas para fazer isso. Ou você também pode criar um gatilho para alimentar uma tabela de auditoria. Claro que você tem que proteger a tabela com os dados de auditoria e não dar GRANT para nenhum usuário dar DELETE ou UPDATE nela. Se o usuário da aplicação for o dono da tabela de auditoria então… melhor nem fazer.

    SQL Injection

    Este é um mal que afeta aplicações descuidadas, principalmente aquelas expostas na interntet. Existem zilhões de receitas prontas para invadir bancos de dados utilizando SQL Injection. E por incrível que pareça, as pessoas continuam caindo nisso! O assunto é um pouco extenso, mas tenho um artigo escrito especificamente sobre isso aqui. Veja que neste tipo de ataque, você não precisa explorar nenhuma vulnerabilidade do servidor, nem ter qualquer tipo de senha. O único elo frágil aqui é a sua aplicação. Então ou você aprende a escrever aplicações blindadas contra SQL Injection, ou você será invadido. Certeza.

    Gere logs

    Logs podem lhe ajudar a entender o que está acontecendo quando as coisas dão errado. Você pode sofrer uma invasão, perder dados e ser invadido novamente depois por não ter se protegido adequadamente. A única forma de entender o que aconteceu é gerar log no SO, na aplicação e no banco de dados. Gere logs sempre e aprenda a analisa-los de forma eficiente. Hoje temos uma infinidade de ferramentas para ajudar nisso. JUST DO IT!

    Se tudo o mais falhar: backup

    Parece besteira, mas muita gente não tem a menor ideia de como fazer um backup direito num banco de dados e tem aplicações enormes rodando em produção sem jamais terem lido a documentação sobre isso. Só um detalhe importante: ter um standby não lhe protege contra perda de dados em caso de invasão. Se o invasor apagar os dados de uma tabela em produção, esta alteração vai ser propagada para o standby. Portanto, você NÃO PODE FICAR SEM BACKUP. E como eu já escrevi e repeti por aqui… Dump não é backup!!!

  • Sintaxe no PostgreSQL: endereço de rede

    Bom, chega um ponto em que estou falando mais sobre tipos de dados do que sobre sintaxe propriamente dito. O PostgreSQL é um SGDB que nasceu com uma proposta ousada, não apenas substituir o Ingres, mas ter uma arquitetura orientada a objetos e ser muito extensível. Um dos impactos disso é a capacidade de se criar vários tipos de dados diferentes. É realmente simples de fazer isso. Quando vimos o ENUM, vimos que você tem o CREATE TYPE, mas é só a ponta do iceberg: você tem o CREATE OPERATOR, CREATE AGGREGATE, CREATE CAST, CREATE ACCESS METHOD, CREATE COLLATION e por aí vai. Você nem precisa conhecer a linguagem C para fazer muita coisa interessante.

    Uma das coisas interessantes que o PostgreSQL faz é criar tipos de dados novos. É quase um vício. Quase todo ano aparece um tipo de dados novo. O capítulo “Data Types” da documentação está dividido em 20 sessões na versão 10 do PostgreSQL. Na versão 7.1 eram apenas 8. Cada sessão apresenta um conjunto de tipos de dados específico. É claro que isso começa a parecer jabuticaba (uma daquelas coisas que só tem no Brasil…). Na verdade é mesmo. São extensões ao padrão SQL. Ninguém mais tem. Mas se considerarmos que a linguagem SQL é fortemente tipada, acho que os demais SGDBs deveriam ser um pouco mais desta forma também. Todos os SGDBs correram para criar uma implementação de XML e JSON nos seus bancos de dados. Mas existem muitas outras situações em que criar um tipo de dados específico para uma situação ajuda muito.

    Vamos ver o caso específico de redes aqui. Este é um caso emblemático, pois é bem antigo no PostgreSQL e exemplifica bem como um tipo que poderia ser apenas um VARCHAR, pode ser muito mais que isso. O Postgres possui atualmente 4 tipos que armazenam endereços de rede:

    • inet: Armazena endereços IPv4 ou IPv6 e opcionalmente a subrede ou máscara (ok, é mais comum ouvir em inglês netmask).
    • cidr: Armazena a rede ou netmask da rede;
    • macaddr: Armazena  endereços MAC ou MAC addresses;
    • macaddr8: Semelhandte ao macaddr, mas utilizando o formato EUI-64 com 6 ou 8  bytes.

    inet

    A sintaxe para fazer a coerção para o tipo correto é a mesma que demonstramos no primeiro episódio da nossa saga. Vejamos o uso do inet:

    SQL
    teste=# SELECT inet '192.168.0.1/24' AS ip;
           ip
    ----------------
     192.168.0.1/24
    (1 row)
    
    teste=# SELECT  '192.168.0.1/24'::inet AS ip;
           ip
    ----------------
     192.168.0.1/24
    (1 row)
    
    teste=# SELECT  CAST('192.168.0.1/24' AS inet) AS ip;
           ip
    ----------------
     192.168.0.1/24
    (1 row)

    Cada um dos tipos possui uma sintaxe específica que é aceita e convertida internamente antes de armazenar. A primeira vantagem óbvia é a validação. Se você tentar inserir um valor inválido, o Postgres vai acusar um erro imediatamente, o que não aconteceria se você utilizar um simples VARCHAR:

    SQL
    teste=# SELECT inet '192.168.0.0.0/24' AS ip;
    ERROR:  invalid input syntax for type inet: "192.168.0.0.0/24"
    LINE 1: SELECT inet '192.168.0.0.0/24' AS ip;
                        ^
    teste=# SELECT inet '192.168.0.257/24' AS ip;
    ERROR:  invalid input syntax for type inet: "192.168.0.257/24"
    LINE 1: SELECT inet '192.168.0.257/24' AS ip;

    Claro que você pode criar uma função que faz esse tipo de validação na sua aplicação. Mas aqui você já tem isso pronto. Veja que o formato inet admite vários formatos diferentes de entrada, considerando sempre a máscara também. Vejamos alguns exemplos:

    SQL
    teste=# SELECT inet '192.168.0.1/32' AS ip;
         ip
    -------------
     192.168.0.1
    (1 row)
    
    teste=# SELECT inet '192.168.0.1/24' AS ip;
           ip
    ----------------
     192.168.0.1/24
    (1 row)
    
    teste=# SELECT inet '192.168.0/32' AS ip;
    ERROR:  invalid input syntax for type inet: "192.168.0/32"
    LINE 1: SELECT inet '192.168.0/32' AS ip;
                        ^
    teste=# SELECT inet '192.168.0/24' AS ip;
           ip
    ----------------
     192.168.0.0/24
    (1 row)

    Veja que um com máscara 32 o IP é exibido sem uma máscara uma vez que /32 é a mesma coisa não utilizar uma subrede. Já quando omitimos um dos últimos dígitos e utilizamos uma Classe C por exemplo, o PostgreSQL subentende que o último dígito é zero.

    Podemos trabalhar com IPv6 também:

    SQL
    teste=# SELECT inet '2001:0DB8:0000:0000:130F:0000:0000:140B' AS "IPv6";
              IPv6
    -------------------------
     2001:db8::130f:0:0:140b
    (1 row)
    
    teste=# SELECT inet '2001:DB8:0:0:130F::140B' AS "IPv6";
              IPv6
    -------------------------
     2001:db8::130f:0:0:140b
    (1 row)
    
    teste=# SELECT inet '2001:DB8::130F:0:0:140B' AS "IPv6";
              IPv6
    -------------------------
     2001:db8::130f:0:0:140b
    (1 row)

    cidr

    Aqui temos algo semelhante, mas pensando apenas na máscara:

    SQL
    teste=# SELECT cidr '192/16' AS mask;
     mask
    --------------
     192.0.0.0/16
    (1 row)
    teste=# SELECT cidr '192.168/16' AS mask;
          mask
    ----------------
     192.168.0.0/16
    (1 row)
    
    teste=# SELECT cidr '192.168.0/16' AS mask;
          mask
    ----------------
     192.168.0.0/16
    (1 row)
    
    teste=# SELECT cidr '192.168.0.0/16' AS mask;
          mask
    ----------------
     192.168.0.0/16
    (1 row)
    
    teste=# SELECT cidr '192.168.0.1/16' AS mask;
    ERROR:  invalid cidr value: "192.168.0.1/16"
    LINE 1: SELECT cidr '192.168.0.1/16' AS mask;
                        ^
    DETAIL:  Value has bits set to right of mask.

    Se você omitir o tamanho da máscara, o PostgreSQL vai deduzir o tamanho pela faixa de IPs que você fornecer:

    SQL
    teste=# SELECT cidr '10' AS mask;
        mask
    ------------
     10.0.0.0/8
    (1 row)
    
    teste=# SELECT cidr '128' AS mask;
         mask
    --------------
     128.0.0.0/16
    (1 row)
    
    teste=# SELECT cidr '192' AS mask;
         mask
    --------------
     192.0.0.0/24
    (1 row)

    É claro que a quantidade de dígitos que você fornecer também afeta a interpretação:

    SQL
    teste=# SELECT cidr '10' AS mask;
        mask
    ------------
     10.0.0.0/8
    (1 row)
    
    teste=# SELECT cidr '10.1' AS mask;
        mask
    -------------
     10.1.0.0/16
    (1 row)
    
    teste=# SELECT cidr '10.1.2' AS mask;
        mask
    -------------
     10.1.2.0/24
    (1 row)
    
    teste=# SELECT cidr '10.1.2.3' AS mask;
        mask
    -------------
     10.1.2.3/32
    (1 row)

    macaddr

    A sintaxe para o macaddr admite o uso dos separadores ‘.’, ‘:’, ‘-‘ ou nenhum separador, dependendo da forma como você agrupar ou não os dígitos:

    SQL
    teste=# SELECT macaddr '01:02:03:04:05:06' AS mac;
            mac
    -------------------
     01:02:03:04:05:06
    (1 row)
    
    teste=# SELECT macaddr '01-02-03-04-05-06' AS mac;
            mac
    -------------------
     01:02:03:04:05:06
    (1 row)
    
    teste=# SELECT macaddr '01.02.03.04.05.06' AS mac;
    ERROR:  invalid input syntax for type macaddr: "01.02.03.04.05.06"
    LINE 1: SELECT macaddr '01.02.03.04.05.06' AS mac;
                           ^
    teste=# SELECT macaddr '0102.0304.0506' AS mac;
            mac
    -------------------
     01:02:03:04:05:06
    (1 row)
    
    teste=# SELECT macaddr '0102-0304-0506' AS mac;
            mac
    -------------------
     01:02:03:04:05:06
    (1 row)
    
    teste=# SELECT macaddr '0102:0304:0506' AS mac;
    ERROR:  invalid input syntax for type macaddr: "0102:0304:0506"
    LINE 1: SELECT macaddr '0102:0304:0506' AS mac;
                           ^
    teste=# SELECT macaddr '010203:040506' AS mac;
            mac
    -------------------
     01:02:03:04:05:06
    (1 row)
    
    teste=# SELECT macaddr '010203-040506' AS mac;
            mac
    -------------------
     01:02:03:04:05:06
    (1 row)
    
    teste=# SELECT macaddr '010203.040506' AS mac;
    ERROR:  invalid input syntax for type macaddr: "010203.040506"
    LINE 1: SELECT macaddr '010203.040506' AS mac;
                           ^
    teste=# SELECT macaddr '010203040506' AS mac;
            mac
    -------------------
     01:02:03:04:05:06
    (1 row)

    Apesar de aceitar vários formatos, o padrão IEE especifica o uso do segundo exemplo como correto.

    macaddr8

    Da mesma forma, o MAC com 8 bytes ao invés de 6 pode ser utilizado em diferentes formatos:

    SQL
    teste=# SELECT macaddr8 '01:02:03:04:05:06' AS mac;
               mac
    -------------------------
     01:02:03:ff:fe:04:05:06
    (1 row)
    
    teste=# SELECT macaddr8 '01:02:03:04:05:06:07:08' AS mac;
               mac
    -------------------------
     01:02:03:04:05:06:07:08
    (1 row)
    
    teste=# SELECT macaddr8 '01-02-03-04-05-06-07-08' AS mac;
               mac
    -------------------------
     01:02:03:04:05:06:07:08
    (1 row)
    
    teste=# SELECT macaddr8 '0102.0304.0506.0708' AS mac;
               mac
    -------------------------
     01:02:03:04:05:06:07:08
    (1 row)
    
    teste=# SELECT macaddr8 '0102030405060708' AS mac;
               mac
    -------------------------
     01:02:03:04:05:06:07:08
    (1 row)

    Note que se você inserir um MAC de 6 bytes num macaddr8 ele vai preencher 2 bytes com ff:fe no lugar dos bytes faltantes.

    Armazenamento

    É claro que os tipos de rede são mais eficientes em termos de armazenamento que utilizar simplesmente um VARCHAR. Cada dígito aqui é um dígito hexadecimal de 0 a F e não um byte completo de 00 a FF. Portanto, há uma economia de 50% do espaço ocupado. Em termos de espaço temos:

    • inet: 7 bytes com IPv4 e 19 bytes com IPv6
    • cdir: 7 bytes com IPv4 e 19 bytes com IPv6
    • macaddr: 6 bytes
    • macaddr8: 8 bytes

    Operadores

    A brincadeira começa a ficar interessante aqui. Se você olhar o capítulo “Funções e Operadores” na documentação, verá uma sessão específica só para tipos de rede. Antes de mais nada, vou criar uma tabela com alguns registros aleatórios para poder brincar aqui:

    SQL
    CREATE TABLE net (ip inet);
    
    INSERT INTO net SELECT inet (
        '10.' || 
        round(random()*255) || '.' ||
        round(random()*255) || '.' ||
        round(random()*255) || '/' || 
        '8')
    FROM generate_series(1,100);
    
    INSERT INTO net SELECT inet (
        '128.191.' || 
        round(random()*255) || '.' ||
        round(random()*255) || '/' || 
        '16')
    FROM generate_series(1,100);
    
    INSERT INTO net SELECT inet (
        '192.168.1.' || 
        round(random()*255) || '/' || 
        '24')
    FROM generate_series(1,100);
    
    INSERT INTO net SELECT 
        inet (round(random()*255) || '.' || 
              round(random()*255) || '.' ||
              round(random()*255) || '.' ||
              round(random()*255) || '/' || 
              round(random()*4)*8) AS ip 
    FROM generate_series(1,100);

    Alguns operadores não são novidade como <, <=, =, >=, > e <>. Como esperado temos:

    
    
    
    
    
    SQL
    
    teste=# SELECT ip FROM net WHERE ip > inet '192.168.0.0';
            ip
    -------------------
     221.208.133.56/16
     248.244.222.86/16
     254.187.237.159/8
    (3 rows)
    
    teste=# SELECT ip FROM net WHERE ip < inet '192.168.0.0';
            ip
    ------------------
     110.46.113.5/24
     173.21.188.12
     13.117.195.196/8
     143.51.137.1/8
     47.222.9.180/0
     164.98.44.97/16
     38.91.99.5/24
    (7 rows)
    
    teste=# SELECT ip FROM net WHERE ip =  inet '164.98.44.97';
     ip
    ----
    (0 rows)
    
    teste=# SELECT ip FROM net WHERE ip =  inet '164.98.44.97/16';
           ip
    -----------------
     164.98.44.97/16
    (1 row)

    Mas o PostgreSQL traz outros operadores mais interessantes:

    • << está contido
    • <<= está contido ou igual
    • >> contém
    • >> contém ou igual
    • && contém ou está contido
    • NOT bit a bit
    • AND bit a bit
    • OR bit a bit
    • +

    Vejamos como ficam alguns exemplos:

    SQL
    teste=# SELECT ip FROM net WHERE ip <<  inet '192.168.1.0/16';
            ip
    ------------------
     192.168.1.32/24
     192.168.1.115/24
     192.168.1.168/24
    
    teste=# SELECT ip FROM net WHERE ip >>  inet '192.168.1.0/32';
            ip
    ------------------
     192.168.1.32/24
     192.168.1.115/24
     192.168.1.168/24
     192.168.1.233/24
     192.168.1.213/24
    
    teste=# SELECT
    teste-#     ip,
    teste-#     ~ip AS "NOT",
    teste-#     ip & inet'10.0.0.1' AS "AND",
    teste-#     ip | inet'10.0.0.1' AS "OR"
    teste-# FROM net LIMIT 5;
           ip        |        NOT        |   AND    |      OR
    -----------------+-------------------+----------+---------------
     10.38.170.142/8 | 245.217.85.113/8  | 10.0.0.0 | 10.38.170.143
     10.134.7.73/8   | 245.121.248.182/8 | 10.0.0.1 | 10.134.7.73
     10.70.82.112/8  | 245.185.173.143/8 | 10.0.0.0 | 10.70.82.113
     10.224.98.126/8 | 245.31.157.129/8  | 10.0.0.0 | 10.224.98.127
     10.75.233.180/8 | 245.180.22.75/8   | 10.0.0.0 | 10.75.233.181
    (5 rows)
    
    teste=# SELECT
        ip,
        ip + 64 AS soma,
        ip - 64 AS subtracao,
        ip - inet'10.0.0.1' subtracao_ip
    FROM net LIMIT 5;
            ip        |       soma       |    subtracao     | subtracao_ip
    ------------------+------------------+------------------+--------------
     10.38.170.142/8  | 10.38.170.206/8  | 10.38.170.78/8   |      2534029
     10.134.7.73/8    | 10.134.7.137/8   | 10.134.7.9/8     |      8783688
     10.199.2.34/8    | 10.199.2.98/8    | 10.199.1.226/8   |     13042209
     10.78.195.52/8   | 10.78.195.116/8  | 10.78.194.244/8  |      5161779
     10.153.148.224/8 | 10.153.149.32/8  | 10.153.148.160/8 |     10065119
    (5 rows)

    Agora a cereja do bolo. Primeiro vamos aumentar o volume de dados na tabela:

    SQL
    INSERT INTO net SELECT inet (
        round(random()*255) || '.' ||
        round(random()*255) || '.' ||
        round(random()*255) || '.' ||
        round(random()*255) || '/' || 
        '8')
    FROM generate_series(1,100000);

    Agora vejamos o plano de execução de uma de nossas consultas:

    SQL
    teste=# EXPLAIN ANALYZE SELECT ip FROM net WHERE ip <<  inet '192.168.1.0/32';
                                                QUERY PLAN
    --------------------------------------------------------------------------------------------------
     Seq Scan on net  (cost=0.00..1697.75 rows=1 width=7) (actual time=18.627..18.627 rows=0 loops=1)
       Filter: (ip << '192.168.1.0'::inet)
       Rows Removed by Filter: 100300
     Planning time: 0.082 ms
     Execution time: 18.660 ms

    Você não precisa entender muito sobre planos de execução. Apenas observe que fizemos um “Seq Scan” na tabela “net”, ou seja, varremos todas as linhas da tabela em busca de quais atendem aos requisitos da nossa cláusula WHERE. E claro: levou 18,66ms para rodar o comando.

    Agora vamos criar um índice e rodar o mesmo plano de execução:

    SQL
    teste=# CREATE INDEX ON net (ip);
    CREATE INDEX
    teste=# EXPLAIN ANALYZE SELECT ip FROM net WHERE ip <<  inet '192.168.1.0/32';
                                                         QUERY PLAN
    ---------------------------------------------------------------------------------------------------------------------
     Index Only Scan using net_ip_idx on net  (cost=0.29..2.52 rows=1 width=7) (actual time=0.027..0.027 rows=0 loops=1)
       Index Cond: ((ip > '192.168.1.0'::inet) AND (ip <= '192.168.1.0'::inet))
       Filter: (ip << '192.168.1.0'::inet)
       Heap Fetches: 0
     Planning time: 0.336 ms
     Execution time: 0.063 ms
    (6 rows)

    Agora o plano de execução passou a utilizar o índice “net_ip_idx” que criamos. E o resultado? Um tempo de execução de 0,062ms. Este é o grande pulo do gato com os operadores. Suas operações já são indexáveis por natureza. E isso você nunca vai conseguir imitar utilizando um VARCHAR.

    Funções

    Além dos operadores, temos também algumas funções nativas para trabalhar com tipos de dados para redes. Estas não são indexáveis por natureza, mas você pode criar índices incluindo estas funções se for realmente importante. Você pode e deve ver a lista das funções existentes na documentação oficial. Sempre. Não pretendemos aqui substituir a documentação, apenas dar uma visão mais clara sobre alguns pontos específicos. Então vá lá e faça uma visita.

    Conclusões

    Tipos de dados específicos como os tipos de rede são muito poderosos, eles nos ajudam de diversas formas:

    • Armazenamento otimizado, ocupando muito menos espaço;
    • Validação nativa bem feita;
    • Existe um arsenal operadores e funções prontas para utilizarem estes tipos de dados;
    • Operadores nativos utilizam índices automaticamente sem que você precise fazer nada além de criar um índice comum no campo.
plugins premium WordPress