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

[Solli Honorio]

Mantovani,

Muito obrigado pela resposta, e antes de qualquer coisa me senti muito
orgulho de ver a qualidade da tua resposta. Você razão, eu comi uma enorme
bola e estava esquecendo do sistema de fila de verdade. Não sei dizer o
motivo, mas em algum momento fiz confusão e apaguei o RabbitMQ que estou
planejando, e aí não iria funcionar mesmo.

Sobre o banco de dados, isto não é um problema meu. Tem outra pessoa sendo
muito bem paga para isto e é ele quem vai ter que sofrer com este assunto
:D.

Enorme abraço,

Solli Honorio

Em 13 de março de 2012 23:33, Daniel de Oliveira Mantovani <
daniel.oliveira.mantovani em gmail.com> escreveu:

> 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."
> =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
>



-- 
"o animal satisfeito dorme". - Guimarães Rosa
-------------- Pr?xima Parte ----------
Um anexo em HTML foi limpo...
URL: <http://mail.pm.org/pipermail/saopaulo-pm/attachments/20120314/1ddae7b5/attachment.html>