0055 - 085 8112 2187
wiebe@docner.comNa Docner Software, nós gostamos de usar o Hadoop e o Hbase em nossos projetos que precisam persistir uma grande massa de dados. Essa página explica porque e examina a pilha de tecnologias que usamos na Docner para criar aplicações web escaláveis, quando precisamos gerenciar milhões de documentos e bilhões de objetos indexados. ( Veja tambem nossos websites escaláveis ).
Nós descobrimos que usar uma massiva e escalável camada de persistência simplifica a pilha de software enormemente. Sem queues distribuídas e gerenciadores de processos, sem caros softwares intermediadores para troca de mensagens... HBase e Hadoop estão encapsulando os problemas da computaçao distribuida de forma eficiente. Com uma aplicação web Stateless conversando com um cluster HBase - Ele faz a mágica. Quando a carga aumentar em seus servidores web: adicione novas máquinas. Quando a carga aumentar em seus servidores de dados no cluster: adicione novas máquinas.
Acima está a pilha de tecnologias que usamos em máquinas “nuas” com a distribuição CentOS linux. Nós adicionamos monitoramento de hardware, a versão mais recente de Java, e então Hadoop e HBase em nossos clusters.
Nossos nós de rede rodam Tomcat ou Jetty onde lançamos arquivos WAR normalmente, mas não usamos nenhum gerenciamento de sessão servlet J2EE: os nós de rede são completamente Stateless (sem estado) para que possamos fazer distribuição de carga e facilitar a reinicialização de nós individuais. Nós confiamos no HBase e cache de rede para manter nossos acessos rápidos. Nós vinculamos nosso mecanismo de autenticação em uma infraestrutura JAAS regular.
A partir desse ponto, qualquer tecnologia baseada em servlet que possa gerar HTML pode ser colocada numa camada acima. Em nosso último projeto usamos Jersey REST e uma pequena biblioteca baseada em JAXB para gerar nossas páginas HTML, mas JSP também é uma opção aqui.
Uma restrita separação entre interface, regras de negócios e persistência nos ajuda a encapsular o acesso ao HBase em nossa camada de persistência - nada realmente especial. Os objetos "DAO" do HBase são encontrados usando chamadas ServiceLoader ou injetando Google Guice. Na verdade, qualquer framework que use injeção de dependência também dará conta.
Isso não é apenas uma vantagem para os desenvolvedores na fase de manutenção, mas também para administradores de sistemas java experientes que irão reconhecer as ferramentas instantaneamente. Nós apenas mudamos o jogo onde realmente importa: sistema de arquivos distribuido Hadoop e banco de dados chave-valor HBase.
Enquanto a pilha HBase não for claramente tão madura quanto o Hibernate sobre o SQL, a simplicidade da API HBase e os designs sem-esquemas fazem o desenvolvimento mais rápido e eficiente. A flexibilidade tem um preço: fortes testes unitários sobre a camada, mais testes de regressão restritos que dão conta de vazamentos de tradução de Objeto-para-Registro. Contudo, como TDD vem a ser a nossa segunda natureza, nós preferimos esta “controlada flexibilidade” sobre um “mecanismo mágico”.
Trabalhar nesse baixo nível nos dá um melhor controle sobre a performance. Por exemplo, quando programamos a API HBase, você está decidindo, explicitamente, quando escanear sobre um intervalo de chaves, e quando escanear uma tabela completamente. Porque você pode decidir todos os passos em um proceso de carregamento de dados, uma consciência e um sentimento sobre problemas de performance são naturais. Compare isso como tentar conseguir uma boa performance de um banco SQL; onde o query optimizer está escondido dos desenvolvedores em uma linguagem como SQL e então abstraidas ainda mais por uma camada Hibernate ou JPA sobre ela. Como nós estamos desenvolvendo para grandes massas de dados, performance é algo crítico. Usando HBase temos todo o controle: Nós podemos facilmente manipular e refazer designs até que consigamos o resultado correto.