Qual sistema de arquivos devo utilizar no meu banco de dados?

A pergunta clássica que todos sempre fazem em listas de discussão, fóruns e bate-papos no IRC é “Qual o melhor sistema de arquivos eu devo utilizar para o meu banco de dados”? Para variar, fizeram novamente esta pergunta na lista do PostgreSQL.org.br

E lá fui eu responder o que para muitos é óbvio, mas para muitos não. Em primeiro lugar, deixe-me dizer que estou falando, é  claro, de sistemas de arquivos em Linux. Para outros sistemas operacionais, a coisa funciona mais ou menos assim:

• Windows » NTFS
• Mac OS X » HFS+
• OS/2 » HPFS
• Solaris » ZFS
• AIX » JFS2
• FreeBSD » UFS2
• HP-UX » VxFS
• IRIX » XFS

É claro que boa parte dos sistemas operacionais acima também tem suporte para outros sistemas de arquivos. Mas o uso de outro sistema de arquivo é algo mais raro e atende a necessidades específicas. Também não estou falando aqui de sistemas de arquivos com propósitos especiais, otimizados para clusters, servidores de arquivos, discos SSD, etc. De fato existe uma grande variedade de  sistemas de arquivos por aí. Mas é no Linux em que encontramos uma quantidade grande de sistemas de arquivos maduros e que funcionam muito bem, com poucas ou nenhuma limitação. E é aí que a confusão está armada.

Entre os mais comuns estão o EXT2, EXT3, JFS, XFS e ReiserFS. Todos eles são bons sistemas de arquivos e levam alguma vantagem uns sobre os outros em alguma coisa. O ReiserFS é muito bom em lidar com uma grande quantidade de arquivos pequenos. O XFS é bom em lidar com arquivos grandes, e por aí vai. Existem milhares de testes e brigas intermináveis apontando qual deles é o melhor.

O Fato é que tirando a distribuição SUSE, o EXT3 é o sistema de arquivo padrão das grandes distribuições Linux. É também o único sistema de arquivos que a Oracle homologa para a instalação dos seus bancos de dados, tirando é claro o OCFS2, mas que é um sistema de arquivos para cluster, que é outra história.

Antes de mais nada, é preciso entender que em geral todos são bons e apresentam boa velocidade e segurança (ok, tirando o EXT2 neste ponto). O fato é que para cada tipo de aplicação, existe uma forma peculiar de usar os discos. E digo mais, bancos de dados de fornecedores diferentes usam o disco de forma diferente. Mais ainda, um banco de dados do mesmo fornecedor pode utilizar o disco de forma completamente diferente dependendo do tipo de aplicação que o utiliza.

Como eu já demonstrei bem antes por aqui, um banco de dados não deve em situação ideal contar apenas com uma única partição e um único disco. O SO deve ficar num lugar, os logs de transação em outro, os dados em outro lugar e por aí vai. Assim, cada um destes discos são utilizados de forma completamente diferente. Vejamos alguns pontos notáveis:

• O  Sistema Operacional tem um perfil de uso mais comum e não é crítico em termos de desempenho. Em termos de segurança, você irá ficar muito tempo indisponível se tiver que instalar tudo novamente, mas de fato não vai perder nenhuma informação crítica. É o caso de utilizar o sistema de arquivos padrão e não tentar nenhuma configuração especial;
• Os logs de transação possuem um perfil bem específico,  gravação sequencial em arquivos de tamanho bem definido. É claro que a gravação só vai ser sequencial mesmo se o disco físico (não o volume lógico) for utilizado apenas para isso e não tiver nenhuma outra operação paralela. Já comentei antes que os logs de transação são um ponto crítico no desempenho e na segurança de um banco de dados com grande volume de atualizações, ou OLTP. Você poderia escolher um sistema de arquivos com uma configuração bem específica só para os logs de transação;
• Uma partição contendo tablespaces com dados históricos sem atualizações, pode utilizar um sistema de arquivos com opções mais agressivas reforçando apenas a leitura e sem preocupações com segurança como a jornalização;
• Uma partição com índices que podem ser recriados sem prejuízo para os negócios (a recriação dos índices pode levar várias horas ou até dias) pode dispensar também preocupações com a segurança, mas não com desempenho em gravação;

Tirando estes pontos notáveis, existem algumas considerações de ordem genérica que podemos citar:

• Embora alguns digam que em bancos de dados você pode utilizar EXT2 ou outros sistema de arquivos sem jornalização, uma vez que você já tem a “jornalização” dos logs de transação do sistemas de arquivos, a afimação só é válida se:
  • Você realiza backup físico e não apenas lógico (dump) do banco de dados periodicamente;
  • Você realiza um backup dos logs de transação arquivados para outro disco e para outro servidor/fita, com período de retenção superior ao intervalo entre os backups físicos;
  • Você está disposto a perder os últimos dados contidos do log de transação ativo, que se for perdido não poderá ser recuperado, afinal não foi arquivado e você não tem cópia em outro disco dele;
  • Você não se importa de perder tempo recuperando backups, seu banco de dados tem suporte ao PITR e você sabe utiliza-lo bem.
• Todo sistema de arquivos destinado a guardar dados deverá lidar em geral com arquivos grandes, beirando sempre a casa do Gigabyte. Isto geralmente exclui o ReiserFS como sistema de arquivos predileto para bancos de dados. Isto não significa que ele não seja ótimo em outras situações;
• Se você estiver com um Data Mart ou um Data Warehouse onde o perfil de uso é de cargas em lotes agendadas e poucas consultas monstruosas, utilizar tamanhos de bloco maior do que o padrão pode ser vantajoso. Mas só é vantagem neste tipo de situação, fora destas condições o efeito é o inverso;
• Os ganhos de desempenho ao escolher o sistema de arquivos mais rápido com as configurações mais agressivas são da ordem de 5 a 20%;
• Os ganhos de desempenho no ajuste mais agressivo num sistema de arquivos onde ficam tablespaces de uso geral podem ser de cerca de 20% em determinadas operações, mas a perda em outras operações pode ser de mais de 60%;

Se preocupe com segurança de verdade

Todo DBA que já foi acordado de madrugada para ir recuperar um banco de dados corrompido já ouviu a mesma frase “mas em X anos que eu estou aqui na mesma empresa isso nunca aconteceu”. E não raro X chega a ser maior que 5 ou até 10 anos. A verdade é que o fato de você utilizar um bom hardware, um sistema operacional estável e um bom banco de dados não significa que não vai acontecer. E só quem é chamado para consertar os desastres que ocorrem por aí pode ter uma noção de que tipo de sistemas de arquivos é mais ou menos perigoso. Você não acha que porque está X anos numa mesma empresa usando o sistema de arquivos XPTO isto significa que ele é seguro, acha?

Tudo isso para dizer claramente e em bom tom:

NÃO TROQUE SEGURANÇA POR DESEMPENHO

Pode surgir o momento em que você terá de fazer alguns ajustes de desempenho. Eles existem sim. Mas não é qualquer um sabe utilizar isso de forma segura. De fato, conheço poucas pessoas com bom conhecimento técnico que se arriscam a utilizar este tipo de coisa em ambientes realmente críticos. Então, antes de partir para o tuning do seu sistema de arquivos, tenha em mente que você tem coisas muito mais importantes que podem melhorar o desempenho do seu banco de dados:

1. Normalização e refatoração das tabelas (ganhos de 100% a 10.000%)
2. Reescrever consultas mal escritas (ganhos de 10% a 10.000% na consulta alterada);
3. Configurar adequadamente o sistema operacional e o banco de dados adequadamente (ganhos de 10% a 400%);
4. Separar o log de transação em discos a parte (ganhos de 20% a 40%);
5. Usar RAID 0+1 ao invés de RAID 5 (ganhos de 30% a 60%);
6. Dobrar o número de discos do seu RAID (ganho de 60% a 80%)

Ok, não leve muuuito a sério as porcentagens utilizadas aqui. Não tenho nenhuma pesquisa científica para comprovar estes dados. Um DBA mais experiente poderia discordar um pouco dos números apresentados, mas a proporção entre os itens não iria mudar muito. E de qualquer forma ele iria provavelmente concordar com a ordem de importância apresentada aqui.

Se você procura uma forma de ganhar desempenho sem ter que mexer na aplicação, os parâmetros de configuração do seu sistema operacional (particularmente limites de memória e semáforos), e do seu banco de dados (memória, checkpoints e outros) podem ter um impácto enorme. Mas o problema é que são muitos parâmetros, particularmente no banco de dados e os testes não são tão simples. O ajuste ideal pode levar meses no ambiente de produção.

De qualquer forma, sempre haverá o momento em que para aumentar o desempenho você terá que abrir mão da segurança ou colocar a mão no bolso. Muitos parâmetros e configurações que aumentam o desempenho tem impacto muito negativo na segurança . Se você não está disposto a correr riscos então saiba que o preço dos discos não é mais tão assustador quanto antigamente. Mas se você está numa daquelas empresas que não investe nem em espaço extra para guardar os dados, esta não será uma opção viável. De qualquer forma, aumentar o desempenho do hardware, costuma mascarar os problemas na aplicação. Mas é claro, que apesar da aplicação ser o primeiro alvo de otimização, em geral ele é o último a ser atacado. Seja porquê a aplicação é um pacote escrito por terceiros, ou porquê os seus desenvolvedores estão ocupados com uma nova aplicação, o fato é que falar de remodelagem e normalização de uma aplicação em produção para um desenvolvedor é pior do que ofender a mãe. Bom… na verdade dá trabalho para todo mundo, e muitas vezes até o DBA acaba fazendo vista grossa.

O mito dos discos que não falham e da luz que não acaba

É fato que os discos de hoje em dia são muto bons. Muito longe dos discos que vinham com um software para fazer formatação física pois a mídia ia se deteriorando progressivamente. Mas um dia eles podem falhar, particularmente se já estiverem em uso 24/7 há mais de 3 ou 4 anos. Mesmos os melhores discos falham e tem mais, os discos com número de série iguais tem o hábito de falhar na mesma época… como lâmpadas num grande galpão que vão queimando todas juntas. Contra a queima do disco, o seu sistema de arquivo não tem muito o que fazer, a não ser que ele tenha embutido um mecanismo de espelhamento como o ZFS tem. Usando LVM, você também consegue este tipo de funcionalidade, que pode ser uma alternativa para aqueles que não dispõem de uma boa controladora que faça espelhamento por Hardware. Há quem até prefira o RAID por software embora isso esteja longe de ser um consenso. Em todo caso, um bom storage costuma ser a resposta ideal, com monitoramento remoto e tudo o mais.

Mas há algo em que a maioria dos sistemas de arquivos são vulneráveis, a perda de energia. A jornalização foi criada exatamente para você que já viu uma falha de energia corromper todo o seu sistema de arquivos com o seu banco de dados junto.  A jonalização não é perfeita, mas melhora muito o nível de segurança. Vale citar que cada sistema de arquivos implementa a jornalização de uma forma diferente, e que o EXT2 simplesmente não o faz. Mais que isso, algumas opções de montagem dos sistemas de arquivos como o ‘writeback’ tem impacto positivo na performance, mas negativo na segurança da jornalização.  Outros parâmetros como o ‘noatime’ costumam ser mais seguros de se utilizar, e trazem algum ganho de desempenho.

Então chega uma das perguntas que produzem lembranças divertidas em muitos, mas que não foram tão divertidas na época em que ocorreram: “Se eu tenho nobreak, por que eu tenho que me preocupar com jornalização?”. Vejamos alguns bons motivos:

• Nobreaks quebram;
• Nobreaks que estão fora da garantia e não tem contrato de manutenção podem já estarem quebrados e você nem desconfia;
• Nem todos testam os seus nobreaks da foram correta;
• Nem todos habilitam o agente do nobreak para desligar gentilmente o servidor quando a bateria está no fim;
• Um banco de dados pode demorar horas para ser desligado gentilmente quando tem muitos usuários conectados simultaneamente ou rodam longas transações;
• As baterias do nobreak tem vida útil curta, em 2 ou 3 anos você tem
  que trocar. Tem gente que “esquece de trocar”;
• Um nobreak com isolação total (onde a alimentação ocorre sempre
  diretamente das baterias) tem baterias com uma vida útil de pouco mais
  de 1 ano;
• Em muitos lugares é comum haver falta de energia por mais de 3
  horas. Não tem nobreak que aguente isso. Nos final de semana a
  concessionária de energia adora fazer manutenção sem aviso prévio;
• Você pode ter uma manutenção na rede elétrica interna do prédio e
  ficar sem energia. O pessoal da manutenção pode ter esquecido de lhe
  avisar;
• Mesmo que você tenha um gerador, pode ocorrer de você não estar com a manutenção do gerador em dia, ou ele simplesmente estar sem
  combustível;
• O número de equipamentos ligados ao nobreak e gerador pode ter aumentado nos últimos meses e o nobreak e/ou gerador podem não suportar a carga adicional;
• Os servidores ou o sistema operacional  podem travar de repente. Se o servidor for um  Windows ele pode (e vai) pegar  um vírus;
• Alguém pode desligar um servidor acidentalmente no CPD. Há não muito tempo atrás, os teclados vinham com uma infame tecla chamada “power”, que ficava ao lado da tecla delete. Você não precisava estar dentro do CPD para fazer uma besteira, bastava numa conexão remota apertar a tecla “power” sem querer….
• Algumas vezes, mesmo quando o sistema operacional é desligado gentilmente, o banco de dados não está configurado para ser desligado gentilmente antes;
• Agora para matar definitivamente: você sabia que todos os storages tem um nobreak adicional embutido?

O Que há de novo no mundo dos sistemas de arquivos?

Bom, a esta altura eu já poderia estar escrevendo assim:

– Espelho, espelho meu, existe sistema de arquivos melhor que o XPTO?

– Caro sysadmin, é carnaval, vai tomar uma cerveja e deixa o sistema de arquivos aí.

Mas é claro que no último e-mail da conversa na lista de discussão que deu origem ao texto que você esta lindo aqui, o Sr. Fernando Ike estragou a piada infame. Na verdade eu já estava esperando a posição dele que acabou fechando a conversa. Para quem não sabe, o Sr. Fernando Ike é um sysadmin que foi para o PGCon2008 no Canadá apresentar um trabalho de pesquisa feito junto com o Sr. Euler Taveira sobre testes de desempenho no PostgreSQL utilizando diferentes configurações de sistemas de arquivos. Vale a pena conferir aqui. E o que foi que mestre fike disse? Num futuro próximo teremos EXT4 e Btrfs.

Bom, por uma questão de sanidade mental, minha e dos meus leitores, vou deixar isso para o próximo post. Mas fiquem antenados, o mundo continua girando e as coisas estão mudando…