Cloud Computing - Tom Zé e o Amazon Mechanical Turk

/* Olá Senhores, Senhoras e Senhoritas DBAS!



Capa do album Com Defeito de Fabricação, Tom Zé.

      Em 1998, o músico experimental Tom Zé lançou o album Com Defeito de Fabricação. Seguindo um costume antigo (e que eu gosto muito), Tom Zé sempre cria um tema para seus trabalhos e todas as músicas envolvem esse tema. O tema de Com Defeito de Fabricação é uma linha de raciocínio simples mas ao mesmo tempo irônica e divertida.

     O albúm é sobre todos os trabalhadores do Terceiro Mundo, pouco especializados e abundantes e que na ótica de Tom Zé se tornam como robôs mais baratos do que os reais robôs alemães ou japoneses. Afinal, esses robôs reais ainda são muito caros e as grandes corporações do Primeiro Mundo ainda preferem optar pelas máquinas humanas e mais baratas, aceitando o risco de seus "defeitos" inatos (cada música é a respeito de um desses "defeitos").

    O que Tom Zé nunca imaginaria é que a gigante Amazon que vem se destacando no Cloud Computing com seus clusters elásticos de capacidade de processamento absurda a preços muito baixos iria pensar nessa mesma idéia e criar um "cluster de humanos"! 

    Lançado em 2005 e ainda no Beta, o serviço Amazon Mechanical Turk permite que através de uma API desenvolvedores e empresas (requesters) insiram tarefas (hits) que os softwares ainda não são capazes de fazer ou que são caras demais para serem desenvolvidas (como digitar o contéudo de cartões de visita ou selecionar os objetos em uma imagem).      Essas tarefas são disponibilizadas para qualquer usuário (workers)que queira se conectar e realiza-las, recebendo uma módica quantia para cada hit.

   Os pagamentos dos hits variam de US$ 0,01 (localizar o email de contato em um site) até US$ 50,00 (transcrever um arquivo de audio de uma hora e meia) mas só podem ser resgatados em dinheiro vivo por americanos ou indianos (porque será?), para outros paises os pagamentos podem ser convertidos em Gift Cards para serem usados no próprio site da Amazon.

   Em outras palavras, a inteligência humana que ainda não consegue ser emulada, ou os robôs defeituosos de Tom Zé foram clusterizados e colocados na nuvem. Uma companhia pode optar entre desenvolver um módulo que analisa contéudos de sites em busca de emails de contato, ou simplesmente deixar que trabalhadores humanos façam isso a US$ 0,02 por contato. Ela pode obter opiniões sobre milhares de artigos de jornal e usar o resultado para treinar uma Learning Machine que automatize essa verificação! 

    As possibilidades são infinitas, mas com certeza esbarram em uma série de novas  limitações (mau uso, fraude, etc...) que evitaram que esse serviço se popularize mais rapidamente.

    Afinal, Tom Zé já sabia, são pelo menos 14 defeitos.

*** Curiosidade ****

O Turco em ação!

  O nome Mechanical Turk foi tirado de uma máquina criada no final do século 18 que supostamente seria capaz de jogar xadrez contra um oponente humano. A engenhoca composta por um boneco vestido de turco e uma mesa com engrenagens  na verdade era um truque, pois um jogador humano ficava escondido dentro da mesa e operava a máquina

 fonte: Wikipedia

   

   

Espero que tenha gostado. Abraços!!

Felipe Antunes

email: fjantunes@gmail.com

twitter: @felipe_store

NoSQL- Graph databases (Neo4J), or the graph model - English Version

Para versão em português,

/* Ladies And Gentlemen DBAS!!!
  

     In my first post in english (sorry in advance), I would like to show you one of most interesting database models. The Graph Database (or Property Graph data model).

     

      

Fig.1 – Modeling my family

      Instead of use tables, columns and PK/FK relationships

      A vertex is a object with properties. Example: In a book store, the vertices could be books, authors and publishers. Books could be described with properties like Title, Genre, Price, Total Pages, etc... authors receive properties like Name, Birthday, biography, etc..
             The edges connects the nodes with labels like Writed_by,
Published_by, etc... Edges can also have properties

Tools

      The tool that we are going to use in our "hands on" is here. The Neo4J it is a

  

     

      We will also use 

Note:

Creating an graph

      

      The script will open a java windows

      The http://localhost:7474/webadmin/

   To start, click on

Inserting vertex, properties and listing

  

   Lets to create a basic social network

   You can see below the code to add some users (a litle tribute to some friends of mine)

            Just after the ASCII Art, the webadmin instance the variable g that represents the graph.

After that, we use addVertex function to add our first vertex

            The vertex properties are passed as a parameter of the function, it is an JSON that basically have this structure:
         [PropertyName:PropertyValue, ...]

As you can notice, one differece between a relational database and a noSQL is that noSQL is schemaless,so properties can varies in the vertices.
To list vertex, use g.V, where V is a collection of vertices inside the graph G. To list a specific property type the property name after V. Example: g.V.Name or g.V.any_other_property.

We notice that the Bruno Salim position ("profissão" in portuguese) was writed wrong. Lets update this ( the vertex ID of Bruno is 28).

Very simple, as is simplier add new properties. For example, lets add a position to Gustavo vertex.

Or add a completely new property (this is schemaless!)

     The map show all vertex properties (a JSON structure).

Connecting vertices.

      Now, we are going to create connections between vertices through the edge type KNOWS

First of all, we assign the vertices to friendly named variables , then we add the edges between them.

      Finally, lets answer a few typical questions of social networks and figure the power of graph db.

      Gremlin queries are divided by steps separated by dots.

Object.step1.step2.stepN.property

A step use the result of the previous step and can  transform, filter or insert some side effects in results.

Who I know?

      The

Who are the friends of my friends?

    

     One way to avoid the use of the out step many times it is use the loop step, it repeat the previous step until the rule in brackets is not fulfilled (In our case, we limited the loop to twice times checking the it.loops property.)

Who can introduces Felipe to Gustavo?

     The power of graph can be showed solving this question. In a relational database, the correspondent query will be heavy and unsuitable for applications with many users, but in a graph db regardless the quantity of users and iterations the result will keep the same performance.

      

      

     The loop will iterate until it find the the gustavo vertex. The query list two possible paths.

     Replacing the "out" steps  for pairs of "outE" (outbound edges) and "inV" (to get the vertices) we will get how they relate.

     Lets delete the connection between Spigariol and Gustavo and try again.

    In the first line, we use 'g.E' to list all edges, then 'inV' to get the verices and 'has' to filter that vertices with property Name equals "Gustavo". Finally, we use back(2), to show the results of two steps behind.(returning to E).
    The next command we remove the Edge, now we have only one possible path to Gustavo.

Conclusion

   

    That was a little tour on GraphDB, what are the tools to access and a "hands on" to create, erase and query the stored vertices. This post is not a full tutorial, for a more complete information please see this great video of Andreas Kollegger < , he explain the graph database concept and present an full demo of Neo4j.  My favorite part of the video is when he said that a relational database is great to calculate the salary average of the attendees of the webcast, but the graph would be better to identify who would buy him a beer.

      Thanks for your reading. If you have any questions, feel free to send me a email, or follow me on twitter, I´m always posting related content of the marvelous world of data!

Best Regards!

Felipe Antunes

Comunidade ! - A visão de um DBA no DNAD 2012

/*Olá Senhores, Senhoras e Senhoritas DBAs, (e simpatizantes!)

     

     

     
     
      
     
            Praticamente das sete palestras do dia pelo menos quatro envolviam ou ao menos tangenciavam Big Data.

Mas o que é Big Data?!

Big Data é a um termo geral para cenários onde os dados a serem processados/armazenados são criticos

Isso não exatamente uma novidade, mas está se tornando muito mais acessível por conta da comoditização de storage/processamento e a elasticidade de custos dos servicos de Cloud Computing (a palestra do José Papo <

            A Microsoft também não ficou atrás e está integrando o Hadoop (uma plataforma para processamento distribuido) no Azure, inclusive dando suporte ao Java (nada boba ela).
          
           Outra palestra que demonstrou bem qual é o tipo de desafio que o Big Data proporciona foi a palestra do Juan Lopes <

            Ainda o evento fechou com duas palestras . Uma do Felipe Oliveira <

Nessa ultima palestra, o volume de entrada de dados que o sistema em questão teria de absorver estava crescendo exponencialmente e eles não podiam trocar de um db relacional para um noSQL por razões politicas/comerciais.

     

Abraços!

Felipe Antunes

NoSQL - Graph databases (Neo4J) ,ou o modelo gráfico!

For english version, please

/* Olá Senhores, senhoras e senhoritas DBAS!!!

     

     

     

Fig.1 – Modelando minha familia

     

Um nó é um objeto que possui propriedades. Exemplo: Em um e-commerce de livros, os nós podem ser Livros, Autores e

     

     

Ferramentas

      aqui. O Neo4J é uma implementação do

  

     

      A linguagem que usaremos para manipular o banco é a

Nota:

Criando um graph

     

     

      http://localhost:7474/webadmin/

   Para inserir o nó clique na aba

Inserindo nós, propriedades e listando.

  

   

   Segue código para adicionar algumas pessoas (pequena homenagem a alguns amigos visitantes)

            Logo após a ASCII Art do Gremlin o webadmin já carrega a variagel g que representa o gráfico.

Na sequencia usamos a função addVertex para adicionar o primeiro nó. (g.addVertex)

            As properties do nó são passadas como parâmetro (um JSON), que basicamente tem essa estrutura

[Nome_da_Propriedade:Valor_Da_Propriedade, ...]

É interessante notar que diferente do banco relacional que possue um schema fixo de colunas, as propriedades de cada nó podem variar, existindo ou não. Todo noSQL é schemaless.

Para listar os nós, simplesmente use g.V, onde V é a coleção de Vertices dentro do grafico g. A lista exibirá apenas os nós, voce pode pedir para exibir os nomes usando g.V.Nome, ou g.V.Qualquer_propriedade que voce_tenha criado.

Notamos que a profissão do Bruno Salim está com a grafia errada (foi de propósito, juro). Vamos fazer o update então. Note que o ID do nó dele é 28.

Simples assim. Assim como é fácil adicionar novas propriedades. Por Exemplo, no caso do Gustavo que foi adicionado sem uma profissão.

Ou adicionar uma nova propriedade que nem estava na inicialização (essa é a característica do schemaless)

     Aqui o map é uma exibição de todas as propriedades do nó em JSON 

Relacionando os nós

      Agora vamos estabelecer as relações entre os usuários atrávés do relacionamento CONHECE.

Na primeira parte atribuimos os nós a variaveis com nomes mais amigáveis, na segunda adicionamos os relacionamentos(edges) CONHECE entre eles.

Com o Gráfico criado vamos começar a responder algumas consultas típicas das redes sociais e perceber o poder do graph db.

      As consultas do Gremlin são feitas em passos divididos pelo ponto.

Objeto.passo1.passo2.passoN.propriedade

O passo usa o resultado do passo anterior e pode transforma-lo, filtra-lo ou o chamado sideeffect usado para agregações.

Então vamos as consultas!

Quem eu conheço?

      

Quem são os amigos de meus amigos?

    

     Uma forma de evitar o uso do out repetidas vezes é usando ó pasos loop, que repete o passo anterior até que a regra entre colchetes não seja mais satisfeita (no caso limitando a duas vezes o numero de iterações do loop)

Através de quem Felipe pode conhecer Gustavo?

     Essa é uma das mais interessantes propriedades dos graphs, responder esse tipo de pergunta em um modelo relacional é muito dificil e inevitavelmente geraria uma consulta muito pesada e isso seria fatal para uma aplicação web com muitos usuários. A vantagem do graph é que independentemente da quantidade de nós e iterações a resposta para essa pergunta mantém a mesma velocidade.

      

      

     A condição para o loop foi que ele não parasse enquanto não encontrasse o nó referente ao gustavo. Assim ele me apresentou dois caminhos possiveis.

     Podemos também trocar o out por uma combinação de outE (relacionamentos de saida) e inV (para obter os nós) e termos como esses nós se relacionam

     Como existem dois caminhos possiveis     Vamos remover o link entre Spigariol e Gustavo e tentar novamente 

Na primeira linha a identificação do relacionamento, 'g.E' para listar todos os edges, seguido de 'inV' para pegar os nós retornados e 'has' para filtrar aqueles com nome Gustavo. E por fim, um back(2), para exibir os resultados de dois passos atras. (voltando no E).

A remoção e novamente o comando para listar o caminho entre os dois nós.

Conclusão

Fizemos um pequeno tour sobre o que é o GraphDB, quais são as peças que você deve juntar para usá-lo e uma lab "mão na massa" de como criar, apagar e consultar os nós armazenados. Apesar de extenso, esse post está muito longe de ser um tutorial completo, para isso recomendo esse ótimo video tutorial, onde o analista Andreas Kollegger <twitter>;

Enfim obrigado por ler até aqui, se você ficou com alguma dúvida fique a vontade para me encaminhar um email, ou me siga no twitter onde sempre tento postar links e materias interessantes desse nosso maravilhoso mundo dos dados!

Abraços!

Felipe Antunes

Modelagem - NoSQL - Experimentando novos sabores - Introdução

/*
Olá senhores, senhoras e senhoritas DBAs!!!


 Recentemente recebi uma solicitação de um leitor do blog. Ele me pedia uma comparação entre o MS-SQL, Oracle e o DB2, quais são suas características, quais são suas vantagens, o que eles comem, como eles vivem, tudo isso e muito mais no Globo Reporter.

  Infelizmente, caro leitor, para uma analise desse nível eu teria que conhecer profundamente cada uma delas. E teria que ser profundamente pelo simples motivo de que na essência elas são iguais!

  Explico melhor. Tanto Oracle, MS-SQL ou MySQL são bancos de dados relacionais, todos possuem tabelas, chaves primárias e estrangeiras,índices e demais objetos relacionais. A linguagem é padrão (SQL) com acréscimos de funções para diferenciar um fornecedor do outro, mas em teoria, se você conhecer apenas o padrão ANSI já estará qualificado a trabalhar com qualquer uma delas.

  Tenho comigo também que na maioria dos casos tanto faz qual dessas ferramentas você usará, sua escolha estará mais baseada em critérios não técnicos (licenciamento, mão de obra disponível ou cultura organizacional) do que em requisitos específicos da solução que você quer prover.

  De forma que a orientação simples é: Escolha uma que tenha mercado ou aquela que a vida te impôs e fique bom nela, mais tarde e opcionalmente, você pode adicionar outra a sua bagagem e se tornar um DBA bilíngue.

  Agora se você quer ir além do DBA SQL Server e tentar ser um provedor de soluções de plataforma de dados, minha sugestão é dar uma espiadela fora do mundo relacional.

noSQL

  Não vou ficar de histórinha, pois tudo isso já está muito bem definido e explicado na Wikipedia ou em livros sobre o assunto, mas basicamente você deve entender como noSQL um grupo bem diversificado de SGBDs que não usam o modelo relacional, alguns deles, inclusive, nem mesmo possuem as propriedades ACID (atomicidade, consistencia, isolamento e durabilidade) em sua totalidade. E não é porque eles são grandes rebeldes ou querem reinventar a roda, mas sim porque eles podem responder de maneira mais eficiente alguns problemas que são “possíveis mas dolorosos” no modelo relacional.

  Existem vários tipos de bancos NoSQl (key-value, document based, graph, entre outros) e apenas uma vez vi uma solução completamente baseada em um deles, nos outros casos a combinação de SQL e NoSQL é que entregava o pacote completo.

  Estou planejando pelo menos mais um post prático ou quem sabe até uma série sobre esse tipo de banco, então não perca os próximos capítulos!

Abraços!

Felipe Antunes
twitter: @felipe_store
email: fjantunes@gmail.com

Comunidade! - SQL Saturday 127 - Rio de Janeiro!

/*
      Caros senhores, senhoras e senhoritas DBAs!
   

      No ultimo sábado tive o prazer de comparecer ao SQL Saturday 127, um evento da PASS focado em SQL Server.

      Um alto nível técnico, ótimos palestrantes e uma oportunidade de interagir diretamente com a comunidade SQL.

      Como eram três palestras concorrentes por sessão, só pude assistir quatro, mas voce pode conferir a programação completa aqui.

      Segue minhas impressões sobre o evento:

Palesta 1

Dimensionando Hardware e Storage para SQL Server

Com Marcelo Sincic <blog|twitter>

Essa sozinha já me valeu o evento, passei por maus bocados recentemente devido a problemas com I/O e vários itens explicados nessa palestra me ajudaram muito a entender alguns conceitos importantes e me dar uma luz quando o assunto é infra (meu confesso ponto fraco).

Coffe Break:

      Biscoitinhos e suco de cajú… tava bom, mas faltou o café!

Palestra 2

Pontapé inicial em Business Inteligence na Nuvem

Com Diego Nogare <blog|twitter>

      Como o próprio nome da palestra disse, foi um pontapé inicial. O uso de SSIS, SSRS e DataSync no Azure. O destaque aqui foi o modo “No PPT” que o Nogare escolheu para exibir o assunto, fazendo a explicações diretamente na demo.

Lunch Break:

      Um momento estranho, feijão carioca em São Paulo é marrom, mas no Rio, o feijão é preto! Estranho…

Palestra 3

SQL Server 2012: FileTable e Semantic Search

Com Dennes Torres de Oliveira <blog|twitter>

      Uma feature impressionante, o usuário pode jogar um arquivo em um pasta e imediatamente um registro é inserido na FileTable, o usuário remove e o registro desaparece.

      Essa nova “interface” com o banco permite se encaixa como uma luva em sistemas de GED. Vale a pena conferir a apresentação no site da Bufalo.

Coffe Break:

      Café!! Cafééééé…. braaaains…

Palestra 4

SQL Server 2012: AlwaysOn Availability Groups

Com Nilton Pinheiro <blog|twitter>

      Outra feature impressionante. Um serviço instalado, meia duzia de cliques e “tcharam” você tem alta disponibilidade configurada e operando.

      Não é a toa que o AlwaysOn está tão badalado.
      Mas gato escaldado tem medo de agua fria. A coisa é tão fácil que deixa até desconfiado.

Happy Hour:

      Final de evento, satisfação no ar e toca todo mundo pro Buxixo! Paulistas pediram um chopps e dois pastel e o assunto correu do despretesioso papo de boteco até bons debates sobre as novas certificações, distribuição x paralelismo, Oracle e seu mito e como é impossivel achar informação para DB2!

      Enfim, um evento sensacional e que vale muito a pena participar. Obrigado a todos os organizadores, e rumo ao SQL Saturday 147 em Recife! !! Imperdível!
 

Abraços!

Felipe Antunes
Email:fjantunes@gmail.com
Twitter: @felipe_store

*/