2011/1/12 Alexei Znamensky <[email protected]>: > Ok, pode me chamar de velho, old-school, o que for. Mas na minha época, > file-system era algo que tinha alguma coisa a ver com o kernel do sistema > operacional. Mesmo com o uso cada vez menos incomum de "user space" file > systems hoje, sempre há um gancho no kernel. Por exemplo, sou um feliz > usuário de sshfs [1], mas ele precisa que o fuse [2] faça o gancho dentro do > kernel do Linux.
Na minha época (com certeza uns 20 anos depois da sua :-P) o FS também é coisa do Kernel, mas em casos específicos, ele pode ser portado para o user-space, com o foco de lidar com os dados usando um nível mais alto de abstração. TMTOWTDI. Nós pregamos isso o tempo todo, porque não pode ser válido para um filesystem ou para outro projeto/linguagem? > Dei uma lida rápida no começo da documentação do HDFS. Ok, entendi (em > linahs gerais) o que o cara quis fazer. Eu mudaria o nome de "filesystem" > para algo como "JVM-based filesystem" ou algo assim, para evitar > ambiguidades. But hey, that's just me. Humm, preconceito hein. > Pessoalmente eu não sei se usaria algo em Java (+ pesado) para lidar com > algo que pode ter requerimentos de performance como I/O de dados. Algo em > Java dificilmente irá se aproveitar de coisas como tamanho do bloco no disco > físico para melhorar o desempenho. Em escala menor, isso não importa, mas se > falarmos de massas de dados gigantes, esse tipo de detalhe pode fazer > diferença. O HDFS será tão bom com os arquivos quanto for a implementação de > Java utilizada para rodá-lo. Espero *muito* que estejam usando java.nio.* - > não faria sentido se não usassem. Eu pensaria em algo feito em C/C++ para Vamos esperar para ver o Btrfs, então. > implementar esse "file system", e que provesse essa funcionalidade > "genérica" em todas as plataformas onde fosse compilado, mas que pudesse se > proveitar de coisas como o FUSE no Linux para ser acessado diretamente como > um "real file system" (mesmo que em user-space), sem que isso tenha um custo > de performance tão alto. Este é o trade-of que você vai ter que fazer, não? Existe casos onde disponibilidade é muito mais importante do que performance, e etc. E pela forma como o Hadoop forma clusters, eu estou para lhe afirmar que seu "problema" de performance não vai ser tão grave assim ;-). > yet another $0.02 Perai. Da forma como você colocou, dá a impressão que todos os seus dados ficariam neste filesystem. Eu não faria isso e tenho a certeza de que você também não. Partindo desta premissa, podemos "chutar" que o HDFS vai ser utilizado para resolver um problema específico. E se chegamos a este ponto, eu também assumo que você estudou cuidadosamente o problema e concluiu que o Hadoop é uma boa solução. > -- > Alexei Znamensky [russoz_gmail_com] [russoz.wordpress.com] > [www.flickr.com/photos/alexeiz] > «Only love / Can bring the rain / That makes you yearn to the sky» Eu já vi Hadoop rodando em algumas poucas empresas, porem, guardando dados não-tão-importantes, como logs por exemplo. É questão de tempo para este FS escalar para posições mais importantes. um abraço, -- Otávio Fernandes otaviof at ( gmail.com, cpan.org ) http://github.com/otaviof =begin disclaimer Sao Paulo Perl Mongers: http://sao-paulo.pm.org/ SaoPaulo-pm mailing list: [email protected] L<http://mail.pm.org/mailman/listinfo/saopaulo-pm> =end disclaimer
