A revolução dos bichos

Toda vez que eu ia nas livrarias me deparava com um livro do Geroge Orwell chamado a Revolução dos Bichos. O meu amigo George foi ótimo escrevendo 1984. Mas ficava na dúvida sobre um livro com bichos.

A té que um dia, seguindo a recomendação do livreiro eu comprei, no mesmo dia resolvi ler. E o livro é fantástico, pensava que o esquema dos bichos ia ser uma coisa meio infantil, mas quando o cara escreve que um porco está montando o esquema para construir um moinho, e que eles criaram uma sociedade onde todos são iguais (ou não) é ótima.

Em resumo, os bichos de uma fazenda criam inteligencia e expulsam o dono humano, sendo os proprietários da Fazenda dos Bichos. Tudo começa em harmonia, todos são iguais, eles criam mandamentos e tudo vai bem… Mas se não tivesse um problema não existiria um livro.

Acontece uma revolta interna e as coisas começam a piorar, mas os demais bichos são indiferentes a isso. Qualquer semelhança com a nossa realidade não poderia ser coincidência. O final da história é irritante de tão bem, pois mostra a verdade inconveniente.

Anúncios

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

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.

TCC

Para terminar o meu dia, voltei a fazer o meu TCC. Ele é sobre Arquitetura de Dados NoSQL para Indexação de Tweets. o material pode ser acessado através de Texto e a Apresentação.

Estou nesse momento implementando 2 programas:

  • o Marvin (referência a O Guia da Mochileiro das Galáxias) que é um programa de importação de Tweets para uma base no NoSQL
  • o Telescreern (referência a 1984) que é um website para visualização desses Tweets.

Batizei com duas grandes referências Nerds, dois livros que são ótimos.

O Marvin já está lendo o Twitter e falta gravar no banco de dados, o Telescreen está apresentando e só falta ler do banco de dados. Ou seja eu não fiz nada de importante ainda.

Não estou seguindo os principio ágeis (SCRUM, XP) e entregar rápido valor. Vou me focar isso.