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:

É 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:

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

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:

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…

2 respostas

  1. O Btrfs (ficou escrito errado no post) é bem legal, já testei ele. O problema é que o formato dele ainda não está completamente definido e pode mudar. Vários recursos que serão implementados nele são semelhantes ao ZFS, como ser copy-on-write, fazer checksum dos dados e suportar snapshots.

    Ah, acho que SUSE largou do ReiserFS como padrão há um tempo atrás (http://www.linux.com/feed/59039)

Deixe uma resposta