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.


>  > 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 <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; } -->

Responder a