Localizando uma Agulha: usando MongoDB para dados Geolocalizados

A recomendação de conteúdo para usuários é um dos pontos principais no Superplayer. Desde o inicio do ano criamos uma estrutura de geolocalização utilizando MongoDB para selecionar Playlists e propagandas para os usuários. No meio do caminho algumas coisas não funcionaram muito bem, mas apreendemos muito desde então e nesta palestra vou compartilhar os principais pontos.

Trechos de código: https://github.com/calielc/TDC2015-Geolocation

Anúncios

TDC Porto Alegre

No dia 25/10/2013 pude apresentar por 15 minutos no TDC Porto Alegre 2013 (http://www.thedevelopersconference.com.br/tdc/2013/portoalegre/trilha-dot-net#programacao)

Falei sobre o banco de dados Amazon DynamoDB. Nossa, como 15 minutos passam muito rápidos. Mas deu quase tudo certo.

Comecei explicando como o DynamoDB funciona e em seguida criei um demo. Segue a apresentação.

O demo é muito parecido com o Kwitter, importar do Twitter algumas mensagens e salvar no banco e mostrei as 3 maneiras de utilizar o DynamoDB no .net:

  • Low API
  • Mid API
  • High API

Segue os fontes estão no GitHUb: https://github.com/calielc/TDC-2013. Não consegui fazer todo o demo na palestra. Mas segue o exemplo completo.

Para mim foi muito bom o TDC.

Compartilhar é bom, compartilhar NoSQL é melhor

A vida nos prega peças interessantes

Ontem, 05/11/2012 tive o prazer de compartilhar um pouco da minha experiência em NoSQL na UCS, graça ao convite do professor Daniel Notari. Pude apresentar como foi desenvolver um sistema utilizando o banco de dados Amazon DynamoDB para a turma de Estrutura de Dados.

Com o objetivo de ser único, não comentei uma apresentação, criei um mapa mental e fui escrevendo no quadro branco.

Comecei falando sobre o que era Big Data, em segui porquê surgiram os bancos de dados NoSQL e suas categorias. Depois  entrei no assunto que mais domino no momento o Amazon DynamoDB.

Falei sobre estrutura de tabelas, como é feito o particionamento e replicação dos dados, concorrência.

Após 1 hora falando, fiquei muito feliz ao ouvir perguntas. Entre elas se foi muito difícil desenvolver, o que para mim não foi pois como utilizei as metodologias ágeis, consegui me policiar bastante no tempo e esforço para desenvolver.

Ao final de tudo deu tempo para apresentar o Telescreen (http://kwitter.no-ip.info) rodando.

Um dos grandes materiais de recomendo a leitura para quem ficou interessado sobre o DynamoDB é o blog de Werner Vogels, CTO da Amazon. o nome do seu blog é All Things Distributed, lá duas excelentes postagens são:

http://www.allthingsdistributed.com/2007/10/amazons_dynamo.html

http://www.allthingsdistributed.com/2012/01/amazon-dynamodb.html

Continuar lendo

Isso não é um banco de dados relacional

A ordem dos fatores altera o produto

Como já comentei, estou fazendo o TCC baseado em um banco de dados não relacional, neste caso o DynamoDB.

Nestas duas últimas semanas venho desenvolvendo os aplicativos para gravar e ler no DynamoDB (Marvin e Telescreen, respectivamente).

Para gravar, o processo é extremamente simples; basta montar o registro e mandar salvar no dado. Mas tive alguns problemas na hora de retornar o dado. Primeiramente, com o fato de não haver relacionamento entre tabelas. Imaginando as tabelas abaixo, onde cada mensagem pertence a um usuário.

Durante a apresentação, para cada mensagem é necessário fazer uma nova requisição ao servidor, solicitando o Usuário através de seu username. Então para carregar 200 mensagens são necessárias 201 requisições (1 para pegar a lista de mensagens e mais 200 para cada usuário). Todo esse processo se mostrou muito lento, quase 30 segundos para carregar 50 mensagens.

A primeira tentativa para otimizar esse processo foi criando um buffer de usuários, onde ao invés de realizar diretamente a requisição de usuário, era verificado se o registro já estava armazenado na memória local. Este processo não trouxe efeito por causa do tipo de dado que está sendo armazenado. Como são Tweets capturados de acordo com uma taxonomia, a chance de um usuário mandar 2 mensagens próximas é pequena, sendo assim o buffer não se mostrou útil e foi retirado.

A solução para esse problema foi colocar os campos da tabela de usuários junto à tabela de mensagens, não sendo mais necessária a tabela de usuários. Isso produziu uma desnormalização na tabela de usuários, mas o ganho de velocidade em consultas foi interessante. Para retornar 50 mensagens, é necessário 1 segundo.

O outro problema que tive foi com relação à ordem de retorno dos registros. Como o banco de dados realiza sharding, ou seja, os dados são replicados e particionados entre diversos servidores, ao solicitar diversos registros, eles não retorna em uma ordem que eu tenha identificado, nem na ordem de inclusão. É outro problema pois não consigo apresentar as mensagens mais recentes primeiro. A solução para isso foi apresentar cada página de 50 registros ordenada. Mas não sei se é a melhor solução.

Até o presente momento estou gravando e lendo corretamente todos os dados, o retorno das consultas está rápido e tudo está bem.

A difícil e reconfortante arte de aprender

It is a very sad thing that nowadays is so litle useless information

– Oscar Wilde

Como já comentei estou fazendo o meu TCC sobre armazenamento de dados em banco de dados NoSQL.

O banco que escolhi utilizar foi o DyamoDB. Ele é um banco proprietário da Amazon e é da categoria chave-valor, ou seja  é uma grande tabela identificada por uma chave única. É um paradigma não muito diferente dos utilizados nos dicionários em memória, a grande diferença é a escalabilidade suportando milhões de registros.

Ontem comecei a estudar como armazenar os dados no Dynamo, e uma boa fonte de partida foi o material da própria Amazon. Escolhi desenvolver o programa na linguagem .NET (pois tenho mais facilidade)  e existe um SDK muito bom para o Visual Studio.

Demorei algum tempo para entender os exemplos disponíveis e realizar algumas alterações básicas. Mas a lógica é bem simples.

  • Após concluir o cadastro na Amazon,
  • Vá no console da ferramenta
  • E crie uma tabela
  • Informe o nome
  • Informe o tipo de chave que será utilizada, Hash que é uma chave simples ou Hash and Range que é uma chave composta de dois campos
  • Pronto a sua tabela está pronta.
  • As operações disponíveis para as tabelas são: Load (para carregar uma chave), Save (para salvar uma chave), Delete (para excluir uma chave), Scan (para listar todas as chaves) e Query (para consultar)

Como as tabelas não possuem uma estrutura rígida, cada registro pode ter campos diferentes o que facilita bastante a estrutura. Não existe relacionamento entre diferentes tabelas, isso é realizado diretamente durante a programação.

Ao final da minha secção de trabalho eu tinha as tabelas criadas, conforme “DER” abaixo

E realizei a codificação o Marvin gravar nas tabelas Usuário e Mensagem.

Durante os testes de execução do programa, com uma taxonomia limitada, encontrei uma postagem de @lespider publicando uma comparação entre diversos bancos NoSQL (acesse aqui).

O Marvin começou a criar forma, espero que ele não seja muito deprimido.