Bancos de dados ideais para pesquisas em redes sociais

Conhecemos varios programas para banco de dados, mais existem alguns que são usados em redes sociais ou para adquirir certas informações vamos falar sobre eles.


As redes sociais escondem informações valiosas sobre comportamento e consumo. Os bancos de dados de grafos podem trazê-las à tona.

Não há quem não goste de redes sociais. O governo a usa para rastrear os contatos de suspeitos de terrorismo. A lavanderia quer saber quem são seus amigos, para que você passe à frente a propaganda boca-a-boca.

Enquanto isso, as empresas de mídia acreditam poder ligar os pontos entre as preferências das pessoas em filmes, televisão e música, para fazer com que quem amou Duro de Matar 1 saiba que também existe o Duro de Matar 2.

Para resolver este e outros problemas típicos dos diretores de marketing de todo o mundo é que existem os sistemas de bancos de dados de grafos, ou de rede. (Os cientistas da computação usam o termo “grafo” para descrever coleções de objetos e as ligações entre eles.)

Ao usar bancos de dados de grafos em vez de relacionais para armazenar as estruturas de dados que descrevem as redes sociais, é possível obter mais rapidamente respostas a questões importantes, como que tipo de salgadinho o amigo do amigo do amigo prefere, ou se alguém de seu DVD do casamento também esteve em um filme de Kevin Bacon.

Outras soluções
Os bancos de dados de grafos não são a única resposta. Bancos relacionais despojados de esquemas vêm aparecendo no mercado com recursos que rivalizam com os de grafos, fornecendo respostas rápidas graças a um mecanismo que não os fazem perder tempo gerenciando transações e que privilegiam respostas pré-programadas.

Em alguns casos, certos tipos de pesquisas em relação a redes sociais podem ser melhor atendidas por um banco de dados relacional típico. Por exemplo, se você mantém as ligações entre pessoas armazenadas em uma tabela indexada com um número de identificação em ambas as colunas, será fácil para um banco relacional encontrar todos os amigos de João ou todo mundo que segue o Daniel. Nesses casos, a estrutura de grafos não será de grande ajuda.

Demos uma olhada em três sistemas de bancos de dados úteis para a análise de redes sociais: Neo4j, Cassandra e FluidDB. Todos os três são relativamente novos, mas são boas promessas de ajuda a organizações que querem ligar os pontos em sua base de usuários.

Neo4j
À primeira vista, não há muita coisa no Neo4j, um banco de dados de grafos escrito em Java que pode funcionar em conjunto com o Ruby e o Phyton. Há apenas nós, atributos para nós, e relacionamentos entre esses nós. Para encontrar uma resposta, você deve criar um objeto transversal que toca os nós seguindo os relacionamentos até que a resposta apareça.

O Neo4j pode responder a questões básicas, como “Quantos amigos de um amigo alguém tem?”, simplesmente seguindo as ligações de amizade entre os nós das pessoas. De fato, a documentação do Neo4j inclui um esboço de projeto do IMDB.com para resolver o clássico problema de Seis Graus de Separação de Kevin Bacon com apenas algumas linhas de código.

A força do Neo4j reside em sua habilidade de resolver problemas que demandam consultas repetidas. Os algoritmos de busca não são novidade para qualquer um que tenha tido aulas básicas de ciência da computação. Há até um punhado de bibliotecas, como a JGraphT, que implementam, em Java, muitos dos algoritmos clássicos.

O Neo4j é oferecido com uma dessas licenças: AGPL (a mais dura licença de código aberto) ou uma licença comercial da Neo Technology.

Cassandra
Nem todas as pesquisas em uma rede social exigem a sofisticação de uma ferramenta como a Neo4j, porque nem todas as pesquisas requerem explorações profundas nos grafos. Muitas envolvem simples interseções e junções das informações ligadas aos vários nós.



O Digg, por exempo, queria que um símbolo aparecesse junto a um link cada vez que ele fosse “cavado” pelo usuário. Esta interseção simples, no entanto, torna-se complicada pela enorme massa de informação que flui pelo Digg, tornando as soluções convencionais com “join” de tabelas relacionais algo muito lento, mesmo com boa indexação.

O Digg usa o Cassandra, um banco de dados NoSQL (não-SQL) que promete ser “eventualmente consistente” – isto é, a atualização não ocorre ao mesmo tempo em todas as instâncias, o que já atende a algo tão efêmero como um link para um artigo.

Um exemplo: o Facebook, que é o desenvolvedor original do Cassandra, frequentemente fornece versões imprecisas de minha lista de atualizações. No entanto, isso não é um grande problema.

A desnormalização de dados exigida por essas implementações pode consumir espaço excessivo no disco, já que os dados são exaustivamente repetidos. Mas isso também não é problema, agora que espaço em disco se tornou tão barato.

O Cassandra é uma ferramenta excelente, e há uma variedade de bancos de dados similares que podem trabalhar com a mesma concepção. Os mais populares são o MongoDB e o CouchDB.

FluidDB
O FluidDB não é um banco de dados de grafos, mas pode lidar com pesquisas em redes sociais, graças a uma estrutura simples e uma flexibilidade radical. O banco de dados foi projetado para aceitar a cooperação de todos na identificação de elementos de dados; este trabalho colaborativo pode trazer respostas a questões.

A estrutura do FluidDB é solta. Qualquer um pode colar etiquetas em qualquer objeto de dados, mas apenas as pessoas com os privilégios certos poderão ver essas etiquetas.

Se as etiquetas forem coladas a uma estrutura consistente, então as operações lógicas com essas etiquetas vão produzir soluções precisas a muitas das questões que podem surgir numa rede social.

Mas existem limites a esse poder. As pesquisas funcionam em apenas uma camada por vez, tal como os exemplos de uso do Cassandra pelo Digg. A pesquisa não pode atuar sobre diversas camadas sem fazer repetidas perguntas ao banco de dados, refinar a resposta, e então enviar outra pesquisa.

A ausência de estrutura das etiquetas, no entanto, torna possível pré-calcular algumas das pesquisas mais complexas. Se alguém parar de seguir uma pessoa no Twitter, o leitor de Twitter poderá acrescentar uma etiqueta “parou de seguir”, economizando tempo de subtração ou de interseção de linhas.

Grande interesse
Todas essas soluções são apenas um primeiro olhar sobre as ferramentas que podem responder a questões sobre redes sociais. Elas não fazem tarefas muito complexas, tais como cálculos de soma e de média sobre um conjunto de linhas, pelo menos não com comandos prontos. Mas você poderá implementá-los por conta própria, se precisar.

O campo do NoSQL está atraindo grande interesse, e as técnicas usadas com o Cassandra podem facilmente ser aplicadas a qualquer outro banco de dados NoSQL emergente.

Fonte: IDG Now

Twitter troca MySQL por Cassandra


De acordo com Ryan King, engenheiro do Twitter, a rede social pretende trocar o MySQL pelo banco de dados Cassandra.

A razão estaria na resiliência, na escalabilidade e na grande comunidade de desenvolvedores de código aberto do repositório leve de dados feito em Java, que dispensa a sobrecarga de recursos dos bancos de dados relacionais convencionais. A tecnologia é parecida com a de outros bancos de dados NoSQL emergentes, como MapReduce e Hadoop.

Hoje, o Twitter utiliza um cluster de servidores MySQL com um sistema de cache em memória que "está rapidamente se tornando proibitivo para operar. Precisamos de um sistema que possa crescer de forma mais automática e que tenha alta disponibilidade", disse o engenheiro.

O volume de dados no Twitter aumentou consideravelmente no último ano. Em janeiro de 2008, o microblog movimentava cerca de 2 milhões de tweets por dia. Um ano depois, esse volume chegou a 50 milhões de posts diários.

Com informações de BR-Linux