Arquivo da tag: http

A arquitetura do SpiderDuck em detalhes: o novo serviço de processamento de links do Twitter

O SpiderDuck, é um novo serviço do Twitter para gerenciar e otimizar o processamento em tempo real de URLs inseridos em tweets. Foi projetado com 6 componentes principais, distribuindo a responsabilidade de consultar, processar e armazenar as informações das URLs. A arquitetura do sistema tem o foco em reduzir o tempo de resposta e a latência do tráfego de dados, além de permitir o aumento em escala conforme o crescimento da demanda.

Links em tweets devem ser processados pelo Twitter quanto ao tipo e a relevância do conteúdo referenciado. Caso a URL aponte para uma foto ou vídeo, por exemplo os aplicativos do lado do cliente (web, mobile etc.) precisam apresentar a mídia correspondente junto ao texto do tweet. Os links também são processados pelo módulo de segurança, que verifica a presença de malware no endereço referenciado, entre outras coisas, e os “Tweet Buttons” contabilizam o número de compartilhamentos de cada link.

Antes do SpiderDuck o Twitter usava um serviço mais simples para análise de URLs compartilhadas, fazendo requisições via HEAD e eventuais redirecionamentos. Mas essa solução apresentava algumas limitações:

O serviço resolvia o endereçamento da URL, mas não realizava o download do conteúdo. As informações sobre a resolução da URL não eram persistidas em disco, permanecendo apenas em memória, no cache. Caso uma instância do cache ficasse fora do ar, os dados seriam perdidos.

O serviço também não leva em conta regras para bots modernos, como limitação da taxa de transferência; também não seguia diretivas do controlador de buscas de robots (robots.txt).

O time de engenheiros do Twitter chegou à conclusão que seria necessário desenvolver um serviço mais sofisticado para processamento de URLs, que atendesse à necessidade da empresa no longo prazo:

Nossa primeira ideia foi construir o sistema em cima de um crawler existente, que fosse open source. Mas percebemos que todos os crawlers disponíveis possuem duas características de que não precisávamos: os crawlers realizam a leitura de URLs de forma recursiva o que aumenta sua complexidade; além disso, são otimizados para a leitura em grande escala, e precisávamos de algo mais leve, capaz de fazer a leitura de URLs em tempo real. Decidimos então criar um novo sistema que atendesse às necessidades específicas do Twitter.

O SpiderDuck utiliza algumas soluções open source já adotadas em outros serviços do Twitter, como o agregador de conteúdo Scribe; o Finagle, um protocolo RPC criado para realizar o tráfego intenso de dados; e o Twitter Commons, um conjunto de bibliotecas que opera sobre a JVM.

Arquitetura

A arquitetura do SpiderDuck é modular (veja a figura), o que contribui para a escalabilidade do serviço.

Componentes do SpiderDuck (fonte: Twitter)

O SpiderDuck é composto por seis módulos principais:

  • Kestrel. Sistema de mensageria utilizado no Twitter para enfileiramento dos tweets mais recentes. O Kestrel é o ponto de partida do SpiderDuck, assim que recebe um tweet contendo uma URL, solicita a busca das informações dessa URL para outro módulo, o Scheduler.
  • Schedulers. Determinam se a busca do conteúdo da URL deve ser agendada ou não, e caso necessário faz o redirecionamento da URL. Esse módulo realiza o parse e o download do conteúdo, extrai os metadados e armazena toda essa informação em duas estruturas de armazenamento do sistema, o Metadata Store e o Content Store. Cada schedule trabalha de forma independente, permitindo que novos schedulers sejam adicionados, favorecendo a escalabilidade horizontal do sistema.
  • Fetchers. Componente que realiza a requisição HTTP em busca do conteúdo da URL. São implementados com servidores Thrift, com inteligência para tratar os limites de taxa de transferência e reconhecer as diretivas do controlador de buscas via bots, resolvendo umas das principais limitações da solução anteriormente usada.
  • Memcached. Um cache distribuído utilizado pelo Fetcher para armazenar temporariamente as informações dos arquivos robots.txt.
  • Metadata Store. Distribuição customizada do Cassandra que permite armazenar informações sobre a resolução e os metadados da URL. Essas informações são mantidas em uma tabela de hash, utilizando a URL como chave. O repositório é utilizado pelos aplicativos cliente do Twitter, para consumir informações da URL em tempo real.
  • Content Store. Um cluster com Hadoop Distributed File System (HDFS), um sistema para replicação de dados distribuídos extremamente rápido, que formam o repositório com o conteúdo de todas as URLs processadas.

Performance

A separação entre o Schedulers e os Fetchers permite que múltiplos tweets com a mesma URL sejam processados somente uma vez. Isso reduz a latência e aumenta a velocidade no processamento. Veja o que dizem sobre isso os engenheiros do projeto:

O SpiderDuck processa centenas de URLs a cada segundo, e o Metadata Store trata perto de 10 mil requisições por segundo. Normalmente cada requisição é realizada para uma URL especifica, sendo possível uma requisição para um lote de até 300 URLs ao mesmo tempo.

Para processar uma nova URL, que ainda não foi armazenada pelo SpiderDuck, partindo da criação do tweet e indo até a requisição externa e o armazenamento dos dados, o sistema gasta em média cinco segundos de processamento. A maior parte desse tempo é consumida no Fetcher, no momento em que o sistema extrai as informações da URL em um site externo.

Quando um novo tweet menciona uma URL que foi armazenada pelo SpiderDuck, o tempo para processar as informações da URL se reduz para dois segundos em média. Ou seja, uma aplicação cliente do Twitter tem de esperar por dois segundos para obter todas as informações da URL. E boa parte das 10 mil requisições por segundo recebidas pelo Metadata Store trata de consultas que em média, levam de quatro a cinco milissegundos de processamento.

Integração

Os serviços do Twitter consomem dados do SpiderDuck de várias maneiras; a mais frequente é a busca de informações complementares (metadados e resolução) da URL no Metadata Store. Outros serviços acessam os logs do SpiderDuck no HDFS para agregar informações utilizadas pelos sistemas de analise e métricas internas, o dashboard do Twitter.

No SpiderDuck serviços não solicitam o processamento de uma URL. O próprio sistema resolve e processa o conteúdo das URLs de tweets recentes. Após processar as URLs o sistema disponibiliza as informações para consumo dos serviços.

Conclusões


Uma forma efetiva para gerenciar URLs é apenas um dos desafios da do Twitter, que vem fazendo muanças constantes em arquitetura e tecnologias (como já reportamos aqui). Através do blog de engenharia do Twitter e da conta @twittereng, os engenheiros do Twitter compartilham um pouco sobre esses desafios, apresentando informações e estratégias relacionadas a arquitetura do serviço.

Fonte: Eder Magalhães/InfoQ

Como usar declarações e tags condicionais em PHP no WordPress

Para quem desenvolve temas WordPress, ou tem curiosidade em melhorar a qualidade do seu template, alterando o código dos arquivos para torná-lo mais funcional e ao mesmo tempo mais simples de usar, umas das estratégias a se pensar são as declarações condicionais e as tags do PHP. Recentemente, os colegas do wptuts falaram sobre esse assunto e deram alguns exemplos práticos bem interessantes para quem ainda não usa esse tipo de declarações e tags de PHP. O objetivo é que você possa aproveitar ao máximo os recursos do WordPress.

As declarações condicionais são extremamente poderosas e podem ajudá-lo a realizar uma série de ações no WordPress de forma extremamente simples e direta. Com uma utilização inteligente dessas declarações de PHP, você pode conseguir puxar muita informação e funcionalidades com o seu WordPress. Usando as declarações condicionais conjuntamente com as tags condicionais do WordPress, você consegue encontrar determinados textos, ou fazer com que uma determinada imagem apareça apenas em uma página específica. Dessa forma, não há a necessidade de criar novas páginas, ou templates para o efeito.

Compreender as declarações condicionais

Provavelmente, você já ouviu falar das declarações “if”, que, basicamente, definem que, se uma coisa for igual ou diferente de outra, uma ação acontece. Essa é uma declaração condicional do PHP, que é usada pelos arquivos de Temas WordPress, juntamente com algumas funções internas da plataforma, para definir a lógica e informar como os conteúdos devem ser apresentados, de acordo com os critérios definidos, a base de dados do WordPress. Essas declarações são extremamente importantes para, por exemplo, criar hierarquias nos templates.

Uma declaração condicional simples seria algo deste gênero:

<?php if ( ) { ?>......<?php  } ?>

A seguinte declaração pode ser lida, basicamente, desta forma: “Se (if) alguma coisa acontecer = fazer alguma coisa”. Os critérios “acontecer” e “fazer” serão definidos, obviamente, por si. Você pode usar este gênero de declarações “if” dentro do WordPress sempre que desejar e sem qualquer tipo de restrição. O WordPress tem, também, um conjunto de declarações próprias que você pode usar.

As tags condicionais do WordPress

Existem diferentes tipos de tags condicionais dentro das declarações condicionais. Esse tipo de tag busca uma informação específica no banco de dados do WordPress e é definido por diferentes itens na plataforma, como, por exemplo, posts, tags, textos, imagens, categorias, entre outros.

Eis as tags condicionais mais populares do WordPress:

  • is_page() – Ela é usada para atribuir uma determinada condição a uma das suas páginas específicas, como, por exemplo, a sua página “Contatos”. Você pode usá-la para se referir a essa página em concreto, usando o ID da página no banco de dados, o título, ou o slug/nome;
  • is_category() – Usada para atribuir uma determinada condição a uma das suas categorias específicas, como, por exemplo, a sua categoria “Revistas”. Você pode usar esta tag para se referir a essa categoria em concreto, usando o ID da categoria no banco de dados, o título, ou o slug/nome;
  • is_home() – Esta tag é usada para se referir à homepage do seu site/ blog;
  • is_single() – Esta tag é usada para se referir a blogs de uma única página, artigos singulares, ou anexos;
  • is_tag() – Esta tag é usada para se referir a arquivos de tags específicas. Trabalha de forma similar à tag condicional de categorias;
  • is_archive() – Esta tag é usada para se referir a páginas de arquivos;
  • is_search() – Esta tag é usada para se referir à página de resultados de pesquisas internas;
  • is_404() – Esta tag é usada para se referir à página de erro HTTP 404;
  • is_author() – Esta tag é usada para se referir à página de arquivos do Autor;
  • is_comments_popup() – Esta tag é usada para se referir a um Popup de comentários.

Você pode ver a lista completa de tags condicionais no Codex do WordPress. Para tornar a compreensão mais fácil, por que não testarmos alguns exemplos?

Conteúdos diferentes em várias páginas

Imagine que você gostaria de mostrar uma imagem na sua primeira página, não mostrar nada na segunda, e mostrar um texto na terceira página. Obviamente, neste exemplo, você poderá trocar as páginas por casos reais, como as suas páginas de “Publicidade”, “Contatos”, “Sobre”, ou outras que desejar. O princípio aplica-se da mesma maneira.

<?php  if ( is_page('First_Page') ) { ?>
<img src="imagem_aqui.gif" />
<?php  } elseif ( is_page('Third_Page') ) { ?>
<p>Algum texto aqui….</p>
<?php  } else { ?>
<?php  } ?>

Estes códigos devem ser inseridos no artigo page.php, onde você deseja que o conteúdo seja apresentado.

Esta é uma declaração multi-condicional (veja a utilização de múltiplos recursos, como o “if, elseif, else…”). Este código vai procurar as páginas corretas e depois, utilizando as tags condicionais, mostrar a informação de acordo com o especificado. Você pode usar condições ilimitadas em um só código. Se você usar a declaração is_page(array(‘First_Page’,’Second_Page’)), você pode mostrar o mesmo conteúdo nas três páginas em simultâneo, por exemplo.

Mostrar um texto em um post ou em uma categoria

Aqui, você vai usar o símbolo “||” para mostrar algo, caso uma das condições seja cumprida. Se nenhuma das condições for cumprida, ele não vai mostrar nada.

<?php  if is_category(Category_Page) ) || ( is_single(Single_Page)  { ?>
<p>Mostrar texto aqui….</p>
<?php  } else { ?>
<?php  } ?>

Normalmente, nós usamos o símbolo “||” para verificar se alguma das condições foi cumprida. Alternativamente, poderemos usar o símbolo “&&” para criar uma condições do tipo E (algo E algo), em que ambas as condições têm de ser cumpridas para que o item seja apresentado visualmente ao usuário. O símbolo “!” é usado, normalmente, para excluir algo da lista. Veja este exemplo: !( is_page(Excluded_PageName)). Com este código, excluímos uma determinada página da equação automaticamente.

Verificar se um thumbnail (miniatura) para o artigo foi carregado

Este código verifica se foi carregada uma imagem de thumbnail (miniatura) para o artigo e, caso não tenha sido, ele carrega uma imagem alternativa.

<?php  if(posted_thumbnail()) {
show_thumbnail();
}  else {?>
<img src="<?php  bloginfo('template_directory');?>/images/default_Image.gif" alt="Image not Displayed">
<?php  }?>

Estas tags condicionais, e as próprias declarações condicionais, podem servir para tirar o máximo proveito do WordPress através de códigos super práticos – quando usadas com maestria.

Fonte: Paulo Faustino/InfoQ

Um olhar sobre alguns bancos de dados NoSQL

Em um artigo anterior, falei sobre o NoSQL e algumas ferramentas para serem usadas com ele. Neste artigo, daremos uma olhada no MongoDB, no Redis e no Riak.

MongoDB

O MongoDB combina o melhor dos armazenamentos chave-valor, documentos de bancos de dados, bancos de dados (ou database?) de objeto e sistemas de gerenciamento de bancos de dados relacionais (RDBMS). Isso significa que o MogoDB executa o sharding automaticamente (como com armazenamentos chave-valor), permite documentos de schema dinâmicos baseados em JSON, e oferece uma rica linguagem de query na forma de RDBMS. Além disso, o MongoDB oferece auto-sharding (o sharding de dados novos e pré-existentes é feito automaticamente) e um recurso de implementação MapReduce. Dê uma olhada mais de perto no cluster MongoDB, e você verá que ele é feito de vários tipos de servidores:

  • Servidores shard que armazenam dados
  • Servidores de configuração que armazenam a configuração
  • Servidores router que recebem e roteiam as solicitações
  • Uma thread de servidor usando MapReduce

Alguns fatos adicionais sobre MongoDB: é uma ferramenta de armazenagem distribuída orientada a documentos e usa a linguagem de implementação C++. Com o progresso do schema, documentos do tipo JSON são armazenados, e schemas dinâmicos podem ser usados. Entre as companhias que usam o MongoDB encontramos: Shutterfly, Evite e The New York Times. Impressionante! Uma das coisas bacanas das quais gosto a respeito desse produto é a existência de uma interface web bastante boa, que permite testar o MongoDB em seu browser – mas usando uma shell JavaScript.

Redis

O Redis não é um simples armazenamento chave-valor, porque suporta uma variedade de valores em diferentes estruturas de dados, tais como listas e conjuntos de binary-safe strings, bem como conjuntos ordenados, que contêm uma pontuação de números float. No ano passado, o VMWare se tornou patrocinador do Redis. Ele possui uma orientação chave-valor, e sua linguagem de implementação é ANSI C. Entretanto, o Redis não é distribuído. Sob seu schema, Redis oferece um armazenamento chave-valor, usando um nome-chave de servidor para armazenar e recuperar valores. Como MongoDB, o Redis tem uma lista impressionante de clientes – incluindo Python, Twisted Python e a nova linguagem do Google, Go. O Redis é open source, e há uma página muito bacana que oferece um tutorial Redis que permite experimentá-lo diretamente de seu browser usando JavaScript. Descubra-a em http://try.redis-db.com.

Basho Riak

Riak é um banco de dados híbrido fabricado pela BashoTecnologies, mas é baseado no Amazon Dynamo. Funciona como um banco de dados (tradução de database?) orientado para documentos, e também com um armazenamento chave-valor distribuído. É tolerante a falhas e faz escalas linearmente. É direcionado para uso em aplicativos web. Como o Cassandra, não tem um controlador central, e assim não tem um ponto único de falhas. O Riak é um armazenamento de chaves/valor plenamente distribuído, e implementa o MapReduce. O design do Riak inclui três elementos básicos: buckets, chaves e valores. Os dados são organizados em buckets, que são pouco mais do que flat namespaces para agrupar logicamente pares chave/valor. Os buckets podem armazenar os dados diretamente ou através de links para outro bucket. Todos os nós no cluster têm o mesmo papel. O sharding de dados (existentes ou novos) é feito automaticamente entre os nós. O Riak vem tanto em versão comercial quanto em versão open source. Roda em Unix, mas não em sistemas Windows. Ele é distribuído, um sistema tanto de documento quanto de armazenamento chave-valor, e sua linguagem de implementação é Erland, juntamente como alguma coisa de C e de JavaScript. O Riak tem uma estrutura simples e não usa tipos de dados específicos. Os valores associados às chaves são objetos. O Riak interage com clientes via JSON sobre a interface HTTP; tem drivers para Erlang, Python, Java, PHP, JavaScript e Ruby; e, finalmente, uma interface de cliente que suporta o Protocol Buffers, do Google. A base de clientes do Riak inclui a Comcast.

Texto original disponível em: http://blog.monitis.com/index.php/2011/06/06/a-look-at-some-nosql-databases-mongodb-redis-and-basho-riak/

Fonte: Mikayel Vardanyan/Imaster

Ruby on Rails 3.1 está disponível

David Heinemeier Hansson, criador do framework web Ruby on Rails, anunciou que a versão 3.1 do Rails já está disponível. Essa última versão do Rails traz uma grande gama de melhorias ao framework, como o “asset pipelining”, que torna o gerenciamento e uso de código JavaScript e CSS mais simples e eficiente promovendo-os como “cidadãos de primeira classe” em um projeto Rails, streaming HTTP, que envia previamente folhas de estilo e código JavaScript ao navegador enquanto o servidor está construindo uma resposta, e a alteração da biblioteca padrão JavaScript, de Prototype para jQuery.

Outras melhorias incluem migrações reversíveis, um mapa de identidade criado por demanda para a recuperação rápida de registros, além de numerosas mudanças no Action Pack, Active Record, Active Model, Active Resource e Active Support. Detalhes completos dessas mudanças podem ser encontradas nas notas de lançamento.

O Ruby on Rails 3.1 pode ser baixado diretamente do repositório GitHub, o framework está licenciado sob uma licença MIT.

Fonte: H-online

Desenvolvedores repensam banco de dados na nuvem

Fornecedores como NimbusDB, Xeround, ParAccels e Cloudant estão criando soluções para gerenciar grandes volumes de informações em cloud.

Diversas companhias estão desenvolvendo novas tecnologias de banco de dados para resolver a deficiência de seus sistemas para gerenciar informações no ambiente de cloud computing.

Quatro delas contaram como estão realizando esse trabalho durante um painel na conferência Estrutura GigaOm, realizada esta semana em São Francisco (EUA), para debater a infraestrutura para cloud computing. São elas: NimbusDB, Xeround, ParAccels e Cloudant.

O problema básico que essas empresas estão tentando resolver é a dificuldade de escalonamento dos bancos de banco de dados em sistemas em clusters com servidores x86. Executivos das quatro fornecedoras disseram que precisam fazer com que esse ambiente seja elástico para aumentar ou reduzir o processamento de acordo com a demanda por processamento.

“O problema essencial, a meu ver, é que os atuais sistemas de gestão de banco de dados relacional não são escaláveis, disse Jim Starkey, arquiteto sênior do banco de dados de código aberto MySQL.

Starkey é fundador e CTO da NimbusDB, que está tentando resolver esse problema com o desenvolvimento de uma tecnologia que adota a linguagem de consulta padrão SQL.

O software da NimbusDB permite que um grande número de bancos de dados seja gerenciado automaticamente em um ambiente distribuído. Starkey diz que os desenvolvedores devem ser capazes de começar pequeno, desenvolvendo uma aplicação em uma máquina local, e depois transferir o seu banco de dados para uma nuvem pública, sem precisar colocá-lo offline.

A NimbusDB ainda está em estágio inicial desse trabalho e Starkey não informou data de entrega da solução. A empresa espera fornecer o software de graça.

Com o mesmo objetivo, a Xeround está tentando resolver o problemas com uma solução em MySQL. A versão beta conta com cerca de 2 mil clientes, segundo informou o CEO da companhia, Razi Sharir. O software quer oferecer a elasticidade da nuvem, com mesma a familiaridade da codificação do SQL.

“Somos um banco de dados distribuído que funciona na memória, que se divide em vários nós virtuais e vários centros de dados e serve muitos clientes ao mesmo tempo”, disse Sharir. Ele afirmou que a escala e a elasticidade são tratadas pelo serviço automaticamente.

O serviço da Xeround já está disponível na Europa e EUA, fornecido por provedores de cloud, incluindo Amazon e Rackspace.

Sharis oberva que que os clientes do banco de dados em nuvem, em geral, precisam executar suas aplicações no mesmo centro de dados, ou próximos uns dos outros, por razões de desempenho.

Grandes volumes de dados

Diferentemente da solução da Xeround, o software da ParAccel foi projetado para executar cargas de trabalho de análise em grandes bancos de dados distribuído, em torno 25 TB, infomou o CTO da companhia, Barry Zane.

“Somos o resumo dos grandes dados”, diz Zane. Clientes da ParAccel são empresas que dependem da análise de grande quantidade de dados, incluindo serviços financeiros, companhias de publicidade e de varejo online.

A Interclick recorreu à ParAccel para realizar análises demográficas de dados para permitir que empresas de publicidade online saibam quais anúncios devem mostrar aos usuários finais. A companhia roda um banco de dados de cerca de 2TB em um cluster de 32 nós. Outros clientes com conjuntos de dados maiores usam uma arquitetura baseada em disco.

A ParAccel também permite que desenvolvedores façam consultas no SQL, mas com extensões para que eles possam usar a estrutura MapReduce, software que faz a distribuição e a análise de uma enorme quantidade de dados.

“SQL é uma linguagem realmente poderosa, é muito fácil de usar para ações incrivelmente sofisticadas, mas claro que também há uma série de atividades que não pode realizar”, avalia Zane.

Já a Cloudant, que produz software para nuvens privadas e públicas, foi a única empresa que afirmou durante o painel estar desenvolvendo um banco de dados “não SQL”. A solução foi projetada para gerenciar tanto dados estruturados como não estruturados, e ainda para encurtar o “ciclo de vida de aplicativos”, disse o cofundador e cientista-chefe Mike Miller.

“Aplicativos não têm de passar por uma fase complexa de modelagem de dados”, afirma Miller. A interface de programação é HTTP. “Isso significa que você pode se inscrever e começar a conversar com o banco de dados de um navegador e construir aplicativos dessa maneira. Estamos tentando torná-lo mais fácil de implementar.”

Desafios do hardware

Enquanto bancos de dados em nuvem podem resolver problemas de escala, também apresentam novos desafios, reconhecem os palestrantes. A qualidade do servidor na nuvem pública é “muitas vezes um problema”, afirma Zane da ParAccels. Por isso, as empresas para quem a alta velocidade de análise é crítica, podem optar por comprar e gerenciar seu próprio hardware.

E enquanto muitos prestadores de serviços alegam não acreditar na nuvem, a realidade é muitas vezes diferente, diz Miller. Fornecedores de software em nuvem precisam realizar “uma engenharia reversa” para descobrir o que as arquiteturas de serviços como a Amazon EC2 possuem “por trás da cortina”, a fim de obter o máximo desempenho do software de banco de dados.

Fonte: Computerworld