[SP-pm] Arquitetura de um projeto que utilizará sistema de fila com

[Daniel Mantovani]

Ah, acabei de sonhar com um ponto crucial, você vai precisar usar DNS Caching. Eu te recomendo o Dnsmasq[1].

Depois preciso fazer um benchmark com DNS Caching e sem usando as API's das redes sociais.

[1] - https://help.ubuntu.com/community/Dnsmasq

Agora vou voltar a dormir, boa noite.

Sent from my iPhone

On 13 Mar 2012, at 23:33, Daniel de Oliveira Mantovani <daniel.oliveira.mantovani em gmail.com> wrote:

> Shonorio, o Gearman não é um sistema de fila, ele funciona como um
> distribuid system.
> 
> Você deva usar o AMPQ[1] ou o Apache ActiveMQ[2] para criar a fila e o
> Gearman para processar a informação. O Worker não sabe da existência
> do Client, quem faz esse intermédio é o Gearman Server[3].
> 
> "A Gearman powered application consists of three parts: a client, a
> worker, and a job server. The client is responsible for creating a job
> to be run and sending it to a job server. The job server will find a
> suitable worker that can run the job and forwards the job on. The
> worker performs the work requested by the client and sends a response
> to the client through the job server. Gearman provides client and
> worker APIs that your applications call to talk with the Gearman job
> server (also known as gearmand) so you don't need to deal with
> networking or mapping of jobs. Internally, the gearman client and
> worker APIs communicate with the job server using TCP sockets. To
> explain how Gearman works in more detail, lets look at a simple
> application that will reverse the order of characters in a string. "
> 
> [User Interface] <===>[RDBMS]<===> [Queue System]
>                                                                  /\
>                                                                  ||
>                                                                  ||
>                                                       [Distribuid
> System] <===> [Document-oriented database]
> 
> 
> Se baseando nesse arquitetura o Queue System vai mandando "jobs" de
> acordo com número de workers que você tem disponível, evitando um
> overhead e criando um sistema "auto scalability".
> 
> Se eu fosse você eu me preocuparia com a forma de armazenamento dos
> dados, as redes sociais já garantem a integridade dos dados, sendo
> assim uma solução Document-oriented database te pouparia muito
> processamento e trabalho. Existem várias opções, eu recomendo o
> MongoDB[4] mesmo com o Eden Cardim me crucificando por isso.
> 
> Guarde os dados dos usuários e do site num RDBMS, se você estiver
> pensando num RDBMS open source eu te recomendo o PostgreSQL, ele tem
> um ótimo suporte ao paradigma temporal.
> Se você usar o PostgreSQL, eu te recomendo usar o Pgpool[5] para
> replication, clustering, load balance etc.
> 
> [1] - http://www.amqp.org/about/what
> [2] - http://activemq.apache.org/
> [3] - http://gearman.org/
> [4] - http://www.mongodb.org/display/DOCS/Sharding+Introduction
> [5] - http://www.pgpool.net/mediawiki/index.php/Main_Page
> 
> Grande Abraço.
> 
> 2012/3/13 Solli Honorio <shonorio em gmail.com>:
>> Pessoal,
>> 
>> Estou iniciando um projeto de monitoramento de mídias sociais e fazer algum
>> processamento com estas informações, e acredito que utilizar esquemas de
>> fila serviria muito bem para este ambiente.
>> 
>> Basicamente o esquema que estou imaginando para o ambiente é :
>> 
>> [ Interface com o usuário ] <===> [Banco de Dados] <====> [Sistema de Fila]
>> 
>>                    ||             ||
>> 
>>                    ||             +- [Executa a pesquisa]
>> 
>>                    ||
>> 
>>                    +-- [ Processa o resultado da pesquisa]
>> 
>> As ações que eu imagino nisto são :
>> 
>> * interface com o usuário não é meu problema, tem um webdeveloper
>> trabalhando nisto;
>> * não quero de maneira alguma fazer os 'agentes' interagir diretamente com o
>> banco de dados, por isto penso em criar um cliente que leia o banco de dados
>> e coloque os dados formatados para o agente na fila do agente. O caminho
>> contrário também, ler o resultado do agente e gravar no banco de dados;
>> 
>> Estou avaliando a possibilidade de utilizar o Gearman (na verdade não tenho
>> certeza se esta é a melhor alternativa mesmo), na verdade o
>>  AnyEvent::Gearman. Mas algumas coisas me chamaram no Gearman do qual eu
>> acho meio estranho para o ambiente sistema de fila que eu tenho na minha
>> cabeça.
>> 
>> 1. o worker (aparentemente o cara que executará o serviço) não fica em loop
>> lendo uma fila, parece que ele está sendo acionado pelo cliente;
>> 2. o parece que o cliente fica 'preso' aguardando o final da execução do
>> worker.
>> 
>> Ainda não tenho código (que o meu cliente não leia isto, pois estou muito
>> atrasado), mas eu gostaria de obter recomendações de vocês sobre a
>> arquitetura que estou imaginando.
>> 
>> Obrigado,
>> 
>> Solli Honorio
>> 
>> 
>> --
>> "o animal satisfeito dorme". - Guimarães Rosa
>> 
>> =begin disclaimer
>>   Sao Paulo Perl Mongers: http://sao-paulo.pm.org/
>>  SaoPaulo-pm mailing list: SaoPaulo-pm em pm.org
>>  L<http://mail.pm.org/mailman/listinfo/saopaulo-pm>
>> =end disclaimer
>> 
> 
> 
> 
> -- 
> "If you’ve never written anything thoughtful, then you’ve never had
> any difficult, important, or interesting thoughts. That’s the secret:
> people who don’t write, are people who don’t think."