A velocidade de repercussão de uma frase

Com a disseminação dos computadores e do acesso à internet, as redes sociais estão cada vez mais presentes no dia a dia das pessoas. A fronteira de conhecer uma pessoa ou concordar com as suas ideias não está mais limitada à localização geográfica, por exemplo, uma pessoa do Brasil pode ter suas ideias rapidamente propagadas pela Ásia, através de um de seus seguidores do Twitter ou amigo do Facebook. Não só as pessoas compartilham suas fotos ou o que estão fazendo naquele momento; mas as organizações também estão inseridas nesse mundo apresentando sua marca.

Quando alguém elogia ou reclama de um produto fornecido pela empresa, instantaneamente seus amigos ficam sabendo e qualquer outra pessoa pode consultar e fazer uso disso. As empresas estão vendo essa propagação rápida da informação como uma oportunidade para melhorar seus serviços, além de conseguirem trazer novos clientes e não perdendo outros. Quando um cliente está insatisfeito, ele pode ser diretamente atendido, visando solucionar seu problema mais rápido.

Neste artigo apresenta-se argumentos para a utilização das redes sociais pelas organizações.

Com a Web 2.0, a referência de amigos para um produto passou a ser a postagem em um blog ou a discussão em um fórum de vários desconhecidos, sendo assim uma menção positiva pode ampliar o alcance da marca, conforme Torres. Medeiros cita a empresa Adams, por causa de uma grande mobilização feita na internet, decidiu por recolocar no mercado o seu sabor de Halls Uva Verde, juntamente com uma grande campanha de marketing onde quatro pessoas que solicitam a volta do sabor foram homenageados com seu busto feito da bala.

O mesmo ocorre com reclamações, conforme Torres e Salustiano, onde o monitoramento pode criar contornos e saídas, evitando que “bolas de neve” sejam criadas. Pode-se citar o caso ocorrido com a Telefonica que teve de suspender a venda de novas assinaturas após um grande número reclamações nas redes sociais.

Para Mendes “a marca é o que dizem e não o que o marketing determina” sendo assim, profissionais de marketing podem analisar quais palavras são mais mencionadas pelos clientes e concorrentes e através de técnicas de SEO utilizadas pelos mecanismos de busca (Google e Bing, por exemplo) levar novos clientes a utilizarem a marca. A utilização de tags em anúncios objetiva atingir um público mais seleto e com mais interesse na compra da ideia.

Salustiano comenta que no Brasil, a maioria das agencias publicitarias não tem acesso aos dados financeiros dos seus clientes, assim sendo obter o índice de retorno do investimento (ROI) é ainda complicado. Uma das formas de medi-lo é através da quantidade de menções positivas espontâneas feitas à marca antes, durante e depois da campanha. Com relação ao custo da produção e execução da campanha, uma pesquisa de maio de 2011, citada por Sarraf, aponta que utilizar as redes sociais pode diminuir em 54% o custo total.

Neste artigo foram apresentados alguns motivos para que as empresas utilizem e acompanhem as redes sociais para difundir a sua marca frente ao mercado, um exemplo disso é a frase, de Erik Qualman autor do livro Socialnomics: How Social Media Transforms the Way We Live and Do Business, citada no vídeo Brazil Social Media Revolution: “Nós não temos a escolha se devemos usar mídia social, a questão é a forma como vamos usá-la”. Em 2009 eram feitas 34 bilhões de consultas ao Google por mês, em 2010 ele foi ultrapassado em tráfego semanal (nos Estados Unidos) pelo Facebook; as redes sociais e a mídia social estão guiando cada vez mais as interações com a internet e com o mundo real. As redes sociais existem a mais de 5 anos, quantos mais tempo as empresas demorarem para utiliza-las mais estragos a sua imagem podem acontecer.

Continuar lendo

Desenvolvimento com Amazon DynamoDB

A Amazon fornece um kit para desenvolvimento (software development kit ou SDK em inglês) para as tecnologias: Android, iOS, Java, .NET, PHP e Ruby. Esse kit permite o desenvolvimento e integração com toda a plataforma de serviços em nuvem da Amazon, inclusive com o DynamoDB.

Como o Kwitter foi desenvolvido em .NET, existem duas formas de realizar a codificação:

  • Primeira é utilizando .NET Low-Level API que fornece um controle maior sobre a codificação (pode-se realizar a analogia com o ADO.NET).
  • Segunda é .NET Object Persistence Model que possui uma abstração ainda maior agilizando o desenvolvimento de rotinas mais simples (análogo ao ADO.NET Entity Framework).

Nesse projeto utilizou-se uma junção de ambos. Na parte de gravação de registros, foi utilizado .NET Object Persistence Model, já, na parte de consultas seletivas (query), foi utilizada a .NET Low-Level API. Isso permitiu um controle melhor e mais especifico buscando o melhor desempenho nas consultas.

O principal motivo pelo qual o DynamoDB foi escolhido entre os bancos de dados apresentados foi pelo fornecimento da infraestrutura juntamente com o SGBD. Como já mencionado, esse critério foi plenamente atendido pela Amazon, fornecendo uma arquitetura robusta e escalável a um valor justo.

Uma das principais ressalvas é com relação ao modelo de consistência eventual. Porém, isso não se tornou um problema em vista que a mensagem é um registro estável, uma vez gravada não é mais alterada, o que pode ocorrer é a alteração na taxonomia necessitando uma reanalise de cada mensagem, mas isso não é uma necessidade constante.

Mesmo que as mensagens fossem seguidamente alteradas, seria necessária uma quantidade muito grande de acessos multiusuário ao mesmo registro para causar problemas, já que a latência da aplicação é muito baixa.

Uma das grandes dificuldades percebida é que a equipe de desenvolvimento tem que se adaptar aos novos tempos. O desenvolvimento tem que pensar em como fazer melhor uso da arquitetura, pois agora o custo de uso é medido rapidamente. No modelo de banco de dados relacional quando uma aplicação não está obtendo muito desempenho deixa-se ao cargo do DBA criar índices ou stored procedure. Neste paradigma a criação de uma nova tabela vai necessitar de desenvolvimento, além de um monitoramento das métricas do sistema, mas enquanto isso não acontece o custo de aumentar a vazão de uma determinada tabela pode ser alto.

O DynamoDB atendeu todas as expectativas de um banco de dados, o autor desse trabalho com base na experiência de 8 anos utilizando o modelo relacional, o DynamoDB se encaixaria em muitas dessas aplicações, em alguns casos muito melhor que o banco relacional adotado. Um exemplo é o sistema para controle de ponto eletrônico onde é necessário armazenar cada uma das batidas de cada funcionário. Continuar lendo

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

Uma agulha num palheiro

Encontrar um dado específico num mundo de Big Data pode ser mais difícil do que encontrar uma agulha em um palheiro.

Amazon DynamoDB

O DynamoDB é um banco de dados NoSQL totalmente gerenciado que fornece rapidez e performance. Ele automaticamente distribui os dados e o tráfego das tabelas a um número de servidores que seja capaz de lidar com as requisições dos clientes. Os dados são armazenados em discos Solid State Disks (SSD) e são automaticamente replicados através de múltiplas regiões para prover alta disponibilidade e durabilidade.

O DynamoDB possui as seguintes características:

  •  Provisionamento de transferência: Durante a criação ou edição da tabela, a capacidade de requisição desejada  pode ser especificada. O SGBD se encarrega de alocar os recursos necessários para garantir a capacidade especificada. O provisionamento é feito através da quantidade de unidades de 1KB, que se deseja gravar ou ler.
  • Escalabilidade de armazenamento: Não existe um limite de quantidade de dados armazenados. O serviço automaticamente aloca mais espaço quando necessário.
  • Distribuição Total: O escalonamento horizontal e automatizado replica a mesma tabela sobre uma centena de servidores.
  • Construído à prova de falhas: O processo automático e assíncrono de replicação de dados através de múltiplos servidores espalhados em diferentes regiões garante além de alta disponibilidade também protege os dados contra falhas individuais ou coletivas de hardware.
  • Consistência forte e contadores atômicos: Diferente de outros BD não relacionais, o DynamoDB facilita o desenvolvimento para garantir a consistência forte durante a leitura, retornando sempre o último valor do registro. Além disso, a API fornece chamadas para incremento e decremento de contadores de forma atômica.
  • Flexibilidade: O BD não possui um esquema fixo de dados, o que significa que cada registro de uma tabela pode ter um número diferente  de atributos e de tipos de dados.

Operações no Banco de Dados

A API fornece as operações de criação, atualização e exclusão de tabelas. A atualização da tabela permite o aumento ou diminuição do provisionamento de transferência. Cada tabela é formada por uma chave primária (campo Hash) e pode ou não ter uma variação (campo Range). O conteúdo de um atributo pode ser: número, literal, conjunto de números ou conjunto de literais.  O tamanho em bytes de cada registro é definido pelo somatório do tamanho dos nomes dos campos mais 0 tamanho binário dos dados.

Também são fornecidos métodos para adicionar, atualizar e excluir registros das tabelas. Durante a atualização de itens é possível modificar valores e adicionar ou remover colunas. Para otimizar as buscas, pode ser utilizada uma operação de retorno de um ou múltiplos items através de sua chave primária, inclusive em múltiplas tabelas.

Leitura e consistência

O SGBD mantém múltiplas cópias de cada item para garantir durabilidade, para que isso aconteça após uma operação de alteração de dados é necessário que o dado seja gravado em múltiplos servidores, o que demora algum tempo. Essa demora faz com que o dado fique temporariamente inconsistente, ou seja, caso uma leitura seja feita imediatamente o valor antigo pode ser retornado. Essa é a forma padrão de leitura. Mas em alguns casos, é necessário utilizar uma leitura consistente, para isso o DynamoDB retorna o mais recente que reflita todas as operações de escrita. Essa forma de leitura é mais suscetível a lentidão da rede.

Controle de Concorrência

Em um ambiente multiusuário, em alguns casos, é necessário garantir que a atualização de um usuário não afete a gravação de outro. Para isso, o DynamoDB suporta a escrita condicional, que nada mais é do que a verificação de valor gravado antes de realizar a gravação de um novo valor.  Para contadores de valor, é possível utilizar operações atômicas que incrementam ou decrementam valores sem serem interferidas por outras operações de gravação.

A figura abaixo apresenta uma simulação de como os dados são solicitados e gravados.

Consultas

Para consultas, existem dois mecanismos: Query e Scan. A Query permite a consulta na tabela utilizando o campo Hash e, opcionalmente, um filtro de Range. Esse mecanismo é o mais eficiente de buscar items na tabela.
A operação de Scan é a forma menos eficiente, pois realiza uma varredura em todos os dados da tabela. Nessa operação é possível realizar pesquisa por valores que não são chave, porém isso implica em uma busca comparativa registro-a-registro.
Para uma melhor performance o Scan somente deve ser utilizado quando a Query não for possível. Para diminuir o tempo de responta do Scan e Query, o retorno das requisições são páginas com tamanho máximo de 1MB e a quantidade de registros é delimitada através de parâmetros.

Continuar lendo

Escutando o Twitter

 Um bom ouvinte não só é popular em qualquer lugar, mas também fica sabendo das coisas depois de algum tempo.

O programa importador de Tweets, designado Marvin, necessita da API fornecida pelo Twitter. Num primeiro momento foi utilizada a REST API, mas a maneira mais correta é utilizando a Streaming API.

A Streaming API fornece um acesso de baixa latência ao fluxo global de Tweets. O streaming funciona através do envio de mensagens indicando novos Tweets. São fornecidos 3 endereços de acordo com a necessidade:

  • Public Streams: utilizado para seguir específicos usuários ou tópicos e para mineração de dados;
  • User Sreams: retorna os dados de apenas um usuário, utilizado para apresentar uma visão;
  • Site Streams: utilizado por servidores que necessitam conectar ou Twitter em nome de muitos usuários.

Para o desenvolvimento do Marvin, foi utilizado a Public Streams que suporta uma série de parâmetros passados através de POST. Para obter as mensagens desejadas, foi utilizado o parâmetro track. Esse parâmetro é uma lista de frases separadas por vírgulas, cada frase pode ter entre 1 e 60 caracteres e um ou mais termos separados por espaço. O  Tweet será retornado se ao menos uma das frases possuir todos os seus termos (em ordem e ignorando a caixa alta ou baixa). As frases são comparadas através de UTF-8, levando em consideração até a acentuação.

Para a conexão com a API, é necessário a autenticação que pode ser feita de duas formas: Básica e OAuth. No Marvin, optei por utilizar a autenticação básica que necessita um usuário e senha válidos do Twitter. Uma conexão pode ser desconectada pelo servidor quando uma outra conexão é realizada com as mesmas credenciais.

Para evitar super-congestionamento, as conexões podem receber o código HTTP 420 (Rate Limited). Essa situação pode acontecer através de sucessivas desconexões e reconexões (para troca de parâmetros por exemplo). Para evitar que o IP seja bloqueado por um período de tempo é importante que ao receber uma notificação 420, as tentativas de novas conexões sejam suspensas por alguns minutos.

A diferença básica entre o Streaming API e REST API é que no Streaming a conexão HTTP é mantida aberta, o que envolve uma utilização diferente pela aplicação.

Enquanto no REST, cada requisição de mensagens abre e fecha uma conexão HTTP (Figura 1), no Streaming API, a conexão HTTP é mantida por um processo paralelo e os Tweets são atualizados por notificações (Figura 2)

Figura 1

Mesmo o Streaming API sendo mais complexo que a REST, possui como benefício a utilização em uma infinidade de aplicativos.

Figura 2

Fonte: Twitter