Fala Rafael =)

2009/8/11 Rafael Monnerat <rmonner...@gmail.com>:
>
>
> E ai Rodrigo,
>
> Rodrigo Castardo wrote:
>>
>>
>> Fala Rafael,
>>
>> 2009/8/6 Rafael Monnerat <rmonner...@gmail.com>:
>>
>> <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 <lucm...@gmail.com
>> >> <mailto:lucmult%40gmail.com>>:
>> >> >
>> >> >
>> >> > 2009/7/31 Alexandre Marinho <lyrale...@gmail.com
>> >> <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
>> >> rodrigocasta...@liberiun.com <mailto:rodrigocastardo%40liberiun.com>
>> >> +55 61 9123-7847
>> >> +55 61 3468-2662
>> >>
>> >>
>> >
>> >
>>
>> --
>>
>> --
>> Rodrigo Castardo
>> Liberiun
>> COO
>> rodrigocasta...@liberiun.com
>> +55 61 9123-7847
>> +55 61 3468-2662
>>
>> <!-- #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
rodrigocasta...@liberiun.com
+55 61 9123-7847
+55 61 3468-2662

Responder a