Vejo vocês por lá.

Bom, vou lhes dizer que eu concordo com os mestres em gênero número e grau. Vejamos como a Sun vai reagir quanto a isso no caminho. Alias, o Sr. Josh Berkus escreveu sobre o Drizzle logo após anunciar sua saída do time da Sun. Ele ainda não falou para onde vai, mas já apresentou quem será o seu sucessor, o Sr. Peter Eisentraut, outro grande desenvolvedor do PostgreSQL.

Não percam os próximos capítulos desta saga que promete muitos lances curiosos no caminho.

Tudo que você sempre quis saber sobre discos em servidores PostgreSQL e tinha vergonha de perguntar

Este é um texto que eu tenho vontade de escrever já faz bem um ano. Não escrevi antes por preguiça (é um texto longo) e porque é um texto um tanto pretensioso (tive receio de falar bobagem). Esta semana eu resolvi correr o risco. Já fazia um tempo que eu não me debruçava sobre um texto técnico um pouco mais longo, então tomei coragem e coloquei as idéias no papel, ou melhor, no blog. Muitos DBAs experientes sentirão que eu posso ter escorregado ou simplificado demais aqui ou ali. O propósito era escrever algo didático e não um livro inteiro sobre o assunto. Mas se você encontrar imprecisões técnicas ou tiver alguma sugestão para melhorar/corrigir o texto, por favor deixe um comentário.

Todo DBA é ou deveria ser tarado por discos. A não ser que você seja um daqueles que acreditam que um banco de dados possa conviver inteiro na memória sem nenhum problema (já ouviram falar de um SGDB escrito em Java que é mais rápido que o MySQL e o PostgreSQL?) você verá que os discos são o ponto chave no desempenho, na segurança e no custo do hardware. Neste texto vamos abordar alguns aspectos importantes e tentar visualizar ver como aplicar um pouco disso práticos no final. Vejamos os tópicos a serem abordados:

• RAID
• Discos
• Controladoras de Discos
• Tipos de Arquivos
• Particionamento
• Como distribuir as partições nos discos existentes

RAID

Em termos de desempenho o mantra sempre foi “quanto mais discos melhor”. Mas algo mudou no meio do caminho. Há tempos atrás as pessoas ficavam fazendo uma ginastica danada para distribuir os tablespaces em discos diferentes. O resultado era a paralelização no acesso ao disco. Se realizado com sucesso, o processo iria dobrar a velocidade quando uma operação fosse realizada em dois discos ao mesmo tempo. Fazer isso não é simples. Uma formula mágica muito divulgada era o de separar os índices das tabelas. Como é comum acessar uma tabela e acessar seus índices também, isto parecia fazer muito sentido. Surpresa, não é bem assim que as coisas funcionam. Você tem que fazer uma avaliação real de quais objetos (tabelas e índices) são acessados mais concomitantemente. Isso era o que se chama de “evitar a contenção de discos”. Ocorre que o otimizador ao fazer uma consulta que envolve várias tabelas pode realizar o acesso a disco de diversas formas diferentes. De acordo com a época do ano, a freqüência no acesso aos objetos pode mudar, enfim, são inúmeros detalhes para serem avaliados. Resultado: distribuir os objetos em dois discos ao invés de um não significa ter o dobro de velocidade o tempo todo.

O uso massivo do RAID começou a trazer uma nova abordagem. Quanto mais discos você colocar no RAID, mais rápido o acesso será para todas as operações. Então se você dobra o número de discos no RAID, você dobra a velocidade em todo o acesso aos objetos armazenados naqueles discos. Então a questão fundamental é em quantos discos a informação vai ser dividida para gravarmos ela simultaneamente. É aqui que começa a guerra dos tipos de RAID a se utilizar.

Com o RAID 0, você tem o aproveitamento máximo dos discos. A implementação é simples e o ganho de desempenho é máximo também: o ganho de desempenho é exatamente igual ao número de discos utilizados. 2 discos, 2 vezes mais rápido. 5 discos, 5 vezes mais rápido, 100 discos, 100 vezes mais rápido. Não é maravilhoso? Simples, barato e eficiente. Só tem um problema. Se um único disco falhar… todos os seus dados em todos os discos do RAID vão para o espaço, junto com o seu emprego. Resultado, o RAID 0 só pode ser utilizado em um servidor de banco de dados em uma situação: dados temporários cuja perda não causa perda de dados nem indisponibilidade no sistema. Há um bom exemplo disso. Se você utiliza sistemas que fazem consultas muito complexas, numa base grande (vejamos, pelo menos uns 500GB é algo de tamanho considerável) como num data warehouse, você terá um volume de dados temporários considerável. Neste caso, vale a pena ter um RAID separado só para os tablespaces temporários. O PostgreSQL 8.3 traz a capacidade de indicar um lugar específico para os dados temporários. Aqui é o lugar para isso.

Então vem o nosso amigo RAID 5, que é muito rápido para leitura, mas é considerado lento para gravação. Se você tem um grande volume de dados estáticos, com muita leitura e pouca gravação, o RAID 5 pode ser para você. É verdade que o RAID 5 tem desempenho inferior em gravação. Mas se você colocar um volume grande de discos, com pelo menos 5 discos, este custo passa a ser compensado pelo aumento no número de discos. Existem também implementações do RAID 5 em hardwares proprietários que não apresentam uma penalização de gravação tão alta quanto se divulga por aí. É claro que isto depende do uso de uma ótima controladora de discos. Mas o fato é que o RAID 5 tem má fama devido ao seu problema com a segurança. Enquanto no RAID 0 você não tem segurança nenhuma, o RAID 5 permite que você perca até um disco. O problema é que se você comprar vários discos num mesmo lote, existe uma grande chance deles apresentarem defeito em no mesmo período. Se você observar dezenas de lâmpadas trocadas ao mesmo tempo, verá que elas começam a queimar na mesma época. Se isto ocorrer com seu RAID 5, você terá problemas. Então, se você se preocupa com segurança, não use RAID 5. No RAID 5 você precisa ter no mínimo 3 discos, mas você não deveria jamais montar um RAID 5 com 3 discos. Por outro lado, se você se preocupa com a segurança, colocar um número muito grande de discos aumenta a chance de haver uma falha em mais de um disco. Outro detalhe bizarro é que se ocorrer uma falha e você tiver um hot spare, este entrará em operação e começará a remontar todo o esquema de redundância novamente. Essa operação de reconstrução da paridade do RAID 5 é pesada e lenta, então se o seus discos forem do mesmo lote, a chance de um segundo disco quebrar durante a reconstrução é grande. Se isso ocorrer, você perderá todos os seus dados. Se você se preocupa com desempenho só use RAID 5 com pelo menos 5 discos. Se você se preocupa com a segurança, use um hot spare e também não aumente muito o número de discos.

Então porquê todos usam tanto o RAID 5? É simples… ele é muito mais barato que o RAID 1. Destes discos, o espaço total de armazenamento será equivalente ao espaço de todos os discos juntos menos 1. Então se você tem 10 discos de 300 GB, o espaço útil é de 3TB - 300GB = 2.7TB. Nada mau, não? Mas veja bem… a quantidade de discos tem influência enorme não apenas no custo, mas na segurança e no desempenho também. Então onde posso usar o RAID 5? Se você se preocupa exclusivamente com o custo, o RAID 5 é uma solução barata em termos de capacidade de armazenamento, combinando uma segurança mínima que diminui conforme o número de discos aumenta. Se você pensa em desempenho e tem dados atualizados com pouca freqüência, como em dados históricos, o RAID 5 é uma boa solução. Mas se você se preocupa com segurança, evite o RAID 5 e só use para armazenar dados não críticos.

Existe também o RAID 6 que começou a ser utilizado recentemente. Ele é muito semelhante ao RAID 5, mas permite a perda de até 2 discos sem interrupção no funcionamento. É mais seguro sem ser muito mais caro. Você provavelmente só vai encontrar o RAID 6 em controladoras mais sofisticadas e storages externos. Num RAID 6, com 10 discos de 300GB o espaço útil é de 2.4TB. Para um número pequeno de discos (o mínimo são 4 discos, mas você deveria pensar e começar com 6) o uso de um disco a mais para a paridade é significativo, mas para um número grande isto se torna uma questão menor. Em termos de segurança, poder perder 2 discos é muito interessante. O RAID 6 não sofre tanto com o problema da reconstrução da paridade como no RAID 5, o que aumenta bem a sua segurança. Em termos de desempenho ele é semelhante ao RAID 6.

O nosso amigo RAID 1 é o mais simples e o mais caro tipo de RAID. O ganho de desempenho dele é nulo na gravação e mas dobra a velocidade na leitura. Além disso a capacidade total de armazenamento é metade da soma dos discos. O RAID 1 é o simples espelhamento dos discos. Vejamos como as coisas ficam. Se você tem dois discos de 300GB em RAID 1, o seu espaço útil é de 300GB. Simples assim. Se você tem apenas 2 discos e não quer se arriscar com o RAID 0, o RAID 1 é sua única opção.

O tipo de RAID que fez as pessoas largarem mão de distribuir os dados em diferentes discos isolados (sem RAID), foi o RAID 10, ou RAID 1 + 0. O RAID 10 combina o aumento de segurança do RAID 1 com o aumento de desempenho do RAID 0. Só tem um problema, assim como o RAID 1, ele precisa de 50% dos discos para o espelhamento, o que encarece a solução. Outro detalhe, é que você começa a brincar de RAID 10 a partir de 4 discos e daí para frente sempre em números pares como 4, 6, 8, 10, 12, etc. Com dois discos você tem apenas o RAID 1. Assim, o único problema do RAID 10 é o custo. Imagine que com 4 discos de 300GB, você só aproveitará 600GB. Com 10 discos de 300GB, só aproveitará 1,5TB. É bem possível também que com 10 discos em RAID 5 ou 6 você tenha um desempenho de gravação semelhante ou superior e um desempenho em leitura muito maior. Então a questão do RAID 10 é realmente a segurança.

Então fica a questão: quando eu devo usar o RAID? Resposta: SEMPRE, escolhendo o RAID 10, 1, 5 ou 6 dependendo das suas prioridades e RAID 0 para casos muito especiais como um esquema complementar. A cultura que está se formando em tornos dos DBAs hoje é a de usar RAID 1 ou 10 para tudo, uma vez que a segurança raramente é uma questão menor e o custo $/GB estar caindo, particularmente com os discos SAS em substituição aos SCSI.

Discos

Falando em tipos de discos, outra coisa que você deve lembrar é que existem no mercado 3 tipos de interfaces para discos: fibre channel, SAS e SCSI. Não exite SATA, esqueça que eles existem mesmo em RAID. Não importa o que você leu no blog do beltrano, SATA é muito mais lento e muito menos confiável. Mesmo os discos SAS estão ainda sob vigilância, uma vez que sempre que o preço dos discos cai muito, a desconfiança aumenta. De qualquer forma, os discos SAS devem dominar o mercado rapidamente. Os discos fibre channel são usados apenas em storages externos de alto desempenho. É comum ver storages que suportem discos SCSI, fibre channel, SAS e SATA. Mesmo que o seu storage seja caríssimo, o fato dele suportar os discos SATA não significa que eles sejam adequados para bancos de dados. Pode ser que para servidores de arquivo o seu uso junto com RAID seja aceitável, para bancos de dados não. Você realmente vai ter que comprar uma controladora descente e discos dedicados a servidores e não a desktops.

Sobre o tamanho dos discos, há outro detalhe importante. Pelo menos na tradição dos discos SCSI, os discos de maior capacidade são os que tem o custo de $/GB melhor e o pior desempenho. Não sei se a mesma tendência se repetirá com os discos SAS, mas é bom ficar de olho. Mesmo porquê, se você precisa de muito espaço em disco, é claro que a melhor solução é ter muitos discos pequenos e não poucos discos enormes. Aumentar o número de discos é sinônimo de aumentar o desempenho. Não existem servidores de bancos de dados sérios com 1 disco. Comece com 2 discos e aumente este número aos pares. Isto o deixa na posição de começar com um RAID 1 que é uma solução aceitável para um servidor pequeno e crescer para 4 ou 6 no futuro com um RAID 10. É claro que se você não utiliza um storage externo, o gabinete do servidor vai limitá-lo seriamente. Então evite os servidores 1U (estou falando da altura do servidor no rack, é claro) que só comportam cerca de 2 discos e prefira os servidores com 2U que comportam em geral até 6 discos ou 4U que comportam cerca de 15 discos. Existem discos novos com tamanho de 2,5 polegadas ao invés das tradicionais 3,5 polegadas. Estes devem possibilitar um aumento no número de discos num mesmo gabinete além de diminuir o consumo de energia. Ainda é muito cedo para fazer uma comparação séria.

A estatística que realmente interessa para o desempenho do banco de dados é o número de operações por segundo, o IOPS e a taxa de transferência sustentada. O IOPS depende não apenas dos discos, mas da controladora e do SO utilizado. Você pode verificar o IOPS do seu servidor no Linux através do iostat. A coluna “tps” do relatório do iostat é equivalente ao IOPS do seu disco. A taxa de transferência sustentada é a quantidade de bytes que o disco consegue transferir por um longo período. Os fabricantes costumam publicar nas suas especificações a taxa de transferência e a taxa de transferência sustentada. Você deve se preocupar apenas com a segunda. É aqui que os HDs SATA perdem e muito, pois o protocolo utilizado pelo HD SATA não consegue manter uma taxa de transferência razoável. Já os discos Fibre Channel, SCSI e SAS (lembre-se que o SAS nada mais é do que o protocolo SCSI com uma interface serial).

Ao comparar os últimos lançamentos dos discos da Seagate por exemplo, vemos o disco Savvio de 2.5 polegadas, 15Krpm com interface SAS e capacidade de 36GB e 72GB. Já em 3.5 polegadas temos o Cheetah um disco de 15,6Krpm com interface SAS ou Fibre Channel e capacidade de 146GB, 300GB ou 450GB. Vejamos alguns detalhes das especificações:

Notamos que:

• A taxa de transferência externa do Fibre Channel é maior que o SAS;
• A taxa de transferência sustentada é menor nos discos de 2.5 polegadas. Vale a pena lembrar que quanto maior o diâmetro do disco, maior a quantidade de setores nas trilhas externas do disco. Assim, mantendo o número de rotações do disco, os discos com maior diâmetro conseguem transferir um número maior de dados;
• O tempo de busca que mede a velocidade com a qual o cabeçote se move (de trilha para trilha) é igual, mas como o disco de 3,5 polegadas tem que se movimentar por um disco com maior diâmetro, o tempo médio de busca dele é maior.
• O consumo de energia dos discos de 2,5 é substancialmente menor, devido ao menor peso dos discos;

O custo de cada um destes discos, está entre 400 e 600 dólares. Acredite ou não, este é um preço muito razoável. Não faz nem 2 anos e tive que comprar discos de 146GB em Fibre Channel e 10Krpm por nada menos que R$ 15.000,00 cada um. Então, considerando que estamos olhando para um hardware de ponta, podemos esperar que em 2 anos estes discos se tornar opções standard.

Controladoras de discos

Bom, para encerrar a questão do hardware, você tem que pensar com cuidado na sua controladora de discos. Assim como quem vê processador não vê chipset, quem vê discos, não vê controladora de discos. Não adianta ter vários discos de 15Krpm SAS e uma controladora standard. Uma boa controladora faz toda a diferença. Há quem diga que com uma controladora ruim, vale mais a pena utilizar RAID por software do que aproveitar o RAID nativo da controladora. Além disso, a quantidade de discos que a controladora suporta, as modalidades de RAID, a quantidade de buffer cache disponível, a presença de bateria, tudo isso influencia muito. Uma controladora mais simples pode ter seu preço em torno dos 250 dólares e uma mais poderosa pode ultrapassar os 1000. Mas você deve reservar uma parte do orçamento para alguns acessórios para a sua controladora como cabos, pentes de memória e baterias externas que podem fazer você chegar facilmente aos 2 mil dólares.

Apesar de haverem controladoras que suportam até 128 discos SAS no mercado, pode ser que alocar esta quantidade de discos dentro do seu servidor não seja tão simples. Se você chegar neste ponto, pode ser interessante pensar num storage externo. Há diversos modelos de storage, escaláveis para quantidades consideráveis de discos. Você pode começar com uma gaveta contendo uma dezena de discos e ir adicionando novas gavetas e até mesmo racks chegando aos milhares de discos. Há outras vantagens consideráveis no uso de um storage externo. Você pode compartilhar o mesmo storage com mais de um servidor e montar uma SAN (Storage Area Network), o que pode ser muito interessante, para migrar dados de produção para teste, usar replicação ou até técnicas de cluster. A performance também é um fator fundamental. Eles chegam a ter vários GB de cache e boas baterias internas, o que lhe permite utilizar o cache de gravação com segurança. Além disso, os storages costumam vender alguns softwares (proprietários até a alma) que ativam capacidades especiais do hardware como tuning de discos, monitoramento avançado e o meu preferido: snapshots! O custos de soluções de médio porte de storage despencaram. Acredite ou não, já é possível contar com uma estrutura de storage completa com menos de R$ 50 mil. Vale a pena ressaltar, que para bancos de dados, os storages iSCSI embora mais baratos, não são recomendados, pois até o momento apresentam um desempenho inferior ao fibre channel. Acha muito? Você não tem idéia de o quanto os preços já caíram. Não faz muito tempo que um storage básico com Fibre Channel e 1TB não saia por menos de uns R$200 mil. É claro que esta conta pode chegar na casa dos milhões muito rápido. É só colocar milhares de discos na conta. Você acha que utilizar milhares de discos é um exagero? Convido você a olhar os testes de performance do TPC… o teste mais simples, não usam menos de 100 discos. Realmente vale a pena olhar os testes, pois além do resultado de performance, eles detalham todos os custos de hardware e software, incluindo suporte para 3 anos.

Tipos de arquivos

Agora vem uma parte realmente importante que é entender os diferentes tipos de informação que serão gravados no seu servidor. Mesmo se você tem um pequeno servidor de banco de dados com apenas dois discos (se você só tem 1, bem… sinto muito), isso é fundamental antes de sair particionando os discos.

Vejamos como podemos classifica-los:

• Sistema Operacional

Estamos imaginando obviamente que você está criando um servidor dedicado. Servidores de bancos de dados são serviços que gostam de exclusividade, principalmente no acesso a disco. Então, se for inevitável ter que colocar mais um serviço no mesmo servidor, que este não seja um servidor de e-mail ou arquivos. Nada que vá disputar o acesso aos discos com o banco de dados. De toda a forma a idéia é que o SO não costuma ocupar muito espaço, não é um gargalo de desempenho e não compõe uma parte crítica dos dados uma vez que ele pode sempre ser reinstalado. Claro que perder o SO, vai lhe causar um bom tempo com o servidor fora do ar até que ele seja reinstalado, portanto algum tipo de proteção deve existir, como um RAID 1, 5, 6 ou 10. Em geral, uma partição com alguns GB devem ser suficientes para todo o SO, e executáveis do SGDB. Se estiver usando Linux, não esqueça de guardar uma pequena partição para o kernel (algo como 100 ou 200 MB).

• Swap

O Linux e outros SOs utilizam uma parte do disco para servir de memória virtual paginada em caso de falta de memória. Em tese isto nunca deve acontecer e você deve ter memória suficiente para evitar este tipo de situação na maior parte do tempo. No entanto, se acontecer o Swap deve estar lá para evitar que todos os processos se percam repentinamente. O Swap deve sempre possuir sua própria partição que em geral possui o mesmo tamanho da sua memória RAM. Se você tiver mais de 4GB, pode pensar em usar um pouco menos de isso, chegando a 50% da RAM a partir dos 8GB para cima.

• Logs

O seu servidor gera uma série de logs sobre o que acontece no banco de dados e no servidor. A quantidade de logs gerados variam muito conforme a configuração do banco de dados e demais serviços. Em geral a configuração standard do SO é suficiente para a maioria dos casos enquanto as configurações do banco de dados devem ser estudadas caso a caso. Você deve determinar onde colocar seus logs, o que logar, quando logar, etc. Uma análise de performance num ambiente de produção pode gerar alguns GB de logs em poucos minutos. Guardar uma partição para estes logs é importante. Os logs devem ficar sob controle e não devem ocupar um espaço maior do que o previsto. É comum executar faxinas periódicas nos logs. Não esqueça de configurar os logs do PostgreSQL.

• Tablespace padrão.

O tablespace padrão é aquele utilizado para guardar o dicionário de dados. Este tablespace é crítico. Ele ocupa pouco espaço pois só consiste nos metadados a respeito dos demais objetos do banco. Se você perder o dicionário de dados, não conseguirá acessar mais nenhum objeto do banco, tornando-o completamente inútil. Em termos de segurança, este é um tablespace que deve ser muito bem protegido. Se você tiver muita memória, provavelmente o dicionário do sistema deve estar quase sempre no buffer tornando o desempenho uma questão secundária. O problema que se encontra com freqüência é que as pessoas não criam novos tablespaces para uso dos objetos normais das aplicações. Misturar ambos não é uma boa idéia. O espaço ocupado pelo tablespace default costuma ser mínimo, se ele realmente contiver apenas o dicionário de dados. A não ser que você tenha uma quantidade muito grande de objetos, particularmente visões e funções, destinar 1GB para este tablespace costuma ser mais que o suficiente.

• Tablespace temporário

O tablespace temporário não tem impacto em termos de segurança para as informações. As informações lá armazenadas são apenas uma área de trabalho para operações intermediárias e tabelas temporárias. Em tese, estas informações jamais precisariam ser guardadas em disco, porém operações pesadas como a ordenação de uma tabela muito grande podem exigir muito deste tablespace. Particularmente os DataWarehouse, Data Marts e relatórios pesados exigem um volume considerável em disco. O desemprenho das consultas pesadas podem fazer deste tablespace algo crítico também. Vale a pena conhecer o perfil de carga da sua aplicação para saber se vale a pena investir em uma abordagem específica para este tablespace. Por padrão o tablespace temporário fica junto com o dicionario de dados, mas você pode setar a partir da versão 8.3 do PostgreSQL o parâmetro temp_tablespaces para escolher um local diferente.

• Outros tablespaces

As informações do banco de dados ficam armazenadas ao fim e ao cabo nos seus arquivos de dados que devem possuir seus próprios tablespaces. Um critério para dividir os tablespaces é usar um par de tablespaces para tabelas e outro para índices em cada aplicações. Apesar de não ser mais comum dividir índices e tabelas em discos distintos, isto pode lhe ajudar muito em termos administrativos, resolução e recuperação de desastres. Além disso, você pode fazer ajustes de desempenhos mais agressivos nos índices, uma vez que eles podem ser reconstruídos facilmente. No entanto, alguns objetos muito grandes podem exigir particionamento. Os benefícios do particionamento de tabelas e índices se fazem mais presentes quando colocamos cada partição em um tablespace distinto que por duas vez devem estar em discos distintos. Outra questão é o tipo de uso do tablespace de acordo com o perfil de operações SQL executadas sobre seus objetos. Vou deixar aqui classificados 5 tipos básicos:

Tablespace para OLTP: é o tablespace mais crítico em termos de desempenho e segurança. Isto ocorre pois ele sofre um grande volume de pequenas gravações concorrentes. As gravações concorrentes são o verdadeiro inferno em termos de desempenho. Por outro lado, exigem técnicas mais sofisticadas para evitar a perda de dados. Tablespaces de aplicações com forte carga OLTP devem estar em discos distintos dos demais pois precisam de atenção especial.

Tablespace para BI: as aplicações de BI são completamente diferentes. Elas sofrem em geral grandes cargas periódicas de dados e não sofrem atualizações constantes. Ao contrario da carga em OLTP, em BI temos poucos usuários simultâneos e quase nenhuma operação de gravação. O grande desafio é conseguir suportar consultas complexas que envolvem um grande volume de dados. Aqui o desempenho também é crucial, pois uma única consulta pode facilmente levar dias para se concluir. A segurança não é em geral um ponto crucial, visto que os dados podem ser reconstruídos a partir de cargas externas.

Tablespace para Web: as aplicações web tradicionais são aquelas que possuem um volume absurdo de conexões simultâneas em operações predominantemente de pequenas leituras. Devido ao grande volume de acessos que um site na web pode ter, o desempenho é novamente um fator crucial. Se por um lado o baixo número de gravações costuma minimizar a chance de perda de dados, a indisponibilidade costuma ser um problema muito sério.

Tablespace Histórico: algumas aplicações ou parte delas, carregam um volume enorme de informações históricas e quase sempre estáticas. Estes dados precisam estar on-line para fins de auditoria ou consultas esporádicas. Este é um raro caso onde o desempenho e a segurança não são tão importantes. Aqui é um dos locais onde, tomando os devidos cuidados, podemos economizar um pouco nos discos.

• Logs de transação

Os logs de transação, no PostgreSQL, são conhecidos como WAL ou Write Ahead Log. Estes arquivos são arquivos de tamanho fixo utilizados para assegurar a segurança dos dados em caso de queda de energia. Sem eles a segurança do banco de dados seria tragicamente comprometida. Os logs são então alvo de enorme preocupação em termos de segurança contra a perda de dados e ao mesmo tempo tem uma influência enorme no desempenho. Para se ter uma idéia de como o WAL é importante, em um artigo do Indiano Jignesh Hah (veja os comentários também…) ele demonstra que numa aplicação OLTP pesada com cerca de 3000 transações por segundo, seriam necessários 25 discos para atingir o IOPS necessário para não ter uma grande degradação de performance. Se adicionarmos o espelhamento que é praticamente obrigatório nestes casos estaremos falando de 50 discos só para o WAL! Veja que como as gravações no WAL são seqüenciais, deixa-los isolados em discos vai garantir uma maior velocidade, mas isto se não houver nenhum outro acesso em paralelo naquele disco ou RAID.

• Arquivamento dos logs de transação

O archive consiste na cópia dos logs de transação que são reciclados. Fazer um backup do WAL é considerado obrigatório em ambientes de produção. Sem ele, qualquer arquivo de dados corrompido implicaria obrigatoriamente em perda de dados. O archive junto com o backup on-line dos tablespaces permitem o uso de uma técnica avançadas para recuperações de desastres conhecida como “Point In Time Recovery”. Enquanto o WAL precisa de um pouco espaço de armazenamento, é de praxe deixar em disco algo em torno de uma semana de backups do WAL, o que pode significar vários GB em disco de acordo com o volume de atualizações que o banco sofre.

• Backup físico

A não ser em caso de bases pequenas com alguns poucos GB, o backup físico é praticamente obrigatório. Isto significa que você tem que ter espaço em disco (local ou remoto) para armazenar uma cópia de todos os seus datafiles. As exigências de desempenho aqui vão depender da sua janela de backup. Se você estiver na graça de possuir um storage com software de snapshot, então sua vida se tornará muito mais simples aqui. Lembre-se que os backups em disco não devem jamais substituir os backups em fita. Em último caso, fique apenas com os backups em fita. Mas ter uma cópia do último backup físico em disco, pode acelerar muito o processo de recuperação de desastres.

• Backup lógico

O backup lógico não é uma estratégia recomendada para bases medias e grandes. Mesmo assim, você deve pensar em reservar um espaço em disco para os backups lógicos. O motivo é que a movimentação de dados entre as bases de produção, homologação e testes costumam ser frequentes. Seria decepcionante perceber que você não tem espaço em disco para isso. Aqui, o desempenho e a segurança não costumam ser algo fundamental.

Particionamento

É possível utilizar apenas uma partição para todo o servidor? Sim. Isto é bom? Não. Existem quatro bons motivos para você separar diferentes tipos de arquivos em diferentes partições:

1. Segurança contra perda de dados: se você tiver os dados do seu servidor em um grupo de discos, o WAL e seus arquivamentos em outro e possuir um backup físico em algum lugar, a perda completa do grupo de discos onde os tablespaces estão não implicarão em perda de dados. Separar os tablespaces do WAL e seus archives e possuir um backup físico em algum outro lugar (em outro servidor, outro disco local, outra fita, etc) são uma política muito segura para se evitar a perda de dados e conseqüentemente a perda de emprego…
2. Segurança contra indisponibilidade: se você tiver apenas uma partição e um erro qualquer acontecer no servidor ou mesmo numa aplicação que acessa o banco de dados, ele pode começar a exigir repentinamente um montante enorme de espaço em disco até que ele fique completamente cheio. Se você tiver uma única partição no seu servidor, você terá não apenas o seu banco de dados travado, como o seu SO também. Separando os tipos de arquivos em partições distintas, você limita drasticamente o impacto deste tipo de situação;
3. Administração: Fica mais fácil detectar áreas que estão crescendo demais se elas estiverem guardadas em caixas separadas. Dividir os tipos de arquivos em diferentes partições permite que com um único comando no SO (um ‘df’ no caso do Linux) seja possível verificar como andam se comportando diferentes tipos de arquivos;
4. Desempenho: Se você separar diferentes tipos de arquivos em diferentes partições, poderá utilizar diferentes sistemas de arquivos em cada um deles. Além disso, discos, controladoras e sistemas de arquivos possuem diferentes configurações que podem ajudar a aumentar o desempenho em algumas áreas críticas.

Ter tipos de arquivos diferentes em partições diferentes, nem sempre significa utilizar discos ou grupos de discos em RAID distintos. Se você tiver apenas 2 discos, não será possível fazer muita coisa. Ainda assim, separar algumas coisas como: SO, logs, tablespace padrão, outros tablespaces, WAL, archives e backups em partições distintas, costuma fazer muito sentido. Um problema com as partições é que elas tem tamanho fixo, obrigando você a prever quanto espaço será necessário para cada partição. Em geral, prever isso costuma ser um dever do DBA, mas em bases novas isto pode ser mais difícil. Em todo caso, os storages e controladoras modernas permitem o uso de LUNs que mudam de tamanho dinamicamente. Se você não tiver acesso a este tipo de tecnologia, pode usar também o LVM que funciona muito bem, apesar que causar uma pouco de perda de desempenho no acesso a disco.

Como distribuir as partições nos discos existentes

Vamos imaginar aqui diferentes números de discos no servidor e possíveis configurações que poderiam ser utilizadas. Aqui estamos fazendo um chute grosseiro, você pode mudar um pouco as configurações dos discos e partições de acordo com algumas das dicas acima entre outras coisas, inclusive por exigências contratuais ou SLA.

• Um disco

Bom, esta é a pior situação que você pode encontrar pois não é possível montar um RAID. A sua segurança contra falhas de discos é nula e o seu desempenho também será pobre. Neste caso, você deve pelo menos adorar uma política de backups freqüentes para minimizar a possível perda de dados a qual você está sujeito. Tenha certeza de alertar sobre os riscos por escrito aos seus superiores.

Mesmo tendo apenas um disco, você deve ter ao menos ter as seguintes partições:

/boot para o kernel do linux (100MB a 200MB)

/ para o restante do SO (algo entre 5 e 10GB)

/var/log ou outro local destinado aos logs (algo entre 1 e 10 GB costumam ser valores razoáveis)

swap (o mesmo tamanho do tamanho da memória RAM)

/var/lib ou /postgres outro local destinado aos dados (cerca da metade do espaço em disco restante

/backup ou outro local para os backups lógicos e/ou físicos (o restante do espaço em disco)

• Dois discos

A não ser que você tenha dois discos de tamanhos diferentes, use RAID 1 e mantenha o esquema de particionamento descrito acima;

• Três discos

Se você se preocupa com disponibilidade, use um RAID 1 com dois discos e deixe o disco restante como hot spare. Se você está precisando desesperadamente de mais espaço em disco, você pode montar um RAID 1 com dois discos e utilizar o 3º disco ser RAID para guardar os seus backups

• Quatro discos

Se a sua prioridade for segurança, você pode montar dois RAIDs 1. No primeiro RAID 1 coloque o seu SO, os logs, o WAL, o archive e os backups físicos. No segundo RAID 1 coloque os tablespaces e os backups lógicos. Voucê também pode montar um RAID 1 com 2 discos, mais um disco de hot spare e utilizar o 4º disco para guardar seus backups.

Se a sua prioridade for desempenho, coloque tudo em um RAID 10 com os 4 discos.

• Cinco discos

Use dois RAIDs 1 ou um RAID 10 e deixe um disco de hot spare.

• Seis discos

Use a mesma configuração de 5 discos, mas reserve um disco só para backup lógico e/ou físico

• Sete discos

Um disco ficará para hot spare, as os 6 discos sobrando podem ser divididos em um RAID 1 com dois discos e um RAID 10 com 4 discos (opção recomendada para aumentar a segurança) ou montar um RAID 10 com 6 discos (opção recomendada para privilegiar o desempenho).

Você verá que com um maior número de discos você pode separar mais as coisas em pelo menos 3 grupos:

• Logs de transação e archives
• Datafiles
• Backups

Se você tiver algo como 15 ou mais discos, poderá começar a separar tablespaces em discos diferentes, optar ocasionalmente por um RAID 5 ou 6 para arquivos menos críticos e coisas do tipo. É claro que isso vai depender do seu conhecimento da aplicação, das suas exigências de performance e segurança e é claro… do seu bolso.

Bom, vejamos aqui uma primeira versão da grade do evento:

26/09 - Sexta-feira

08:00   Credenciamento
09:00   Abertura (Fala de representantes da UNICAMP, Governo Federal, Comunidade PostgreSQL Brasileira, Conunidade PostgreSQL Internacional e Empresários).
09:50   Bruce Momjian - “PostgreSQL’s Path to the Future”
11:00   Intervalo
11:20   Palestra de patrocinador OURO (Dextra)
12:00   Almoço
14:00   Case / Palestrante Platina
14:50   — (a definir)
15:40   — (a definir)
16:30   Intervalo
16:50   Wagner Corrêa Ramos - “Projeto de replicação multi-master com 143 servidores”
17:40   Euler Taveira - “Monitorando o PostgreSQL”
18:30   David Fetter - “Trees in PostgreSQL”

27/09 - Sábado
09:00   Tutorial: Leandro Dutra - “O elefante aparelhado: ferramental e processo
de administração de dados em PostgresSQL”
11:00   Intervalo
11:20   Palestra de patrocinador OURO (OpenGEO)
12:00   Almoço
14:00   Lightning Talks (paineis de 5 minutos cada)
15:00   Eduardo Leal - “Utilizando o PostgreSQL em bancos de dados biológicos”
15:50   Fábio Telles - “PostgreSQL, o Elefante Encouraçado”
16:40   Intervalo
17:00   Dickson dos Santos Guedes - Replicação Síncrona - “Não existe
almoço de graça!”
17:50   Fernando Ike - “skytools, pgbouncer, plproxy”
18:40   Diogo Biazus - PostgreSQL Br - “Passado, Presente e Futuro”

Como vocês podem ver, temos ainda 2 vagas que estão sendo definidas pela comissão. Uma das vagas deverá ser de Geoprocessamento. Recebemos muitas propostas nesta área (5 ao todo) e estamos com dificuldades para escolher uma. Então, se a sua palestra não foi escolhida, aguarde mais um pouco. Você pode ser escolhido em breve.

Este ano ainda contaremos com duas novidades na programação:

• Os Lightning Talks são uma novidade importada do PGCon internacional, por sugestão do Josh Berkus quando veio ao Brasil durante o IX FISL. A idéia é que as pessoas podem dar um “recado” no estilo painel contendo até alguns slides (acho que uns 2 ou 3, por exemplo). Assim, serão até 12 apresentações relâmpago. A idéia é fazer algo mais descontraído e dar a oportunidade para os 5 minutos de fama para os participantes do evento. Segundo o Fernando Ike, os Lightning Talks no PGCon em Otawa foram uma parte muito interessante do evento, acho que as pessoas vão gostar. A chamada de trabalhos para os Lightning Talks devem abrir às vésperas do evento e terminar no primeiro dia do evento. O Sr. Dickson Guedes será o organizador desta parte do evento e prometeu até levar um sino (sugestão do Josh) para tocar no final dos 5 minutos de cada um.
• Haverá uma pequena sala (com com capacidade aproximada de 25 pessoas) onde se pretende dar algumas palestras destinadas a incentivar novos desenvolvedores do PostgreSQL. Serão poucas vagas e os tópicos abordados serão bem avançados. Então se você está com a intenção de se tornar um desenvolvedor do PostgreSQL, está na hora de desenferrujar o seu C e ficar de olho no que estamos por enquanto chamando de “hard talks”.

Bom, por enquanto é isso pessoal. Em breve estaremos atualizando o site do PGCon Brasil com a primeira versão oficial da grade. Lembre-se que o que apresentei aqui é apenas um rascunho da grade, sujeito a alterações sem aviso prévio.

• A aplicação está acessível para toda internet que possui milhares de usuários dispostos a quebrar seu sistema;
• O uso de linguagens de script fracamente tipadas em conjunto com com tipos de dados fracamente tipados ajuda a abrir algumas brexas de segurança.
• O protocolo HTTP tem peculiaridades que quando mal utilizadas podem tornar uma aplicação web mais vulnerável como o uso de parâmetros GET.

O exemplo clássico é o login de um usuário da aplicação. Você pede o nome e senha do usuário numa tela e depois envia um SQL com esta característica:

SELECT TRUE WHERE nome = 'telles' AND senha = 'abizi'

Na tela de login o usuário pode digitar no lugar da senha algo mais ou menos assim:

USUÁRIO: admin
SENHA: ‘ OR 1=1 –

Ao substituir as variáveis o seu SQL ficaria assim:

SELECT TRUE WHERE nome = 'admin' AND senha = '' OR 1=1 --'

Segurança contra o SQL Injection

Regra no mínimo privilégio

Veja que há uma série de problemas a serem analisados aqui. A primeira questão que qualquer sistema deve se preocupar em analisar é saber qual o potencial de destruição que o usuário vai ter se ele conseguir um ataque bem sucedido. Se o usuário que se conecta na aplicação é dono de objetos no banco de dados, como muitas aplicações gostam de fazer por uma questão de comodidade, você verá que o seu usuário terá permissões plenas sobre os seus objetos. Utilizando SQL Injection, ele poderá realizar operações como DROP, TRUNCATE, ALTER além do DELETE, INSERT, UPDATE e SELECT.

Então a primeira regra que deve SEMPRE ser seguida a risca é que:

“O USUÁRIO QUE A APLICAÇÃO UTILIZA PARA SE CONECTAR NO BANCO DE DADOS JAMAIS DEVE SER O DONO DOS OBJETOS CRIADOS NO BANCO DE DADOS”

Alguns artigos que tratam sobre SQL Injection ignoram solenemente esta recomendação. Alguns ficam desempregados inesperadamente. Então, precauções especiais devem ser tomadas em aplicações onde cada usuário da aplicação não tem seu próprio usuário criado no banco de dados - o que é comum em aplicações web com milhares de usuários que surgem sem controle do DBA. Você deve ter pelo menos 4 usuários para cada aplicação com este perfil:

1. Um usuário que é dono dos objetos criados no banco de dados. Este usuário deve estar sob controle somente e tão somente do DBA, tanto no ambiente de testes como em produção. Lembre-se que este usuário tem poderes plenos sobre estes objetos do banco de dados.
2. Um usuário ou grupo de usuários destinado aos desenvolvedores com poderes específicos para as suas tarefas. Pode-se determinar que no ambiente de produção ele tenha permissão de SELECT em todas tabelas e sequências e no ambiente de produção tenha poderes de SELECT, INSERT, UPDATE e DELETE.
3. Um usuário ou grupo de usuários destinado aos administradores da aplicação, que terão poderes específicos na aplicação como deletar registros ou atualizar valores em tabelas. Este usuário deve se conectar a partir de outro executável que não o utilizado pelos usuários normais. A aplicação utilizada para fins administrativos deve ter acesso restrito ao acesso local por exemplo. Este usuário terá permissões de DELETE, UPDATE e INSERT em tabelas que um usuário normal não terá permissão. Portanto, este usuário jamais deve ser utilizado em operações de rotina.
4. Um usuário para os usuários normais da aplicação. Este usuário deve seguir a risca a regra no menor privilégio. Ele deve apenas as permissões para acessar os objetos estritamente necessários. Privilégios de UPDATE e DELETE devem ser concedidos com muita cautela. Operações deste tipo quando executadas sem uma clausula WHERE adequada podem ser desatrosas. É este usuário que será alvo de ataques de SQL Injection. Se você for rigoroso com as permissões para este usuário, limitará muito a dimensão dos estragos que podem acontecer no caso de um ataque bem sucedido.

Use criptografia, visões e funções

Feito isso, você já terá um ambiente muito mais seguro, com certeza. A próxima parte do nosso trabalho será realizar um tratamento dedicado às informações mais sensíveis do seu sistema. Identifique estes objetos com cuidado. Existem dados sigilosos que podem ser alvo de criptografia. Senhas jamais devem ser armazenados sem criptografia. Use uma função como MD5 para isso. Lembre-se que você não poderá saber qual é a senha armazenada no campo, apenas poderá verificar se uma senha é igual a que está armazenada. No entanto, se apenas um grupo específico precisa ter acesso a estas informações você deve restringir o acesso a elas. Quando você quer restringir o acesso a apenas uma coluna ou grupo de columas de uma tabela a melhor alternativa é criar uma visão com apenas as colunas que o usuário vai precisar. De permissão ao usuário acessar esta visão não permita que ele leia a tabela diretamente.

Há casos em que a pessoa precisa alterar ou ler registros, mas você não quer que limitar a possibilidade de que o usuário altere todos os registros da tabela. Para isso, você pode criar funções que encapsulem toda a operação. Você passa para a função os parâmetros a serem alterados, a função checa a validade destes dados, faz todas as alterações em todas tabelas necessárias e retorna se realizou a operação com sucesso ou não, ou ainda retorna um valor desejado como se fosse um SELECT. O resultado disso é que você só precisa dar permissão ao usuário para executar a função e não precisa dar nenhum acesso a qualquer um dos objetos envolvidos na transação. Isto significa que o usuário só poderá realizar aquela transação especificada pela função, que se for bem codificada, evitará definitivamente qualquer chance de acesso indevido.

Procedimentos preparados

A terceira etapa é utilizar os procedimentos preparados ou “prepared statements’. Este procedimentos fazem com que você passe como parâmetros os valores a serem substituídos num comando SQL qualquer. As pessoas evitam utilizar este procedimento pois ele requer que você o execute em duas etapas: preparar o procedimento e executar o procedimento. Quando executado com freqüência, os procedimentos preparados não só são mais seguros, como também apresentam um ganho de performance.

Dollar Quoting

A quarta etapa que você pode utilizar é peculiar ao PostgreSQL, e chama-se “dollar quoting“. Ao invés colocar strings de caractere entre aspas simples em expressões SQL, você pode usar o $$ como em:

SELECT TRUE FROM users WHERE name = $$$$ AND senha = $$abizi$$;

Você ainda pode fazer coisas como:

SELECT TRUE FROM users WHERE name = $name$telles$name$ AND senha = $senha$abizi$senha$;

Note que você pode colocar suas strings entre $$, $nome$, $senha$ ou qualquer outra coisa, tendo somente que começar e terminar com a mesma marca. Usar este tipo de notação no código SQL pode parecer um tanto grotesco inicialmente, mas quando você for escrever funções, ela pode tornar a sua vida muito mais simples, pois você não terá situações bizarras como um grupo de várias aspas simples ou contra barras. Com o dollar quoting, você não precisa se preocupar com as aspas simples.

Checar o tipo de dados

A próxima barreira de defesa na luta contra a injeção de SQL é checar o tipo de dados utilizado. Um tipo comum de ataque é por exemplo ingetar código em parâmetros GET do protocolo http. Se você espera um número, tenha certeza de que ele é um número antes de substituir a sua variável no seu código SQL. Uma forma eficiente de fazer isso é utilizar a função ‘printf’. Quase toda linguagem de programação possui um comando semelhante ao printf da linguagem C. A nossa string SQL utilizando printf ficaria alguma coisa assim:

SQL = printf('SELECT TRUE FROM users WHERE nome = %s AND senha = %s', nome, senha)

A questão aqui é que a função printf vai forçar o uso do tipo de dados correto na função SQL. Não é uma solução perfeita, mas pode evitar alguns problemas além de evitar a conversão implícita de tipos de dados, fonte de muitas dores de cabeça no banco de dados.

Escapar as strings

A barreira mais conhecida na proteção contra a injeção de SQL é o uso de funções que escapem as strings. Hoje a maioria das linguagens de programação possuem funções para escapar caracteres como aspas simples em strings. Veja que uma aspa simples pode fazer parte de uma string como em “database’s security”. Para que uma string deste tipo seja aceita, é preciso escrevê-la desta forma numa expressão SQL:

INSERT INTO titulo VALUES ('database''s security');

Note que existem duas aspas simples e não uma aspas dupla. Esta é a única forma de se adicionar aspas simples numa string em banco de dados. Você deve esperar que o seu usuário por qualquer motivo digite uma aspa simples em qualquer string. A não ser que você remova explicitamente as aspas simples da sua string antes de construir o seu comando SQL, você deverá sempre escapa-las. Se a sua linguagem de programação possuir uma função de escape de strings específica para o seu banco de dados, utilize-a no lugar de uma função genérica.

Conclusão

Os problemas de segurança em geral são criados por profissionais mal informados ou por desenvolvedores que acreditam que segurança é um fator supérfluo e que implementar todas as barreiras necessárias é muito trabalhoso. O descuido com a segurança chega num ponto onde muitos servidores web exibem suas mensagens de erro diretamente na tela do usuário, no ambiente de produção. O uso de técnicas de SQL Injection em ambiente que não implantaram todas as barreiras citadas e ainda oferecem de bandeja os erros da aplicação na tela é absolutamente devastador. O usuário consegue descobrir o nome de todas as tabelas e colunas da sua aplicação, alterar qualquer registro ou mesmo apagar todas as informações de todas tabelas. Não é incomum encontrarmos aplicações de grande porte com furos homéricos de segurança. Não é incomum sites famosos e grandes corporações sofrerem com o vazamento de informações, fraudes e perda de dados. O prejuízo é sempre maior do que o custo de implementar a segurança de forma correta na aplicação.

Quando pensar novamente em segurança, lembre-se que a tarefa é de todos. Os ataques de SQL injections são muito simples de executar, a pondo de criarem a expressão “Script kiddie” para designar pessoas com pouco conhecimento técnico que utilizam receitas simples e eficientes para invadir sistemas. Não adiante a rede, o servidor e o banco de dados adotarem condutas rigorosas de segurança se você lança mão de aplicações (desenvolvidas por você ou por terceiros) que não tomam este tipo de precaução.

Está esperando o que??? Ah… você conhece uma pessoa que é fera em PostgreSQL? Convide-o a participar também! E não deixe de divulgar o evento!

Mas, voltando ao nosso colega, vejamos os resultados que ele obteve:

TPS: 19
TPS: 23
TPS: 18
TPS: 25
TPS: 23
TPS: 29
TPS: 35
TPS: 17

Veja que de 17 para 35, a direrença é de mais de 100%. Realmente, não dá para desprezar uma diferença tão grande. Eu diria que de qualquer forma, apredi no laboratório de física que você tem que realizar a mesma experiência pelo menos umas 5 vezes. Além disso, se você encontra um resultado que está destoando demais dos outros, é melhor repetir o teste mais umas 5 vezes com cuidado redobrado e se apenas um valor destoar, você deve descarta-lo. Assim o seu resultado é uma média entre os testes considerados válidos (sem o resultado descartado). No caso de um instrumento de medida direta (como uma régua ou termômetro) é fácil saber qual é a precisão da sua medida (metade da menor divisão, repetia o professor todas em as aulas no laboratório). No nosso caso, temos que ficar com o dado estatístico das medições considerando a variação dos resultados obtidos.

Veja, se você faz um ajuste na configuração do PostgreSQL e tem um aumento de desempenho de 2%, mas as suas amostras tem uma margem de erro (em relação a média) de 10%, você pode se questionar se realmente pode afirmar alguma coisa. Bom, mas se você tem 100% de variação… alguma coisa está realmente errada.

O primeiro detalhe sobre o nosso colega é que ele usa o PostgreSQL em Windows. Veja… usar o PostgreSQL em Windows funciona… mas fazer tuning em Windows não é tão eficiente. Não sou um profundo conhecedor do Windows, mas que eu saiba você tem muitas opções de ajustes de desempenho neste SO. O PostgreSQL, assim como outros grandes SGDBs, foram construídos para funcionar originalmente em sistemas operacionais Unix. Outro problema é que como o SO é uma caixa preta, você nunca sabe o que está rodando em paralelo exatamente e dificilmente tem controle sobre isso. Isto não quer dizer que não é possível ver o PostgreSQL rodando satisfatóriamente em Windows, significa que o Windows não é a opção número um de quem procura um SO robusto, confiável, seguro e rápido. Mas se você não está querendo levar o seu banco de dados ao limite, não há nada de errado em usar o Windows e ajustar o PostgreSQL para que ele tenha um desempenho melhor nele.

Vejamos alguns outros ítens que você deve se perguntar antes de avaliar os resultados:

1. Qual tipo de disco você usa? Os discos SATA são muito instáveis para testes, pois não conseguem manter um fluxo de dados em alta velocidade por muito tempo. Este não é um problema do disco físico em si e sim do protocolo do SATA. Usar discos SCSI ou SAS lhe trarão resultados mais confiáveis.
2. Você deixou os discos isolados para o banco? Deixou discos isolados para o Wall?? A questão aqui é saber se alguma outra aplicação pode estar competindo com o acesso aos discos.
3. Você tem certeza absoluta que não tem nenhuma outra aplicação rodando em segundo plano. O ideal é deixar uma instalação do SO o mais crua possível. O principio básico da experimentação científica é ter um ambiente controlado para que qualquer pessoa possa reproduzir exatamente os mesmos testes. Isto significa que você tem de documentar exatamente como o SO foi instalado, incluindo parâmetros de configuração.
4. Você tem que realizar testes mais longos para que ocorram checkpoints no meio. Se você parar para estudar o mecanismo de funcionamento interno do PostgreSQL, descobrirá que o momento em que o checkpoint ocorre há uma degradação de performance significativa. Realize testes que garantam a ocorrencia de pelo menos uns 10 checkpoints. Imagine testes que durem no mínimo uma hora cada.
5. Você precisa decidir como vai configurar o vacuum. Se usar o autovacuum, tem que utilizar testes longos para que a ocorrencia do autovacuum nas tabelas seja computado e ocorram um número de vacuuns semelhantes em cada testes.
6. O cache de memória é um ponto crítico. Cada vez que você roda um teste, uma parte dos dados fica em memória, seja o IPC, cache em userspace, kernespace, o cache da controladora de discos ou o cache dos discos em si. Resultado: para ter certeza que a memória está num estado idêntico entre os testes… reinicie o servidor entre cada testes. Após reiniciar o servidor, tenha o cuidado de realizar exatamente as mesmas operações na mesma órdem para minimizar as diferenças de quais dados entram no cache. Podem haver outras formas de controlar o cache do disco, mas eu só conheço esta.
7. Use uma quantidade gererosa de dados, usar menos de 1GB de dados dificilmente reproduz cenários realistas. A não ser que o seu alvo sejam bases realmente pequenas, é melhor fazer testes com diferentes tamanhos de bases. 1GB, 10GB e 100GB são um bom começo.
8. Se você pretende realizar os testes simulando uma grande quantidade de conexões, faça-o a partir de 1 ou mais clientes remotos e não a partir do servidor. Testes com 100, 200, 500, 1000 conexões simultâneas podem exigir uma estrutura considerável para os clientes. Você vai querer medir o impácto da rede no desempenho e ao mesmo tempo não vai querer que os clientes sejam um peso no desempenho do servidor, a não ser que a sua aplicação e o seu banco de dados fiquem no mesmo servidor. Se for esse o seu caso, prepare-se para um ajuste de desempenho bem mais complexo.

Antes de você achar que o PostgreSQL é um banco “instável”, “lento” ou pouco confiável, Recomendo enfáticamente que você estude mais sobre o funcionamento do PostgreSQL, realize testes em um SO Unixlike como Linux, Solaris e FreeBSD, e use outras ferramentas de testes como o DBT-2 e os testes do TPC como o TPC-C, TPC-E e TPC-H.

Em tempo, escrevi um pequeno texto para quem está começando: “12 dicas para aprender a ajustar a performance em bancos de dados“.

Alguns detalhes interessantes:

• A chamada de trabalhos internacional. Espera-se a vinda de 2 desenvolvedores internacionais, além dos desenvolvedores nacionais.
• O número de desenvolvedores nacionais parece que está aumentando neste ano e o número de colaboradores na organização do evento também.
• O plano de captação do evento já está no ar também, se você conhece alguém que poderia patrocinar o evento, não deixe nos avisar.
• Se você quer ajudar a divulgar o evento, já temos banners para você colocar no seu blog, site, etc.
• As inscrições para o evento ainda não começaram, mas quem quiser ir fazendo reservas num hotel, você já pode fazer sua reserva. Conseguimos proços especiais para os participantes do evento.
• Para se ter uma idéia, para fazer o site do evento, foram dezenas de e-mails trocados na lista pgbr-dev o que tornou a lista mais movimentada que a lista pgbr-geral. Um recorde. Gostaria de agradecer a contribuição do Dickson S. Guedes, Euler Taveira, Leandro Dutra, Leonardo César, Rodrigo Gomes Santana, Rodrigo Marins, Sebastian SWC, Thiago Risso e outros que não lembro agora por terem contribuído para o site sair.

Em breve, estaremos melhorando o site do evento, colocando mais informações, abrindo a chamada de trabalhos nacional e abrindo as incrições também. Por enquanto é só pessoal.

Caramba… mas segurança é um tema tão complexo assim? Bom, depende de como você define o que é segurança em SGDB para você. Vamos começar pensando em duas ou três formas de se enarar o problema:

• Segurança em SGDB não se refere apenas ao seu banco de dados, diz respeito a toda a cadeia tecnologia associada a sua aplicação, uma vez que um único elo fraco da sua solução de TI põe em risco o conjunto como um todo. Então não basta pensar no SGDB isoladamente. Temos que pensar no equipamento onde o SGDB se encontra, no SO, na instalação do SGDB, nos dados contidos no banco de dados, na aplicação acessando o banco de dados e finalmente no usuário que precisa destas informações;
• Todos estão carecas de saber, mas não custa repetir: os bancos de dados guardam um patrimônio valioso: informação. Quando você tem um problema de segurança num SGDB, são os seus dados que estão ameaçados. A pergunta que sempre se faz é “quanto vale a informação guardada nos bancos de dados”. Melhor pergunta seria: “quanto custa a perda destes dados?”.
• Segurança tem haver com coisas com o potencial de tirar o sono/emprego de toda uma equipe de TI. O desempenho é importante. Algumas vezes é muito importante. Mas em geral, a segurança vem em primeiro lugar. Esta importancia hoje tem nome, endereço, telefone, e-mail e tudo o mais. Depois da onda gerada pelo SOx nos Estados Unidos, a segurança passou a ser mais importante ainda. O COBIT e o ITIL e suas normas e regulamentações associadas são representam mais uma pressão na busca por mais segurança em torno das informações.

Muito bonito tudo isso… mas enfim, quando falamos em segurança qual é a pauta em questão? Ah sim… muitas coisas, vejamos algumas:

• Integridade: tem muito haver com ACID. Seus dados não podem se corromper, independente do que venha a acontecer. Mesmo que seus dados se tornem indisponíveis durante um certo período (devido a uma queda de energia, falha na rede ou num disco por exemplo) você tem que garantir que uma vez que o problema de indisponibilidade esteja resolvido, todos os dados tem que reaparecer intactos. Integridade também tem muito haver com o uso de restrições de integridade, para que um erro do usuário ou da aplicação não permita que os dados sejam corrompidos. O uso das restrições de integridade devem proteger seus dados contra alterações que não estão de acordo com as suas regras de negócio;
• Perda de dados: a preocupação número 1 de todo administrador de banco de dados é evitar ao máximo a perda de dados. Aí entra em cena a mais tediosa das tarefas: o backup. Ocorre que em bancos de dados, não existe uma única forma de se fazer um backup, existem várias estratégias. De toda forma, é preciso definir antes de mais nada: qual é o volume máximo de dados que admissível perder? Os dados relativos a última semana de operação? Talvez o último dia? A última hora? Nem um segundo sequer? Bom, é claro que ninguém quer perder nada, mas você sabe realmente qual é a o grau de proteção que a sua atual política de backup lhe oferece?
• Disponibilidade: capacidade de manter o acesso às informações de forma contínua. Falhas humanas, falhas de software e falhas de hardware podem gerar indisponibilidade a qualquer momento. A sua tolerância a indisponibilidade vai variar conforme a importância e rítimo de operação das suas aplicações. Algumas não podem parar nunca e trabalham em regime 24/7. Outras só precisam estar ativas em horário comercial, mas não admitem um minuto sequer de indisponibilidade neste período. Seja como for, é importantíssimo definir qual é o SLA agregado aos serviços prestados pelo banco de dados para que se possa traçar uma estratégia adequada para se atingir estes objetivos. Sua estratégia deve garantir que mesmo ocorrendo uma falhas, mesmo graves, os dados devem estar disponíveis no prazo determinado pelo seu contrato de SLA.
• Controle de Acesso: capacidade de que as informações disponíveis no banco de dados estejam disponíveis para as pessoas corretas, que terão permisão de acesso apenas as operações permitidas para o seu perfil. Geralmente o controle de acesso se dá a partir de objetos do banco de dados, mas pode se re referir ao acesso de apenas um parte dos dados de um objeto, como apenas algumas linhas de uma tabela. O controle de acesso pode limitar a quantidade de recursos que você pode utilizar no banco de dados. Os recursos podem ser o número de conexões ativas, memória, processador, volume de dados acessados em disco, etc.
• Auditoria: registro de operações realizadas no banco de dados. O registro pode conter informações sobre quem, realizou que tipo de operação, sobre qual objeto e em qual momento. O registro também pode conter quais foram as alterações realizadas, permitindo reconstruir os dados num estado anterior se necessário. A auditoria também pode significar monitorar outras condições do banco de dados, como picos de utilização, espaço em disco e outros detalhes que se deseje registrar.

Como se pode ver, ao falar em segurança, temos inúmeros desafios pela frente. Temas consagrados como “Alta Disponibilidade”, “Backup”, “Política de Mínimo Privilégio”, “Trilhas de auditoria” entre outros, fazem parte do dia-a-dia (ou seria noite-a-noite?) dos que se preocupam com segurança. Em grandes equipes de TI, há pessoas especializadas em segurança. Muitas vezes, encontramos Administradores de Bancos de Dados especializados em um ou dois aspectos da segurança, como o controle de acesso e auditoria. Administradores de Dados são especialistas em avaliar problemas de restrição de integridade enquanto os Administradores de Sistemas costumam se preocupar com backup e alta disponibilidade.

Com isso, em mente, vejamos alguns capítulos de deveremos abordar em seguida:

• Trabalhando de forma segura:
  • Escrevendo código robusto e flexível;
  • Usando o psql;
  • Documentando o trabalho realizado;
• Ambientes de Trabalho
  • Isolar para proteger
  • Ambiente de Produção
  • Ambiente de Homologação
  • Ambiente de Testes
  • Ambiente de Laboratório
• Integridade
  • Modelagem de Dados;
    • Domínios;
    • Sequências;
    • Chaves Primárias;
      • Chaves Primárias artificiais X naturais;
      • Quando é permitido criar uma tabela sem PK?
    • Chaves Estrangeiras;
    • Restrição UNIQUE;
    • Restrição NOT NULL;
    • Restrição CHECK;
    • Gatilhos;
    • Visões Materializadas;
  • ACID
    • Transações
    • MVCC
    • LOCKs
    • Write Ahead Log
      • Espelhamento dos logs;
      • Arquivamento e Stand By;
      • Recuperação de instância;

• Perda de Dados e Disponibilidade;
  • Backup
    • Backup lógico;
    • Backup físico off-line;
    • Backup físico on-line;
      • Dificuldades com grandes bases;
    • Backup via Snapshot;
  • Técnicas de fail over
    • Hardware Redundante;
      • RAID
    • LVM e RAID por software;
    • Stand By;
    • Heart beat;
    • Replicação X Clusterização;
  • Replicação
    • Replicação Síncrona X Assíncrona;
    • Replicação Multi Master X Master/Slave
    • Replicação via log de transação;
    • Replicação via commit em duas fases;
    • Replicação via gatilhos;
    • Replicação via Midleware;
    • Implementações para PostgreSQL;
  • Cluster
    • Shared Nothing
    • Shared All
    • Implementações para PostgreSQL;
• Controle de Acesso
  • Política do Privilégio Mínimo;
  • SQL Injection;
  • Segurança na autenticação
    • Visões;
    • Funções;
    • Serviços de Diretório;
  • Ferramentas de controle no PostgreSQL;
    • GRANT / REVOKE
    • Roles
    • Limite de acesso aos recursos do servidor;
    • pg_hba.conf
    • SELinux
  • Estratégias de Autenticação da Aplicação;
    • Autenticação Interna;
      • Uso de grupos de usuários;
      • Impedindo os usuários de obterem acesso por fora da aplicação;
      • Lidando com senhas;
    • Autenticação Externa;
    • Autenticação via Aplicação;
      • Pool de Conexões;
• Auditoria
  • Auditoria dos dados:
    • Utilizando campos adicionais em tabelas já existentes;
    • Utilizando tabelas de autitorias alimentadas por RULEs e TRIGGERs;
    • Utilizando o log do PostgreSQL;
    • O problema da identificação do usuário em aplicações com Autenticação via Aplicação;
      • Criando uma variável de sessão;
    • Protetendo as informações de auditoria;
  • Monitorando o seu servidor:
    • Monitorando a disponibilidade;Monitorando a performance;
    • Monitorando o espaço em disco;
      • Dividir para melhor enchergar;
    • Disparando alertas;

Como se pode ver, temos muito assunto pela frente. Não tenho nenhum ímpeto de escrever seguindo uma órdem específica, provavelmente eu deverei escrever numa ordem caótica e tentar juntar as peças aos poucos.

O evento estava realmente lotado. Segundo a organização, cerca de 7500 pessoas estavam lá, fora os alunos da PUCRS que passeavam livremente por lá, trazendo uma contribuição significativa para o “astral” do evento. Os corredores estavam lotados. As salas estavam lotadas e tinha palestra com gente sentada no chão e amontoado na porta. A pesar das boas palestras, o melhor foi reencontrar os amigos por lá. Gente que eu não via faz tempo. Foi muito bom.

O Stand do PostgreSQL estava bem organizado, mas logo se mostrou apertado para a multidão que aparecia por lá no intervalo das palestras. Tive a oportunidade de conversar com muita gente interessante por lá. Muita gente querendo saber mais sobre PostgreSQL, tirar dúvidas, fazer entrevistas, comprar camisetas ou mesmo bater papo e tomar um café! Não tenho a menor idéia de quantas pessoas passaram por lá, mas foi muita gente.

As maioria das palestras de PostgreSQL se concentraram no primeiro dia. Casa cheia em todas as palestras, inclusive na minha que ocorreu no último horário, ás 20h. Muita gente ficou depois do término da palestra para tirar dúvidas. Fomos convidados a nos retirar da sala pela organização que precisava liberar o local. Para todos aqueles que me pediram cópias dos meus slides, eles estão disponíveis para download aqui. Para quem não sabe, a palestra foi parecida com a do PGCon Brasil 2007, com o título “Fazendo um Elefante Passar Debaixo da Porta”, sobre melhores práticas para DBAs e desenvolvedores. Melhorei algumas coisas e possivelmente piorei outras. Acredito que em breve teremos todas as palestras do PostgreSQL no site da comunidade.

Infelizmente não pude ficar até o final do evento, fui embora na 6ª feira a noite, mas deu para curtir um bocado do evento e tomar algumas Polares com os amigos e renovar meu estoque de camisetas . Hoje devo estar indo ainda em outro evento com a presença dos nossos palestrantes internacionais do FISL. Eles estarão na UNICAMP para o Dia PostgreSQL promovido pela Dextra.. Na verdade eu devo aproveitar o momento para acertar alguns detalhes do PGCon Brasil 2008, que vai ocorrer na UNICAMP nos dias 27 e 28 de setembro. Muito em breve teremos notícias.

Bom, vou ficando por aqui… hoje vou poupa-los de um post enorme para descrever em detalhes o FISL. Fico apenas com a descrição do David Fetter no PostgreSQL Weekly News: “FISL had almost 7500 participants this year, making it the world’s largest FLOSS conference.”

Uma outra diferença fundamental é que a documentação do PostgreSQL mostra detalhadamente “o que” mas mostra pouco “como”. Isto não significa que precisamos de um livro do tipo “Torne-se um DBA PostgreSQL em 7 dias”. Estes livros costumam ter o péssimo hábito de emburrecer as pessoas com receitas de bolo prontas e não convida o leitor a pensar ou tomar decisões. Quando li a documentação oficial do PostgreSQL pela primeira vez, me senti finalmente encorajado a começar a modelar meu primeiro sistema dedicado a ele. No entanto, uma infinidade de desafios e decisões apareceram no caminho, e a documentação oficial tinha pouco a me dizer naqueles momentos. Eu ainda tinha pouca experiência e isso me levou a tomar decisões baseadas muitas vezes no meu bom senso e outras em alguns poucos artigos que encontrei na Internet. Mas… já dizia o Sr. Hobbes, que o bom senso é o dom mais democrático e contraditório da humanidade: todos acham que os outros carecem e bom senso e se julgam igualmente possuidores de boas doses dele. Resultado, fracassei miseravelmente em diversos aspectos.

Com o tempo e envolvimento com a comunidade, fui descobrindo um erro aqui e outro acolá. Aprendendo sobre outros bancos de dados, principalmente olhando para as diferenças entre eles, percebi algumas coisas nas entrelinhas que nem sempre estão explícitas na documentação. Isto me levou a escrever alguns artigos neste blog, particularmente nos últimos tempos, quando comecei a me sentir mais corajoso no sentido de expor minhas idéias e me permitir errar, expondo idéias inacabadas. Isto culminou com uma palestra no PGCon Brasil 2007. A idéia da palestra “Como Fazer um Elefante Passar Debaixo da Porta” era a de ajudar as pessoas que estão começando a utilizar o PostgreSQL, mas não tem tanta experiência como DBA. Olhando para o público do evento, percebo que existe uma minoria de DBAs na platéia. A maioria eram desenvolvedores/analistas/programadores e haviam também administradores de sistemas/redes. A questão é a de que praticamente não existem cursos de graduação para formar Administradores de Bancos de Dados. A meu ver, a maioria dos DBAs foram administradores de sistemas ou desenvolvedores que por alguma razão misteriosa decidiram se especializar nesta área.

Se formos pensar bem, o DBA fica justamente numa posição entre o desenvolvedor e o administrador de sistemas. O novo DBA trás certamente as melhores práticas da sua área de origem. Os administradores de sistema trarão uma preocupação com o uso e monitoramento dos discos, métodos de autenticação autenticação, ajustes do SO e por aí vai. O desenvolvedor trás um padrão de codificação, esquemas de autenticação da aplicação, modelagem, distribuição de objetos, etc. Mas bancos de dados não são novos… já em priscas eras, os computadores utilizam bancos de dados. O modelo relacional, no qual todos os grandes SGDBs se baseam (e ao contrário do que o pessoal da programação orientada a objeto imagina, continuará assim por um bom tempo) foi criado há mais de 30 anos. O livro “Introdução a Banco de Dados” do C. J. Date também já é pode ser considerado um clássico e está em sua oitava edição.

Os bancos de dados relacionais atravessaram a era dos sistemas centralizados em mainframes (que continuam existindo), a era cliente-servidor e a era programação em 3 camadas. O PostgreSQL tem suporte para utilizar tudo isso, mas nem sempre os novos DBAs tem consciência desta história toda. Ao ler a documentação do PostgreSQL, hoje eu vejo décadas de história relacionadas com as suas funcionalidades. Então fica claro para mim, qual livro falta ser escrito para o PostgreSQL. Não é um livro que substiua a documentação oficial. Vale muito mais a pena complementar e traduzir a documentação oficial do que escrever pequenos livros que repetem boa parte do que já existe lá. Hoje eu descobri mais um pequeno livro sobre PostgreSQL. Nada contra o livro. Mas eu não preciso ler ele para saber como ele é. Este tem apenas 240 páginas. Para um livro genérico, isso mal dá para começar. Segundo a editora, a Érica que tem fama de fazer livros didáticos, que mais parecem apostilas. Terceiro, o autor, com quem eu já tive aula, tem dezenas de livros editados no mesmo estilo.

Minha idéia não seria esta, muito pelo contrário. Acredito que um bom livro de melhores práticas deveria estimular o leitor a ler a documentação com freqüência, citando-a em diversos pontos. Mesmo porquê, existe um trabalho intenso da comunidade em atualizar a documentação oficial a cada nova versão do PostgreSQL. Um livro de melhores práticas deveria se um pouco menos dependente de uma versão específica.

Um livro de melhores práticas deveria servir como subsídio didático para cursos de PostgreSQL, deveria conter inúmeros exemplos práticos e conduzir o leitor ao erro. Sim, ao erro. Somente a pessoa que erra tem condições de aprender de fato. Não são os acertos sucessivos que nos fazem acertar, e sim os erros e como corrigi-los. Assim, eu imagino uma aplicação sendo construída a partir do seu início, e as decisões sendo tomadas no meio do caminho. Imagino o livro conduzindo a decisões e discutindo as implicações destas decisões. Imagino muita polêmica onde não há um único caminho correto a seguir. Imagino a coleta de diferentes opiniões que convidem o leitor a pensar e escolher o seu próprio caminho. Imagino exemplos concretos de como seria a implementação em cada um destes caminhos. A questão ao fim é mostrar “como” e não “o que”.

O livro passaria certamente por tópicos que não são específicos do PostgreSQL. Uma coisa interessante seria mostrar as diferenças da implementação do PostgreSQL com as implementações de outros bancos de dados, quando isso for comparável. Imagino particularmente comparações entre implementações do Oracle, DB2, SQL Server e MySQL. Imagino também comparações com o padrão SQL e comparações com versões anteriores do próprio PostgreSQL. Seria muito interessante abrir o jogo aqui. O PostgreSQL não é perfeito e nunca será. Se ele fosse perfeito a humanidade teria esgotado a sua insatisfação e imperfeição eternas. Poderia-se mostrar onde outros bancos de dados oferecem vantagens e desvantagens em relação ao PostgreSQL. Pode-se dizer o mesmo em relação ao padrão SQL, que não é perfeito. No entanto, melhor do que criticar o padrão SQL - afinal, querendo ou não é o padrão que nós temos - devemos comparar os Bancos de Dados tendo o padrão SQL como referência.

Imagino algumas premissas para escrever o livro:

• Escrito a várias mãos. É preciso de alguém para organizar o livro, mas é preciso pegar o que há de melhor na especialidade de cada um. Uns conhecem melhor modelagem de dados, outros conhecem melhor que ninguém como ajustar a performance do seu servidor ou de uma consulta. Em momentos polêmicos, poderíamos citar mais de um autor e deixar o leitor tirar suas próprias conclusões.
• Licença livre. Seria imprecindível adotar uma licença que permita a cópia e modificação do livro. Gostaria no entanto de preservar a contribuição de cada pessoa no livro. Já vi trechos da documentação do PostgreSQL em diversas apostilas por aí. Sim, daquele curso que você está pensando também. Acho que manter os créditos é uma questão de respeito. Cada um pode alterar o livro para as suas necessidades e utilizar da forma que melhor entender, mas por favor, cite os autores que lhe ajudaram.
• Precisaria ser construído aos poucos. A idéia não seria juntar um monte de texto, revisar, publicar e abandonar. Muito pelo contrário, seria feito em capítulos, sendo que qualquer capítulo poderia sofrer acréscimos e correções a qualquer momento, eternamente.
• Precisaria ser construído via Internet. Não há como um projeto colaborativo prescindir do uso da internet. Não tenho certeza sobre a ferramenta correta a se adotar. Imagino que ao mesmo tempo deveria ser tão simples como usar uma ferramenta de escritório, fácil de se transformar em outros padrões como SGML (utilizado na documentação oficial), fácil de agregar novos colaboradores como uma ferramenta Wiki e tavez tão universal como o Google Docs.
• Precisa de um case real a ser desenvolvido. Para que os exemplos se tornem consistentes ao longo do livro, precisaríamos eleger um problema inicial a ser desenvolvido sob diferentes aspectos. Num determinado ponto do livro, chegaríamos a um pequeno grupo de tabelas e demais objetos que seriam explorados por todo o restante do livro. Só precisaríamos definir algumas regras de negócio bem básicas para que o exemplo se desenrole pelo restante do livro. Algumas licenças poéticas poderão ser admitidas, pois algumas técnicas só fazem sentido quando temos centenas de transações concorrentes ou tabelas com milhões de registros. A minha idéia inicial seria utilizar o pagila que já é mantido pela comunidade e vai sendo atualizado conforme novas versões do PostgreSQL vão surgindo. Ele pode ser tão simples e auto-explicável quanto se queira e também pode possuir graus de complexidade bem grandes para exemplificar algumas coisas;
• O público alvo seriam novos DBAs PostgreSQL, que podem ser estudantes, desenvolvedores, administradores de sistemas ou mesmo DBAs que estejam acostumados com outros bancos de dados.
• Deve ter profundidade na sua abordagem. Se sabemos que é possível fazer de algum jeito alguma tarefa, temos que mostrar como. Isto significa ter de desenvolver scripts e procedimentos em diversos pontos, bem como demonstrar a sua utilização com testes reais.
• Citar com cuidado e precisão. Realizar citações com links para a origem com a maior freqüência possível e apenas de fontes com boa credibilidade.

Possíveis tópicos a serem abordados:

• Implementando uma aplicação:
  • Ferramentas de trabalho: editores de texto em Windows e *nix, em modo gráfico e texto, formas de se trabalhar no dia-a-dia.
  • Modelagem básica: criação de tabelas, PK, FK;
  • Padrões de codificação: case sensitive, nomes para objetos, codificação explicita X implícita;
  • Domínios e tipos de dados;
  • Sequências e o uso de chaves artificiais e naturais;
  • ORDER BY, WHERE, GROUP BY, usos práticos;
  • Visões e visões atualizáveis (utilizando o RULEs);
  • Dados hierárquicos, abordagens possíveis;
  • Exportação de dados com dump, copy e PL;
  • Joins e subselects na clausula FROM, WHERE e SELECT;
  • Trabalhando com números: Localização, formatação;
  • Trabalhando com data e hora: Localização, internacionalização, conversão, formatação;
  • Trabalhando com texto: codificação de caracteres, internacionalização, conversão, formatação e manipulação;
  • Busca textual;
  • Desnormalização controlada: Gatilhos, funções e visões materializadas;
  • Uso de esquemas;
• Trabalhando com dados binários:
  • Tipos de uso por tamanho de arquivos, volume total, tipo de acesso e concorrência;
  • Uso do Bytea, OID e sistemas de arquivo;
  • Desempenho, flexibilidade e confiabilidade;
• Autitoria:
  • Campos de auditoria;
  • Tabelas de auditoria;
  • Logs de auditoria;
  • Ferramentas de auditoria;
• Segurança:
  • A rede, o SO, o PosgreSQL e a aplicação;
  • Ambiente de produção, homologação e testes;
  • Arquitetura da aplicação e estratégias de autenticação;
  • Encriptação de dados;
  • Obfuscando código;
  • Contornando falhas de segurança;
• Monitoramento de usuários:
  • Descobrindo o que os usuários estão fazendo no banco;
  • Locks de tabelas;
  • Uso de índices e estatísticas de uso;
  • Logs externos ao banco;
• Backup e Alta Disponibilidade;
  • Escolhendo a melhor estratégia;
  • Backup Lógico;
  • Transferindo dados entre bases;
  • Backup físico off-line;
  • Point-In-Time-Recovery;
  • Backup físico on-line;
  • Stand by;
  • Replicação assíncrona;
  • Replicação síncrona;
• Discos:
  • Planejando o volume de dados;
  • Particionamento do servidor;
  • Volumetria e monitoramento;
  • Distribuição de carga e uso de Tablespaces;
  • Sistemas de Arquivo;
  • LVM;
  • RAID por software e hardware;
• Instalação e Manutenção:
  • Compilação X Pacotes binários;
  • Testando e migrando de uma nova versão;
  • Flexibilidade para o ambiente de testes;
  • Segurança para o ambiente de produção;
  • Simetria entre ambientes;
  • Isolando ambientes no mesmo servidor;
  • Autovacuum manual, automático, full;
  • Reindex;
• Integrando aplicações:
  • DBLink;
  • DBILink;
  • Cargas de dados com dump, copy , via aplicações e outros métodos;
  • Validação, e auditoria na integração;
• Desempenho:
  • EXPLAIN e ANALYZE;
  • PREPARED STATEMENT;
  • Subconsultas;
  • Monitoramento avançado;

Ok, você não é fã de wiki? Então você pode montar um blog, todo seu. Existem inúmeras ferramentas que permitem como o blogger e o wordpress que permitem você criar um blog em minutos e sem gastar um tostão. E para provar que você terá público garantido, agora existe o Planeta PostgreSQL que reúne as publicações de vários blogs que tem por hábito publicar artigos sobre PostgreSQL em pt_BR. Para entrar no Planeta, basta seguir as instruções e todos os seus artigos relacionados com o PostgreSQL vão aparecer automaticamente por lá.

Há tempos, foi proposto reformular o site do PostgreSQL Brasil, e colocar o Drupal no lugar do MoinMoin. Na verdade o MoinMoin não seria desativado, mas passaria a ser utilizado para organização interna da comunidade. Por inúmeros fatores isto não aconteceu ainda. Eu reconheço que inclusive ajudei a atrapalhar um pouco a história. Mas o curioso é que na época em que isso foi proposto, um monte de gente se propôs a escrever e ajudar. Foi aí que surgiu a proposta do Planeta, que é algo mais simples de criar e manter. Bom, o Planeta está no ar… mas o curioso é que temos apenas 5 blogs nele até agora. É muito pouco na minha opinião… gostaria de ver mais gente escrevendo.

Ok, confesso que tenho escrito poucos artigos técnicos por aqui também… já até me puxaram a orelha… mas se você não sabe sobre o que escrever, então você pode tirar alguns posts que estão na minha fila de espera:

• Monitoramento vi psql e shell;
• Estratégias de autenticação de aplicações e segurança no PostgreSQL;
• Tipos de ferramentas de replicação e suas aplicações práticas;
• Estratégias de backup, recuperação de desastres e alta disponibilidade;
• Ambientes heterogêneos com DBI-Link;
• Usando e abusando das tabelas do pg_class e informatio_schema;
• Configurando logs para diversos propósitos;
• Como criar métricas de performance;
• Procurando gargalos de performance;
• Skytools;
• Ptop;

E por aí vai…

• Fernando Ike: HA em PostgreSQL: O Elefante disponível para além do infinito HA em PostgreSQL: O Elefante disponível para além do infinito
• Josh Berkus: Using SQL tools to secure your database application
• David Fetter: The Postgres Application Server
• Fábio Telles: Fazendo Um Elefante Passar Debaixo da Porta
• Diogo Biazus: Replicação Assíncrona Multi-Mestre com Bucardo

E se você acha pouco… então venha conhecer a Comunidade PostgreSQL, no Stand M3 que já está na planta baixa do evento bem em frente das salas “John Maddog Hall” e “Richard Stallman”. Vejo vocês por lá!

Entre lá e dê sua opinião, agora!

• O Linux historicamente escala melhor do que o FreeBSD;
• O PostgreSQL historicamente escala melhor que o MySQL;

Digam o que quiserem, todos os testes conduzidos por pessoas sérias parecem concordar com estas duas afirmações. Para quem não sabe, “escalar” significa aumentar de performance proporcionalmente ao número de CPUs existentes no equipamento.

Mas o tempo passa, e como prometido, a versão 7.0 do FreeBSD parece ter cumprido a promessa de melhorar o escalonador de processos. O resultado você observa aqui. Os testes podem não ser 100% fidedignos ao representar uma situação real com banco de dados, mas os números parecem ser bastante promissores.

Parabéns a equipe de desenvolvimento do FreeBSD… certamente vocês vão ganhar novos DBAs como usuários.

OBS: Os testes foram realizados com até 8 cores, não há informações para um número maior de processadores.

I am the very model of a database relational,
My updates are atomic and ACIDic and transactional,
My planner aims to optimise your queries scatological,
My indexes will cope with SQL that is pathological

My data types encompass from mundane to geographical,
My data safety record shows concern that’s quite fanatical,
My cost per TPC will beat both DB2 and Oracle,
And yet the plebs persist in writing apps for bloody MySQL!

• O Sr. Leonardo Cezar nos honrou finalmente com seu conhecimento sobre PostgreSQL em seu blog, o Postgreslogia’s weblo. Como era de se esperar, material de primeira qualidade… imperdível!
• Outro novo site é o PostgreSQL Docs, um wiki com diversas documentações em inglês. O site em 4 dias de existência tem crescido num rítimo bom com mais de 50 documentos, apontando para inúmeras outras documentações também. Não deixe de anotar esse.
• Acredite se quiser, mas dentro do site da IBM, encontra-se a notícia com o título: “2008 The Year For PostgreSQL“.
• O 9º FISL se aproxima, vai ocorrer nos dias 17, 18 e 19 de abril. Além de mim, várias pessoas do PostgreSQL nacional e internacional estarão por lá palestrando. O PostgreSQL promete fazer mais uma participação memorável. A novidade este ano fica por conta do Stand da comunidade que estará mais incrementado, graças a valorosa contribuição da Isis e demais voluntários. Se você vai para lá de avião, fica aqui a dica, a Varig está com bons preços.
• O PGCon 2008, o maior evento de PostgreSQL vai ocorrer em Otawa, Canadá no dias 20 a 23 de maio. O evento tem a maior concentração de desenvolvedores do PostgreSQL vindos dos 4 cantos do planeta, inclusive do Brasil.
• O número de eventos sobre PostgreSQL realmente explodiu em todo o planeta. Nós aqui no Brasil já iniciamos a organização do PGCon Brasil 2008. Muito breve já teremos data, local, chamada de trabalhos e outras novidades. Aguardem!

Bom, por enquanto é só pessoal.