O restaurante no fim do universo

Eu acho a trilogia de 5 livros de Douglas Adams fantástica.

Eu terminei de ler o segundo livro agora é me mato de rir com algumas passagens:

  1. Como a incrível batalha entre Marvin (um robô depressivo) e uma máquina de destruição.
    image
  2. Ou o encontro entre Zaphod e seu bisavô.
    image
  3. Já imaginou se um elevador fosse inteligente?
    image
  4. Ou se quando você fosse em um restaurante (que tal no fim do universo) e pedisse o prato do dia é…
    image
  5. O quão chocante uma verdade sobre o universo
    image
  6. Quase no final, e o resumo para muita coisa.
    image

Teria inúmeras outras passagens, mas todo fã de ficção e fantasia deveria ler essa série.

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

Ágil é diferente de Rápido

Ágil = Que tem grande facilidade de se mover; ligeiro, leve.

Para o andamento do TCC estou utilizando um modelo bem simples baseado em princípios ágeis. Criei e vou atualizando um backlog de todas as funcionalidades que quero fazer no Marvin e no Telescreen. Todo o domingo eu faço o planejamento de quais atividades eu vou fazer até sábado, ou seja, sprints de 7 dias corridos.

Isso foi um aprendizado com relação ao inicio do TCC 1 onde eu estava fazendo sprints de 14 dias e o processo não estava fluindo. Para dar vazão, alterei para sprints de 4 dias, o que fez com que as atividades realmente fossem concluídas. Com os atuais 7 dias, as atividades estão fluindo bem, o planejamento do que pode ser feito tem sido bom, sobrando algumas horinhas que utilizo para fazer “perfumarias” no sistema.

Para o controle desse backlog e sprints, estou utilizando o site Acunote que é muito prático e vem com vários recursos, entre eles o gráfico de Burndown e detalhamento de tarefas.

Para estimar as tarefas estou utilizando a metodologia de story points (baseada na sequencia de Fibonacci) onde as atividades recebem pontos na sequencia de 1, 2, 3, 5, 8, 13, 21. Estou falhando em descrever as tarefas, pois somente estou descrevendo o título e não justificando o valor agregado. Como todo esse processo (PO, analista, designer, programador, testador, etc) está sendo realizado pela minha pessoa, não estou perdendo nenhuma informação. Mas seria interessante detalhar um pouco mais.

Uma das coisas mais importantes que eu fiz foi com relação ao design do sistema. Fui criando uma arquitetura emergente, onde os pacotes e classes foram surgindo e evoluindo naturalmente, sem a necessidade de ficar pensando muito como fazê-los. Da primeira versão da aplicação até a versão atual (01.00.004)  foram criados 4 pacotes e diversas classes e interfaces, transformando a aplicação em um formato bem modular e escalável.

A melhor definição que ouvi de rapidez e agilidade é a do Coyote e Papa Léguas: o Coyote só é rápido, mas não consegue fazer bem as coisas, já o Papa Léguas é ágil, pois além de também ser rápido utiliza isso em seu benefício.

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.