No dia 15 de maio de 2010 ocorreu o NoSQL Brasil, o 1º encontro sobre bancos de dados não relacionais no Brasil, organizado pelo Alexandre Porcelli em São Paulo.

Desenvolvedores no NoSQL Brasil

Desenvolvedores no NoSQLBrasil. Créditos: Henrique Bastos

</p>

Quem foi no NoSQL Brasil

</h2>

Mais de 200 desenvolvedores compareceram para mostrar ao mundo que bancos de dados não são só SQL.

Assim como existem linguagens de programação que facilitam o desenvolvimento de determinada aplicação, existem bancos de dados (leia: SGBDs) que se encaixam melhor em um projeto.

NoSQL é sobre escolha.

</p>

Como estava a organização

</h2>

Sensacional!

Porcelli teve ajuda de sua família e amigos.

Afinal, um evento que ia ter 40 pessoas tomando cerveja e conversando sobre NoSQL teve 200 pessoas e aconteceu num dia inteiro no Hotel Park Suites ITC na Vila Olímpia.

Os coffee breaks estavam muito bons em especial os pães de queijo. ;)

</p>

Quais foram as palestras

</h2>

    </p>

  • </p>

    SQL anti patterns and NoSQL alternatives (Gleicon Moraes)

    Gleicon mostrou que você deve abrir a cabeça para a desnormalização.

    Uma apresentação recheada de exemplos do que você não deve fazer em bancos de dados relacionais e quais são algumas das opções para soluções racionais e elegantes.

    </li>

  • Performance e simplicidade com Chave/Valor utilizando Redis (Luiz Fernando Teston)

    </p>

    Redis é um banco de dados chave-valor rápido que guarda os dados na memória e persiste no disco de tempos em tempos.

    Me pareceu interessante para aplicações simples.

    </li>

  • O papel do REST no Neo4J e CouchDB, um comparativo (Guilherme Silveira)

    </p>

    Guilherme falou que devemos:

      </p>

    • sempre desenvolver em camadas</p>

      </li>

    • evitar bater no banco de dados, devemos cachear tanto no client como no servidor. No máximo devemos ver se a informação cacheada é atual.</p>

      </li>

    • ter servidores stateless - não guardar dados de aplicação nos mesmos. Por exemplo: guardar dados de sessões de usuário no memcached.</p>

      </li>

    • aproveitar mais os cabeçalhos do HTTP como o de links</p>

      </li>

    • usar ETags para checar versões de dados.</p>

      </li>

      </ul>

      </li>

    • Introdução ao MongoDB - direto da fonte! (Alberto Lerner)

      </p>

      Alberto foi engenheiro do BigTable no Google e agora está começando na 10gen, empresa que criou o MongoDB.

      Ele deu uma introdução bem legal sobre o Mongo e como é possível escalá-lo.

      </li>

    • </p>

      Tio: um NoSQL made in Brasil (Rodrigo Strauss)

      Rodrigo apresentou seu projeto chamado Tio, um servidor de containers focado em publish/subscribe.

      Você pode criar servidores só mexendo no código do client.

      É possível criar um message Broker, servidor de fila e várias outras coisas.

      </li>

    • Nas Nuvens com KVM, JBoss REST-Easy e InfiniSpan (Edgar Silva e Samuel Tauil)

      </p>

      Os palestrantes falaram sobre mapeamento de verbos de serviços na web usando URIs (exemplo: /voos/atrasados/gru) e como usar usar Inifinispan como cache distribuído através de uma interface REST com o RESTEasy.

      </li>

    • Divide et impera - Processamento massivo com Hadoop, Pig e HBase (Vinicius Carvalho)

      </p>

      Vinicius falou que anda testando o Hadoop usando Pig na Amazon.

      Ele envia os dados pra Amazon S3 e executa o script Pig semanalmente com a Amazon Elastic MapReduce.

      Ele também disse que provavelmente não usaria Hadoop se não fosse pelas facilidades da Amazon.

      Hadoop é bem chato de instalar.

      </li>

    • </p>

      Estudo de caso: avaliando o Apache Cassandra como cache distribuído (Julio Viegas)

      Julio falou sobre como estão usando Cassandra como cache na SPC Brasil.

      Antes eram usados Ehcache e RMI.

      Sua equipe pesquisou o:

        </p>

      • memcached - não usaram porque o failover era "manual"</p>

        </li>

      • Redis - não usaram porque tiveram problemas com chaves e memória. Isso os limitava.</p>

        </li>

      • </p>

        Voldemort - não usaram porque tinha uma comunidade pequena

        </li>

        </ul>

        Resolveram usar o Cassandra porque:

          </p>

        • tem um bocado de gente grande que usa. Tipo o Digg, Rackspace e Twitter.</p>

          </li>

        • é tolerante à falhas</p>

          </li>

        • escala horizontalmente</p>

          </li>

        • é bem rápido</p>

          </li>

          </ul>

          Um ponto negativo (não é possível ter tudo num sistema distribuído) é que ele não é sempre consistente.

          Se ele buscar um certo dado em determinadas máquinas e não achar o que tem o timestamp mais recente, ele pode retornar uma versão antiga.

          Isso é difícil de acontecer, mas é possível definir quantas máquinas ele vai consultar.

          Quanto mais máquinas você buscar a informação, mais lenta fica a resposta, porém você ganha em consistência.

          Cassandra

          Cassandra é uma delicinha...

          </li></ul>

          O que não foi legal

          Porcelli fez de tudo pra acontecer o evento, logo teve que cortar algumas coisas.

          Não tivemos acesso à interwebs.

          Eu gostaria de ter testado os SGBDs enquanto os caras palestravam, mas não deu.

          Fica como dever de casa. :)

          Valeu a pena?

          Claro, conteúdo e pessoal nota 10!

          #HoraExtra sensacional no bar da esquina depois do evento com um monte de gente!

          Mais uma coisa

          Porcelli pagou boa parte do próprio bolso.

          Mais de R$1000,00 em doações foram feitas durante o evento, mas não conseguimos tirá-lo do vermelho.

          Participe da Vakinha para ajudar nosso amigo. ;)

          Você curte bancos de dados não relacionais? Quais? Quer ver algum tutorial ou artigo sobre eles aqui no blog? Acha que é viagem?