O #PGBR2011 foi um marco para mim. Morreu aquele jeito moleque de juntar a turma e ficou claro que a “pegada” da comunidade mudou. A turminha que se conheceu há 10 anos atrás nos FISLs da vida cresceu e tem desafios para lá de cabeludos na mão. Eu mesmo jamais imaginaria que estaria trabalhando com um dos cases mais importantes de Postgres do Brasil há 10 anos atrás. Acho que eu nem imaginava que daria para fazer o que a gente faz com o Postgres hoje naquele tempo. Mas a gente apostou, eu consegui abandonar a minha vida de DBA Oracle e estou feliz da vida me matando de trabalhar com Postgres quase em tempo integral (aka 24/7).

O evento foi num hotel. Não foi numa universidade, não foi num lugar barato. E para a nossa surpresa: fomos nós mesmos que pagamos boa parte da conta: Eu, o Euler, Fabrízio, o Charly, o Coutinho, etc. Nós patrocinamos o evento. Nós pudemos tirar $$ do bolso para fazer o evento acontecer. Para quem não sabe, eu e o Euler Taveira, somos Sócios da Timbira, que está já há uns 2 anos na estrada. A gente nunca teve muita pressa de crescer. Nem no nosso site a gente investiu muito. Na verdade a gente está tendo de expandir para dar conta da demanda. Não, ninguém está ganhando muito dinheiro. Talvez empresas maiores como a Dextra e a 4Linux estejam melhor. Certamente a VMware vai bem. Mas estamos vivendo disso. No caso da Timbira, vivendo só disso. E temos encontrado bons parceiros no caminho. Direta ou indiretamente, estivemos presentes em várias palestras comigo, com o Euler Taveira, com o Dickson Guedes, com o Roberto Mello, com o Fabrízio Mello e tem mais um que logo logo deve estar finalmente assumindo seu lugar junto a Timbira. E tem mais, eu, o Euler e o Guedes (os 3 dos 4 fundadores da Timbira) ganharam prêmios pela nossa atuação na comunidade durante o evento. Não, nenhum de nós fez parte da comissão que elegeu os premiados. Acho que dificilmente vamos encontrar alguém que respira mais Postgres no Brasil do que o Euler Taveira. Não foi por acaso que ele foi nomeado para 4 das 5 categorias do “Prêmio PGBR2011″. É realmente uma honra ter estes caras como colegas de trabalho. Mas eu também estou finalmente dando meus pulinhos. Hoje eu teria tanta coisa para escrever aqui no blog que eu nem sei por onde começar. Preciso de um pouco de tempo para voltar a escrever para valer.

Não é pouca coisa né? Mas este ano foi a primeira vez que mandamos fazer um folder da Timbira. A gente passa tanto tempo trabalhando com Postgres que não tivemos tempo de “aparelhar” a nossa empresa. Sim, temos que melhorar isso. Bom, mas tirando a propaganda toda, (que é a primeira vez que eu cito aqui no blog), a questão é que agora a nossa pegada mudou. Não somos mais moleques. Ninguém mais é. Mesmo o Diogo Biazus com o seu novo visual Punk, sabe que a fase da molecagem passou. Ele também é empresário. E são empresários a maioria dos palestrantes que estiveram no evento. Nem tudo são flores. Eu descobri por exemplo que o Carlos Smanioto, um dos ícones que começou a publicar os primeiros artigos sobre Postgres na SQL Magazine estava com dificuldades alguns meses antes do PGBR2011. Outros dois grandes colegas excepcionais ficaram desempregado recentemente. Eu também tenho minhas dívidas para pagar…. Não estamos vivendo de brisa. Estamos trabalhando muito, errando muito e aprendendo muito. No entanto, me arrisco a dizer que estamos felizes. Não é fácil explicar isso para nossas famílias. Mas é bem verdade. Eu posso dizer que trabalho com o que eu gosto e isso não é para qualquer um.

Mas voltando a provocação do Sr. Fernando Ike. Eu tenho sempre medo do que esse cara diz, pois ele tem a mania de acertar – ele também tem a mania de ser sorteado para alguma coisa em todo evento que vai. Já vi ele ser sorteado 2 vezes num único evento. E essa história de banco de dados virar comodity, já está escrito nas estrelas faz um tempo. Quando você vira especialista numa coisa, não quer que ela deixe de existir, pois você se dedicou por anos a fio para adquirir um bom domínio naquilo. Os bancos da dados relacionais não vão deixar de existir. Mas quem acha que eles vão continuar com o seu “reinado”, como o centro do universo que muito DBA acha que é… já caiu do cavalo. Isso está ruindo mesmo. Claro, isso que não muda tão rápido assim. Ninguém acha que as transações bancárias vão começar a rodar em bases NoSQL. Mas é inútil negar que tem muita informação que não precisa de um banco de dados transacional 100% ACID para cuidar. E os novos desafios estão aí para quem quiser enxergar ou não.

Enquanto a adoção do Postgres cresce no mundo todo e notoriamente no Brasil, um novo movimento surge quebrando paradigmas e a gente vai ter de aprender a conviver com isso. A palestra da VMware estava lá para quem quisesse enxergar. A revolução acontecendo bem na nossa cara. Eu sei que o Ike tem uma visão clara disso. Quando você se afasta e olha mais de longe, consegue ver o mundo girar. Esse negócio de nuvem… tem muita balela e gente querendo vender coisa velha com nome novo. Mas quando eu olho o número de clientes nossos que estão colocando seus software como SaaS, é notavel que as coisas estão mudando. E olha só, a Locaweb estava lá no evento…

É pessoal, eu não sei o próximo PGBR vai rolar ou como ele será. Sei que é bem possível que ele ocorra. Não sei se eu terei tempo para me dedicar a ele como me dediquei em 2011. Nem se as minhas prioridades estarão neste rumo até lá. Mas o mundo está girando… independente de nós sentirmos isso ou não. Os polos magnéticos vão se inverter, uma nova era do gelo vai vir e um novo super continente vai se formar. Precisamos mesmo olhar para fora da caixa. Mas enquanto isso, posso dizer que o Postgres tem me surpreendido muito. Tem se mostrado um grande parceiro, e trabalhar com ele tem sido divertido.

Bom, agora tem um monte de coisas para fazer aqui, até a próxima cervejada pessoal!

OBS: Antes que alguém pergunte… o nome Timbira foi escolhido pelo Euler que tem um blog com esse nome bem antes da “Empresa Timbira nascer”. Ele ajudou muito na tradução da documentação e internacionalização do Postgres. Como ele é Goiano e tem lá uma paixão louca pelo Brasil, eu acho que escolher um nome indigena para a nossa “Empresa Brasileira de Postgres” faz até muito sentido. Claro, é bem engraçado quando as pessoas pedem para repetir o nome da empresa umas 2 ou 3 vezes até entender. Todo mundo espera um buzzword em inglês. Mas depois de um tempo, eu achei o nome tão bacana quanto continuar escrevendo um blog em pt_BR e fazer parte do nosso planeta tupiniquim, . De toda forma, quanto mais masterfucking é o cliente, mais legal é ver a Timbira entrando lá de verde e amarelo…

Fazer um evento num hotel tornou tudo muito mais caro. Foram mais de R$ 16K com aluguel das salas, projetores, sonorização, sala VIP, cofee break e claro, a cervejada. As despesas com hospedagem de palestrantes também foram altas, gastamos uns R$ 8K com isso. Mas o retorno foi incrível. O preço da diária não foi tão alto para quem veio de fora (negociamos isso em abril) e estavam todos lá. Sair para dar um passeio em São Paulo com a turma, dormir até mais tarde ou mesmo ficar de bobeira no saguão com os palestrantes internacionais tomando uma caipirinha. Isso tudo ficou mais fácil. Foi um enorme avanço em relação a 2009. Em 2009 só a organização pode desfrutar do excelente hotel da Unicamp. Sim, o hotel da Unicamp era muito mais agradável. A Unicamp em si é muito mais agradável. O mar de prédios de São Paulo não é algo tão bacana assim. Mesmo tirando a nossa tradicional “foto do Bozo” na piscina, a sensação de estar espremido entre prédios é meio bizarra. Mas o evento se tornou mais acessível para todos. No final, quem mais ganhou foi quem pagou para ir ao evento e pode estar mais próximo dos palestrantes e demais congressistas.

Trazer tanta gente de fora, não foi moleza. O Flávio perdeu a conta de quantas vezes foi até o aeroporto. Além de convidar os Srs. Alvaro Herrera, Bruce Momjian, Dave Page, Greg Smith e Koichi Suzuki, o Sr. Jaime Casanova passou pela chamada de trabalhos e houveram pessoas que saíram de outros países só para vir ao PGBR2011, como o Sr. Joe Abbate que também aproveitou para passear pelo Brasil, claro. Bom, o fato é que o evento novamente chamou a atenção de pessoas de outros países e isso foi algo muito interessante de ver. Tenho de reconhecer que assistir uma palestra em espanhol parece mais difícil que assistir uma palestra em inglês. Acho que a nossa overdose diária de documentação em inglês deve ter algo haver com isso. Vamos ter de repensar nisso no próximo evento.

Houveram alguns problemas menores como erros na impressão dos certificados e o atraso no recebimento dos chaveiros e adesivos. O elefante de pelúcia não ficou uma maravilha, mas se esgotou nos primeiros minutos do evento. O chaveiro ficou muito bacana também. No final acho que ficamos bem. A comida do hotel era realmente muito boa. O almoço não tinha muita variedade mas o peixe deles estava ótimo. A sala VIP era VIP mesmo. Dois bons sofás onde era perfeitamente possível tirar um bom cochilo, uma mesa para quem precisasse terminar uma palestra, fazer uma reunião de negócios ou atender um cliente remoto (sim, isto SEMPRE acontece).

Achei a estrutura vertical do hotel um pouco incômoda. Você tinha que ficar subindo e descendo escadas dos auditórios para o salão de exposições. Os patrocinadores podem não ter gostado muito disso também. Mas acho que não foi algo terrível. Por outro lado, o salão de exposições era bem espaçoso, e conseguiu comportar todos no intervalo para o café sem problemas. E olha que era muuuita gente.

As inscrições foram muito mais tranquilas que em 2009. Mais antecedência, o apoio com atendimento telefônico e um sistema de inscrições mais maduro ajudaram muito. Não que não houvessem problemas. O fato da prefeitura de Porto Alegre não emitir nota fiscal eletrônica, junto com a greve dos correios foi um tiro no pé. Mas o Euler e a Débora estão de parabéns pelo trabalho nesta área.

Então vejamos alguns números:

• Quase R$ 65K de custo no evento, sendo R$ 23K recebido pelas inscrições e o restante de 13 patrocinadores nacionais e internacionais. Este também foi o primeiro ano que não precisamos de ajuda da SPI.
• Mais de 240 pessoas inscritas no evento;
• Mais de 50 propostas de palestras na chamada de trabalhos e um total de 32 palestrantes presentes, fora os Lightning Talks.
• 400 ecobags, 200 chaveiros, 100 squeezes, 100 camisetas, 60 elefantes de pelúcia, 5 banners, 1000 cartazes, 1000 adesivos pequenos e 100 adesivos normais.
• 200 litros de chopp e inúmeras histórias para contar.

Foi muito bom ver todos vocês novamente, eu realmente estava com saudades do pessoal. Até a próxima gente.

• Saiu a lista dos palestrantes do PGBR2011. A grade ainda estamos montando.
• Sim, uma palestra minha foi aprovada (não, eu não faço parte da banca avaliadora), vou falar sobre processos de melhoria de desempenho em ambiente OLTP de alta concorrência. A palestra se chama: “Fazendo uma manada passar debaixo da porta”
• O link onde o site do PGBR está hospedado está com problemas sérios no link. Esperamos que isto esteja normalizado em breve.
• Foi publicada a minha participação no #DatabaseCast sobre PostgreSQL, no Imasters.
• Estamos mandando bala no material promocional. Tirando a sacola, tudo será vendido praticamente a preço de custo. Até agora serão:
•  400 ecobags para o material do evento;
• 100 squeezes em alumínio;
• 100 elefantes de pelúcia;
• 100 camisetas pólo;
• 200 chaveiros;
• 1000 adesivos;
• Um mês antes do evento ocorrer, temos 120 inscritos. Sim, brasileiro deixa tudo para a última hora… então devemos ter um número bem superior até lá.
• Teremos um prêmio para as pessoas que mais se destacaram nos últimos tempos. Estamos organizando isso ainda, mas será uma forma de valorizar aqueles que tem contribuído para o fortalecimento da comunidade brasileira.

O chopp está garantido no final do evento!!!

(ok, vai ter refrigerante também… mas não consegui achar o Guaraná Jesus por aqui)

Este ano tudo será diferente…. sim já é. Uma das maiores dificuldades do PGCon Brasil, agora rebatizado como PGBR, é a parte das inscrições. É o tipo de coisa difícil de fazer de forma voluntária. Nas edições anteriores o Euler Taveira e o Diogo Biazus se mataram para fazer as inscrições acontecerem. Bom, a gente continua se matando, mas desta vez temos uma forcinha. Temos algo revolucionário: um número de telefone!!! Ou seja, alguém poderá lhe ouvir, tirar suas dúvidas, falar como nós somos bacanas, ouvir reclamações e passar receitas de bolo pelo telefone. Não, a pessoa que irá atender o telefone não vai lhe ensinar a deixar o seu banco de dados mais rápido…. se a gente faz isso ninguém vai no evento,

Mas não é só isso, o Euler melhorou bastante a 3º versão do sistema de inscrições. As notas fiscais continuarão sendo um problema chato, pois a prefeitura de Porto Alegre – RS ainda não emite nota fiscal eletrônica. Ou seja, ainda vamos ter que continuar mandando pelo correio. Se você não precisa de nota fiscal, pegue o seu boleto, pague, autentique e use-o como comprovante. Dá um trabalhão despachar tudo pelo correio.

Se você pertence a um órgão público, se adiante por favor. Todo mundo sabe o mega trampo que é fazer o processo de empenho. Estamos com todos os documentos em ordem, a ASL (o PostgreSQL-BR é associado a ASL, que é quem nos dá respaldo jurídico e contábil), e já está cadastrada no SICAF. Facilite a sua vida e consulte o SICAF. Sim, o preço da inscrição para governo é mais caro. Também nos custa muito receber o dinheiro da inscrição de um órgão público. E o dinheiro só pode ser utilizado para custear o evento do próximo ano, uma vez que governo só paga depois do evento… e os nossos fornecedores não trabalham assim.

A grande novidade na minha opinião é a inscrição VIP. Todo mundo que se inscreve tem acesso às palestras nos 2 dias, coffe-break e a cervejada que deverá rolar no encerramento. Mas quem puder pagar um pouco mais, já pode incluir o custo do almoço no hotel. As vagas são limitadas, pois o restaurante do hotel não vai comportar todos. Mas para quem optar por isso, vai poder almoçar junto com os palestrantes, patrocinadores e a organização do evento. As vagas são limitadas a 80 pessoas, então corram, pois a maioria dos inscritos até agora optou mesmo pela inscrição VIP.

Bom, por enquanto é só, façam já sua inscrição e o chopp será por nossa conta. Em tempo: há também uma promoção para os 20 primeiros inscritos confirmados no evento. Eles ganharão um elefante de pelúcia do PGBR. Mas acredito que quando você estiver lendo isso, a promoção já tenha acabado. A não ser que o 20 primeiros demorem muito para confirmar (a.k.a. pagar) suas inscrições.

Os palestrantes, a programação e o local estão todos publicados no site do evento. Infelizmente não vou poder estar lá, mas já vi que a grade de palestrantes é excelente e será um evento bem bacana, incluindo um Dojo PL/pgSQL e os já conhecidos Lightning Talks.

Gostaria aqui de parabenizar os palestrantes Dickson Guedes, Diego Rossi, Diogo Biazus, Eduardo Wolak e Fabiano Machado Dias por palestrarem no evento e em especial para o Fabrízio de Royes Mello que é a pessoa que está liderando a organização do evento.

Não esqueçam de mandarem as fotos, publicarem as palestas, ok?

A chamada ficará aberta até o dia 09/09/2011 então não bobeie e mande logo as suas propostas. Este ano serão 4 modalidades diferentes (fora os Lightning Talks): Palestras normais de 50 minutos, tutoriais de 2 horas, hacker talks que podem der de 30 minutos até 2 horas e os painéis acadêmicos que serão expostos no saguão do evento. Tudo explicado no site do evento. Você pode mandar até 5 propostas diferentes para a banca avaliadora (da qual eu não faço parte) escolher.

Eu já estou preparando as minhas propostas, mas segue algumas que eu gostaria de ver lá. Eu sei que tem muita gente que já usa PostgreSQL há um tempão e acha que não teria nada de interessante para falar. Não se intimide, tenho certeza que se você usa o PostgreSQL há mais de um ano, deve se sentir à vontade para falar algum assunto como:

• Postgressssss, lendas urbanas sobre PostgreSQL e um apanhado da sua evolução nas últimas versões;

• Casos de sucesso de quem não tem vergonha de revelar que usa o PostgreSQL em negócios críticos;

• Porquê o PostgreSQL é cada vez mais amante predileta dos DBAs experientes;

• “Meu PostgreSQL não Conecta” e outras coisas que alguém tem de escrever para a gente não repetir novamente na lista…

• Ops, minha base já tem mais de 1TB… ;

• BI, Data Mining, OLAP, PL/R e outros bichos;

• Full Text Search, particularmente como raios se montam Ranks e dicionários personalizados;

• Funções de agregação personalizadas, operadores personalizados, tipos de dados personalizados e o que mais você tiver coragem de inventar;

• Bancos de dados em pesquisas científicas, como em biologia, física e outras ciências ocultas;

• Haks, muitos hacks! Queremos hacks em C, em Perl, Python, SPI, PL/pgSQL etc. Queremos nerds genuínos!!!

• Vou te apresentar a uma tal de libpq…

• Tuning em bases OLTP  com fucking hight concorrência;

• ETL (Extract Transform Load) em ambientes alucinógenos;

• pgbench e outras técnicas para emular a carga da aplicação em ambiente de homologação ou “hum…. então dá para fazer isso antes de sentar a aplicação no cliente?”

• Versionamento de DDL e como controlar do demônio da tasmânia das alterações de estrutura em desenvolvimento e produção sem ir parar no hospital;

• Segurem os trolls, vamos falar sobre sistemas de arquivos, tablespaces e discos de novo….

• Como fazer poesia com SQL e parar de fazer caquinha com PL/você_não_precisa_usar_isto_aqui.

• Técnicas (ok, se você gosta de buzzwords, pode chamar de “design patterns”) de otimização de processos e ajuste de SQL;

• “Rodei o EXPLAIN, e agora?”;

• Magia negra com Window Function;

• CTE, recursividade e como não destruir a memória do seu servidor;

• Localização, codificação de caracteres e coisas que infelizmente você tem de aprender se não quiser sofrer por toda a eternamente com isso;

• Segurança para preguiçosos (ou seja, para todo mundo);

• Técnicas de monitoramento, administração que funcionam e fazem sentido para seres mortais;

• Armadilhas no zoológico das replicações;

• Muito além das configurações do postgresql.conf: personalizando bases, roles , tabelas, tablespaces e até sessões para um ajuste perfeito;

• Eu sei, eu sei…. ACID, blá, blá, blá, Teoria Relacional, etc e tal, mas o C. J. Date diz que bi, bi, bi, bó, bó, bó…. mas eu quero muito ver “Técnicas de NoSQL integradas com PosgreSQL”;

• Backup e o “complexo de Chuck Norris”. (Quem respondeu a pesquisa sobre uso de PostgreSQL sabe do que eu estou falando);

• Técnicas de recuperação de desastres e como é chato ouvir “mas eu já faço assim há 5 anos e nunca deu nenhum problema…”;

• Não entendeu? Vou falar de novo: RECOVER, RECOVER, RECOVER!

• Quer dizer então que para ter um banco de dados é preciso ter um DBA na equipe ou aprender como fazer o trabalho de um?

OBS: Quem sabe este ano o indefectível Osvaldo Kussama não manda uma proposta?

OBS2: Se tiver alguma outra sugestão de palestra que você gostaria de ver no PGBR201, não deixe de deixar um comentário aqui! Vai que alguém gosta da ideia e você acaba tendo uma aula sobre aquele tema que vem lhe assombrando há tempos…

O Sr. Dickson Guedes resurgiu das cinzas em grande estilo e com um projeto muito bacana. O pgcasts é um screencast, ou seja, áudio e vídeo com uma demonstração de como fazer alguma coisa no PostgreSQL. Ver a tela dele fazendo enquanto vai comentando, é muito mais simples do que ler um artigo enorme num blog como o meu…. assuntos que eu levaria páginas para abordar ele mostra como fazer na prática com 20 a 30 minutos de screencast.

Muito bacana, eu recomendo. Até hoje (02/05/11) são 3 episódios e ele vem mantendo a média de um novo screencast por semana:

1. Instalando PostgreSQL 9.0
2. Trabalhando com datas no PostgreSQL
3. Alterando colunas de tipos conflitantes

Divirtam-se.

Para quem não sabe, o PGBR2011 (nome novo para o PGCon Brasil) está à pleno vapor e em sua 4ª edição estamos novamente dando um bom salto de qualidade. Vejamos algumas novidades:

5 Palestrantes internacionais Confirmados

• Álvaro Herrera (Chile)
• Bruce Momjian (EUA)
• Dave Page (Inglaterra)
• Greg Smith (EUA)
• Koichi Suziki (Japão)

Todos eles são desenvolvedores do PostgreSQL e tem grandes contribuições para a comunidade.

O evento será realizado no conforto do Hotel Century Paulista, em São Paulo

Os detalhes do local já estão acertados. A decisão de fazer o evento num hotel deverá ajudar bastante quem vem de longe. Você poderá se hospedar no mesmo local do evento. Assim as pessoas gastam menos com deslocamento e perdem menos tempo. Para quem for se hospedar, confira os preços especiais para quem for participar do evento. Recomendo fazer a sua reserva o quanto antes para evitar surpresas na última hora.

Para quem mora em São Paulo, também será uma grande vantagem, o local fica a apenas algumas quadras da estação Brigadeiro do metrô. Se você preferir vir de carro até o local, há um estacionamento com preço fechado para participantes do evento.

Serão 3 salas simultâneas que juntas comportam 470 pessoas, uma sala de apoio, um salão de exposições e um local para o famoso coffee break à tarde. Estamos esperando um público de 400 pessoas nos 2 dias do evento, que cairão numa 5ª e 6ª feira, diferente das edições anteriores. Notem que na 4ª, haverá um feriado.

Participe

Você pode ajudar:

1. Venha ao evento. Sua presença é o mais importante para nós. As inscrições deverão abrir em agosto. Como sempre, quem se inscrever com antecedência, vai poder aproveitar um preço especial.
2. Mande uma proposta de palestra. A chamada de trabalhos será aberta em meados de junho ou julho, fique atento.
3. Divulgue o evento:
   • Se você tem um blog, um site, pode divulgar um banner do evento ou falar sobre ele.
   • Se você utiliza o Twitter, fale sobre o evento e utilize a hash tag #PGBR2011.
   • Se você participa de alguma lista de discussão por e-mail, informe as pessoas sobre o evento. Não esqueça das boas maneiras e coloque um [off-topic] no assunto.
   • Se você estuda numa faculdade, estaremos fazendo alguns cartazes sobre o evento que você poderá afixar no mural.
4. Se você trabalha numa empresa de TI ou utiliza muito o PostgreSQL no seu trabalho, considere a possibilidade da sua empresa patrocinar o evento.
5. Se você gostaria de dar sugestões ou ajudar na organização do evento, entre na lista da comunidade.

Bom, vale a pena ler o artigo. Você verá que nos comentários o PostgreSQL começa a aparecer, e com boas avaliações. Mais interessante ainda é que o Thomas ignora ao máximo o PostgreSQL nos comentários. Claro, ele não é estúpido, não seria inteligente nem diplomático da parte dele. O máximo que ele chega a citar é que a Oracle tem o XE, que quem conhece sabe que é algo limitado e certamente foi lançado (a exemplo do que fez a MicroSoft e IBM) para retardar o avanço dos bancos de dados livres.

O post é de 2001 e os comentários perduram até 2010. De qualquer forma, fica claro, que os mesmos argumentos que ele utiliza para mostrar a superioridade do Oracle, serviriam para o PostgreSQL…. vale a pena ler.

Comparison between Oracle and Others

Bom, resumindo a história, eu precisei lançar mão das novas funções de janela, incorporadas na versão 8.4 do PostgreSQL. Para exemplificar aqui, vou utilizar uma base de exemplo conhecida de todos, o PAGILA. Eu tentei o DELLSTORE, mas os dados não apareceram tão bem distribuídos para efeito de visualização.

Bom, depois de criar uma base e importar os dados do PAGILA, eu criei uma visão para facilitar a minha vida e simplificar a análise, deixando de lado detalhes desnecessários:

CREATE OR REPLACE VIEW sales_pgday AS
    SELECT
        f.title,
        c.name AS category,
        SUM(p.amount) AS total_sales
        FROM
            (((((payment p JOIN rental r ON ((p.rental_id = r.rental_id)))
                JOIN inventory i ON ((r.inventory_id = i.inventory_id)))
                JOIN film f ON ((i.film_id = f.film_id)))
                JOIN film_category fc ON ((f.film_id = fc.film_id)))
                JOIN category c ON ((fc.category_id = c.category_id)))
        GROUP BY c.name, f.title
    ;

Com um select você verá os dados mais ou menos assim:

           title            |  category   | total_sales
-----------------------------+-------------+-------------
 AMADEUS HOLY                | Action      |       33.79
 AMERICAN CIRCUS             | Action      |      167.78
 ANTITRUST TOMATOES          | Action      |       37.90
 BAREFOOT MANCHURIAN         | Action      |       66.82
 BERETS AGENT                | Action      |       78.78
 BRIDE INTRIGUE              | Action      |       21.81
 BULL SHAWSHANK              | Action      |       21.84
 CADDYSHACK JEDI             | Action      |       51.84
 CAMPUS REMEMBER             | Action      |       90.81
 CASUALTIES ENCINO           | Action      |       72.91
 CELEBRITY HORN              | Action      |       32.76
 CLUELESS BUCKET             | Action      |      112.75
 CROW GREASE                 | Action      |       18.88
 DANCES NONE                 | Action      |       31.86
 DARKO DORADO                | Action      |       82.89
 DARN FORRESTER              | Action      |       93.82
 DEVIL DESIRE                | Action      |       83.85
 DRAGON SQUAD                | Action      |       27.89
 DREAM PICKUP                | Action      |       81.78
 DRIFTER COMMANDMENTS        | Action      |      141.76
...

O primeiro passo para calcular a curva ABC sobre as vendas de cada filme, para cada categoria de filme (os filmes mais vendidos e os menos vendidos em cada categoria) é calcular o total de vendas. Uma vez que queremos os 20% mais vendidos e os 20% menos vendidos, precisamos do total (100%) para calcular a porcentagem:

SELECT category, SUM(total_sales)
    FROM sales_pgday
    GROUP BY category;

E assim teremos:

  category   |   sum
-------------+---------
 Action      | 4375.85
 Animation   | 4656.30
 Children    | 3655.55
 Classics    | 3639.59
 Comedy      | 4383.58
 Documentary | 4217.52
 Drama       | 4587.39
 Family      | 4226.07
 Foreign     | 4270.67
 Games       | 4281.33
 Horror      | 3722.54
 Music       | 3417.72
 New         | 4361.57
 Sci-Fi      | 4756.98
 Sports      | 5314.21
 Travel      | 3549.64
(16 linhas)

Agora vejamos uma função de janela em ação aqui. Ainda não é a que vamos utilizar, é apenas um exemplo:

SELECT
    title,
    category,
    total_sales,
    rank() OVER (ORDER BY total_sales DESC) AS rank
FROM sales_pgday;

Agora vejamos o resultado:

            title            |  category   | total_sales | rank
-----------------------------+-------------+-------------+------
 TELEGRAPH VOYAGE            | Music       |      231.73 |    1
 WIFE TURN                   | Documentary |      223.69 |    2
 ZORRO ARK                   | Comedy      |      214.69 |    3
 GOODFELLAS SALUTE           | Sci-Fi      |      209.69 |    4
 SATURDAY LAMBS              | Sports      |      204.72 |    5
 TITANS JERK                 | Sci-Fi      |      201.71 |    6
 TORQUE BOUND                | Drama       |      198.72 |    7
 HARRY IDAHO                 | Drama       |      195.70 |    8
 INNOCENT USUAL              | Foreign     |      191.74 |    9
 HUSTLER PARTY               | Comedy      |      190.78 |   10
 PELICAN COMFORTS            | Documentary |      188.74 |   11
 CAT CONEHEADS               | Comedy      |      181.70 |   12
 ENEMY ODDS                  | Music       |      180.71 |   13
 BUCKET BROTHERHOOD          | Travel      |      180.66 |   14
 RANGE MOONWALKER            | Family      |      179.73 |   15
 MASSACRE USUAL              | Games       |      179.70 |   16
 VIDEOTAPE ARSENIC           | Games       |      178.71 |   17
 DOGMA FAMILY                | Animation   |      178.70 |   18
 APACHE DIVINE               | Family      |      178.69 |   19
 VELVET TERMINATOR           | Comedy      |      177.74 |   20
...

Agora vamos olhar com calma os dados (tirei aqui apenas as 20 primeiras linhas) e a parte do SELECT que diz:

rank() OVER (ORDER BY total_sales DESC) AS rank

Veja, o campo está utilizando a função RANK, sobre uma janela de dados ordenados pelo total de vendas. O campo RANK simplesmente diz qual é mais significativo, sobre a amostra (OVER) determinada. Agora queremos saber quais são os mais vendidos por categoria. O curioso é que ao invés de utilizar o GROUP BY que afetaria todas as colunas, vamos utilizar o PARTITION BY dentro da definição da janela, assim, isto afetará apenas a nossa última coluna:

SELECT
    title,
    category,
    total_sales,
    rank() OVER (PARTITION BY category ORDER BY total_sales DESC) AS rank
FROM sales_pgday;

Assim teremos:

            title            |  category   | total_sales | rank
-----------------------------+-------------+-------------+------
 FOOL MOCKINGBIRD            | Action      |      175.77 |    1
 AMERICAN CIRCUS             | Action      |      167.78 |    2
 STAGECOACH ARMAGEDDON       | Action      |      154.74 |    3
 EASY GLADIATOR              | Action      |      150.77 |    4
 MINDS TRUMAN                | Action      |      149.80 |    5
 KISSING DOLLS               | Action      |      147.80 |    6
 TRIP NEWTON                 | Action      |      145.72 |    7
 DRIFTER COMMANDMENTS        | Action      |      141.76 |    8
 SUSPECTS QUILLS             | Action      |      133.70 |    9
 WATERFRONT DELIVERANCE      | Action      |      121.83 |   10
...
 DRAGON SQUAD                | Action      |       27.89 |   56
 BULL SHAWSHANK              | Action      |       21.84 |   57
 BRIDE INTRIGUE              | Action      |       21.81 |   58
 CROW GREASE                 | Action      |       18.88 |   59
 LAWRENCE LOVE               | Action      |       15.87 |   60
 MONTEZUMA COMMAND           | Action      |       11.91 |   61
 DOGMA FAMILY                | Animation   |      178.70 |    1
 SUNRISE LEAGUE              | Animation   |      170.76 |    2
 TITANIC BOONDOCK            | Animation   |      154.77 |    3
 FORRESTER COMANCHEROS       | Animation   |      146.73 |    4
 FALCON VOLUME               | Animation   |      127.77 |    5
...

Notem que agora o rank é realizado para cada categoria, o rank é ordenado pelas vendas. Vale a pena executar o SQL no seu computador para verificar os dados com mais calma.

Bom, mas eu quero saber dos 20% mais vendidos. O problema aqui é que você precisaria ir somando o total de vendas de cada produto até chegar em 20% do total. Ocorre que você pode utilizar as funções de agregação como SUM, COUNT e outras junto com a sua janela. Vejamos como isso funciona:

SELECT
    title,
    category,
    total_sales,
    rank() OVER (PARTITION BY category ORDER BY total_sales DESC) AS rank,
    SUM(total_sales) OVER (PARTITION BY category ORDER BY total_sales DESC) AS SUM
FROM sales_pgday;

E teremos os seguintes dados:

            title            |  category   | total_sales | rank |   sum
-----------------------------+-------------+-------------+------+---------
 FOOL MOCKINGBIRD            | Action      |      175.77 |    1 |  175.77
 AMERICAN CIRCUS             | Action      |      167.78 |    2 |  343.55
 STAGECOACH ARMAGEDDON       | Action      |      154.74 |    3 |  498.29
 EASY GLADIATOR              | Action      |      150.77 |    4 |  649.06
 MINDS TRUMAN                | Action      |      149.80 |    5 |  798.86
 KISSING DOLLS               | Action      |      147.80 |    6 |  946.66
 TRIP NEWTON                 | Action      |      145.72 |    7 | 1092.38
 DRIFTER COMMANDMENTS        | Action      |      141.76 |    8 | 1234.14
 SUSPECTS QUILLS             | Action      |      133.70 |    9 | 1367.84
 WATERFRONT DELIVERANCE      | Action      |      121.83 |   10 | 1489.67
 TRUMAN CRAZY                | Action      |      121.77 |   11 | 1611.44
 CLUELESS BUCKET             | Action      |      112.75 |   12 | 1724.19
 SOUTH WAIT                  | Action      |      107.78 |   13 | 1831.97
 DARN FORRESTER              | Action      |       93.82 |   14 | 1925.79
 CAMPUS REMEMBER             | Action      |       90.81 |   15 | 2016.60
 FORREST SONS                | Action      |       87.82 |   16 | 2104.42
 DEVIL DESIRE                | Action      |       83.85 |   17 | 2188.27
 DARKO DORADO                | Action      |       82.89 |   18 | 2271.16
 DREAM PICKUP                | Action      |       81.78 |   19 | 2352.94
 WEREWOLF LOLA               | Action      |       78.86 |   20 | 2431.80
...
 REAR TRADING                | Action      |       32.83 |   52 | 4163.15
 CELEBRITY HORN              | Action      |       32.76 |   53 | 4195.91
 DANCES NONE                 | Action      |       31.86 |   54 | 4227.77
 SIDE ARK                    | Action      |       29.88 |   55 | 4257.65
 DRAGON SQUAD                | Action      |       27.89 |   56 | 4285.54
 BULL SHAWSHANK              | Action      |       21.84 |   57 | 4307.38
 BRIDE INTRIGUE              | Action      |       21.81 |   58 | 4329.19
 CROW GREASE                 | Action      |       18.88 |   59 | 4348.07
 LAWRENCE LOVE               | Action      |       15.87 |   60 | 4363.94
 MONTEZUMA COMMAND           | Action      |       11.91 |   61 | 4375.85
 DOGMA FAMILY                | Animation   |      178.70 |    1 |  178.70
 SUNRISE LEAGUE              | Animation   |      170.76 |    2 |  349.46
 TITANIC BOONDOCK            | Animation   |      154.77 |    3 |  504.23
 FORRESTER COMANCHEROS       | Animation   |      146.73 |    4 |  650.96
 FALCON VOLUME               | Animation   |      127.77 |    5 |  778.73
 MISSION ZOOLANDER           | Animation   |      126.82 |    6 |  905.55
 DOORS PRESIDENT             | Animation   |      123.81 |    7 | 1029.36
 SLEEPLESS MONSOON           | Animation   |      121.80 |    8 | 1151.16
 THIEF PELICAN               | Animation   |      117.81 |    9 | 1268.97
 HORN WORKING                | Animation   |      112.76 |   10 | 1381.73
...

Note que o valor da soma (SUM) vai acumulando registro a registro até que uma nova categoria apareça. Isto é uma coisa muito difícil de se fazer com SQL puro, você não consegue fazer cálculos com base nos registros anteriores.

Agora nós podemos juntar esta última consulta com a primeira para calcular a porcentagem de vendas sobre o total da categoria. Vamos colocar cada uma das consultas como uma entrada em FROM:

SELECT
    sales.category,
    title,
    somatorio,
    total,
    (somatorio / total) * 100 AS porcentagem
    FROM
        (SELECT
            category,
            SUM(total_sales) total
          FROM sales_pgday
          GROUP BY category) AS tot,
        (SELECT
            title,
            category,
            SUM(total_sales) OVER (PARTITION BY category ORDER BY total_sales DESC) AS somatorio
          FROM sales_pgday) sales
    WHERE tot.category = sales.category;

O resultado será:

  category   |            title            | somatorio |  total  |       porcentagem
-------------+-----------------------------+-----------+---------+--------------------------
 Action      | FOOL MOCKINGBIRD            |    175.77 | 4375.85 |   4.01681958933692882500
 Action      | AMERICAN CIRCUS             |    343.55 | 4375.85 |   7.85104608247540477900
 Action      | STAGECOACH ARMAGEDDON       |    498.29 | 4375.85 |  11.38727332975307654500
 Action      | EASY GLADIATOR              |    649.06 | 4375.85 |  14.83277534650410777300
 Action      | MINDS TRUMAN                |    798.86 | 4375.85 |  18.25611024143880617500
 Action      | KISSING DOLLS               |    946.66 | 4375.85 |  21.63373973056663276800
 Action      | TRIP NEWTON                 |   1092.38 | 4375.85 |  24.96383559765531268200
 Action      | DRIFTER COMMANDMENTS        |   1234.14 | 4375.85 |  28.20343476124638641600
 Action      | SUSPECTS QUILLS             |   1367.84 | 4375.85 |  31.25884113943576676500
 Action      | WATERFRONT DELIVERANCE      |   1489.67 | 4375.85 |  34.04298593416136293500
 Action      | TRUMAN CRAZY                |   1611.44 | 4375.85 |  36.82575956671275295100
 Action      | CLUELESS BUCKET             |   1724.19 | 4375.85 |  39.40240181907515111300
 Action      | SOUTH WAIT                  |   1831.97 | 4375.85 |  41.86546613800747283400
 Action      | DARN FORRESTER              |   1925.79 | 4375.85 |  44.00950672440782933600
 Action      | CAMPUS REMEMBER             |   2016.60 | 4375.85 |  46.08476067506884376700
...
 Action      | REAR TRADING                |   4163.15 | 4375.85 |  95.13923009243918324400
 Action      | CELEBRITY HORN              |   4195.91 | 4375.85 |  95.88788463955574345600
 Action      | DANCES NONE                 |   4227.77 | 4375.85 |  96.61597175405921135300
 Action      | SIDE ARK                    |   4257.65 | 4375.85 |  97.29881051681387616100
 Action      | DRAGON SQUAD                |   4285.54 | 4375.85 |  97.93617240079070352000
 Action      | BULL SHAWSHANK              |   4307.38 | 4375.85 |  98.43527543220174366100
 Action      | BRIDE INTRIGUE              |   4329.19 | 4375.85 |  98.93369288252568072500
 Action      | CROW GREASE                 |   4348.07 | 4375.85 |  99.36515191334255059000
 Action      | LAWRENCE LOVE               |   4363.94 | 4375.85 |  99.72782430842007838500
 Action      | MONTEZUMA COMMAND           |   4375.85 | 4375.85 | 100.00000000000000000000
 Animation   | DOGMA FAMILY                |    178.70 | 4656.30 |   3.83781113759852243200
 Animation   | SUNRISE LEAGUE              |    349.46 | 4656.30 |   7.50510061636922019600
 Animation   | TITANIC BOONDOCK            |    504.23 | 4656.30 |  10.82898438674484032400
 Animation   | FORRESTER COMANCHEROS       |    650.96 | 4656.30 |  13.98019887034770096400
 Animation   | FALCON VOLUME               |    778.73 | 4656.30 |  16.72422309559091982900
 Animation   | MISSION ZOOLANDER           |    905.55 | 4656.30 |  19.44784485535725790900
 Animation   | DOORS PRESIDENT             |   1029.36 | 4656.30 |  22.10682301398105792200
 Animation   | SLEEPLESS MONSOON           |   1151.16 | 4656.30 |  24.72263385091166806300
...

O resultado é a porcentagem do total de vendas sendo acumulado até 100% e depois começando novamente para outra categoria. Com isso fica fácil atribuir A para os 20% mais significativos, B para os próximos 60% e C para os 20% menos significativos. Aqui, irei utilizar uma função CASE, que embora ocupe um bom espaço no nosso SQL é algo bastante trivial:

SELECT
    sales.category,
    title,
    TRUNC((somatorio / total) * 100) AS porcentagem,
    CASE
        WHEN (somatorio / total) <= 0.2 THEN 'A'
        WHEN (somatorio / total) > 0.2  AND  (somatorio / total) <= 0.8 THEN 'B'
        ELSE 'C' END AS curva_abc
    FROM
        (SELECT
            category,
            SUM(total_sales) total
          FROM sales_pgday
          GROUP BY category) AS tot,
        (SELECT
            title,
            category,
            SUM(total_sales) OVER (PARTITION BY category ORDER BY total_sales DESC) AS somatorio
          FROM sales_pgday) sales
    WHERE tot.category = sales.category;

E finalmente temos a nossa curva ABC:

  category   |            title            | porcentagem | curva_abc
-------------+-----------------------------+-------------+-----------
 Action      | FOOL MOCKINGBIRD            |           4 | A
 Action      | AMERICAN CIRCUS             |           7 | A
 Action      | STAGECOACH ARMAGEDDON       |          11 | A
 Action      | EASY GLADIATOR              |          14 | A
 Action      | MINDS TRUMAN                |          18 | A
 Action      | KISSING DOLLS               |          21 | B
 Action      | TRIP NEWTON                 |          24 | B
 Action      | DRIFTER COMMANDMENTS        |          28 | B
 Action      | SUSPECTS QUILLS             |          31 | B
 Action      | WATERFRONT DELIVERANCE      |          34 | B
 Action      | TRUMAN CRAZY                |          36 | B
...
 Action      | EXCITEMENT EVE              |          69 | B
 Action      | BAREFOOT MANCHURIAN         |          70 | B
 Action      | HANDICAP BOONDOCK           |          72 | B
 Action      | PARK CITIZEN                |          73 | B
 Action      | UPRISING UPTOWN             |          74 | B
 Action      | MOCKINGBIRD HOLLYWOOD       |          76 | B
 Action      | PATRIOT ROMAN               |          77 | B
 Action      | GRAIL FRANKENSTEIN          |          78 | B
 Action      | SHRUNK DIVINE               |          79 | B
 Action      | CADDYSHACK JEDI             |          81 | C
 Action      | GOSFORD DONNIE              |          82 | C
 Action      | ENTRAPMENT SATISFACTION     |          83 | C
 Action      | SPEAKEASY DATE              |          84 | C
 Action      | MIDNIGHT WESTWARD           |          85 | C
 Action      | FANTASY TROOPERS            |          86 | C
 Action      | WOMEN DORADO                |          87 | C
...
 Action      | DRAGON SQUAD                |          97 | C
 Action      | BULL SHAWSHANK              |          98 | C
 Action      | BRIDE INTRIGUE              |          98 | C
 Action      | CROW GREASE                 |          99 | C
 Action      | LAWRENCE LOVE               |          99 | C
 Action      | MONTEZUMA COMMAND           |         100 | C
 Animation   | DOGMA FAMILY                |           3 | A
 Animation   | SUNRISE LEAGUE              |           7 | A
 Animation   | TITANIC BOONDOCK            |          10 | A
 Animation   | FORRESTER COMANCHEROS       |          13 | A
 Animation   | FALCON VOLUME               |          16 | A
 Animation   | MISSION ZOOLANDER           |          19 | A
 Animation   | DOORS PRESIDENT             |          22 | B
 Animation   | SLEEPLESS MONSOON           |          24 | B
 Animation   | THIEF PELICAN               |          27 | B
 Animation   | HORN WORKING                |          29 | B
 Animation   | GANGS PRIDE                 |          32 | B
...

É claro que existem N coisas que você pode fazer com funções de janela. A documentação possui algumas explicações sobre este recurso e também uma lista com várias funções que você pode testar com a sua base, aproveitando como ponto de partida os exemplos mostrados aqui.

Boa diversão!

Isso exige um pouco de reflexão. E como faz tempo que eu não faço isso por aqui, lá vai…

Bom, quem acompanha o blog aqui está careca de saber que em 2009 eu fui uma das pessoas que colaborou na organização da “III Conferência Brasileira de PostgreSQL“, também conhecida como PGCon Brasil 2009. Bom a organização de um evento deste porte não é nem de perto algo como a organização de um FISL. Mas não é nada simples. Quando você cobra R$ 100,00 pora alguém entrar num evento, tem que fazer este investimento voltar para a pessoa. É um compromisso que você assume. Não pode pisar na bola.

Para quem não sabe, existem 3 tipos de eventos que se encaixam aqui no Brasil:

• O PG Metting, que seria algo como um Happy Hour com uma palestra e um convite para tomar uma cerveja depois. Em São Francisco, CA, o povo do PostgreSQL se encontra toda  na 3ª quinta-feira de cada mês. É algo que São Paulo, Brasília, Porto Alegre, Fortaleza, teriam todas as condições de fazer. Basta achar um local e criar a tradição. Tenho muita vontade de criar algo deste tipo aqui em São Paulo, mas não pode ser no dia do meu rodízio, hehehe.
• O PGDay, que é um dia de palestras em um evento em geral direcionado para novatos. Assim como o PG Metting, pode ser organizado com custo zero, sem cobrar ingresso e sem patrocínio. Se tiver patrocínio, ótimo, mas não é preciso. Já foram vários PGDays com muito sucesso até agora. No ano passado tivemos: Brasília, São Paulo-SP, Porto Velho-RO, Ji-Paraná-RO, Porto Alegre-RS e ainda Florianópolis-SC. Este ano foram Ilheus-BA, Manaus-AM e São Paulo-SP, mas ainda deverá acontecer um no Rio de Janeiro-RJ. Vejam que não é pouca coisa. A simplicidade na organização e o aproveitamento de palestrantes locais é a chave do sucesso. E é a porta de entrada para novos colaboradores na comunidade.
• O PGBR, antes era chamado de PGCon Brasil, mas atendendo ao pedido do Dan Languile, trocamos o nome. Questões internas, não vale a pena discutir e não é nenhum problema para nós. É o grande evento da comunidade nacional e tem tudo para ser referência em toda a América do Sul e é também um dos maiores eventos de usuários de PostgreSQL do mundo. Ele não é voltado para novatos, é voltado para quem já trabalha ou esta avaliando seriamente a possibilidade de trabalhar com o PostgreSQL. Aqui o nível das palestras vai de intermediário para avançado, passando por uma sala reservada aos Hackers onde o nível é para quem quer fazer coisas realmente divertidas.

<mimimi mode ON>
No ano passado a organização do PGCon Brasil 2009 tomou muito do meu tempo assim como o tempo de muitos outros como o Euler Taveira, Diogo Biazus, Leonardo Cezar, Fernando Ike, Marcelo Costa, a equipe da 4Linux e muitos outros mais. Mas houve algo curioso em 2009, que não houve nas outras 2 edições do evento em 2007 e 2008: pouca repercussão. Antes de depois do evento, vi pouca divulgação, comentários, posts em blogs, fotos, etc. E o mais estranho é que o evento deve defeitos mas não se pode dizer que foi pior que os anteriores, então o que aconteceu? Eu não sei exatamente o que aconteceu, só posso especular aqui. Uma pista é o que houve com muitos organizadores este ano: eu, Euler, Fike e Diogo, nos afastamos um pouco da comunidade. E isto teve um peso forte. Mas nós temos trabalhado juntos há alguns anos, o que houve? Bom, quando começamos, o PostgreSQL era quase um hobby para alguns de nós, hoje começa a ser meio de vida. Isso acontece em várias comunidades, eu vi isso claramente aqui no PSL-ABCD. Veja que por outro lado, este anos foram 3 palestrantes brasileiros no PGCon 2010, lá no Canadá! O nível tem crescido, e o nosso tempo disponível está indo para o ralo. De toda forma, depois de ralar muito, ver uma repercussão baixa após o PGCon 2009 também me desanimou um pouco.
<mimimi mode off>

O que aprendemos no passado

• A burocracia é nosso inimigo número 1. Projeto de captação, contratos de patrocínio, notas fiscais, as inscrições, notas de empenho, prestação de contas, etc, etc, etc. Conseguir tirar esta parte burocrática da frente é uma meta que pode mudar tudo. A burocracia é o nosso maior inimigo. Ele nos leva ao próximo ponto:
• As inscrições não podem ser realizadas pela comunidade. Receber dinheiro dá muito trabalho e fazer isso do jeito certo dá um absurdo de trabalho. Se tivéssemos patrocinadores em abundância, seria muito, mas muito mais fácil não cobrar nada. Não se trata apenas de ter um bom sistema para fazer as inscrições (coisa que o Euler fez do zero), não se trata apenas de ter banco, nota, recibo, documentação, etc. Se trata de ter alguém que atenda a meleca do telefone o tempo todo e resolva as dúvidas, encaminhe os processos bizarros de alguns órgãos públicos e suas notas de empenho from hell.
• Patrocínio em troca de serviços é um bom negócio. Ao invés de receber dinheiro, receber o serviço. Foi assim com os brindes (canecas, pins, chaveiros, etc), com o credenciamento e com o Coffee Break. Tira uma boa parte da carga de burocracia e preocupação das nossas costas.
• Começar a organização com pelo menos um ano antes e adiantar ao máximo as coisas no começo, garante que o evento saia, pois:
  • Reservar auditório com menos de 6 meses de antecedência é quase impossível, com 12 meses também não é tão fácil assim;
  • Ter o plano de captação pronto, com local e data definidos com mais de 6 meses de antecedência torna possível conseguir patrocínio. Com isso na mão, muitas portas vão bater na sua cara, mas outras vão se abrir. Sem isso, só na base da amizade mesmo, nem pense em órgãos públicos;
  • Os palestrantes internacionais precisam se agendar com muita antecedência e comprar passagens adiantado sai bem mais barato;
  • Com local, data e plano de captação prontos com um ano de antecedência, você tem tempo de se dedicar aos zilhões de detalhes que vão surgir nos 6 meses que antecedem o evento;
  • As inscrições tem de abrir cedo, para você começar a ter dinheiro em caixa cedo.
• O valor das incrições tem de cobrir pelo menos os dois maiores custos do evento: a locação dos auditórios e o coffee-break.
• Receber dinheiro de patrocinadores estrangeiros é um inferno. Então peça a eles que ajudem no pagamento de viagens de palestrantes internacionais;

Que venha o PGBR 2011!

Bom, e porquê o PGBR 2010 não deu certo? De certo não vale a pena entrar nesta questão. Pessoas, trabalharam muito para tentar organizar o evento mas isso não foi sificiente. A única coisa realmente óbivia é que a organização começou muito tarde. Mas de fato houveram pessoas que trabalharam bastante e imagino o quanto elas estejam frustradas agora. Muito mais do que aqueles que já aguardavam com expectativa o evento deste ano.

Agora é hora de pensar em 2011 e nos PGMettings e PGDays que podemos fazer em breve. Não temos tempo para ficar se remoendo mais, já estamos em cima da hora para começar o PGBR 2011. O mercado de PostgreSQL está crescendo, com o 9.0 está aparecendo um novo Standby em cada esquina. Vamos que vamos gente, que atrás vem muita gente!

Esta com certeza é uma funcionalidade muito interessante para a comunidade como um todo, além de facilitar a vida de muita gente. Mas é aí que VOCÊ entra. Eles montaram um site e estão pedindo a doação para financiar o desenvolvimento desta ferramenta.

A doação pode ser algo vultoso como USD5000 ou algo simples como 25 dólares. Então você, que sempre diz que gostaria de ajudar a comunidade, mas não tem tempo ou diz que não conhece tão bem assim programação e coisa e tal… chegou a sua vez de retribuir um pouco e fazer a sua doação.

Um dia nós brasileiros precisamos perder aquela fama de sanguessugas do Software Livre. Eu já fiz, minha doação, agora é a sua vez. Conheça o projeto e faça a sua parte:

PostgreSQL Extension network

Se inscreva no site do evento, vagas limitadas.

Sim,  este ano tem Copa do mundo, eleição, e claro PGCon e PGDay.

O blog podia estar parado, mas a comunidade brasileira de PostgreSQL continua a todo o vapor. Já tivemos o PGDay BA, em Ilhéus, e em breve deverá sair a data do PGDay RJ. O próximo será o PGDay DF, em 31/05 no SERPRO. Então fiquem antenados para as inscrições no evento.

Palestrantes confirmados:

• Euler Taveira
• Fábio Telles
• Fernando Ike
• Leonardo César
• João Cosme

Nesse eu vou!

Bom, fui convidado para o evento e se nada der errado (fui escalado para uma migração na data do PGDay BA) estarei lá. Nada, já fiz uma mega amarração no trabalho, o meu chefe vai me substituir! Nesse eu vou mesmo.

Me ajude a escolher o tema para a palestra no PGDay DF!

Ocorre que o pessoal me deixou a vontade para escolher o tema da palestra. Eu que sou preguiçoso tenho uma forte tendência a reciclar artigos e palestras anteriores. Claro que para o PGCon Brasil, a gente sempre tras coisa nova, mas com menos de 20 dias para preparar a palestra (é claro que não estar na organização do evento já ajuda muito) a chance de eu dar uma atualizada em uma palestra antiga aumenta.

Então gostaria de saber se alguém tem alguma sugestão para o PGDay DF. Pode ser um artigo aqui do blog, pode ser uma palestra minha no Slide Share, ou pode ser um tema novo. Comentários com sugestões aqui no blog, até o final da semana (que é quando eu vou começar a mexer nisso) são bem vindos. É claro que se eu não mandar logo a descrição da palestra para a organização o povo lá me mata também!

No ano passado fiz uma pesquisa aqui no blog sobre as rotinas de backup utilizados no PostgreSQL. O resultado foi que a maioria esmagadora só utiliza o pg_dump. Veja, eu não tenho absolutamente nada contra o pg_dump. Mas antes de me explicar, vamos pensar… PARA QUE SERVEM OS BACKUPS MESMO?

Se eu fizer uma pesquisa, 10 entre 10 irão dizer: para se recuperar em caso de desastres! Simples assim, eu faço uma cópia dos dados e caso tudo dê errado eu restauro a minha cópia e volto a trabalhar.

Simples não?

NÃO.

Não tem nada de simples nisso. Vamos avaliar melhor o caso. Primeiro temos que entender o que é “tudo dê errado”. Podem acontecer várias coisas diferentes…

Quanto tudo dá errado!

1. Desastre natural
   O CPD pegou fogo, inundou (eu já vi acontecer), teve um terremoto, jogaram um avião no prédio… bom, nestes casos só um stand by em outro prédio (ou outra cidade, outro país) resolve a situação. Mas você bem que poderia guardar os seus backups fora do prédio onde está o CPD, não?
2. Falha de hardware (exceto os discos)
   Um problema no hardware do servidor, que não seja o disco. Neste caso, basta substituir a peça com defeito e voltar a trabalhar, certo? Errado. Quem disse que você tem pentes de memória, fontes, processadores ou mesmo uma placa-mãe sobressalente para substituir naquele servidor. E no caso de você trocar algo como uma placa-mãe, provavelmente vai trocar por outro modelo, o SO pode se desentender com ele e pode exigir algum tipo de ajuste no SO.
   Isto leva tempo, mas não exige que se mexa com backup, certo? Errado. Se você não pode esperar até uma nova peça chegar, você vai querer subir o seu banco de dados em outro servidor o mais rápido possível, e aí sim você vai precisar do seu backup.
3. Falha nos discos
   Um problema físico num disco ou no seu storage. Bom, se você utiliza RAID (RAID 0 a princípio não é RAID e se você utiliza RAID 0 para guardar seus dados, saiba que existe um lugar especial no inferno reservado para você) e tem um Hot Spare configurado, você não precisa fazer nada naquele momento. Todo Storage descente não permite a criação de RAID sem o Hot Spare.
   Se você tem um storage e paga o seu caríssimo contrato de manutenção, tudo que você terá de fazer e dizer para o técnico do storage entrar e substituir o disco. Em geral quem vai lhe avisar que um disco está com problema é o técnico que chegou para trocar o disco. Os storages devem ser monitorados remotamente pelo fornecedor. Em caso de defeito eles mandam um técnico para resolver o problema ANTES de você notar que perdeu um disco.
   Mas, a vida não é perfeita, storages são caros e os contratos de manutenção também. Se você tem um RAID na sua controladora local e teve uma falha em um disco, provavelmente a vida vai continuar e você não vai nem perceber. É aí que mora o perígo. Alguém tem que monitorar os logs do SO para saber que um disco apresentou problema, apesar de tudo continuar funcionando. Se você não perceber isso, então a próxima falha no próximo disco (como os discos são comprados em geral do mesmo lote, eles tem esse péssimo hábito que queimar mais ou menos na mesma época…) vai gerar uma paralisação total dos banco. Aí você volta para o item 1 e com certeza vai ter de utilizar o seu backup para restaurar os dados. Isso se você não tiver aquela idéia maravilhosa de guardar os seus backups justamente naquele disco / RAID que deu problema. Assim fica a dica: monitore os logs do seu SO e nunca guarde o seu backup no mesmo disco que os seus dados.
4. Ok, o hardware está ótimo, mas o SO egripou do nada
   Pegou um vírus (sem comentários), deu uma tela azul (pode escolher outra cor, o efeito é o mesmo) da morte ou um mesmo um kernel panic. Uma atualização do SO fez com que tudo o mais travasse. O banco de dados não sobe mais. Você pode até tentar reinstalar o SO, limpar o vírus, etc e tal. Mas se isso demorar, você vai querer voltar o backup em outro servidor;
5. O sistema de arquivos corrompeu
   Após uma falta de energia, quando o luz voltou você teve uma grata surpresa: justamente a partição onde os dados estavam se corrompeu. Não vou entrar no mérito sobre qual sistema de arquivos é mais seguro agora. Ok, já vi gente que queria rodar um SGDB num Pen Drive… FAT não deveria servir para guardar nem base em .mdb! NTFS corrompe muito, mas EXT3, EXT4, ReiserFS, XFS, JFS, UFS, ZFS e outros também corrompem. Se você inventar de fazer um “ajuste de desempenho” no ser sistema de arquivos então…
   Bom, se a ferramenta do seu sistema de arquivos não conseguir restaurar os dados em 100%, já viu… Formate tudo e volte o backup;
6. Um DBA ou sysadmin desastrado foi lá e apagou/alterou/moveu um arquivo do banco de dados
   Vai corromper na hora. Volte o seu backup… e dê uma bronca ou PNB* no funcionário que fez esta besteira. Se foi o seu estagiário que fez isso, então peça demissão. Quem mandou deixar o estagiário chegar perto do seu banco de dados?
7. O banco de dados corrompeu por uma falha do próprio banco de dados
   É raro mas acontece. Você vai ter que verificar os logs do SO e do banco para entender o que aconteceu. Pode ser preciso aplicar um patch no servidor ou implementar um “workarround”, mais conhecido como gambiarra. Depois de entender minimamente a causa do problema e tomar providências para que isso não ocorra novamente, você vai ter de voltar o seu backup;
8. Um usuário desastrado apagou uma tabela ou outro objeto do banco de dados
   Primeiro você vai se perguntar: quem deu permissão para o usuário apagar alguma coisa no banco de dados? Se o usuário for um desenvolvedor, ídem. Se for o sysadmin, ídem. Se for o DBA… bom, sobra a bronca ou PNB*. E você vai ter que voltar o seu backup para o momento anterior ao desastre. É um detalhe importante. Tem gente que só nota a besteira dias depois de feita a besteira. Se você voltar o backup feito depois da besteira, vai continuar com o mesmo problema. Identifique quando o problema ocorreu antes de voltar o backup.

Outros usos para o backup

Você pode utilizar o seu backup para outras coisas além de recuperação de desastres:

1. Mover dados entre bases. Particularmente atualizar dados de homologação com os dados da produção. Operação bastante comum em que se utiliza o backup. Sempre que você quer fazer um teste de performance ou validar uma atualização da aplicação, alguém solicita uma atualização deste tipo.
2. Auditoria. Você pode guardar backups realizados após fechamentos cíclicos (como mensal ou anual) para efeito de auditoria. Estes backups são em geral guardados por vários anos, pelo menos 5 anos em geral.
3. Criação de novos ambientes de homologação / teste. É muito comum projetos específicos exigirem análises destrutivas dos dados e para isso utilizarem uma base/esquema separados para isso.

O tal do SLA

Antes de definir a sua estratégia de backup, você deve determinar qual o seu SLA ou Service Level Agreement. Seja pessimista e defina o quanto você pode suportar em caso de desastre. Não adianta dizer que você quer 100% de alguma coisa. 100% não existe e os famosos “five nines” ou 99,999% custam uma verdadeira fortuna. O cofre não pode ser mais caro que o ouro que você guarda. Então pense com realismo (ou pessimismo, como você preferir) nos seguintes limites:

• Quanto tempo você pode ficar com o banco de dados indisponível em caso de parada não prevista em horário comercial? E se for em horário não comercial?
• Quanto tempo você pode ficar com o banco de dados indisponível em caso de uma parada prevista (uma manutenção) em horário comercial? E se for em horário não comercial?
• Respire fundo…. você pode perder dados relativos a quanto tempo de operação?

Ok, a resposta para as 3 perguntas sempre deveria ser ZERO. Mas como eu já disse, não existe como garantir isso, e chegar perto disso custa muuuito caro. Cada uma das suas respostas vai te levar para uma estratégia de backup diferente.

Tempo necessário para restaurar um backup em caso de desastre.

Este é um ponto crítico que poucos sabem responder. Então vejamos como calcular isso. O tempo vai variar muito conforme alguns fatores:

• Você já testou uma restauração completa do backup?
• Você tem equipe disponível no local para fazer a restauração?
• Você tem equipe disponível para fazer a restauração fora do horário comercial?
• As pessoas disponíveis para fazer a restauração fora do horário comercial tem acesso remoto ao servidor?
• Você tem o procedimento de restauração documentado em papel?
• A documentação está atualizada?
• Você tem hardware de contingência disponível?

Bom, supondo que você tenha uma base de até 1GB, sem muitas demandas de desempenho, tudo fica simples. Você pode instalar o PostgreSQL em qualquer servidor com um pouco de folga no desempenho e alguns GB de espaço em disco sobrando em subir um dump guardado em outro servidor. Pode não levar mais do que uns 30 minutos para fazer tudo. Neste caso o pg_dump parece fazer sentido.

Agora se você precisar subir um novo servidor dedicado para abrigar uma base com 100GB, então você terá problemas com o pg_dump. Importar um dump para criar uma base de 100GB deve levar várias horas. Se a base tiver alguma tabela muito grande, você poderá precisar fazer ajustes específicos para conseguir recriar seus índices. Se a base tiver algo em torno de 500GB por exemplo, isso pode levar dias. Mesmo com a paralelização do processo, se você souber fazer isso com cuidado.

Como evitar a perda de dados?

Outro problema com o pg_dump. Quanto tempo de operação em produção você está disposto a perder? Suponha que você faça o backup toda madrugada, e seu desastre ocorra no final da tarde. Se você voltar o seu backup, você vai perder todas as alterações realizadas ao longo do dia. Isso é muito grave e intolerável para a maioria dos ambientes OLTP. É claro que você pode realizar o pg_dump mais de uma vez por dia, mas fazer isso em horário comercial costuma ter um impacto muito negativo na performance. Quais as soluções para contornar este problema?

• Replicação: existem N ferramentas de replicação. Algumas síncronas, outras assíncronas. Existe uma excelente documentação sobre os principais tipos de replicação para PostgreSQL. De qualquer forma, podemos categoriza-las em:
  • As ferramentas síncronas garantem a perda ZERO de dados. Cada vez que um COMMIT é realizado no servidor de produção, outro COMMIT é realizado na réplica. Somente após o COMMIT ser realizado com sucesso na base de produção e na réplica é que a operação prossegue. Resultado: ZERO em perda de dados e um gargalo de performance terrível. Para conseguir ter uma performance razoável com replicação síncrona, você vai ter que gastar muito em hardware e em ajustes de performance.
  • As ferramentas assíncronas não garantem ZERO de perda de dados, todos possuem algum atraso na sincronia entre o servidor de produção e a réplica.
• Point In Time Recovery: é uma técnica que consistem em fazer uma cópia do WAL (Write Ahead Log) do PostgreSQL e utilizar estas cópias para atualizar um backup até um horário específico. O PITR é uma técnica consagrada em todos os SGDBs sérios do mercado. Você não precisa instalar nenhum software extra para faze-lo funcionar. O PITR também não penaliza o desempenho do seu servidor, uma vez que o WAL já é gerado normalmente. O único overhead é a cópia deles. Você também pode ajustar o intervalo máximo entre as cópias do WAL, o que lhe permite um ajuste do período máximo de perda de dados que você terá com o PITR (ele é assíncrono então não garante perda ZERO de dados).

Se você escolher logo uma estratégia de replicação, pense em primeiro lugar no Stand by. Com o lançamento da versão 9.0 o Stand by sofreu melhorias importantes e tudo indica que a próxima versão terá mais melhorias ainda. Combinar um Stand By com outras técnicas de backup é a melhor forma de se proteger contra a perda de dados e o downtime. Você estará utilizando uma solução nativa, relativamente simples, bem testada e documentada, com baixo impacto em performance e com um custo realmente baixo em comparação com outras alternativas.

Backup físico, o primeiro passo.

É claro que apesar de recomendar o uso do stand by, ele não é algo tão simples e barato assim. Você precisa de um servidor com capacidade semelhante ao de produção para suportar a mesma carga, lembre-se disto.  Novamente, existe excelente documentação sobre como criar um standby. Você também precisa aprender com perfeição a fazer backups físicos e saber restaurá-los de forma adequada.

Existem dois tipos de backup físico, o frio e o quente. O frio é feito com o banco de dados desativado. Você copia todos os arquivos do banco (inclusive os de configuração) e depois reativa o banco de dados. Este método é muito simples e seguro, mas tem aquele problema básico: você precisa tirar o banco de dados do ar. Se você não tem janela para isto ou o seu sistema é 24X7, então você terá que recorrer ao backup quente. O quente é um pouco mais complicado,  pois exige que você avise o PostgreSQL quando vai começar a copiar os arquivos e quando terminou. Ele também EXIGE que você faça a cópia dos logs do WAL, utilizando o parâmetro “archive_command“. Não vou me alongar sobre o assunto aqui. Leia a documentação atentamente sobre isso.

Depois que você se tornar um expert em fazer backups e recuperações de backups físicos quentes, já estará de quebra fazendo o PITR de forma natural e estará pronto para fazer o seu Stand By, que utiliza o backup quente como princípio para a sua criação.

Então eu não preciso mais do pg_dump?

Precisa sim. Não para a recuperação de desastres, mas para os outros casos mencionados. Suponhamos que você precisa restaurar um backup feito há 8 anos atrás. Provavelmente o servidor onde este backup foi gerado não existe mais. Talvez  o DBA que criou o procedimento  de backup não trabalhe mais na empresa. Certamente o SO e a versão do SGDB mudaram, pode ser que você não tenha mais versões compatíveis disponíveis. Então o backup físico não é indicado para estas situações. Ele é adequado para recuperação de desastres, mas não para reter backups por um longo período. Com um backup feito pelo pg_dump, você pode migrar os dados para outra versão do PostgreSQL ou até mesmo para outro SGDB.

E tem mais um detalhe, backups físicos são monolíticos. Você precisa restaurar o banco de dados no mesmo SO, com a mesma versão do PostgreSQL, com a mesma estrutura de diretórios, o mesmo sistema de arquivos e além de tudo precisa restaurar o banco de dados inteiro. Suponhamos que você só precise de algumas tabelas, o pg_dump oferece todo o tipo de flexibilidade para restaurar apenas uma parte dos dados.

Estratégia de backup.

Ok, o pg_dump não é O backup, ele é parte de uma estratégia de backup. Você precisa do pg_dump para gerar backups esporádicos e guarda-los por um longo período. Para a recuperação de desastres você deve ter um backup físico (quente ou frio), cópia dos logs do WAL e cópia dos arquivos de configuração. Você não precisa guardar o backup físico pro muito tempo, alguns dias é razoável. Depende de quanto você deseja voltar no tempo se necessário, e de quanto você confia na sua mídia de armazenamento. Lembre-se da máxima: quem tem um backup não tem nada. Faça o backup físico uma vez por dia e não sobreescreva o backup do dia anterior. Você pode fazer o backup físico para o disco em outro servidor e gravar este backup em fita diferentes todos os dias por exemplo.  Já a cópia do WAL é feita automaticamente, mas deve ser copiada para fora do servidor também, se não imediatamente no comando do “archive_command”, faça isso em intervalos curtos para evitar a perda de dados em caso de desastres.

Conclusões :

(atualizado em 17/05/2010)

• Backup não é simples, mesmo em bancos de dados pequenos;
• Backup exige estudo, dedicação e disciplina;
• Backup não deve ser responsabilidade de estagiários, deve ser criado e verificado diariamente por pessoas qualificadas e de confiança;
• Backup é caro: os recursos de hardware são caros e os recursos humanos também;
• Nunca diga que você está 100% seguro, você não está;
• Você pode e deve estimar o tempo para se recuperar de desastres e qual o SLA que você pode entregar com os recursos disponíveis. Documente isso e protocole a entrega deste documento junto ao seu superior. Sim, isto pode salvar o seu emprego e de toda a sua equipe junto. Sua família agradece.

Atualização:

Em tempo, existe uma nova ferramenta para backup incremental chamada pg_rman. Sim, é um clone do RMAN do Oracle para o PostgreSQL. A ferramenta é relativamente nova, mas parece que o projeto está bastante ativo. Alguém aí já testou?

OBS: Gostaria de dedicar este humilde texto à todos aqueles que me contrataram para recuperar seus bancos de dados (desculpe, somente àqueles que não me deram calote depois, os que não pagaram vão para o mesmo lugar daqueles que utilizam RAID 0). Àqueles que sofreram durante madrugadas intermináveis com a pressão de não saber se a empresa voltaria a funcionar no dia seguinte e todas as conseqüências que daí decorrem.

* PNB = Pé Na Bunda, demissão mesmo.

Mas ontem terminamos o evento. Como sempre, muitos problemas, muito mais do que os participantes do evento possam imaginar. Muitos erros, mas também muito aprendizado com os erros das edições anteriores.

Novos patrocinadores, novos palestrantes, novos temas, novos organizadores, novos participantes, novos clientes, novas idéias. Sim. Muita coisa nova. Sobre tudo, novos amigos, novas perspectivas, novos horizontes.

Se o primeiro PGCon Brasil, em 2007, foi um marco em termos de organização da comunidade, hoje, em 2009 temos um novo marco. As pessoas bateram à  nossa porta, entraram no evento, subiram no palco e disseram: “Hey, nós estamos utilizando o PostgreSQL em missão crítica aqui, precisamos da ajuda de vocês”. Sim, o PostgreSQL está crescendo e tomando de assalto grandes CPDs. Não é mais algo que entra pela porta dos fundos. Muita gente já testou, já sabe que funciona e também conhece suas peculiaridades. Já temos casos de implantações grandes rodando há alguns anos. Não é mais uma aventura, é uma realidade.

Sim, muita gente não sabe disso. Temos muito o que caminhar. Mas quem acompanha as listas de discussão (você AINDA não acompanha?), o planeta e principalmente acompanha os nossos eventos sabe que as coisas estão mudando. Pare para pensar como eram as coisas há 5 anos atrás?

Bom, ontem eu vi porquê valeu a pena esperar 3 anos para trazer o Bruce Momjian para o Brasil: em um dado momento ele contou um pouco da história do PostgreSQL e da sua história no PostgreSQL. De como ele começou a se dedicar ao projeto e de como aquilo inicialmente afetou a sua família e as suas finanças pessoais. Mas de repente, algo estranho começa a acontecer…. as pessoas começaram a utilizar o Postgres no Japão! Sim, em ambientes de produção. Estas pessoas criaram uma comunidade, com artigos, documentação, livros, profissionais qualificados e se tornaram o primeiro mercado a efetivamente utilizar o PostgreSQL para valer. A dedicação por anos de trabalho parece ter valido a pena.

Para mim isto tem um significado muito especial. Todos que me conhecem sabem que eu ainda não me sustento trabalhando com PostgreSQL. Mas já fazem alguns anos que eu tenho mantido algum tipo de contribuição para a comunidade brasileira. Sim, tem muita gente que começou muito antes e fez muito mais do que eu. Mas para mim e para muitos outros a questão é acreditar no projeto, acreditar nas pessoas. Cada vez que conheço um novo desenvolvedor do time central do Postgres eu fico mais empolgado. Pois são pessoas facinantes que estão desenvolvendo o Postgres. São pessoas que não são apenas desenvolvedores extraordinários. São pessoas com uma cultura e uma visão de mundo fantástica. É fantástico poder conversar com estas pessoas e saber que existem mais loucos pelo mundo. Que estes loucos fazem a diferença no mundo e que talvez você possa até fazer parte disso tudo, de dar a sua parte para construir um mundo mais próximo daquilo que você acredita que ele deveria ser.

YES, WE CAN!!!

IS DONE

IS JUST THE BEGINING…

Ok, devo postar mais sobre o evento, as fotos, as palestras, as pessoas, e outras coisas que rolaram no PGCon Brasil 2009, mas o dia já está claro e a água da piscina parece estar ótima…

As inscrições para o PGCon Brasil 2009 estarão abertas a partir de 16/09.

Garanta já sua inscrição!!!

Aproveite e baixe também o cartaz do evento aqui.

Eu estava interessado em conseguir uns 100 pendrives personalizados com o nome do PostgreSQL. Ano passado o David Fetter trouxe uns e eles evaporaram instantaneamente quando o pessoal ficou sabendo. Sim, eu tenho um.  Bom, o Josh disse que cada pendrive custava USD 8,00. Seria um pouco mais barato do que o preço aqui no Brasil, mas o Josh já me adiantou que só tem uns 50. Aí ele me disse algo interessante: “Me arranje algo melhor que simplesmente distribuir os pendrives para todo mundo que eu posso lhe conseguir eles de graça para você. E outra pessoa no canal deu a ideia: “Me mostre a sua melhor consulta SQL e ganhe um pendrive”.

O Josh parece que gostou da idéia e eu mais ainda. Aí comecei a rascunhar e pensar em como organizar isso. Pensei logo em algumas categorias para participar:

• Consulta ou script;
• Artigo;
• Artigo traduzido;
• História em quadrinhos;
• Estudo de caso;

A ideia é mais ou menos assim: sabe aquela consulta que você criou para verificar o desempenho do banco? Aquele script de backup que ficou bacana? Ou aqueles testes que você ficou de publicar em algum lugar o resultado? Ah… tem também aquele artigo em inglês que um monte de gente adoraria ler em português. Bom, acho que deu para pegar o espírito da idéia. Você manda para nós o seu material, tem grandes chances de ganhar o seu pendrive e a comunidade ganha material novo para colocar na Internet. Todo mundo acaba ganhando.

Vá na página do concurso “O elefante está entre nós” no site do PGCon Brasil 2009 e participe!

Sim, sim, é verdade! A grade oficial está no ar!!!

Vá lá dar uma olhada e me diga o que você acha…

Vou contar um pouco dos bastidores do evento:

• Foram ao todo 40 propostas na chamada de trabalhos;
• 2 Palestrantes internacionais convidados;
• 65 pessoas votaram nas propostas e disseram quais eram as suas prediletas;
• 3 pessoas na banca avaliadora fizeram a seleção final das palestras;
• 4 tutoriais aprovados;
• 3 palestras avançadas;
• 4 Hacker Talks (palestras para quem deseja conhecer e  contribuir com o código do PostgreSQL);
• 11 palestras normais;
• 12 Lithning Talks  (palestras curtas de até 5 minutos cada);
• 3 salas simultâneas.

Bom, outras novidades estão por vir, inscrições, concurso, patrocínios, divulgação, tudo a caminho. Até o final do mês o evento deverá estar com quase todos os detalhes fechados.  Em breve traremos mais detalhes… em breve!

Diante deste tipo de dificuldade, resolvi fazer esta pesquisa para ver se há algum produto que interessaria mais a comunidade e se teríamos pedidos suficientes para cobrir as despesas com isto.

Você pode chegar nesta situação quando era apenas uma matriz que abriu uma filial. O banco de dados ficava só na matriz e a filial acessa o banco de dados remotamente, via Internet, conexão via rádio, linha privativa, etc. O problema é que a conexão com a filial tinha a mania de cair e quando isso acontece é como se acabasse a luz. Se pensarmos numa empresa que utiliza apenas a conexão da Telefônica aqui em SP, dá para imaginar o desespero.

Então a solução ideal se chama replicação multimaster síncrona: você tem alguns bancos de dados, cada um em um local diferente. Cada atualização realizada numa das bases é automaticamente replicada para as demais e vice-versa. Qualquer base pode sofrer atualizações. Uma vez realizada, ela é visível instantaneamente em todas as bases. Se você der um rollback em uma transação, o rollback será realizado de forma idêntica em todos os nós. Ou seja, tem de garantir o ACID em todos os nós, como se estivesse em apenas um banco de dados. Existe um recurso no PostgreSQL que visa garantir este comportamento, ele se chama commit em duas fases e está disponível a partir da versão 8.1 do PostgreSQL. O commit em duas fases é muito importante por realmente garantir a consistência através de todos os nós. Ele não resolve problemas como o uso intensivo de SEQUÊNCIAS ou o a equivalência de um TIMESTAMP com precisão absoluta, mas resolve o problema de ter um commit ou rollback sincronizado em todos os nós. Deve-se entender que o Commit em duas fases é implemento como comandos SQL e não como uma aplicação. Portanto a sua aplicação tem de ser desenhada específicamente para utiliza-lo.

Há uma solução no universo PostgreSQL conhecida como PGCluster, que não utiliza o commit em duas fases mas faz a replicação multimaster assíncrona através de um serviço de balanceamento de carga e outro serviço de replicação. E vai além disso, se a comunicação com um dos nós cair, ele sincroniza o nó quando ele volta a se comunicar com os demais. Não é ótimo?

Sim, o PGCluster é uma ideia muito interessante, mas não como uma solução de banco de dados distribuído. Cada alteração no banco de dados dispara uma atualização em cada nós que precisa ser confirmada em um por um e depois da confirmação, liberada em todos eles. Isto significa que o que seria feito em X tempo em um único nó, será feito em  2XNL tempo onde N é o número de nós envolvidos na replicação e L é a latência da rede. Isto significa que se os nós não estiverem dispostos lado a lado numa rede local de alta velocidade, a perda de desempenho é absolutamente intolerável.

Mesmo que você utilize fibras ópticas de última geração para interligar seus servidores localizados em lugares distintos, você sofrerá com uma limitação: a velocidade da luz. Até que se prove ao contrário, nada viaja a uma velocidade superior a da luz, inclusive a informação. E nas idas e vindas do commit em duas fazes, a velocidade da luz começa a ser relevante. Ou seja, o PGCluster só é funcional como solução de alta disponibilidade, para servidores que ficam todos no mesmo CPD. Ainda assim há uma perda de performance considerável em cada atualização do banco de dados (nas leituras a distribuídas da carga propcia uma melhora de desempenho). Para encerrar o assunto, vale lembrar que o PGCluster é uma solução complexa de instalar (são no mínimo 3 nós + o balanceador de carga + o replicador), sua última versão foi lançada em 02/2008 e não é uma solução realmente bem aceita pelos desenvolvedores do PostgreSQL.

Sim o commit em duas fases pode ser utilizado com sucesso para bancos de dados distribuídos, mas para sincronizar apenas algumas operações e não a base inteira. Se você pesquisar bastante sobre o assunto, irá esbarrar em outras soluções:

• Houve algum tempo, se pensou numa forma nova para implementar uma replicação multimaster síncrona num projeto batizado como Slony II que rapidamente foi abandonado por ser considerado complexo demais e inviável na prática.
• O PGCluster II  é uma tentativa de implementar algo semelhante ao Oracle RAC, que também é uma solução de alta disponibilidade e exige que todos os nós fiquem no mesmo local (eles tem de compartilhar o mesmo storage). Pelo que consta o PGCluter II ainda não teve nenhuma versão oficial lançada e não sei se ainda tem algum desenvolvimento ativo.
• O Bucardo é uma solução já em produção, mas não é síncrona, ou seja, ela admite um atraso entre as atualizações em cada nó o que exige regras de resolução de conflito quando um mesmo registro é atualizados em diferentes nós. Ou seja, não garante nem tem como garantir o ACID. O Bucardo é indicado para sincronizar uma base principal com outras bases  com pouco volume de atualização, como no caso de forças de vendas que tem uma base isolada no notebook de cada vendedor.

Bom, mas então como resolvemos o problema das filiais??? Duas abordagens distintas:

• Resolva o seu problema com o link e mantenha todos os seus dados numa única base. Pode parecer besteira, mas ainda é a solução mais utilizada por grandes empresas que podem investir na redundância de links de alta velocidade e alta disponibilidade;
• Não integrar todos os dados em uma única base. Faça com que  cada filial tenha apenas uma fatia dos dados e ponto final. Uma variação mais eficiente é fazer com que uma chamada por informações que se encontram em outro servidor sejam desviadas  para o servidor correto. Isto se chama particionamento horizontal ou cluster shared nothing e é uma técnica bastante complexa, mas muito eficiente. Uma forma de implementar isto no PostgreSQL é utlizando o PL/Proxy do Skytools.

As duas abordagens podem parecer um tanto radicais para você? Bom, eu diria que 90% dos grandes bancos utilizam exatamente estas abordagens:  possuem cerca de 3 ou 4 sites (digamos que em SP, DF e PE) cada uma respondendo por todas as transações da sua região. Há um investimento pesado para conectar todos os terminais no site da sua região. Se você precisar de informações de um site em outra região, a conexão é desviada para o site correto.

Estas são as duas formas óbvias de encarar o problema: centralizar tudo numa única base, ou dividir logo todos os dados em bases isoladas. Isto é tudo o que você pode fazer sem ter que mexer na lógica da aplicação. No entanto, se você está disposto a mexer na sua aplicação, particularmente na modelagem desta, então existe sim um meio termo. A primeira coisa a se fazer é dividir as tabelas em partes conforme as regras de negócio para a sua atualização:

1. Tabelas que não são atualizadas ou que são atualizadas raramente: inclua aqui tabelas de parâmetros e coisas do tipo. Se você puder realizar as atualizações em apenas um local então você pode fazer com elas caiam no segundo caso:
2. Tabelas que são atualizadas apenas em um nó como a matriz e são consultadas por todas as outras filiais;
3. Tabelas onde cada filial é responsável pela atualização de apenas um punhado de registros, sendo que cada filial não pode alterar os registros da outra filial;
4. Tabelas onde cada filial deve poder atualizar qualquer registro da tabela, independente de qual filial seja.

• Tudo que estiver nos casos 1 e 2 podem sofrer uma replicação multi/master, que é um pouco menos complexa e possui algumas boas ferramentas para implementar como o Slony I e o Londiste. A ideia é simples, você atualiza as informações em uma única base e as informações são replicadas para os demais nós.
• Tudo que estiver no 3º caso deve ser modificado para cair no 2º caso através do particionamento de tabelas. Assim você divide uma única tabela em uma tabela pai e várias outras tabelas filhas, uma para cada filial. As atualizações só serão feitos na tabela relativa a filial onde ele está e as suas atualizações são replicadas para as demais filiais. O particionamento de tabelas no PostgreSQL é um pouco chato de ser feito (melhorou um pouco no 8.4 mas no 8.5 está prometida uma revolução), mas é bastante flexível, portanto, depois de particionar as tabelas, você cai numa situação onde a replicação master/slave pode ser aplicada novamente;
• Se você tiver o azar de cair no 4º caso , então você não terá outra alternativa senão utilizar o commit em duas fazes. Em geral, com uma boa modelagem você consegue fugir deste tipo de situação ao máximo, mas quando não for realmente possível, a ferramenta é esta. Note que nos casos 2 e 3, não estou falando de replicação síncrona. Se você realmente precisar de transações síncronas, com ACID entre todos os nós, o commit em duas fases é a sua única opção.

Como você pode perceber, não existe solução fácil. Mas, feliz são os desenvolvedores que criam suas aplicações já pensando neste tipo de solução. É claro que hoje se utiliza muito SOA, REST e outras tecnologias para trafegar informações entre aplicações. Outros se aventuram com o envio de TXT, ou XML para lá e para cá das mais diversas formas. Há ainda aqueles que criam uma teia de DBLinks para interligar as bases. Eu como DBA não sou especialista neste tipo de solução, mas acredito que elas sirvam para resolver outro tipo de problema. Um exemplo clássico seria a disponibilização de informações ou serviços de uma aplicação para outra aplicação diferente e não para a replicação de informações dentro de uma mesma aplicação. Trocar informações entre aplicações é muito diferente de replicar informações em bases distribuidas. A chave do problema sempre estará nas diferenças entre síncrono e assíncrono, e master/slave e multimaster.

Bom, eu acho que é só por enquanto. Se alguém conhecer outro tipo de solução que não seja baseada em nenhum dos casos aqui ou se tiver uma experiência que refute os argumentos que apresentei aqui, por favor deixe um comentário abaixo para trocarmos umas figurinhas, ok?

• Para saber mais sobre os diferentes tipos de Cluster e Replicação, veja neste blog o texto: Cluster != Replicação.
• Para saber mais sobre soluções de alta disponibilidade e balanceamento de carva, veja o texto da documentação oficial: High Availability, Load Balancing, and Replication