E o Java se Junta a Era do Big Memory

A startup Terracotta está tentando resolver um dos maiores problemas para desenvolvedores Java. É o bom e velho garbage collection da linguagem, que sempre foi conhecido por simplificar o trabalho do desenvolvedor e não parece estar sendo capaz de atender mais de maneira tão eficiente, em tempos de big data.

A Terracotta afirma que resolveu o problema criando o seu próprio gerenciador de memória. O produto chamado Big Memory coloca os dados direto em cache. Os garbage collectors tradicionais irão armazenar os dados em formato de árvore. Os dados são ligados em rede aos diferentes nós da árvore. O Terracotta usa o cache para que todo o “lixo” vá para a memória. Em vez de uma estrutura de árvore, ele se parece mais com um enorme mapa.

O problema com o garbage collection está se tornando cada vez mais significativo com o surgimento do big data. Para muitos desenvolvedores, as aplicações Java não tem conseguido acompanhar o big data.

A Terracotta recentemente anunciou que havia ampliado o seu recurso ehCache para um terabyte. Foi preciso uma abordagem mais ortogonal com o Big Memory. Ele transforma um problema linear em um espacial. O lixo é despejado na memória. Ele não é colocado em um pequeno espaço que precisa de um alto grau de organização.

A quantidade de dados que vai para o lixo pode ser dimensionada com o Big Memory do Terracotta.

As melhorias têm impactos para o desenvolvedor que agora deve organizar e sincronizar aplicações para se adequar as limitações dos atuais trash managers. Pode levar meses para otimizar um app. Usando o cache resolve o problema, já que o processo de ajuste fino manual é eliminado.

Big data é cada vez mais essencial. A Zynga, mãe do Farmville e aplicativos de serviços como o Travelocity, todos possuem enormes quantidades de dados. As empresas também não estão imunes. Os grandes bancos e outras grandes empresas possuem aplicativos com enorme quantidade de dados.

O que isso faz é colocar o big Java na era do big memory. As questões são aplicáveis para toda a comunidade Java. O Oracle, e agora com o Sun, continuam a tentar desenvolver melhores garbage collectors colocando a cache para trabalhar desviando do problema.

Os problemas com isso, criaram uma oportunidade para os fornecedores de virtualização para consolidar a expansão do parque de servidores das empresas. A virtualização pode resolver alguns dos problemas de garbage collection e com tecnologia de virtualização um servidor pode ser dividido em até 100, mas isso é um ambiente complexo e difícil de gerir.

A Terracotta argumenta que com o Big Memory, um servidor pode ser dividido em duas a quatro máquinas com uma capacidade de memória que escala com cada máquina virtual.

Uma empresa como a Terracotta enfrenta um desafio evangélico. O ehCache pode resolver um monte de problemas de memória. Mas o conceito de virtualização está tomando conta do mercado rapidamente. Os players estabelecidos como o Oracle irão tentar resolver o problema com mais máquinas virtuais no problema de memória do Java. Mas isso cria uma expansão própria.

A resposta pode ser apenas colocar todo o “lixo” do Java na cache. O que vocês acham?

0 responses to “E o Java se Junta a Era do Big Memory

  1. Bastante interessante. Eu não entendi algumas coisas:

    1 – O tradeoff do terracotta é uma melhor solução de recolhimento de lixo em troco de um maior consumo de memória?

    2 – No texto diz que os garbage collectors armazenam referências de objetos em uma estrutura de árvore, mas o Terracotta utiliza uma abordagem diferente. Esta abordagem é uma nova estrutura de dados (tipo uma tabela hash)?

    3 – Se o Terracotta utiliza a grande quantidade de memória que está no sistema para jogar esse lixo na memória ao invés do mesmo ficar em um pequeno espaço altamente gerenciado (e consequentemente com alto overhead), então é plausível ter um cache distrubuído utilizando o Memcache? Será que isso sacrificaria ou aumentaria a escalabilidade de aplicativos BigData?

    1. Oi Herberth,
      Apesar de já fazer bastante tempo que você postou este comentário, achei interessante respondê-lo pois encontrei este artigo somente agora.

      1 – Na realidade o ganho do BigMemory é o fato de todo o cache ficar fora da memória Heap. Quanto maior o Heap, maiores serão as pausas de Garbage Colleciton (GC). Sem o BigMemory, se você quiser definir um cache de 20Gb, ele ficará dentro do Heap e aí você passará a ter problemas com as pausas. Com o BigMemory você pode definir caches de Terabytes de tamanho e especificar um Heap pequeno. As pausas de GC serão desprezíveis. O tradeoff é que, como existe um gerenciador de memória transferindo os dados de/para o Heap, a velocidade será um pouco menor, porém ainda assim na casa dos microssegundos, muito mais rápido do que buscar os dados em disco.

      2 – Sim.

      3 – Para escalabilidade, a Terracotta implementa cache em segundo nível. Existe uma estrutura para cache distribuído chamado Terracotta Server Array. Este array é formado por células, ou “stripes” que permite ter vários servidores Terracotta trabalhando em cluster, cada um deles com Terabytes de capacidade e escalonados horizontalmente conforme a demanda. Todos os servidores de aplicações podem ter ainda um cache local (nível 1) com os dados mais acessados, proporcionando assim uma alta performance das aplicações.

      Você encontra mais informações em http://terracotta.org

Deixe uma resposta

O seu endereço de e-mail não será publicado. Campos obrigatórios são marcados com *