Opa, Rodrigo Castardo wrote: > > > 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 =) >
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 <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 > > <!-- #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; } -->
