Sobre o projeto de vcs

[matzenh]

Pessoal,

Usei a alguns anos atras o Zope para fazer pequenas aplicações usando o mysql. Gostaria de saber de vcs, hoje, em seus projetos vcs utilizam mais o postgres, mysql ou o próprio zodb?

Um abraço.

[Vanderson Mota dos Santos]

Eu e uns colegas fizemos um sistema com Zope3 + Grok utilizando o próprio ZODB.

Até hoje não utilizei nenhum BD relacional com o zope.


[]'s
2009/7/31 matzenh <[hidden email]>:

>
>
> Pessoal,
>
> Usei a alguns anos atras o Zope para fazer pequenas aplicações usando o
> mysql. Gostaria de saber de vcs, hoje, em seus projetos vcs utilizam mais o
> postgres, mysql ou o próprio zodb?
>
> Um abraço.
>
>

--
Vanderson Mota dos Santos

[Pablo Santos]

2009/7/31 matzenh <[hidden email]>:
>
>
> Pessoal,
>
> Usei a alguns anos atras o Zope para fazer pequenas aplicações usando o
> mysql. Gostaria de saber de vcs, hoje, em seus projetos vcs utilizam mais o
> postgres, mysql ou o próprio zodb?
>
> Um abraço.


Acredito que isso dependa muito do tipo de projeto.

Quando estamos falando de gestão de conteúdo, muitos usam Plone e
nesse caso usam o próprio ZODB para guardar o conteúdo. Se o volume
for grande, prefiro que apenas a aplicação fique no ZODB e o conteúdo
em algum banco relacional, pois tenho experiências traumáticas com
arquivos data.fs com tamanho na ordem de gigabytes.

Se pensarmos em sistemas de gestão empresarial, prefiro que os dados
fiquem em algum banco relacional: mais pela questão de facilidade de
extração de dados ou integração com outros sistemas / processos que
qualquer outra coisa. ;-)

Sobre banco de dados, parei de trabalhar com MySQL na versão 4.0,
quando passei a usar o PostgreSQL. Postgres é estável e aguenta um
volume de dados considerável: estou usando-o em um projeto onde há
tabelas com mais de 10 milhões de registros e ele está aguentando
muito bem.

[]'s
Pablo

[matzenh]

Obrigado pelas respostas...

Aproveitando, qual seria as limitações do ZODB? Pelo que ja foi falado, o grande volume de dados, mais algum?

[Alexandre Marinho-2]

Acredito que a grande quantidade de dados não seja uma limitação do ZODB,
usando corretamente o catalogo e so "acordando" os objetos quando for
estritamente necessário... o único problema será o tamanho do Data.fs que
realmente pode chegar em gigas.

Á unica situação em que usei uma base relacional foi quando precisava fazer
soma e agrupamento de valores. Ai era mais fácil utilizar SQL no lugar do
ZODB.

--
Alexandre Marinho
http://alexandre.cuboestudioweb.com


2009/7/31 matzenh <[hidden email]>

> Obrigado pelas respostas...
>
> Aproveitando, qual seria as limitações do ZODB? Pelo que ja foi falado, o
> grande volume de dados, mais algum?
>
>
>
> ------------------------------------
>
> Para enviar uma mensagem: [hidden email]
> Para desistir envie uma mensagem em branco para:
> [hidden email] do Yahoo! Grupos
>
>
>

[lucmult]

2009/7/31 Alexandre Marinho <[hidden email]>

>
>
> Acredito que a grande quantidade de dados não seja uma limitação do ZODB,
> usando corretamente o catalogo e so "acordando" os objetos quando for
> estritamente necessário... o único problema será o tamanho do Data.fs que
> realmente pode chegar em gigas.
>

Concordo que podemos ter o ZODB mesmo em casos com muitos dados, as vezes
temos que tomar alguns cuidados, mas toda aplicação grande precisa de
cuidados, mesmo em base relacional.


>
> Á unica situação em que usei uma base relacional foi quando precisava fazer
> soma e agrupamento de valores. Ai era mais fácil utilizar SQL no lugar do
> ZODB.
>

Eu fiz um produto que pode-se utilizar para fazer o agrupamento, ai não
precisei usar SQL \o/

http://pypi.python.org/pypi/collective.pivottable

Sobre utilizar o SQL, eu acho tão simples e eficiente utilizar o ZODB que
prefiro ficar com ele, eu usava muito SQL em outros tipos de aplicação, mas
é tão bom viver sem ele. :-)

Até mais,
--
Luciano Pacheco
Simples Consultoria
www.simplesconsultoria.com.br

[Rodrigo Castardo]

Fala pessoal.

Bom, o Pablo respondeu mto bem e sobra pouco pra falar.

A nossa visão aqui é não misturar alhos com bugalhos.

Onde alhos e bugalhos seriam respectivamente gerenciamento de conteúdo
e aplicações. Gerenciamento de conteúdo vai muito bem com ZODB, já
aplicações nem tanto. Por exemplo, se você for fazer uma aplicação que
lida com transações financeiras use um banco relacional.

Em casos onde mesmo a informação de conteúdo de um portal é grande,
você tem artifícios como o FSS[1] e o Catalog mencionado pelo Marinho.
Como no caso do pessoal da EBC (antiga RADIOBRAS), eles tem as
notícias todas em ZODB (e estamos falando de uns 10G pelo menos) e os
infográficos (imagens em alta, vídeos, flash, etc...) estão todos em
File System (na época somavam 40G).

Com os binários em FS você pode trabalhar mais tranquilo com o ZODB. É
a mesma coisa que fazemos com streaming por exemplo, os vídeos estão
em FS e o conteúdo todo em ZODB.

Abraços.

[1] http://plone.org/products/filesystemstorage

2009/7/31 Luciano Pacheco <[hidden email]>:

>
>
> 2009/7/31 Alexandre Marinho <[hidden email]>
>>
>>
>> Acredito que a grande quantidade de dados não seja uma limitação do ZODB,
>> usando corretamente o catalogo e so "acordando" os objetos quando for
>> estritamente necessário... o único problema será o tamanho do Data.fs que
>> realmente pode chegar em gigas.
>
> Concordo que podemos ter o ZODB mesmo em casos com muitos dados, as vezes
> temos que tomar alguns cuidados, mas toda aplicação grande precisa de
> cuidados, mesmo em base relacional.
>
>>
>> Á unica situação em que usei uma base relacional foi quando precisava
>> fazer soma e agrupamento de valores. Ai era mais fácil utilizar SQL no lugar
>> do ZODB.
>
> Eu fiz um produto que pode-se utilizar para fazer o agrupamento, ai não
> precisei usar SQL \o/
>
> http://pypi.python.org/pypi/collective.pivottable
>
> Sobre utilizar o SQL, eu acho tão simples e eficiente utilizar o ZODB que
> prefiro ficar com ele, eu usava muito SQL em outros tipos de aplicação, mas
> é tão bom viver sem ele. :-)
>
> Até mais,
> --
> Luciano Pacheco
> Simples Consultoria
> www.simplesconsultoria.com.br
>
>

--



--
Rodrigo Castardo
Liberiun
COO
[hidden email]
[phone]
[phone]

[Marcus Fazzi (Anunakin)]

Aqui a única aplicação que usa o ZODB é o plone e mais nada, todas as outras
são em mySQL, msSQL, Oracle e Postgres....

2009/7/31 Rodrigo Castardo <[hidden email]>

>
>
> Fala pessoal.
>
> Bom, o Pablo respondeu mto bem e sobra pouco pra falar.
>
> A nossa visão aqui é não misturar alhos com bugalhos.
>
> Onde alhos e bugalhos seriam respectivamente gerenciamento de conteúdo
> e aplicações. Gerenciamento de conteúdo vai muito bem com ZODB, já
> aplicações nem tanto. Por exemplo, se você for fazer uma aplicação que
> lida com transações financeiras use um banco relacional.
>
> Em casos onde mesmo a informação de conteúdo de um portal é grande,
> você tem artifícios como o FSS[1] e o Catalog mencionado pelo Marinho.
> Como no caso do pessoal da EBC (antiga RADIOBRAS), eles tem as
> notícias todas em ZODB (e estamos falando de uns 10G pelo menos) e os
> infográficos (imagens em alta, vídeos, flash, etc...) estão todos em
> File System (na época somavam 40G).
>
> Com os binários em FS você pode trabalhar mais tranquilo com o ZODB. É
> a mesma coisa que fazemos com streaming por exemplo, os vídeos estão
> em FS e o conteúdo todo em ZODB.
>
> Abraços.
>
> [1] http://plone.org/products/filesystemstorage
>
> 2009/7/31 Luciano Pacheco <[hidden email] <lucmult%40gmail.com>>:
> >
> >
> > 2009/7/31 Alexandre Marinho <[hidden email] <lyralemos%40gmail.com>
> >
> >>
> >>
> >> Acredito que a grande quantidade de dados não seja uma limitação do
> ZODB,
> >> usando corretamente o catalogo e so "acordando" os objetos quando for
> >> estritamente necessário... o único problema será o tamanho do Data.fs
> que
> >> realmente pode chegar em gigas.
> >
> > Concordo que podemos ter o ZODB mesmo em casos com muitos dados, as vezes
> > temos que tomar alguns cuidados, mas toda aplicação grande precisa de
> > cuidados, mesmo em base relacional.
> >
> >>
> >> Á unica situação em que usei uma base relacional foi quando precisava
> >> fazer soma e agrupamento de valores. Ai era mais fácil utilizar SQL no
> lugar
> >> do ZODB.
> >
> > Eu fiz um produto que pode-se utilizar para fazer o agrupamento, ai não
> > precisei usar SQL \o/
> >
> > http://pypi.python.org/pypi/collective.pivottable
> >
> > Sobre utilizar o SQL, eu acho tão simples e eficiente utilizar o ZODB que
> > prefiro ficar com ele, eu usava muito SQL em outros tipos de aplicação,
> mas
> > é tão bom viver sem ele. :-)
> >
> > Até mais,
> > --
> > Luciano Pacheco
> > Simples Consultoria
> > www.simplesconsultoria.com.br
> >
> >
>
> --
>
> --
> Rodrigo Castardo
> Liberiun
> COO
> [hidden email] <rodrigocastardo%40liberiun.com>
> [phone]
> [phone]
>  
>

--
Marcus Fazzi
オープンソースコード いきかた!
http://anunakin.blogspot.com/
http://www.vivaphp.net

[Wagner Francisco]

Pergunta de iniciante: quando esse arquivo (data.fs) cresce demais, não
existem alternativas pra isso? E quão grande o arquivo precisa ser para
realmente ser um problema?

Obrigado!


2009/8/3 Marcus Fazzi (Anunakin) <[hidden email]>

>
>
> Aqui a única aplicação que usa o ZODB é o plone e mais nada, todas as
> outras são em mySQL, msSQL, Oracle e Postgres....
>
> 2009/7/31 Rodrigo Castardo <[hidden email]>
>
>
>>
>> Fala pessoal.
>>
>> Bom, o Pablo respondeu mto bem e sobra pouco pra falar.
>>
>> A nossa visão aqui é não misturar alhos com bugalhos.
>>
>> Onde alhos e bugalhos seriam respectivamente gerenciamento de conteúdo
>> e aplicações. Gerenciamento de conteúdo vai muito bem com ZODB, já
>> aplicações nem tanto. Por exemplo, se você for fazer uma aplicação que
>> lida com transações financeiras use um banco relacional.
>>
>> Em casos onde mesmo a informação de conteúdo de um portal é grande,
>> você tem artifícios como o FSS[1] e o Catalog mencionado pelo Marinho.
>> Como no caso do pessoal da EBC (antiga RADIOBRAS), eles tem as
>> notícias todas em ZODB (e estamos falando de uns 10G pelo menos) e os
>> infográficos (imagens em alta, vídeos, flash, etc...) estão todos em
>> File System (na época somavam 40G).
>>
>> Com os binários em FS você pode trabalhar mais tranquilo com o ZODB. É
>> a mesma coisa que fazemos com streaming por exemplo, os vídeos estão
>> em FS e o conteúdo todo em ZODB.
>>
>> Abraços.
>>
>> [1] http://plone.org/products/filesystemstorage
>>
>> 2009/7/31 Luciano Pacheco <[hidden email] <lucmult%40gmail.com>>:
>> >
>> >
>> > 2009/7/31 Alexandre Marinho <[hidden email]<lyralemos%40gmail.com>
>> >
>> >>
>> >>
>> >> Acredito que a grande quantidade de dados não seja uma limitação do
>> ZODB,
>> >> usando corretamente o catalogo e so "acordando" os objetos quando for
>> >> estritamente necessário... o único problema será o tamanho do Data.fs
>> que
>> >> realmente pode chegar em gigas.
>> >
>> > Concordo que podemos ter o ZODB mesmo em casos com muitos dados, as
>> vezes
>> > temos que tomar alguns cuidados, mas toda aplicação grande precisa de
>> > cuidados, mesmo em base relacional.
>> >
>> >>
>> >> Á unica situação em que usei uma base relacional foi quando precisava
>> >> fazer soma e agrupamento de valores. Ai era mais fácil utilizar SQL no
>> lugar
>> >> do ZODB.
>> >
>> > Eu fiz um produto que pode-se utilizar para fazer o agrupamento, ai não
>> > precisei usar SQL \o/
>> >
>> > http://pypi.python.org/pypi/collective.pivottable
>> >
>> > Sobre utilizar o SQL, eu acho tão simples e eficiente utilizar o ZODB
>> que
>> > prefiro ficar com ele, eu usava muito SQL em outros tipos de aplicação,
>> mas
>> > é tão bom viver sem ele. :-)
>> >
>> > Até mais,
>> > --
>> > Luciano Pacheco
>> > Simples Consultoria
>> > www.simplesconsultoria.com.br
>> >
>> >
>>
>> --
>>
>> --
>> Rodrigo Castardo
>> Liberiun
>> COO
>> [hidden email] <rodrigocastardo%40liberiun.com>
>> [phone]
>> [phone]
>>
>
>
>
> --
> Marcus Fazzi
> オープンソースコード いきかた!
> http://anunakin.blogspot.com/
> http://www.vivaphp.net
>  
>

[Vanderson Mota dos Santos]

Pergunta de iniciante: quando esse arquivo (data.fs) cresce demais,
não existem alternativas pra isso?

O data.fs cresce pois ele armazena transações também. Logo, o que se
pode fazer para diminuir o tamanho dele é dar um "pack" no zodb, que é
feito via ZMI.

abs




2009/8/4 Wagner Francisco <[hidden email]>:

>
>
> Pergunta de iniciante: quando esse arquivo (data.fs) cresce demais, não
> existem alternativas pra isso? E quão grande o arquivo precisa ser para
> realmente ser um problema?
>
> Obrigado!
>
>
> 2009/8/3 Marcus Fazzi (Anunakin) <[hidden email]>
>>
>>
>>
>> Aqui a única aplicação que usa o ZODB é o plone e mais nada, todas as
>> outras são em mySQL, msSQL, Oracle e Postgres....
>>
>> 2009/7/31 Rodrigo Castardo <[hidden email]>
>>>
>>>
>>>
>>> Fala pessoal.
>>>
>>> Bom, o Pablo respondeu mto bem e sobra pouco pra falar.
>>>
>>> A nossa visão aqui é não misturar alhos com bugalhos.
>>>
>>> Onde alhos e bugalhos seriam respectivamente gerenciamento de conteúdo
>>> e aplicações. Gerenciamento de conteúdo vai muito bem com ZODB, já
>>> aplicações nem tanto. Por exemplo, se você for fazer uma aplicação que
>>> lida com transações financeiras use um banco relacional.
>>>
>>> Em casos onde mesmo a informação de conteúdo de um portal é grande,
>>> você tem artifícios como o FSS[1] e o Catalog mencionado pelo Marinho.
>>> Como no caso do pessoal da EBC (antiga RADIOBRAS), eles tem as
>>> notícias todas em ZODB (e estamos falando de uns 10G pelo menos) e os
>>> infográficos (imagens em alta, vídeos, flash, etc...) estão todos em
>>> File System (na época somavam 40G).
>>>
>>> Com os binários em FS você pode trabalhar mais tranquilo com o ZODB. É
>>> a mesma coisa que fazemos com streaming por exemplo, os vídeos estão
>>> em FS e o conteúdo todo em ZODB.
>>>
>>> Abraços.
>>>
>>> [1] http://plone.org/products/filesystemstorage
>>>
>>> 2009/7/31 Luciano Pacheco <[hidden email]>:
>>> >
>>> >
>>> > 2009/7/31 Alexandre Marinho <[hidden email]>
>>> >>
>>> >>
>>> >> Acredito que a grande quantidade de dados não seja uma limitação do
>>> >> ZODB,
>>> >> usando corretamente o catalogo e so "acordando" os objetos quando for
>>> >> estritamente necessário... o único problema será o tamanho do Data.fs
>>> >> que
>>> >> realmente pode chegar em gigas.
>>> >
>>> > Concordo que podemos ter o ZODB mesmo em casos com muitos dados, as
>>> > vezes
>>> > temos que tomar alguns cuidados, mas toda aplicação grande precisa de
>>> > cuidados, mesmo em base relacional.
>>> >
>>> >>
>>> >> Á unica situação em que usei uma base relacional foi quando precisava
>>> >> fazer soma e agrupamento de valores. Ai era mais fácil utilizar SQL no
>>> >> lugar
>>> >> do ZODB.
>>> >
>>> > Eu fiz um produto que pode-se utilizar para fazer o agrupamento, ai não
>>> > precisei usar SQL \o/
>>> >
>>> > http://pypi.python.org/pypi/collective.pivottable
>>> >
>>> > Sobre utilizar o SQL, eu acho tão simples e eficiente utilizar o ZODB
>>> > que
>>> > prefiro ficar com ele, eu usava muito SQL em outros tipos de aplicação,
>>> > mas
>>> > é tão bom viver sem ele. :-)
>>> >
>>> > Até mais,
>>> > --
>>> > Luciano Pacheco
>>> > Simples Consultoria
>>> > www.simplesconsultoria.com.br
>>> >
>>> >
>>>
>>> --
>>>
>>> --
>>> Rodrigo Castardo
>>> Liberiun
>>> COO
>>> [hidden email]
>>> [phone]
>>> [phone]
>>
>>
>>
>> --
>> Marcus Fazzi
>> オープンソースコード いきかた!
>> http://anunakin.blogspot.com/
>> http://www.vivaphp.net
>
>

--
Vanderson Mota dos Santos

[Rafael Monnerat-2]

Rodrigo Castardo wrote:

>  
>
> Fala pessoal.
>
> Bom, o Pablo respondeu mto bem e sobra pouco pra falar.
>
> A nossa visão aqui é não misturar alhos com bugalhos.
>
> Onde alhos e bugalhos seriam respectivamente gerenciamento de conteúdo
> e aplicações. Gerenciamento de conteúdo vai muito bem com ZODB, já
> aplicações nem tanto. Por exemplo, se você for fazer uma aplicação que
> lida com transações financeiras use um banco relacional.
>

Eu acredito que o ZODB, nao tem problemas com armazenamento mesmo pra
aplicações financeiras prova disso é o [1], basta só planejar
direitinho, criar mounting points... etc etc.

O grande problema é a buscar dentro de uma base de dados > 10 milhoes de
objetos por exemplo, ou quando você que fazer uma operaçao que precisa
de muitos objetos (exemplo calcular a movimentação financeira do ultimo
ano). Pra resolver esse "pequeno" problema o ERP5 substituiu o ZCatalog
pelo ZSQLCatalog a anos atrás, mas o BD relacional é usado apenas pra
catalogação, toda a persistência e armazenamento dos dados ainda
permanecem no ZODB.

[1] http://www.erp5.com/news-central.bank

[]'s

Rafael

>
> Em casos onde mesmo a informação de conteúdo de um portal é grande,
> você tem artifícios como o FSS[1] e o Catalog mencionado pelo Marinho.
> Como no caso do pessoal da EBC (antiga RADIOBRAS), eles tem as
> notícias todas em ZODB (e estamos falando de uns 10G pelo menos) e os
> infográficos (imagens em alta, vídeos, flash, etc...) estão todos em
> File System (na época somavam 40G).
>
> Com os binários em FS você pode trabalhar mais tranquilo com o ZODB. É
> a mesma coisa que fazemos com streaming por exemplo, os vídeos estão
> em FS e o conteúdo todo em ZODB.
>
> Abraços.
>
> [1] http://plone.org/products/filesystemstorage 
> <http://plone.org/products/filesystemstorage>
>
> 2009/7/31 Luciano Pacheco <[hidden email]
> <mailto:lucmult%40gmail.com>>:
> >
> >
> > 2009/7/31 Alexandre Marinho <[hidden email]
> <mailto:lyralemos%40gmail.com>>
> >>
> >>
> >> Acredito que a grande quantidade de dados não seja uma limitação do
> ZODB,
> >> usando corretamente o catalogo e so "acordando" os objetos quando for
> >> estritamente necessário... o único problema será o tamanho do
> Data.fs que
> >> realmente pode chegar em gigas.
> >
> > Concordo que podemos ter o ZODB mesmo em casos com muitos dados, as
> vezes
> > temos que tomar alguns cuidados, mas toda aplicação grande precisa de
> > cuidados, mesmo em base relacional.
> >
> >>
> >> Á unica situação em que usei uma base relacional foi quando precisava
> >> fazer soma e agrupamento de valores. Ai era mais fácil utilizar SQL
> no lugar
> >> do ZODB.
> >
> > Eu fiz um produto que pode-se utilizar para fazer o agrupamento, ai não
> > precisei usar SQL \o/
> >
> > http://pypi.python.org/pypi/collective.pivottable 
> <http://pypi.python.org/pypi/collective.pivottable>
> >
> > Sobre utilizar o SQL, eu acho tão simples e eficiente utilizar o
> ZODB que
> > prefiro ficar com ele, eu usava muito SQL em outros tipos de
> aplicação, mas
> > é tão bom viver sem ele. :-)
> >
> > Até mais,
> > --
> > Luciano Pacheco
> > Simples Consultoria
> > www.simplesconsultoria.com.br
> >
> >
>
> --
>
> --
> Rodrigo Castardo
> Liberiun
> COO
> [hidden email] <mailto:rodrigocastardo%40liberiun.com>
> [phone]
> [phone]
>
>

[matzenh]

Achei interessante o exemplo que o Rodrigo Castardo citou.

Obrigado pela opnião de todos.

--- Em [hidden email], Rafael Monnerat <rmonnerat2@...> escreveu

>
> Rodrigo Castardo wrote:
> >  
> >
> > Fala pessoal.
> >
> > Bom, o Pablo respondeu mto bem e sobra pouco pra falar.
> >
> > A nossa visão aqui é não misturar alhos com bugalhos.
> >
> > Onde alhos e bugalhos seriam respectivamente gerenciamento de conteúdo
> > e aplicações. Gerenciamento de conteúdo vai muito bem com ZODB, já
> > aplicações nem tanto. Por exemplo, se você for fazer uma aplicação que
> > lida com transações financeiras use um banco relacional.
> >
>
>
>
>
>
>
>
>
>
>
>
>
> Eu acredito que o ZODB, nao tem problemas com armazenamento mesmo pra
> aplicações financeiras prova disso é o [1], basta só planejar
> direitinho, criar mounting points... etc etc.
>
> O grande problema é a buscar dentro de uma base de dados > 10 milhoes de
> objetos por exemplo, ou quando você que fazer uma operaçao que precisa
> de muitos objetos (exemplo calcular a movimentação financeira do ultimo
> ano). Pra resolver esse "pequeno" problema o ERP5 substituiu o ZCatalog
> pelo ZSQLCatalog a anos atrás, mas o BD relacional é usado apenas pra
> catalogação, toda a persistência e armazenamento dos dados ainda
> permanecem no ZODB.
>
> [1] http://www.erp5.com/news-central.bank
>
> []'s
>
> Rafael
>
>
> >
> > Em casos onde mesmo a informação de conteúdo de um portal é grande,
> > você tem artifícios como o FSS[1] e o Catalog mencionado pelo Marinho.
> > Como no caso do pessoal da EBC (antiga RADIOBRAS), eles tem as
> > notícias todas em ZODB (e estamos falando de uns 10G pelo menos) e os
> > infográficos (imagens em alta, vídeos, flash, etc...) estão todos em
> > File System (na época somavam 40G).
> >
> > Com os binários em FS você pode trabalhar mais tranquilo com o ZODB. É
> > a mesma coisa que fazemos com streaming por exemplo, os vídeos estão
> > em FS e o conteúdo todo em ZODB.
> >
> > Abraços.
> >
> > [1] http://plone.org/products/filesystemstorage 
> > <http://plone.org/products/filesystemstorage>
> >
> > 2009/7/31 Luciano Pacheco <lucmult@...
> > <mailto:lucmult%40gmail.com>>:
> > >
> > >
> > > 2009/7/31 Alexandre Marinho <lyralemos@...
> > <mailto:lyralemos%40gmail.com>>
> > >>
> > >>
> > >> Acredito que a grande quantidade de dados não seja uma limitação do
> > ZODB,
> > >> usando corretamente o catalogo e so "acordando" os objetos quando for
> > >> estritamente necessário... o único problema será o tamanho do
> > Data.fs que
> > >> realmente pode chegar em gigas.
> > >
> > > Concordo que podemos ter o ZODB mesmo em casos com muitos dados, as
> > vezes
> > > temos que tomar alguns cuidados, mas toda aplicação grande precisa de
> > > cuidados, mesmo em base relacional.
> > >
> > >>
> > >> Á unica situação em que usei uma base relacional foi quando precisava
> > >> fazer soma e agrupamento de valores. Ai era mais fácil utilizar SQL
> > no lugar
> > >> do ZODB.
> > >
> > > Eu fiz um produto que pode-se utilizar para fazer o agrupamento, ai não
> > > precisei usar SQL \o/
> > >
> > > http://pypi.python.org/pypi/collective.pivottable 
> > <http://pypi.python.org/pypi/collective.pivottable>
> > >
> > > Sobre utilizar o SQL, eu acho tão simples e eficiente utilizar o
> > ZODB que
> > > prefiro ficar com ele, eu usava muito SQL em outros tipos de
> > aplicação, mas
> > > é tão bom viver sem ele. :-)
> > >
> > > Até mais,
> > > --
> > > Luciano Pacheco
> > > Simples Consultoria
> > > www.simplesconsultoria.com.br
> > >
> > >
> >
> > --
> >
> > --
> > Rodrigo Castardo
> > Liberiun
> > COO
> > rodrigocastardo@... <mailto:rodrigocastardo%40liberiun.com>
> > [phone]
> > [phone]
> >
> >
>

[Rodrigo Castardo]

Fala Rafael,

2009/8/6 Rafael Monnerat <[hidden email]>:

<corta> ...

> Eu acredito que o ZODB, nao tem problemas com armazenamento mesmo pra
> aplicações financeiras prova disso é o [1], basta só planejar
> direitinho, criar mounting points... etc etc.

Claro, eu concordo contigo na questão tecnológica pura. Porém o RP5
tem inumeras funcionalidades interessantes que não existem por padrão,
este é um ponto.

Outro ponto é que, embora a essência da pergunta seja técnica, estamos
falando sob uma ótica um pouco mais abrangente, uma visão mais
sócio-técnica. O que eu coloquei não foi que o ZODB não serve para
aplicações financeiras, de forma alguma, ele pode muito bem ser
utilizado, porém com uma certa expertise que imagino que o autor da
pergunta ainda não tem.

Sem contar o esforco de integracao e a fase de convencimento de que o
banco escolhidos eh algo novo, diferente dos outros bancos (que
normalmente tem investimentos muito altos e confiabilidade consumada),
entrar nesse merito em grandes corporacoes eh complicado.

Mas como vc bem disse, tecnicamente eh possivel sim.

> O grande problema é a buscar dentro de uma base de dados > 10 milhoes de
> objetos por exemplo, ou quando você que fazer uma operaçao que precisa
> de muitos objetos (exemplo calcular a movimentação financeira do ultimo
> ano). Pra resolver esse "pequeno" problema o ERP5 substituiu o ZCatalog
> pelo ZSQLCatalog a anos atrás, mas o BD relacional é usado apenas pra
> catalogação, toda a persistência e armazenamento dos dados ainda
> permanecem no ZODB.

Mais aqui vc jah nao estah falando de storage, e sim de outras estrategias.

Estes tipos de estrategia sao bem interessantes e tem outras coisas q
poderiam ser elencadas pra isso, por exemplo:

1- Usar memcached pra segurar em cache as operacoes que tem baixa
tempestividade ou grande carga de processamento
2- Separar o catalog, deixar ele fora ... usando o Lucene (um solr da vida)
3- Usar Deliverance + tema vazio no plone, pra poupar o plone de
processar um tema (q eh bem pesado) e poder processar mais requisicoes

E por ai vai, mas a duvida era de storage em si, claro q eh bom levar
isso td em consideracao tbm ...

Abracos

> [1] http://www.erp5.com/news-central.bank
>
> []'s
>
> Rafael
>
>>
>> Em casos onde mesmo a informação de conteúdo de um portal é grande,
>> você tem artifícios como o FSS[1] e o Catalog mencionado pelo Marinho.
>> Como no caso do pessoal da EBC (antiga RADIOBRAS), eles tem as
>> notícias todas em ZODB (e estamos falando de uns 10G pelo menos) e os
>> infográficos (imagens em alta, vídeos, flash, etc...) estão todos em
>> File System (na época somavam 40G).
>>
>> Com os binários em FS você pode trabalhar mais tranquilo com o ZODB. É
>> a mesma coisa que fazemos com streaming por exemplo, os vídeos estão
>> em FS e o conteúdo todo em ZODB.
>>
>> Abraços.
>>
>> [1] http://plone.org/products/filesystemstorage
>> <http://plone.org/products/filesystemstorage>
>>
>> 2009/7/31 Luciano Pacheco <[hidden email]
>> <mailto:lucmult%40gmail.com>>:
>> >
>> >
>> > 2009/7/31 Alexandre Marinho <[hidden email]
>> <mailto:lyralemos%40gmail.com>>
>> >>
>> >>
>> >> Acredito que a grande quantidade de dados não seja uma limitação do
>> ZODB,
>> >> usando corretamente o catalogo e so "acordando" os objetos quando for
>> >> estritamente necessário... o único problema será o tamanho do
>> Data.fs que
>> >> realmente pode chegar em gigas.
>> >
>> > Concordo que podemos ter o ZODB mesmo em casos com muitos dados, as
>> vezes
>> > temos que tomar alguns cuidados, mas toda aplicação grande precisa de
>> > cuidados, mesmo em base relacional.
>> >
>> >>
>> >> Á unica situação em que usei uma base relacional foi quando precisava
>> >> fazer soma e agrupamento de valores. Ai era mais fácil utilizar SQL
>> no lugar
>> >> do ZODB.
>> >
>> > Eu fiz um produto que pode-se utilizar para fazer o agrupamento, ai não
>> > precisei usar SQL \o/
>> >
>> > http://pypi.python.org/pypi/collective.pivottable
>> <http://pypi.python.org/pypi/collective.pivottable>
>> >
>> > Sobre utilizar o SQL, eu acho tão simples e eficiente utilizar o
>> ZODB que
>> > prefiro ficar com ele, eu usava muito SQL em outros tipos de
>> aplicação, mas
>> > é tão bom viver sem ele. :-)
>> >
>> > Até mais,
>> > --
>> > Luciano Pacheco
>> > Simples Consultoria
>> > www.simplesconsultoria.com.br
>> >
>> >
>>
>> --
>>
>> --
>> Rodrigo Castardo
>> Liberiun
>> COO
>> [hidden email] <mailto:rodrigocastardo%40liberiun.com>
>> [phone]
>> [phone]
>>
>>
>
>

--



--
Rodrigo Castardo
Liberiun
COO
[hidden email]
[phone]
[phone]

[Rafael Monnerat-2]

E ai Rodrigo,

Rodrigo Castardo wrote:

>
>
>  Fala Rafael,
>
>  2009/8/6 Rafael Monnerat <[hidden email]>:
>
>  <corta> ...
>
>  > Eu acredito que o ZODB, nao tem problemas com armazenamento mesmo pra
>  > aplicações financeiras prova disso é o [1], basta só planejar
>  > direitinho, criar mounting points... etc etc.
>
>  Claro, eu concordo contigo na questão tecnológica pura. Porém o RP5
>  tem inumeras funcionalidades interessantes que não existem por padrão,
>  este é um ponto.
>
>  Outro ponto é que, embora a essência da pergunta seja técnica, estamos
>  falando sob uma ótica um pouco mais abrangente, uma visão mais
>  sócio-técnica. O que eu coloquei não foi que o ZODB não serve para
>  aplicações financeiras, de forma alguma, ele pode muito bem ser
>  utilizado, porém com uma certa expertise que imagino que o autor da
>  pergunta ainda não tem.
>
>  Sem contar o esforco de integracao e a fase de convencimento de que o
>  banco escolhidos eh algo novo, diferente dos outros bancos (que
>  normalmente tem investimentos muito altos e confiabilidade consumada),
>  entrar nesse merito em grandes corporacoes eh complicado.
>
>  Mas como vc bem disse, tecnicamente eh possível sim.

Bem, meu ponto de vista era puramente técnico (tecnicamente quase tudo é
possível hehe). E também acho que muitas vezes as pessoas sao
desestimuladas a acreditar no ZODB, por vários motivos. Eu só dei um
exemplo de caso de uso, onde o ZODB possui muitos milhares de documentos
(ou objetos) em uma aplicação financeira.


>  > O grande problema é a buscar dentro de uma base de dados > 10 milhoes de
>  > objetos por exemplo, ou quando você que fazer uma operaçao que precisa
>  > de muitos objetos (exemplo calcular a movimentação financeira do ultimo
>  > ano). Pra resolver esse "pequeno" problema o ERP5 substituiu o ZCatalog
>  > pelo ZSQLCatalog a anos atrás, mas o BD relacional é usado apenas pra
>  > catalogação, toda a persistência e armazenamento dos dados ainda
>  > permanecem no ZODB.
>
>  Mais aqui vc jah nao estah falando de storage, e sim de outras
estrategias.

Bem, esta de certa forma relacionado, porque a quantidade de objetos
influencia na busca dele. Mas sim, isso nao é necessariamente
diretamente ao storage.

>
>  Estes tipos de estrategia sao bem interessantes e tem outras coisas q
>  poderiam ser elencadas pra isso, por exemplo:

Eu vou dar meus exemplos tbm : )

>
>  1- Usar memcached pra segurar em cache as operacoes que tem baixa
>  tempestividade ou grande carga de processamento

Esse é um ponto interessante, no erp5 a gente tem suporte nativo ao
memcache e recentemente foi adicionado suporte ao Flare [1]. Estamos
mudando os caches persistentes (que usavam PersistenseMapping por algum
motivo) para usar o Flare. Isso reduz as modificações no ZODB e evita
que o cache seja perdido em um restart.

>  2- Separar o catalog, deixar ele fora ... usando o Lucene (um solr da
vida)

Como a gente usa MySQL , temos support nativo o Senna[2] (segundo a
lenda é mais rapido que o Lucene mas isso gera muitas controvérsias hehehe)

>  3- Usar Deliverance + tema vazio no plone, pra poupar o plone de
>  processar um tema (q eh bem pesado) e poder processar mais requisicoes

Eu nao conheço deliverance direito, preciso me atualizar : )

>
>  E por ai vai, mas a duvida era de storage em si, claro q eh bom levar
>  isso td em consideração tbm ...

Bem, eu nao acho que storage por si só seja um problema, o problema é o
como você um arquivo (ou mais) de 100 GB depois : ), acho que o sistema
tem muitos outros gargalos antes do tamanho do Storage ser um problema.

[1] http://labs.gree.jp/Top/OpenSource/Flare-en.html
[2] http://qwik.jp/senna/

>  Abracos
>
>  > [1] http://www.erp5.com/news-central.bank
>  >
>  > []'s
>  >
>  > Rafael
>  >
>  >>
>  >> Em casos onde mesmo a informação de conteúdo de um portal é grande,
>  >> você tem artifícios como o FSS[1] e o Catalog mencionado pelo Marinho.
>  >> Como no caso do pessoal da EBC (antiga RADIOBRAS), eles tem as
>  >> notícias todas em ZODB (e estamos falando de uns 10G pelo menos) e os
>  >> infográficos (imagens em alta, vídeos, flash, etc...) estão todos em
>  >> File System (na época somavam 40G).
>  >>
>  >> Com os binários em FS você pode trabalhar mais tranquilo com o ZODB. É
>  >> a mesma coisa que fazemos com streaming por exemplo, os vídeos estão
>  >> em FS e o conteúdo todo em ZODB.
>  >>
>  >> Abraços.
>  >>
>  >> [1] http://plone.org/products/filesystemstorage
>  >> <http://plone.org/products/filesystemstorage>
>  >>
>  >> 2009/7/31 Luciano Pacheco <[hidden email]
>  >> <mailto:lucmult%40gmail.com>>:
>  >> >
>  >> >
>  >> > 2009/7/31 Alexandre Marinho <[hidden email]
>  >> <mailto:lyralemos%40gmail.com>>
>  >> >>
>  >> >>
>  >> >> Acredito que a grande quantidade de dados não seja uma limitação do
>  >> ZODB,
>  >> >> usando corretamente o catalogo e so "acordando" os objetos

quando for

>  >> >> estritamente necessário... o único problema será o tamanho do
>  >> Data.fs que
>  >> >> realmente pode chegar em gigas.
>  >> >
>  >> > Concordo que podemos ter o ZODB mesmo em casos com muitos dados, as
>  >> vezes
>  >> > temos que tomar alguns cuidados, mas toda aplicação grande precisa de
>  >> > cuidados, mesmo em base relacional.
>  >> >
>  >> >>
>  >> >> Á unica situação em que usei uma base relacional foi quando

precisava
>  >> >> fazer soma e agrupamento de valores. Ai era mais fácil utilizar SQL
>  >> no lugar
>  >> >> do ZODB.
>  >> >
>  >> > Eu fiz um produto que pode-se utilizar para fazer o agrupamento,
ai não

>  >> > precisei usar SQL \o/
>  >> >
>  >> > http://pypi.python.org/pypi/collective.pivottable
>  >> <http://pypi.python.org/pypi/collective.pivottable>
>  >> >
>  >> > Sobre utilizar o SQL, eu acho tão simples e eficiente utilizar o
>  >> ZODB que
>  >> > prefiro ficar com ele, eu usava muito SQL em outros tipos de
>  >> aplicação, mas
>  >> > é tão bom viver sem ele. :-)
>  >> >
>  >> > Até mais,
>  >> > --
>  >> > Luciano Pacheco
>  >> > Simples Consultoria
>  >> > www.simplesconsultoria.com.br
>  >> >
>  >> >
>  >>
>  >> --
>  >>
>  >> --
>  >> Rodrigo Castardo
>  >> Liberiun
>  >> COO
>  >> [hidden email] <mailto:rodrigocastardo%40liberiun.com>
>  >> [phone]
>  >> [phone]
>  >>
>  >>
>  >
>  >
>
>  --
>
>  --
>  Rodrigo Castardo
>  Liberiun
>  COO
>  [hidden email]
>  [phone]
>  [phone]
>  
>  <!-- #ygrp-mkp{ border: 1px solid #d8d8d8; font-family: Arial; margin:

14px 0px; padding: 0px 14px; } #ygrp-mkp hr{ border: 1px solid #d8d8d8;
} #ygrp-mkp #hd{ color: #628c2a; font-size: 85%; font-weight: bold;
line-height: 122%; margin: 10px 0px; } #ygrp-mkp #ads{ margin-bottom:
10px; } #ygrp-mkp .ad{ padding: 0 0; } #ygrp-mkp .ad a{ color: #0000ff;
text-decoration: none; } --> <!-- #ygrp-sponsor #ygrp-lc{ font-family:
Arial; } #ygrp-sponsor #ygrp-lc #hd{ margin: 10px 0px; font-weight:
bold; font-size: 78%; line-height: 122%; } #ygrp-sponsor #ygrp-lc .ad{
margin-bottom: 10px; padding: 0 0; } --> <!-- #ygrp-mlmsg
{font-size:13px; font-family:
arial,helvetica,clean,sans-serif;*font-size:small;*font:x-small;}
#ygrp-mlmsg table {font-size:inherit;font:100%;} #ygrp-mlmsg select,
input, textarea {font:99% arial,helvetica,clean,sans-serif;} #ygrp-mlmsg
pre, code {font:115% monospace;*font-size:100%;} #ygrp-mlmsg *
{line-height:1.22em;} #ygrp-text{ font-family: Georgia; } #ygrp-text p{
margin: 0 0 1em 0; } dd.last p a { font-family: Verdana; font-weight:
bold; } #ygrp-vitnav{ padding-top: 10px; font-family: Verdana;
font-size: 77%; margin: 0; } #ygrp-vitnav a{ padding: 0 1px; }
#ygrp-mlmsg #logo{ padding-bottom: 10px; } #ygrp-reco { margin-bottom:
20px; padding: 0px; } #ygrp-reco #reco-head { font-weight: bold; color:
#ff7900; } #reco-category{ font-size: 77%; } #reco-desc{ font-size: 77%;
} #ygrp-vital a{ text-decoration: none; } #ygrp-vital a:hover{
text-decoration: underline; } #ygrp-sponsor #ov ul{ padding: 0 0 0 8px;
margin: 0; } #ygrp-sponsor #ov li{ list-style-type: square; padding: 6px
0; font-size: 77%; } #ygrp-sponsor #ov li a{ text-decoration: none;
font-size: 130%; } #ygrp-sponsor #nc{ background-color: #eee;
margin-bottom: 20px; padding: 0 8px; } #ygrp-sponsor .ad{ padding: 8px
0; } #ygrp-sponsor .ad #hd1{ font-family: Arial; font-weight: bold;
color: #628c2a; font-size: 100%; line-height: 122%; } #ygrp-sponsor .ad
a{ text-decoration: none; } #ygrp-sponsor .ad a:hover{ text-decoration:
underline; } #ygrp-sponsor .ad p{ margin: 0; font-weight: normal; color:
#000000; } o{font-size: 0; } .MsoNormal{ margin: 0 0 0 0; } #ygrp-text
tt{ font-size: 120%; } blockquote{margin: 0 0 0 4px;} .replbq{margin:4}
dd.last p span { margin-right: 10px; font-family: Verdana; font-weight:
bold; } dd.last p span.yshortcuts { margin-right: 0; } div.photo-title
a, div.photo-title a:active, div.photo-title a:hover, div.photo-title
a:visited { text-decoration: none; } div.file-title a, div.file-title
a:active, div.file-title a:hover, div.file-title a:visited {
text-decoration: none; } #ygrp-msg p#attach-count { clear: both;
padding: 15px 0 3px 0; overflow: hidden; } #ygrp-msg p#attach-count span
{ color: #1E66AE; font-weight: bold; } div#ygrp-mlmsg #ygrp-msg p a
span.yshortcuts { font-family: Verdana; font-size: 10px; font-weight:
normal; } #ygrp-msg p a { font-family: Verdana; } #ygrp-mlmsg a { color:
#1E66AE; } div.attach-table div div a { text-decoration: none; }
div.attach-table { width: 400px; } -->

[Rodrigo Castardo]

Fala Rafael =)

2009/8/11 Rafael Monnerat <[hidden email]>:

>
>
> E ai Rodrigo,
>
> Rodrigo Castardo wrote:
>>
>>
>> Fala Rafael,
>>
>> 2009/8/6 Rafael Monnerat <[hidden email]>:
>>
>> <corta> ...
>>
>> > Eu acredito que o ZODB, nao tem problemas com armazenamento mesmo pra
>> > aplicações financeiras prova disso é o [1], basta só planejar
>> > direitinho, criar mounting points... etc etc.
>>
>> Claro, eu concordo contigo na questão tecnológica pura. Porém o RP5
>> tem inumeras funcionalidades interessantes que não existem por padrão,
>> este é um ponto.
>>
>> Outro ponto é que, embora a essência da pergunta seja técnica, estamos
>> falando sob uma ótica um pouco mais abrangente, uma visão mais
>> sócio-técnica. O que eu coloquei não foi que o ZODB não serve para
>> aplicações financeiras, de forma alguma, ele pode muito bem ser
>> utilizado, porém com uma certa expertise que imagino que o autor da
>> pergunta ainda não tem.
>>
>> Sem contar o esforco de integracao e a fase de convencimento de que o
>> banco escolhidos eh algo novo, diferente dos outros bancos (que
>> normalmente tem investimentos muito altos e confiabilidade consumada),
>> entrar nesse merito em grandes corporacoes eh complicado.
>>
>> Mas como vc bem disse, tecnicamente eh possível sim.
>
> Bem, meu ponto de vista era puramente técnico (tecnicamente quase tudo é
> possível hehe). E também acho que muitas vezes as pessoas sao
> desestimuladas a acreditar no ZODB, por vários motivos. Eu só dei um
> exemplo de caso de uso, onde o ZODB possui muitos milhares de documentos
> (ou objetos) em uma aplicação financeira.

"Tecnicamente td eh possivel" Essa frase eh meio emblematica =)

Claro, acho otimo teu exemplo ... o case de vcs fala sozinho, e eh bem
conhecido ... ateh conversei com um developer de vcs no FISL, ele
quase sempre aparece junto com o Claudio no INPI, mas sempre esqueco o
nome dele =)

>
>> > O grande problema é a buscar dentro de uma base de dados > 10 milhoes de
>> > objetos por exemplo, ou quando você que fazer uma operaçao que precisa
>> > de muitos objetos (exemplo calcular a movimentação financeira do ultimo
>> > ano). Pra resolver esse "pequeno" problema o ERP5 substituiu o ZCatalog
>> > pelo ZSQLCatalog a anos atrás, mas o BD relacional é usado apenas pra
>> > catalogação, toda a persistência e armazenamento dos dados ainda
>> > permanecem no ZODB.
>>
>> Mais aqui vc jah nao estah falando de storage, e sim de outras
> estrategias.
>
> Bem, esta de certa forma relacionado, porque a quantidade de objetos
> influencia na busca dele. Mas sim, isso nao é necessariamente
> diretamente ao storage.

Vdd, no caso de aplicacoes Zope eh diferente o modo como vc pensa, as
coisas se unem, aplicacao+storage+servidor de aplicacao+etc ... e
poucas coisas sao eficientes qdo sao mto pontuais.

>>
>> Estes tipos de estrategia sao bem interessantes e tem outras coisas q
>> poderiam ser elencadas pra isso, por exemplo:
>
> Eu vou dar meus exemplos tbm : )

Como se diz, so awesome =)

>>
>> 1- Usar memcached pra segurar em cache as operacoes que tem baixa
>> tempestividade ou grande carga de processamento
>
> Esse é um ponto interessante, no erp5 a gente tem suporte nativo ao
> memcache e recentemente foi adicionado suporte ao Flare [1]. Estamos
> mudando os caches persistentes (que usavam PersistenseMapping por algum
> motivo) para usar o Flare. Isso reduz as modificações no ZODB e evita
> que o cache seja perdido em um restart.

Essa eh nova, bem interessante.

Nossa API de memcached eh software livre e pode ser baixada em:

http://bitbucket.org/liberiun/liberiunportalcaching/

>> 2- Separar o catalog, deixar ele fora ... usando o Lucene (um solr da
> vida)
>
> Como a gente usa MySQL , temos support nativo o Senna[2] (segundo a
> lenda é mais rapido que o Lucene mas isso gera muitas controvérsias hehehe)

Essa lenda eu desconhecia, conhecia apenas a lenda do Lucene =)

>> 3- Usar Deliverance + tema vazio no plone, pra poupar o plone de
>> processar um tema (q eh bem pesado) e poder processar mais requisicoes
>
> Eu nao conheço deliverance direito, preciso me atualizar : )

Basicamente tu tem um cara WSGI que lida com o tema, vc tira essa
carga de dentro do Plone (que soa a camisa pra montar esse
quebra-cabeca).

Esse cara WSGI tem o tema morto (XHTML+CSS puros, sem logica) e regras
(troque o id x do plone pelo y do tema morto), qdo o acesso (user ->
deliv -> zope) chega ao portal normalmente, na volta ele sofre a
aplicacao das regras e faz a magica!

Nosso portal usa Deliverance, e roda em uma maquina que tem poucos
recursos (sao 512 de RAM) e nao estamos usando praticamente nenhum
cache, e ele tem uma velocidade mto boa.

>>
>> E por ai vai, mas a duvida era de storage em si, claro q eh bom levar
>> isso td em consideração tbm ...
>
> Bem, eu nao acho que storage por si só seja um problema, o problema é o
> como você um arquivo (ou mais) de 100 GB depois : ), acho que o sistema
> tem muitos outros gargalos antes do tamanho do Storage ser um problema.

Concordo, a equacao eh mais complexa e o storage eh uma parte dela.

Acho importante tbm citar que estas evolucoes todas q estou trocando
com o Rafael sao para grandes projetos (leia-se: gde
sites/portais/intranets/sistemas aliados a um grande assedio). Se vc
tem um projeto, ou um grande projeto, que nao tem mtos acessos vc pode
usar o Plone padrao pra atender a mtos casos ... e em caso de
problemas, coisas mais simples podem te garantir performance.

No caso estas praticas nos utilizamos para cases com 70 milhoes de
hits/mes. Temos um caso que tem 140G de transferencia por dia, e
crescendo. O Rafael deve ter numeros de transacoes absurdos,
compartilha com a gente Rafael?

Valeu Rafael, um abraco!

> [1] http://labs.gree.jp/Top/OpenSource/Flare-en.html
> [2] http://qwik.jp/senna/
>
>> Abracos
>>
>> > [1] http://www.erp5.com/news-central.bank
>> >
>> > []'s
>> >
>> > Rafael
>> >
>> >>
>> >> Em casos onde mesmo a informação de conteúdo de um portal é grande,
>> >> você tem artifícios como o FSS[1] e o Catalog mencionado pelo Marinho.
>> >> Como no caso do pessoal da EBC (antiga RADIOBRAS), eles tem as
>> >> notícias todas em ZODB (e estamos falando de uns 10G pelo menos) e os
>> >> infográficos (imagens em alta, vídeos, flash, etc...) estão todos em
>> >> File System (na época somavam 40G).
>> >>
>> >> Com os binários em FS você pode trabalhar mais tranquilo com o ZODB. É
>> >> a mesma coisa que fazemos com streaming por exemplo, os vídeos estão
>> >> em FS e o conteúdo todo em ZODB.
>> >>
>> >> Abraços.
>> >>
>> >> [1] http://plone.org/products/filesystemstorage
>> >> <http://plone.org/products/filesystemstorage>
>> >>
>> >> 2009/7/31 Luciano Pacheco <[hidden email]
>> >> <mailto:lucmult%40gmail.com>>:
>> >> >
>> >> >
>> >> > 2009/7/31 Alexandre Marinho <[hidden email]
>> >> <mailto:lyralemos%40gmail.com>>
>> >> >>
>> >> >>
>> >> >> Acredito que a grande quantidade de dados não seja uma limitação do
>> >> ZODB,
>> >> >> usando corretamente o catalogo e so "acordando" os objetos
> quando for
>> >> >> estritamente necessário... o único problema será o tamanho do
>> >> Data.fs que
>> >> >> realmente pode chegar em gigas.
>> >> >
>> >> > Concordo que podemos ter o ZODB mesmo em casos com muitos dados, as
>> >> vezes
>> >> > temos que tomar alguns cuidados, mas toda aplicação grande precisa de
>> >> > cuidados, mesmo em base relacional.
>> >> >
>> >> >>
>> >> >> Á unica situação em que usei uma base relacional foi quando
> precisava
>> >> >> fazer soma e agrupamento de valores. Ai era mais fácil utilizar SQL
>> >> no lugar
>> >> >> do ZODB.
>> >> >
>> >> > Eu fiz um produto que pode-se utilizar para fazer o agrupamento,
> ai não
>> >> > precisei usar SQL \o/
>> >> >
>> >> > http://pypi.python.org/pypi/collective.pivottable
>> >> <http://pypi.python.org/pypi/collective.pivottable>
>> >> >
>> >> > Sobre utilizar o SQL, eu acho tão simples e eficiente utilizar o
>> >> ZODB que
>> >> > prefiro ficar com ele, eu usava muito SQL em outros tipos de
>> >> aplicação, mas
>> >> > é tão bom viver sem ele. :-)
>> >> >
>> >> > Até mais,
>> >> > --
>> >> > Luciano Pacheco
>> >> > Simples Consultoria
>> >> > www.simplesconsultoria.com.br
>> >> >
>> >> >
>> >>
>> >> --
>> >>
>> >> --
>> >> Rodrigo Castardo
>> >> Liberiun
>> >> COO
>> >> [hidden email] <mailto:rodrigocastardo%40liberiun.com>
>> >> [phone]
>> >> [phone]
>> >>
>> >>
>> >
>> >
>>
>> --
>>
>> --
>> Rodrigo Castardo
>> Liberiun
>> COO
>> [hidden email]
>> [phone]
>> [phone]
>>
>> <!-- #ygrp-mkp{ border: 1px solid #d8d8d8; font-family: Arial; margin:
> 14px 0px; padding: 0px 14px; } #ygrp-mkp hr{ border: 1px solid #d8d8d8;
> } #ygrp-mkp #hd{ color: #628c2a; font-size: 85%; font-weight: bold;
> line-height: 122%; margin: 10px 0px; } #ygrp-mkp #ads{ margin-bottom:
> 10px; } #ygrp-mkp .ad{ padding: 0 0; } #ygrp-mkp .ad a{ color: #0000ff;
> text-decoration: none; } --> <!-- #ygrp-sponsor #ygrp-lc{ font-family:
> Arial; } #ygrp-sponsor #ygrp-lc #hd{ margin: 10px 0px; font-weight:
> bold; font-size: 78%; line-height: 122%; } #ygrp-sponsor #ygrp-lc .ad{
> margin-bottom: 10px; padding: 0 0; } --> <!-- #ygrp-mlmsg
> {font-size:13px; font-family:
> arial,helvetica,clean,sans-serif;*font-size:small;*font:x-small;}
> #ygrp-mlmsg table {font-size:inherit;font:100%;} #ygrp-mlmsg select,
> input, textarea {font:99% arial,helvetica,clean,sans-serif;} #ygrp-mlmsg
> pre, code {font:115% monospace;*font-size:100%;} #ygrp-mlmsg *
> {line-height:1.22em;} #ygrp-text{ font-family: Georgia; } #ygrp-text p{
> margin: 0 0 1em 0; } dd.last p a { font-family: Verdana; font-weight:
> bold; } #ygrp-vitnav{ padding-top: 10px; font-family: Verdana;
> font-size: 77%; margin: 0; } #ygrp-vitnav a{ padding: 0 1px; }
> #ygrp-mlmsg #logo{ padding-bottom: 10px; } #ygrp-reco { margin-bottom:
> 20px; padding: 0px; } #ygrp-reco #reco-head { font-weight: bold; color:
> #ff7900; } #reco-category{ font-size: 77%; } #reco-desc{ font-size: 77%;
> } #ygrp-vital a{ text-decoration: none; } #ygrp-vital a:hover{
> text-decoration: underline; } #ygrp-sponsor #ov ul{ padding: 0 0 0 8px;
> margin: 0; } #ygrp-sponsor #ov li{ list-style-type: square; padding: 6px
> 0; font-size: 77%; } #ygrp-sponsor #ov li a{ text-decoration: none;
> font-size: 130%; } #ygrp-sponsor #nc{ background-color: #eee;
> margin-bottom: 20px; padding: 0 8px; } #ygrp-sponsor .ad{ padding: 8px
> 0; } #ygrp-sponsor .ad #hd1{ font-family: Arial; font-weight: bold;
> color: #628c2a; font-size: 100%; line-height: 122%; } #ygrp-sponsor .ad
> a{ text-decoration: none; } #ygrp-sponsor .ad a:hover{ text-decoration:
> underline; } #ygrp-sponsor .ad p{ margin: 0; font-weight: normal; color:
> #000000; } o{font-size: 0; } .MsoNormal{ margin: 0 0 0 0; } #ygrp-text
> tt{ font-size: 120%; } blockquote{margin: 0 0 0 4px;} .replbq{margin:4}
> dd.last p span { margin-right: 10px; font-family: Verdana; font-weight:
> bold; } dd.last p span.yshortcuts { margin-right: 0; } div.photo-title
> a, div.photo-title a:active, div.photo-title a:hover, div.photo-title
> a:visited { text-decoration: none; } div.file-title a, div.file-title
> a:active, div.file-title a:hover, div.file-title a:visited {
> text-decoration: none; } #ygrp-msg p#attach-count { clear: both;
> padding: 15px 0 3px 0; overflow: hidden; } #ygrp-msg p#attach-count span
> { color: #1E66AE; font-weight: bold; } div#ygrp-mlmsg #ygrp-msg p a
> span.yshortcuts { font-family: Verdana; font-size: 10px; font-weight:
> normal; } #ygrp-msg p a { font-family: Verdana; } #ygrp-mlmsg a { color:
> #1E66AE; } div.attach-table div div a { text-decoration: none; }
> div.attach-table { width: 400px; } -->
>
>

--



--
Rodrigo Castardo
Liberiun
COO
[hidden email]
[phone]
[phone]

[Rafael Monnerat-2]

Opa,

Rodrigo Castardo wrote:

>
>
>  Fala Rafael =)
>
>  2009/8/11 Rafael Monnerat <[hidden email]>:
>  >
>  >
>  > E ai Rodrigo,
>  >
>  > Rodrigo Castardo wrote:
>  >>
>  >>
>  >> Fala Rafael,
>  >>
>  >> 2009/8/6 Rafael Monnerat <[hidden email]>:
>  >>
>  >> <corta> ...
>  >>
>  >> > Eu acredito que o ZODB, nao tem problemas com armazenamento mesmo pra
>  >> > aplicações financeiras prova disso é o [1], basta só planejar
>  >> > direitinho, criar mounting points... etc etc.
>  >>
>  >> Claro, eu concordo contigo na questão tecnológica pura. Porém o RP5
>  >> tem inumeras funcionalidades interessantes que não existem por padrão,
>  >> este é um ponto.
>  >>
>  >> Outro ponto é que, embora a essência da pergunta seja técnica, estamos
>  >> falando sob uma ótica um pouco mais abrangente, uma visão mais
>  >> sócio-técnica. O que eu coloquei não foi que o ZODB não serve para
>  >> aplicações financeiras, de forma alguma, ele pode muito bem ser
>  >> utilizado, porém com uma certa expertise que imagino que o autor da
>  >> pergunta ainda não tem.
>  >>
>  >> Sem contar o esforco de integracao e a fase de convencimento de que o
>  >> banco escolhidos eh algo novo, diferente dos outros bancos (que
>  >> normalmente tem investimentos muito altos e confiabilidade consumada),
>  >> entrar nesse merito em grandes corporacoes eh complicado.
>  >>
>  >> Mas como vc bem disse, tecnicamente eh possível sim.
>  >
>  > Bem, meu ponto de vista era puramente técnico (tecnicamente quase tudo é
>  > possível hehe). E também acho que muitas vezes as pessoas sao
>  > desestimuladas a acreditar no ZODB, por vários motivos. Eu só dei um
>  > exemplo de caso de uso, onde o ZODB possui muitos milhares de documentos
>  > (ou objetos) em uma aplicação financeira.
>
>  "Tecnicamente td eh possivel" Essa frase eh meio emblematica =)
>
>  Claro, acho otimo teu exemplo ... o case de vcs fala sozinho, e eh bem
>  conhecido ... ateh conversei com um developer de vcs no FISL, ele
>  quase sempre aparece junto com o Claudio no INPI, mas sempre esqueco o
>  nome dele =)
>

Bem, era eu :)


>  >
>  >> > O grande problema é a buscar dentro de uma base de dados > 10
milhoes de
>  >> > objetos por exemplo, ou quando você que fazer uma operaçao que
precisa
>  >> > de muitos objetos (exemplo calcular a movimentação financeira do
ultimo
>  >> > ano). Pra resolver esse "pequeno" problema o ERP5 substituiu o
ZCatalog

>  >> > pelo ZSQLCatalog a anos atrás, mas o BD relacional é usado apenas pra
>  >> > catalogação, toda a persistência e armazenamento dos dados ainda
>  >> > permanecem no ZODB.
>  >>
>  >> Mais aqui vc jah nao estah falando de storage, e sim de outras
>  > estrategias.
>  >
>  > Bem, esta de certa forma relacionado, porque a quantidade de objetos
>  > influencia na busca dele. Mas sim, isso nao é necessariamente
>  > diretamente ao storage.
>
>  Vdd, no caso de aplicacoes Zope eh diferente o modo como vc pensa, as
>  coisas se unem, aplicacao+storage+servidor de aplicacao+etc ... e
>  poucas coisas sao eficientes qdo sao mto pontuais.
>
>  >>
>  >> Estes tipos de estrategia sao bem interessantes e tem outras coisas q
>  >> poderiam ser elencadas pra isso, por exemplo:
>  >
>  > Eu vou dar meus exemplos tbm : )
>
>  Como se diz, so awesome =)
>
>  >>
>  >> 1- Usar memcached pra segurar em cache as operacoes que tem baixa
>  >> tempestividade ou grande carga de processamento
>  >
>  > Esse é um ponto interessante, no erp5 a gente tem suporte nativo ao
>  > memcache e recentemente foi adicionado suporte ao Flare [1]. Estamos
>  > mudando os caches persistentes (que usavam PersistenseMapping por algum
>  > motivo) para usar o Flare. Isso reduz as modificações no ZODB e evita
>  > que o cache seja perdido em um restart.
>
>  Essa eh nova, bem interessante.
>
>  Nossa API de memcached eh software livre e pode ser baixada em:
>
>  http://bitbucket.org/liberiun/liberiunportalcaching/
>
>  >> 2- Separar o catalog, deixar ele fora ... usando o Lucene (um solr da
>  > vida)
>  >
>  > Como a gente usa MySQL , temos support nativo o Senna[2] (segundo a
>  > lenda é mais rapido que o Lucene mas isso gera muitas controvérsias

hehehe)

>
>  Essa lenda eu desconhecia, conhecia apenas a lenda do Lucene =)
>
>  >> 3- Usar Deliverance + tema vazio no plone, pra poupar o plone de
>  >> processar um tema (q eh bem pesado) e poder processar mais requisicoes
>  >
>  > Eu nao conheço deliverance direito, preciso me atualizar : )
>
>  Basicamente tu tem um cara WSGI que lida com o tema, vc tira essa
>  carga de dentro do Plone (que soa a camisa pra montar esse
>  quebra-cabeca).
>
>  Esse cara WSGI tem o tema morto (XHTML+CSS puros, sem logica) e regras
>  (troque o id x do plone pelo y do tema morto), qdo o acesso (user ->
>  deliv -> zope) chega ao portal normalmente, na volta ele sofre a
>  aplicacao das regras e faz a magica!
>
>  Nosso portal usa Deliverance, e roda em uma maquina que tem poucos
>  recursos (sao 512 de RAM) e nao estamos usando praticamente nenhum
>  cache, e ele tem uma velocidade mto boa.
>

Interessate.

>  >>
>  >> E por ai vai, mas a duvida era de storage em si, claro q eh bom levar
>  >> isso td em consideração tbm ...
>  >
>  > Bem, eu nao acho que storage por si só seja um problema, o problema é o
>  > como você um arquivo (ou mais) de 100 GB depois : ), acho que o sistema
>  > tem muitos outros gargalos antes do tamanho do Storage ser um problema.
>
>  Concordo, a equacao eh mais complexa e o storage eh uma parte dela.
>
>  Acho importante tbm citar que estas evolucoes todas q estou trocando
>  com o Rafael sao para grandes projetos (leia-se: gde
>  sites/portais/intranets/sistemas aliados a um grande assedio). Se vc
>  tem um projeto, ou um grande projeto, que nao tem mtos acessos vc pode
>  usar o Plone padrao pra atender a mtos casos ... e em caso de
>  problemas, coisas mais simples podem te garantir performance.
>
>  No caso estas praticas nos utilizamos para cases com 70 milhoes de
>  hits/mes. Temos um caso que tem 140G de transferencia por dia, e
>  crescendo. O Rafael deve ter numeros de transacoes absurdos,
>  compartilha com a gente Rafael?
>

Transações de que ZODB ou financeiras?

A aplicação gerencia entre outras coisas, controle monetário. Cada
Cédula produzida pelo Banco tem um objecto correspondente no ERP5 e com
tem um workflow.

Eu nao sei os números exatos porque eu nao trabalhei diretamente no
projeto. Mas o ERP5 usa 46 mounting points em um único ZEO, 32 Zopes
como clientes e 1 mysql para o catalog. Cada modulo (cada modulo é um
folder) tem alguns milhões objetos, acredite eu nunca perguntei quanto
da no total, mas já deve ter mais de 20 milhões a algum tempo.

Se somarmos o ZODB dá aproximadamente 64 GB. Que eu até acho pouco hoje
em dia...

Nós acreditamos que somos capazes de implantar o ERP5 em projetos que
cheguem a 1 000 000 000 (um bilhão) de objetos, o difícil é encontrar
alguém que precise de tantos objetos assim. e que esteja interessado em
bancar. : )

[]'s

Rafael

>  Valeu Rafael, um abraco!
>
>  > [1] http://labs.gree.jp/Top/OpenSource/Flare-en.html
>  > [2] http://qwik.jp/senna/
>  >
>  >> Abracos
>  >>
>  >> > [1] http://www.erp5.com/news-central.bank
>  >> >
>  >> > []'s
>  >> >
>  >> > Rafael
>  >> >
>  >> >>
>  >> >> Em casos onde mesmo a informação de conteúdo de um portal é grande,
>  >> >> você tem artifícios como o FSS[1] e o Catalog mencionado pelo

Marinho.
>  >> >> Como no caso do pessoal da EBC (antiga RADIOBRAS), eles tem as
>  >> >> notícias todas em ZODB (e estamos falando de uns 10G pelo menos)
e os
>  >> >> infográficos (imagens em alta, vídeos, flash, etc...) estão todos em
>  >> >> File System (na época somavam 40G).
>  >> >>
>  >> >> Com os binários em FS você pode trabalhar mais tranquilo com o
ZODB. É

>  >> >> a mesma coisa que fazemos com streaming por exemplo, os vídeos estão
>  >> >> em FS e o conteúdo todo em ZODB.
>  >> >>
>  >> >> Abraços.
>  >> >>
>  >> >> [1] http://plone.org/products/filesystemstorage
>  >> >> <http://plone.org/products/filesystemstorage>
>  >> >>
>  >> >> 2009/7/31 Luciano Pacheco <[hidden email]
>  >> >> <mailto:lucmult%40gmail.com>>:
>  >> >> >
>  >> >> >
>  >> >> > 2009/7/31 Alexandre Marinho <[hidden email]
>  >> >> <mailto:lyralemos%40gmail.com>>
>  >> >> >>
>  >> >> >>
>  >> >> >> Acredito que a grande quantidade de dados não seja uma

limitação do
>  >> >> ZODB,
>  >> >> >> usando corretamente o catalogo e so "acordando" os objetos
>  > quando for
>  >> >> >> estritamente necessário... o único problema será o tamanho do
>  >> >> Data.fs que
>  >> >> >> realmente pode chegar em gigas.
>  >> >> >
>  >> >> > Concordo que podemos ter o ZODB mesmo em casos com muitos
dados, as
>  >> >> vezes
>  >> >> > temos que tomar alguns cuidados, mas toda aplicação grande
precisa de
>  >> >> > cuidados, mesmo em base relacional.
>  >> >> >
>  >> >> >>
>  >> >> >> Á unica situação em que usei uma base relacional foi quando
>  > precisava
>  >> >> >> fazer soma e agrupamento de valores. Ai era mais fácil
utilizar SQL

>  >> >> no lugar
>  >> >> >> do ZODB.
>  >> >> >
>  >> >> > Eu fiz um produto que pode-se utilizar para fazer o agrupamento,
>  > ai não
>  >> >> > precisei usar SQL \o/
>  >> >> >
>  >> >> > http://pypi.python.org/pypi/collective.pivottable
>  >> >> <http://pypi.python.org/pypi/collective.pivottable>
>  >> >> >
>  >> >> > Sobre utilizar o SQL, eu acho tão simples e eficiente utilizar o
>  >> >> ZODB que
>  >> >> > prefiro ficar com ele, eu usava muito SQL em outros tipos de
>  >> >> aplicação, mas
>  >> >> > é tão bom viver sem ele. :-)
>  >> >> >
>  >> >> > Até mais,
>  >> >> > --
>  >> >> > Luciano Pacheco
>  >> >> > Simples Consultoria
>  >> >> > www.simplesconsultoria.com.br
>  >> >> >
>  >> >> >
>  >> >>
>  >> >> --
>  >> >>
>  >> >> --
>  >> >> Rodrigo Castardo
>  >> >> Liberiun
>  >> >> COO
>  >> >> [hidden email] <mailto:rodrigocastardo%40liberiun.com>
>  >> >> [phone]
>  >> >> [phone]
>  >> >>
>  >> >>
>  >> >
>  >> >
>  >>
>  >> --
>  >>
>  >> --
>  >> Rodrigo Castardo
>  >> Liberiun
>  >> COO
>  >> [hidden email]
>  >> [phone]
>  >> [phone]
>  >>
>  >> <!-- #ygrp-mkp{ border: 1px solid #d8d8d8; font-family: Arial; margin:
>  > 14px 0px; padding: 0px 14px; } #ygrp-mkp hr{ border: 1px solid #d8d8d8;
>  > } #ygrp-mkp #hd{ color: #628c2a; font-size: 85%; font-weight: bold;
>  > line-height: 122%; margin: 10px 0px; } #ygrp-mkp #ads{ margin-bottom:
>  > 10px; } #ygrp-mkp .ad{ padding: 0 0; } #ygrp-mkp .ad a{ color: #0000ff;
>  > text-decoration: none; } --> <!-- #ygrp-sponsor #ygrp-lc{ font-family:
>  > Arial; } #ygrp-sponsor #ygrp-lc #hd{ margin: 10px 0px; font-weight:
>  > bold; font-size: 78%; line-height: 122%; } #ygrp-sponsor #ygrp-lc .ad{
>  > margin-bottom: 10px; padding: 0 0; } --> <!-- #ygrp-mlmsg
>  > {font-size:13px; font-family:
>  > arial,helvetica,clean,sans-serif;*font-size:small;*font:x-small;}
>  > #ygrp-mlmsg table {font-size:inherit;font:100%;} #ygrp-mlmsg select,
>  > input, textarea {font:99% arial,helvetica,clean,sans-serif;} #ygrp-mlmsg
>  > pre, code {font:115% monospace;*font-size:100%;} #ygrp-mlmsg *
>  > {line-height:1.22em;} #ygrp-text{ font-family: Georgia; } #ygrp-text p{
>  > margin: 0 0 1em 0; } dd.last p a { font-family: Verdana; font-weight:
>  > bold; } #ygrp-vitnav{ padding-top: 10px; font-family: Verdana;
>  > font-size: 77%; margin: 0; } #ygrp-vitnav a{ padding: 0 1px; }
>  > #ygrp-mlmsg #logo{ padding-bottom: 10px; } #ygrp-reco { margin-bottom:
>  > 20px; padding: 0px; } #ygrp-reco #reco-head { font-weight: bold; color:
>  > #ff7900; } #reco-category{ font-size: 77%; } #reco-desc{ font-size: 77%;
>  > } #ygrp-vital a{ text-decoration: none; } #ygrp-vital a:hover{
>  > text-decoration: underline; } #ygrp-sponsor #ov ul{ padding: 0 0 0 8px;
>  > margin: 0; } #ygrp-sponsor #ov li{ list-style-type: square; padding: 6px
>  > 0; font-size: 77%; } #ygrp-sponsor #ov li a{ text-decoration: none;
>  > font-size: 130%; } #ygrp-sponsor #nc{ background-color: #eee;
>  > margin-bottom: 20px; padding: 0 8px; } #ygrp-sponsor .ad{ padding: 8px
>  > 0; } #ygrp-sponsor .ad #hd1{ font-family: Arial; font-weight: bold;
>  > color: #628c2a; font-size: 100%; line-height: 122%; } #ygrp-sponsor .ad
>  > a{ text-decoration: none; } #ygrp-sponsor .ad a:hover{ text-decoration:
>  > underline; } #ygrp-sponsor .ad p{ margin: 0; font-weight: normal; color:
>  > #000000; } o{font-size: 0; } .MsoNormal{ margin: 0 0 0 0; } #ygrp-text
>  > tt{ font-size: 120%; } blockquote{margin: 0 0 0 4px;} .replbq{margin:4}
>  > dd.last p span { margin-right: 10px; font-family: Verdana; font-weight:
>  > bold; } dd.last p span.yshortcuts { margin-right: 0; } div.photo-title
>  > a, div.photo-title a:active, div.photo-title a:hover, div.photo-title
>  > a:visited { text-decoration: none; } div.file-title a, div.file-title
>  > a:active, div.file-title a:hover, div.file-title a:visited {
>  > text-decoration: none; } #ygrp-msg p#attach-count { clear: both;
>  > padding: 15px 0 3px 0; overflow: hidden; } #ygrp-msg p#attach-count span
>  > { color: #1E66AE; font-weight: bold; } div#ygrp-mlmsg #ygrp-msg p a
>  > span.yshortcuts { font-family: Verdana; font-size: 10px; font-weight:
>  > normal; } #ygrp-msg p a { font-family: Verdana; } #ygrp-mlmsg a { color:
>  > #1E66AE; } div.attach-table div div a { text-decoration: none; }
>  > div.attach-table { width: 400px; } -->
>  >
>  >
>
>  --
>
>  --
>  Rodrigo Castardo
>  Liberiun
>  COO
>  [hidden email]
>  [phone]
>  [phone]
>  
>  <!-- #ygrp-mkp{ border: 1px solid #d8d8d8; font-family: Arial; margin:

14px 0px; padding: 0px 14px; } #ygrp-mkp hr{ border: 1px solid #d8d8d8;
} #ygrp-mkp #hd{ color: #628c2a; font-size: 85%; font-weight: bold;
line-height: 122%; margin: 10px 0px; } #ygrp-mkp #ads{ margin-bottom:
10px; } #ygrp-mkp .ad{ padding: 0 0; } #ygrp-mkp .ad a{ color: #0000ff;
text-decoration: none; } --> <!-- #ygrp-sponsor #ygrp-lc{ font-family:
Arial; } #ygrp-sponsor #ygrp-lc #hd{ margin: 10px 0px; font-weight:
bold; font-size: 78%; line-height: 122%; } #ygrp-sponsor #ygrp-lc .ad{
margin-bottom: 10px; padding: 0 0; } --> <!-- #ygrp-mlmsg
{font-size:13px; font-family:
arial,helvetica,clean,sans-serif;*font-size:small;*font:x-small;}
#ygrp-mlmsg table {font-size:inherit;font:100%;} #ygrp-mlmsg select,
input, textarea {font:99% arial,helvetica,clean,sans-serif;} #ygrp-mlmsg
pre, code {font:115% monospace;*font-size:100%;} #ygrp-mlmsg *
{line-height:1.22em;} #ygrp-text{ font-family: Georgia; } #ygrp-text p{
margin: 0 0 1em 0; } dd.last p a { font-family: Verdana; font-weight:
bold; } #ygrp-vitnav{ padding-top: 10px; font-family: Verdana;
font-size: 77%; margin: 0; } #ygrp-vitnav a{ padding: 0 1px; }
#ygrp-mlmsg #logo{ padding-bottom: 10px; } #ygrp-reco { margin-bottom:
20px; padding: 0px; } #ygrp-reco #reco-head { font-weight: bold; color:
#ff7900; } #reco-category{ font-size: 77%; } #reco-desc{ font-size: 77%;
} #ygrp-vital a{ text-decoration: none; } #ygrp-vital a:hover{
text-decoration: underline; } #ygrp-sponsor #ov ul{ padding: 0 0 0 8px;
margin: 0; } #ygrp-sponsor #ov li{ list-style-type: square; padding: 6px
0; font-size: 77%; } #ygrp-sponsor #ov li a{ text-decoration: none;
font-size: 130%; } #ygrp-sponsor #nc{ background-color: #eee;
margin-bottom: 20px; padding: 0 8px; } #ygrp-sponsor .ad{ padding: 8px
0; } #ygrp-sponsor .ad #hd1{ font-family: Arial; font-weight: bold;
color: #628c2a; font-size: 100%; line-height: 122%; } #ygrp-sponsor .ad
a{ text-decoration: none; } #ygrp-sponsor .ad a:hover{ text-decoration:
underline; } #ygrp-sponsor .ad p{ margin: 0; font-weight: normal; color:
#000000; } o{font-size: 0; } .MsoNormal{ margin: 0 0 0 0; } #ygrp-text
tt{ font-size: 120%; } blockquote{margin: 0 0 0 4px;} .replbq{margin:4}
dd.last p span { margin-right: 10px; font-family: Verdana; font-weight:
bold; } dd.last p span.yshortcuts { margin-right: 0; } div.photo-title
a, div.photo-title a:active, div.photo-title a:hover, div.photo-title
a:visited { text-decoration: none; } div.file-title a, div.file-title
a:active, div.file-title a:hover, div.file-title a:visited {
text-decoration: none; } #ygrp-msg p#attach-count { clear: both;
padding: 15px 0 3px 0; overflow: hidden; } #ygrp-msg p#attach-count span
{ color: #1E66AE; font-weight: bold; } div#ygrp-mlmsg #ygrp-msg p a
span.yshortcuts { font-family: Verdana; font-size: 10px; font-weight:
normal; } #ygrp-msg p a { font-family: Verdana; } #ygrp-mlmsg a { color:
#1E66AE; } div.attach-table div div a { text-decoration: none; }
div.attach-table { width: 400px; } -->

[Rodrigo Castardo]

2009/8/13 Rafael Monnerat <[hidden email]>:

>
>
> Opa,
>
> Rodrigo Castardo wrote:
>>
>>
>> Fala Rafael =)
>>
>> 2009/8/11 Rafael Monnerat <[hidden email]>:
>> >
>> >
>> > E ai Rodrigo,
>> >
>> > Rodrigo Castardo wrote:
>> >>
>> >>
>> >> Fala Rafael,
>> >>
>> >> 2009/8/6 Rafael Monnerat <[hidden email]>:
>> >>
>> >> <corta> ...
>> >>
>> >> > Eu acredito que o ZODB, nao tem problemas com armazenamento mesmo

pra

>> >> > aplicações financeiras prova disso é o [1], basta só planejar
>> >> > direitinho, criar mounting points... etc etc.
>> >>
>> >> Claro, eu concordo contigo na questão tecnológica pura. Porém o RP5
>> >> tem inumeras funcionalidades interessantes que não existem por padrão,
>> >> este é um ponto.
>> >>
>> >> Outro ponto é que, embora a essência da pergunta seja técnica, estamos
>> >> falando sob uma ótica um pouco mais abrangente, uma visão mais
>> >> sócio-técnica. O que eu coloquei não foi que o ZODB não serve para
>> >> aplicações financeiras, de forma alguma, ele pode muito bem ser
>> >> utilizado, porém com uma certa expertise que imagino que o autor da
>> >> pergunta ainda não tem.
>> >>
>> >> Sem contar o esforco de integracao e a fase de convencimento de que o
>> >> banco escolhidos eh algo novo, diferente dos outros bancos (que
>> >> normalmente tem investimentos muito altos e confiabilidade consumada),
>> >> entrar nesse merito em grandes corporacoes eh complicado.
>> >>
>> >> Mas como vc bem disse, tecnicamente eh possível sim.
>> >
>> > Bem, meu ponto de vista era puramente técnico (tecnicamente quase tudo

é
>> > possível hehe). E também acho que muitas vezes as pessoas sao
>> > desestimuladas a acreditar no ZODB, por vários motivos. Eu só dei um
>> > exemplo de caso de uso, onde o ZODB possui muitos milhares de
documentos

>> > (ou objetos) em uma aplicação financeira.
>>
>> "Tecnicamente td eh possivel" Essa frase eh meio emblematica =)
>>
>> Claro, acho otimo teu exemplo ... o case de vcs fala sozinho, e eh bem
>> conhecido ... ateh conversei com um developer de vcs no FISL, ele
>> quase sempre aparece junto com o Claudio no INPI, mas sempre esqueco o
>> nome dele =)
>>
>
> Bem, era eu :)
>
>> >
>> >> > O grande problema é a buscar dentro de uma base de dados > 10
> milhoes de
>> >> > objetos por exemplo, ou quando você que fazer uma operaçao que
> precisa
>> >> > de muitos objetos (exemplo calcular a movimentação financeira do
> ultimo
>> >> > ano). Pra resolver esse "pequeno" problema o ERP5 substituiu o
> ZCatalog
>> >> > pelo ZSQLCatalog a anos atrás, mas o BD relacional é usado apenas

pra

>> >> > catalogação, toda a persistência e armazenamento dos dados ainda
>> >> > permanecem no ZODB.
>> >>
>> >> Mais aqui vc jah nao estah falando de storage, e sim de outras
>> > estrategias.
>> >
>> > Bem, esta de certa forma relacionado, porque a quantidade de objetos
>> > influencia na busca dele. Mas sim, isso nao é necessariamente
>> > diretamente ao storage.
>>
>> Vdd, no caso de aplicacoes Zope eh diferente o modo como vc pensa, as
>> coisas se unem, aplicacao+storage+servidor de aplicacao+etc ... e
>> poucas coisas sao eficientes qdo sao mto pontuais.
>>
>> >>
>> >> Estes tipos de estrategia sao bem interessantes e tem outras coisas q
>> >> poderiam ser elencadas pra isso, por exemplo:
>> >
>> > Eu vou dar meus exemplos tbm : )
>>
>> Como se diz, so awesome =)
>>
>> >>
>> >> 1- Usar memcached pra segurar em cache as operacoes que tem baixa
>> >> tempestividade ou grande carga de processamento
>> >
>> > Esse é um ponto interessante, no erp5 a gente tem suporte nativo ao
>> > memcache e recentemente foi adicionado suporte ao Flare [1]. Estamos
>> > mudando os caches persistentes (que usavam PersistenseMapping por algum
>> > motivo) para usar o Flare. Isso reduz as modificações no ZODB e evita
>> > que o cache seja perdido em um restart.
>>
>> Essa eh nova, bem interessante.
>>
>> Nossa API de memcached eh software livre e pode ser baixada em:
>>
>> http://bitbucket.org/liberiun/liberiunportalcaching/
>>
>> >> 2- Separar o catalog, deixar ele fora ... usando o Lucene (um solr da
>> > vida)
>> >
>> > Como a gente usa MySQL , temos support nativo o Senna[2] (segundo a
>> > lenda é mais rapido que o Lucene mas isso gera muitas controvérsias
> hehehe)
>>
>> Essa lenda eu desconhecia, conhecia apenas a lenda do Lucene =)
>>
>> >> 3- Usar Deliverance + tema vazio no plone, pra poupar o plone de
>> >> processar um tema (q eh bem pesado) e poder processar mais requisicoes
>> >
>> > Eu nao conheço deliverance direito, preciso me atualizar : )
>>
>> Basicamente tu tem um cara WSGI que lida com o tema, vc tira essa
>> carga de dentro do Plone (que soa a camisa pra montar esse
>> quebra-cabeca).
>>
>> Esse cara WSGI tem o tema morto (XHTML+CSS puros, sem logica) e regras
>> (troque o id x do plone pelo y do tema morto), qdo o acesso (user ->
>> deliv -> zope) chega ao portal normalmente, na volta ele sofre a
>> aplicacao das regras e faz a magica!
>>
>> Nosso portal usa Deliverance, e roda em uma maquina que tem poucos
>> recursos (sao 512 de RAM) e nao estamos usando praticamente nenhum
>> cache, e ele tem uma velocidade mto boa.
>>
>
> Interessate.
>
>> >>
>> >> E por ai vai, mas a duvida era de storage em si, claro q eh bom levar
>> >> isso td em consideração tbm ...
>> >
>> > Bem, eu nao acho que storage por si só seja um problema, o problema é o
>> > como você um arquivo (ou mais) de 100 GB depois : ), acho que o sistema
>> > tem muitos outros gargalos antes do tamanho do Storage ser um problema.
>>
>> Concordo, a equacao eh mais complexa e o storage eh uma parte dela.
>>
>> Acho importante tbm citar que estas evolucoes todas q estou trocando
>> com o Rafael sao para grandes projetos (leia-se: gde
>> sites/portais/intranets/sistemas aliados a um grande assedio). Se vc
>> tem um projeto, ou um grande projeto, que nao tem mtos acessos vc pode
>> usar o Plone padrao pra atender a mtos casos ... e em caso de
>> problemas, coisas mais simples podem te garantir performance.
>>
>> No caso estas praticas nos utilizamos para cases com 70 milhoes de
>> hits/mes. Temos um caso que tem 140G de transferencia por dia, e
>> crescendo. O Rafael deve ter numeros de transacoes absurdos,
>> compartilha com a gente Rafael?
>>
>
> Transações de que ZODB ou financeiras?
>
> A aplicação gerencia entre outras coisas, controle monetário. Cada
> Cédula produzida pelo Banco tem um objecto correspondente no ERP5 e com
> tem um workflow.
>
> Eu nao sei os números exatos porque eu nao trabalhei diretamente no
> projeto. Mas o ERP5 usa 46 mounting points em um único ZEO, 32 Zopes
> como clientes e 1 mysql para o catalog. Cada modulo (cada modulo é um
> folder) tem alguns milhões objetos, acredite eu nunca perguntei quanto
> da no total, mas já deve ter mais de 20 milhões a algum tempo.
>
> Se somarmos o ZODB dá aproximadamente 64 GB. Que eu até acho pouco hoje
> em dia...
>
> Nós acreditamos que somos capazes de implantar o ERP5 em projetos que
> cheguem a 1 000 000 000 (um bilhão) de objetos, o difícil é encontrar
> alguém que precise de tantos objetos assim. e que esteja interessado em
> bancar. : )

Bacana cara!

É ... pra casos como estes toda evolução é válida!

Como eu esperava, números altos ... parabéns pelo Projeto Rafael!

Gde abraço.

> []'s
>
> Rafael
>
>> Valeu Rafael, um abraco!
>>
>> > [1] http://labs.gree.jp/Top/OpenSource/Flare-en.html
>> > [2] http://qwik.jp/senna/
>> >
>> >> Abracos
>> >>
>> >> > [1] http://www.erp5.com/news-central.bank
>> >> >
>> >> > []'s
>> >> >
>> >> > Rafael
>> >> >
>> >> >>
>> >> >> Em casos onde mesmo a informação de conteúdo de um portal é grande,
>> >> >> você tem artifícios como o FSS[1] e o Catalog mencionado pelo
> Marinho.
>> >> >> Como no caso do pessoal da EBC (antiga RADIOBRAS), eles tem as
>> >> >> notícias todas em ZODB (e estamos falando de uns 10G pelo menos)
> e os
>> >> >> infográficos (imagens em alta, vídeos, flash, etc...) estão todos

em
>> >> >> File System (na época somavam 40G).
>> >> >>
>> >> >> Com os binários em FS você pode trabalhar mais tranquilo com o
> ZODB. É
>> >> >> a mesma coisa que fazemos com streaming por exemplo, os vídeos
estão

>> >> >> em FS e o conteúdo todo em ZODB.
>> >> >>
>> >> >> Abraços.
>> >> >>
>> >> >> [1] http://plone.org/products/filesystemstorage
>> >> >> <http://plone.org/products/filesystemstorage>
>> >> >>
>> >> >> 2009/7/31 Luciano Pacheco <[hidden email]
>> >> >> <mailto:lucmult%40gmail.com <lucmult%2540gmail.com>>>:
>> >> >> >
>> >> >> >
>> >> >> > 2009/7/31 Alexandre Marinho <[hidden email]
>> >> >> <mailto:lyralemos%40gmail.com <lyralemos%2540gmail.com>>>
>> >> >> >>
>> >> >> >>
>> >> >> >> Acredito que a grande quantidade de dados não seja uma
> limitação do
>> >> >> ZODB,
>> >> >> >> usando corretamente o catalogo e so "acordando" os objetos
>> > quando for
>> >> >> >> estritamente necessário... o único problema será o tamanho do
>> >> >> Data.fs que
>> >> >> >> realmente pode chegar em gigas.
>> >> >> >
>> >> >> > Concordo que podemos ter o ZODB mesmo em casos com muitos
> dados, as
>> >> >> vezes
>> >> >> > temos que tomar alguns cuidados, mas toda aplicação grande
> precisa de
>> >> >> > cuidados, mesmo em base relacional.
>> >> >> >
>> >> >> >>
>> >> >> >> Á unica situação em que usei uma base relacional foi quando
>> > precisava
>> >> >> >> fazer soma e agrupamento de valores. Ai era mais fácil
> utilizar SQL
>> >> >> no lugar
>> >> >> >> do ZODB.
>> >> >> >
>> >> >> > Eu fiz um produto que pode-se utilizar para fazer o agrupamento,
>> > ai não
>> >> >> > precisei usar SQL \o/
>> >> >> >
>> >> >> > http://pypi.python.org/pypi/collective.pivottable
>> >> >> <http://pypi.python.org/pypi/collective.pivottable>
>> >> >> >
>> >> >> > Sobre utilizar o SQL, eu acho tão simples e eficiente utilizar o
>> >> >> ZODB que
>> >> >> > prefiro ficar com ele, eu usava muito SQL em outros tipos de
>> >> >> aplicação, mas
>> >> >> > é tão bom viver sem ele. :-)
>> >> >> >
>> >> >> > Até mais,
>> >> >> > --
>> >> >> > Luciano Pacheco
>> >> >> > Simples Consultoria
>> >> >> > www.simplesconsultoria.com.br
>> >> >> >
>> >> >> >
>> >> >>
>> >> >> --
>> >> >>
>> >> >> --
>> >> >> Rodrigo Castardo
>> >> >> Liberiun
>> >> >> COO
>> >> >> [hidden email] <mailto:rodrigocastardo%40liberiun.com<rodrigocastardo%2540liberiun.com>
>
>> >> >> [phone]
>> >> >> [phone]
>> >> >>
>> >> >>
>> >> >
>> >> >
>> >>
>> >> --
>> >>
>> >> --
>> >> Rodrigo Castardo
>> >> Liberiun
>> >> COO
>> >> [hidden email]
>> >> [phone]
>> >> [phone]
>> >>
>> >> <!-- #ygrp-mkp{ border: 1px solid #d8d8d8; font-family: Arial; margin:
>> > 14px 0px; padding: 0px 14px; } #ygrp-mkp hr{ border: 1px solid #d8d8d8;
>> > } #ygrp-mkp #hd{ color: #628c2a; font-size: 85%; font-weight: bold;
>> > line-height: 122%; margin: 10px 0px; } #ygrp-mkp #ads{ margin-bottom:
>> > 10px; } #ygrp-mkp .ad{ padding: 0 0; } #ygrp-mkp .ad a{ color: #0000ff;
>> > text-decoration: none; } --> <!-- #ygrp-sponsor #ygrp-lc{ font-family:
>> > Arial; } #ygrp-sponsor #ygrp-lc #hd{ margin: 10px 0px; font-weight:
>> > bold; font-size: 78%; line-height: 122%; } #ygrp-sponsor #ygrp-lc .ad{
>> > margin-bottom: 10px; padding: 0 0; } --> <!-- #ygrp-mlmsg
>> > {font-size:13px; font-family:
>> > arial,helvetica,clean,sans-serif;*font-size:small;*font:x-small;}
>> > #ygrp-mlmsg table {font-size:inherit;font:100%;} #ygrp-mlmsg select,
>> > input, textarea {font:99% arial,helvetica,clean,sans-serif;}

#ygrp-mlmsg
>> > pre, code {font:115% monospace;*font-size:100%;} #ygrp-mlmsg *
>> > {line-height:1.22em;} #ygrp-text{ font-family: Georgia; } #ygrp-text p{
>> > margin: 0 0 1em 0; } dd.last p a { font-family: Verdana; font-weight:
>> > bold; } #ygrp-vitnav{ padding-top: 10px; font-family: Verdana;
>> > font-size: 77%; margin: 0; } #ygrp-vitnav a{ padding: 0 1px; }
>> > #ygrp-mlmsg #logo{ padding-bottom: 10px; } #ygrp-reco { margin-bottom:
>> > 20px; padding: 0px; } #ygrp-reco #reco-head { font-weight: bold; color:
>> > #ff7900; } #reco-category{ font-size: 77%; } #reco-desc{ font-size:
77%;
>> > } #ygrp-vital a{ text-decoration: none; } #ygrp-vital a:hover{
>> > text-decoration: underline; } #ygrp-sponsor #ov ul{ padding: 0 0 0 8px;
>> > margin: 0; } #ygrp-sponsor #ov li{ list-style-type: square; padding:
6px
>> > 0; font-size: 77%; } #ygrp-sponsor #ov li a{ text-decoration: none;
>> > font-size: 130%; } #ygrp-sponsor #nc{ background-color: #eee;
>> > margin-bottom: 20px; padding: 0 8px; } #ygrp-sponsor .ad{ padding: 8px
>> > 0; } #ygrp-sponsor .ad #hd1{ font-family: Arial; font-weight: bold;
>> > color: #628c2a; font-size: 100%; line-height: 122%; } #ygrp-sponsor .ad
>> > a{ text-decoration: none; } #ygrp-sponsor .ad a:hover{ text-decoration:
>> > underline; } #ygrp-sponsor .ad p{ margin: 0; font-weight: normal;
color:
>> > #000000; } o{font-size: 0; } .MsoNormal{ margin: 0 0 0 0; } #ygrp-text
>> > tt{ font-size: 120%; } blockquote{margin: 0 0 0 4px;} .replbq{margin:4}
>> > dd.last p span { margin-right: 10px; font-family: Verdana; font-weight:
>> > bold; } dd.last p span.yshortcuts { margin-right: 0; } div.photo-title
>> > a, div.photo-title a:active, div.photo-title a:hover, div.photo-title
>> > a:visited { text-decoration: none; } div.file-title a, div.file-title
>> > a:active, div.file-title a:hover, div.file-title a:visited {
>> > text-decoration: none; } #ygrp-msg p#attach-count { clear: both;
>> > padding: 15px 0 3px 0; overflow: hidden; } #ygrp-msg p#attach-count
span
>> > { color: #1E66AE; font-weight: bold; } div#ygrp-mlmsg #ygrp-msg p a
>> > span.yshortcuts { font-family: Verdana; font-size: 10px; font-weight:
>> > normal; } #ygrp-msg p a { font-family: Verdana; } #ygrp-mlmsg a {
color:

>> > #1E66AE; } div.attach-table div div a { text-decoration: none; }
>> > div.attach-table { width: 400px; } -->
>> >
>> >
>>
>> --
>>
>> --
>> Rodrigo Castardo
>> Liberiun
>> COO
>> [hidden email]
>> [phone]
>> [phone]
>>
>> <!-- #ygrp-mkp{ border: 1px solid #d8d8d8; font-family: Arial; margin:
> 14px 0px; padding: 0px 14px; } #ygrp-mkp hr{ border: 1px solid #d8d8d8;
> } #ygrp-mkp #hd{ color: #628c2a; font-size: 85%; font-weight: bold;
> line-height: 122%; margin: 10px 0px; } #ygrp-mkp #ads{ margin-bottom:
> 10px; } #ygrp-mkp .ad{ padding: 0 0; } #ygrp-mkp .ad a{ color: #0000ff;
> text-decoration: none; } --> <!-- #ygrp-sponsor #ygrp-lc{ font-family:
> Arial; } #ygrp-sponsor #ygrp-lc #hd{ margin: 10px 0px; font-weight:
> bold; font-size: 78%; line-height: 122%; } #ygrp-sponsor #ygrp-lc .ad{
> margin-bottom: 10px; padding: 0 0; } --> <!-- #ygrp-mlmsg
> {font-size:13px; font-family:
> arial,helvetica,clean,sans-serif;*font-size:small;*font:x-small;}
> #ygrp-mlmsg table {font-size:inherit;font:100%;} #ygrp-mlmsg select,
> input, textarea {font:99% arial,helvetica,clean,sans-serif;} #ygrp-mlmsg
> pre, code {font:115% monospace;*font-size:100%;} #ygrp-mlmsg *
> {line-height:1.22em;} #ygrp-text{ font-family: Georgia; } #ygrp-text p{
> margin: 0 0 1em 0; } dd.last p a { font-family: Verdana; font-weight:
> bold; } #ygrp-vitnav{ padding-top: 10px; font-family: Verdana;
> font-size: 77%; margin: 0; } #ygrp-vitnav a{ padding: 0 1px; }
> #ygrp-mlmsg #logo{ padding-bottom: 10px; } #ygrp-reco { margin-bottom:
> 20px; padding: 0px; } #ygrp-reco #reco-head { font-weight: bold; color:
> #ff7900; } #reco-category{ font-size: 77%; } #reco-desc{ font-size: 77%;
> } #ygrp-vital a{ text-decoration: none; } #ygrp-vital a:hover{
> text-decoration: underline; } #ygrp-sponsor #ov ul{ padding: 0 0 0 8px;
> margin: 0; } #ygrp-sponsor #ov li{ list-style-type: square; padding: 6px
> 0; font-size: 77%; } #ygrp-sponsor #ov li a{ text-decoration: none;
> font-size: 130%; } #ygrp-sponsor #nc{ background-color: #eee;
> margin-bottom: 20px; padding: 0 8px; } #ygrp-sponsor .ad{ padding: 8px
> 0; } #ygrp-sponsor .ad #hd1{ font-family: Arial; font-weight: bold;
> color: #628c2a; font-size: 100%; line-height: 122%; } #ygrp-sponsor .ad
> a{ text-decoration: none; } #ygrp-sponsor .ad a:hover{ text-decoration:
> underline; } #ygrp-sponsor .ad p{ margin: 0; font-weight: normal; color:
> #000000; } o{font-size: 0; } .MsoNormal{ margin: 0 0 0 0; } #ygrp-text
> tt{ font-size: 120%; } blockquote{margin: 0 0 0 4px;} .replbq{margin:4}
> dd.last p span { margin-right: 10px; font-family: Verdana; font-weight:
> bold; } dd.last p span.yshortcuts { margin-right: 0; } div.photo-title
> a, div.photo-title a:active, div.photo-title a:hover, div.photo-title
> a:visited { text-decoration: none; } div.file-title a, div.file-title
> a:active, div.file-title a:hover, div.file-title a:visited {
> text-decoration: none; } #ygrp-msg p#attach-count { clear: both;
> padding: 15px 0 3px 0; overflow: hidden; } #ygrp-msg p#attach-count span
> { color: #1E66AE; font-weight: bold; } div#ygrp-mlmsg #ygrp-msg p a
> span.yshortcuts { font-family: Verdana; font-size: 10px; font-weight:
> normal; } #ygrp-msg p a { font-family: Verdana; } #ygrp-mlmsg a { color:
> #1E66AE; } div.attach-table div div a { text-decoration: none; }
> div.attach-table { width: 400px; } -->
>
>

--



--
Rodrigo Castardo
Liberiun
COO
[hidden email]
[phone]
[phone]