Vários Bancos ou poucos?

[Jean Franceschi 0]

Opa gente, tudo na paz?

 

Seguinte, fiz um site que é acessado por muitos usuários e eles tem milhares de acessos diários, mas notei que os banco de dados estão aumentando de tamanho significativamente, e pensei em uma solução simples...

 

Ao invés de usar os comuns 15 bancos de dados (eu uso acess pra não ter q mudar todo script), usaria 5 bancos de dados que são divididos entre os usuários (pra login, pra mapeamento, etc) e estava pensando em toda vez que um usuário se inscrever no site, o script asp vai fazer uma cópia dos outros 10 banco acess pra uma pasta só daquele usuário. Assim, ao invés de ter 15 banco de dados inflando muito, eu teria milhares de pequenos banco de dados que só seriam aberto quando um usuário acessace aquela determinada opção.

 

Um exemplo:

 

1. Eu faço login, então usa o banco de dados que todo mundo usa;

2. enquanto acesso minha conta, o script roda usando minha ID pra identificar quais são os "meus" bancos de dados que ele vai acessar, no caso são 10, um pra meus clientes, um pras minhas listas de compras, outro pra minha agenda, etc. Estes bancos de dados só são acessados por mim!

3. Quando vou interagir com outro usuário, acessando a agenda dele por exemplo, então o script que tem as funções de abertura dos banco de dados vai abrir os meus bancos de dados (pq eu uso pra tudo) e vai abrir os 10 do usuário que vou interagir!

 

Estes 10 bancos de dados que cada usuário teria seriam significativamente pequenos, não teriam mais do que 30 ou 40 registros denro deles. Porém, usando 1 banco que divida as informações (como esta atualmente), chega a ter 500 mil registros, sempre apagando, criando, etc, novos registros. Quando alguém faz uma pesquisa em um BD destes que é muito grande eu notei que demora demais pro site abrir... pq ele vai buscar o registro e se não encontrar ele vai varrer todos os 500 mil registros.

 

Por isso pensei em reduzir o tempod e busca, pq se um usuário for buscar algo, ele vai buscar diretamente "naquele usuário" o que procura e como tem pouco mais de 50 registros no BD ficaria mais rápido.

 

 

Estou perguntando aqui antes de tentar fazer isso na prática, pq se eu resolver que assim seria mais rápido e resolver mudar, não vou ter 30 dias de trabalho pra desfazer se algo der errado. E existe aqui gente muito mais entendida que eu nessas situações. E gostaria de uma opinião de todos que puderem ajudar ou dar idéias =)

 

 

 

ps: não uso nenhum tipo de server sql como BD pq aqui onde eu desenvolvo não teria como testar, e ficar testando tudo online faria meu trabalho demorar cerca de 5 vezes mais, por isso optei pelo acess.

 

 

Abração gente, vou estar pro aqui caso precisem de mais informações sobre o assunto =)

Att, Jean

[retrolink 0]

Ai que ta o problema, tem que ser bem estudado...

 

Se você unir os bancos de dados... ficara ainda maior... e para uma simples pesquisa... que poderia fazer em um dos bancos de dados... nesse caso você terá que abrir de qualquer maneira este bd unido.

 

Cada caso é um caso, o correto seria você mudar do access para o mysql, e isso não demoraria muito, pois você não precisaria modificar o code inteiro... teria que mudar algumas coisinhas e teria um banco que realmente aguenta o tranco.

 

O access de fato não foi feito para comportar projetos de muito acesso ou que exija muitos dados, de qualquer maneira uma hora ou outra você terá que fazer essa mudança.

 

Se cada dia seu bd aumenta... e se tem bastante acesso e participação dos usuários, sinto te informar que em breve você terá sérios problemas com o bd, uma vez que o access é limitado abeça.

 

Por isso não adianta ficar empurrando com a barriga, se for para te da uma dica em relação ao seu caso, eu seria simples e direto... torque urgentemente o access por mysql ou sqlserver, não adianta tentar evitar o inevitável.

 

Uma hora ou outra esse processo tera que ser feito.

[Jean Franceschi 0]

pois é... essa mudança eu vou acabar fazendo apesar de estar inseguro por nunca ter usado mysql ou outro do tipo q não seja acess =\

 

Mas neste caso específico, o que você acha que seria melhor? abrir 10 BDs gigantes ou abrir 20 BD´s pequenos?

Pq veja, se fizer 10 BD´s pequenos pra cada usuário e tiver 1000 usuários acessando ao mesmo tempo, o servidor teria que aguentar abrir 10 mil BD´s pequenos...

 

E se fizer 10 BD´s grandes pra todos usuários ao mesmo tempo, o servidor precisaria aguentar abrir mil vezes os BD´s, porém mais demorado já que as consultas seriam muito maiores =\

 

Meu medo é quando falo em números, acho que o servidor ficaria muito lento pra abrir algo como 10 mil BD´s pequenos ao invés de mil vezes BD´s grandes =\

Sinto saudades de quando tinha 5 acessos diários, era mais fácil naquele tempo =(

[retrolink 0]

Velho, eu faria o mínimo possível, o problema nesse caso é o tamanho, mais concerteza eu reduziria ao máximo, mais tudo organizando... os que fossem mais utilizados juntos... e os menos utilizados separados, tem que ser organizado senão acaba piorando.

[Jean Franceschi 0]

sim, isso q pretendia fazer... os que todos usuários usam ao mesmo tempo eu tava pensando em deixar em 1 BD só... mas os com informação que os usuários veem ou usam só deles mesmos eu faria separado, meu medo é a quantidade absurda de bds que o servidor acabaria abrindo =(

[retrolink 0]

exatamente, existe esse problema, mais pense ai e una de forma mais organizada possível, pode criar um bd e colocar 10 funções utilizadas em outros 10 bds... não necessariamente precisa criar um pra cada.

[Jean Franceschi 0]

só uma dúvida...

 

 

OLEDB é mais rápido que ADODB? pq? qual a diferença? e como sei que no servidor que eu uso tem acesso pra usar OLEDB?

 

pois é, entendi a tua idéia... ao invpés de criar 10 banco de dados pra cada usuário, criar um banco de dados, mas com 10 tabelas internas... realmente, facilitaria muito pro servidor processar as informações =)

 

todos os comando pro mysql e pro sql server são os mesmos usados no acess? tipo:

 

aaa.EXECUTE("SELECT * FROM")

aaa.EXECUTE("INSERT INTO")

aaa.EXECUTE("DELETE * FROM")

[retrolink 0]

veja aqui as diferenças: http://social.msdn.microsoft.com/Forums/pt/504/thread/85116c21-b848-48ed-9a12-4a74f94dfeb3

 

Os comandos pro access e mysql em suma minoria são diferentes, mais em grande parte a mudança será pouca no code.

[Vinicius Ianni 189]

Lendo todos os posts, veio algumas perguntas:

O numero de usuários do sistema tende a aumentar ?

Já fez uma projeção desse aumento de usuários e o quanto demandarão de recursos bem como o quanto o banco de dados irá aumentar ?

 

Separar o bd em bd menores, apenas adia para um pouco mais para frente, o inevitável, que será a migração para um banco de dados projetado para isso, como mysql por exemplo.

 

Sem falar no consumo de espaço em disco desnecessário com informações redundantes que irão existir nesses bancos de dados menores.

 

Como já detectou o problema agora, acho interessante mudar já para outro banco de dados, mysql é bem interessante nessa mudança, tendo em vista que a maioria dos grandes e sérios provedores de hospedagem o utilizam como padrão em seus pacotes de hospedagem.

 

Você poderia criar um banco de dados só com as inforações referentes ao usuários, outro só com as informações referentes ao sistema, e um só para tratar o login por exemplo.

Ficaria assim, mais facil de gerenciar as informações.

 

Haveria algumas mudanças a serem feitas no sistema referentes ao acesso dessas informações, mas não teriam grande impacto no sistema como um todo.

 

Creio que seria mais facil realizar essas operações do que ter o sistema entrando em pane por causa das limitações existentes no access.

[xanburzum 169]

um texto que sempre coloco é, para ter uma atenção ao relacionamento entre as tabelas, na verdade, a impôrtancia de uma modelagem de dados bem definida até os mínimos detalhes, como os campos de relacionamentos, um velho ditado diz, que um relacionamento bem definido é a alma do aplicativo, pois daí saem todas as consultas e operações com o banco, influenciando diretamente na otimização e performance do aplicativo.

[Jean Franceschi 0]

Vinicius...

O número de usuários sempre tende a aumentar, e meu limite de espaço em disco é muito grande, conseguiria suportar até 10 vezes mais usuários q eu tenho se for criar pequenos bancos pra cada usuário. Caso precise de mais espaço é só aumentar ele, simples de se fazer, porém, meu maior medo é o "sistema" não suportar tantos bancos pequenos!

 

Supondo que o usuário acesse junto com outros mil usuários, eles hoje iriam abrir 15 bancos de dados em consultas (média de 10, mas falei 15 pq é o total). Então seria abrir 1000 vezes os 15 BD´s ja existentes. Se eu fizer 10 BD´s pra cada 1 separadamente, o sistema teria que abrir 10 vezes mais que isso, ou seja, se antes abriria 10 mil BDs em consultas, neste caso abriria 100 mil, porém em bancos menores, tornando mais rápido cada consulta.

 

O q eu noto quandfo o sistema abre um BD acess é que o sistema cria outro arquivo pequeno com o mesmo nome do banco, e depois que termina de acessa o bd ele apaga este arquivo (uma espécie de arquivo fantasma). E esse é meu ponto crítico. Se o sistema abrir 1000 arquivos "fantasmas" deixa ele lento (como venho notando atualmente), será que realmente deixaria mais rápido o sistema se ele tiver que abrir 10 mil deles?

 

A lentidão atualmente está por conta de apenas um banco de dados, um que é de mapeamento, nele existem 90 mil registros que nunca se modificam, ou seja, ele serve como padrão apenas para consulta de dados. DIgamos que o usuário queira mapear determinada área, então o sistema abre este BD de mapas, procura alocalização que ele pediu e informa ao sistema os dados daquele ponto específico do mapa (exemplo: Nome, Local_X, Local_Y, Tipo e Bloco). COm os dados que são passados por este banco de mapas e´que ele cria em outro BD o que o suário encontrou, deiando ele mecher.

 

Acontece, que os registros estão alinhados no banco de dados do mapa em ordem numérica pela chave primário (autonumeração), e quando o usuário faz uma consulta que ele tenha que pesquisar os primeiros registros, o sistema é rápido, porém, se o usu[ário pedir pra ele pesquisar tudo, o sistema vira uma patrola, principalmente se ele não acha os dados naquele BD, fazendo o acess buscar em todos os 90 mil registros a localização. Este é um dos mapas que eu pretendia quebrar, ao invés de colocar em um BD só 90 mil registros, eu colcaoria em 9 BD´s apenas 10 mil registros. Acredito que ficaria mais rápido uma busca (e pra abrir o BD certo eu mudo no código asp com ifs a localização, indicando que do 1 ao 10 mil vai pro BD tal, do 10.001 ao 20.000 vai pro outro bd, etc.)

 

Se eu mantiver os BD´s como estão, uma hora vão chegar aos 100 mil registros, e ficar lentos como no BD de mapas (que dei exemplo acima), por isso pensei em fazer vários BD´s menores, pq daí eu não teria limite de usuários nunca, ja que um usuário nunca teria mais do que mil registros em um BD só.

 

Então segue a dúvida... Neste caso específico, seria melhor fazer vários BD´s menores, deixando cada usuário com o seu BD, ou seria melhor manter os poucos BD´s divididos entre os usuários?

 

 

 

Sobre optar por migrar para um BD mais poderoso como mysql, ou sql server, ou um oracle da vida, é uma possibilidade, mas devido a questão financeira, no momento essa não é uma opção válida, já que eu precisaria contratar alguém para migrar e depois administrar estes bancos, e a grana é curta. Por isso minha insistência no acess, pelo menos nos próximos mêses a cinta aqui ta bem apertada, quando melhorar essa vai ser a primeira coisa que faria, migrar para um banco de dados mais poderoso que o acess(apesar de ja ouvir dizer que até txt é mais rápido que acess) =P

 

Agradeço pela atenção e por toda ajuda, estão salvando alguém desesperado =)

[Vinicius Ianni 189]

Veja só os limites do access 2007 aqui

 

E as limitações do access 2002 e 2003 aqui

 

Sobre contratar alguem para cuidar só do banco de dados, não sei se seria o caso para este momento, veja, o mysql é bem amigavel e depois de configurado e tals, praticamente de cuida sozinho.

 

Existem sim, várias diferenças entre o access e o mysql, fazendo uma analogia, seria você ter uma saveiro (access) e um caminhão (mysql) adaptavel a sua necessidade, que pode ser um pequeno desses de rodar na cidade, até um desses grandes que são quase uma carreta.

 

Peguei um bom tempo atrás, um sistema para desenvolver que devido aos vários requisitos e projeções, se optasse por access que era mais confortavel para mim por ja conhece-lo, cairia no problema pelo qual está passando agora, ou mesmo não conhecendo mysql, não teria esse tipo de problema.

 

Optei em usar o mysql, instalei ele localmente, li a ajuda on line dele que é muito boa e bem completa, testei exemplos existentes aqui no forum, e fui desenvolvendo o sistema, toda a parte que fazia interação com o banco de dados, desenvolvi rapidamente, a dificuldade que tive foi me adaptar a alguns comandos sql que são diferentes se comparados ao access, mas mesmo assim são facilmente superaveis.

 

Se optar em dividir em tabelas menores, terá de mudar alguns pontos do sistema, assim, como a mudança será feita de qualquer forma, ainda acho interessante migrar seu sistema do access para o mysql, efetuar as alterações necessárias, e depois disso não se preocupar com banco de dados, tendo em vista a robustez do mysql.

 

Algo que poderia ser feito independente do banco de dados escolhido, seria otimizar as queries sql, as vezes só isso já melhora um pouco o desempenho do sistema.

 

A divisão em bd´s menores é uma solução paliativa e de curto prazo, além de ter um outro problema, que seria o aumento de requisições no servidor, o que afetaria o desempenho do servidor conforme fosse aumentando o numero de usuários.

 

É uma situação complexa, e tudo aponta na migração do banco de dados para um melhor.

Note que você poderia separar em bancos menores, ganhando com isso tempo para poder ler um livro de mysql ou aprender mais sobre ele e fazer os testes com calma.

Ou migrar já e conforme vai mudando o sistema para o mysql já fazer os testes e ir corrigindo os possiveis problemas.

[Jean Franceschi 0]

Acho que a solução inicial vai ser dividir em bancos menores, isso vai agilizar a mudança e momentaneamente acredito que vá "desencalhar o servidor temporariamente".

 

Como as chamadas são em funções, fica simples, já que envio a ID do usuário rpa abrir determinado BD...

 

Exemplo de como é atualmente uma conexao com o BD:

'	###################################
'	######## Conexao_Cadastros_Atual
'	###################################
Function Abrir_Conexao_Cadastros_Atual
	Set Conexao_Cadastros_Atual = Server.CreateObject("ADODB.Connection")
		Conexao_Cadastros_Atual.Open "Provider=Microsoft.Jet.OLEDB.4.0;Data Source="& Caminho_Banco_de_Dados &"S01_Cadastros.mdb"
End Function

Function Fechar_Conexao_Cadastros_Atual
		Conexao_Cadastros_Atual.Close
	Set Conexao_Cadastros_Atual = Nothing
End Function

 

E aqui um exemplo de como farei (já que os BDs de cada usuário ficam em uma pasta com a ID deles:

'	###################################
'	######## Conexao_Cadastros_Atual
'	###################################
Function Abrir_Conexao_Cadastros_Atual(ID_Usuario)
	Set Conexao_Cadastros_Atual = Server.CreateObject("ADODB.Connection")
		Conexao_Cadastros_Atual.Open "Provider=Microsoft.Jet.OLEDB.4.0;Data Source="& Caminho_Banco_de_Dados & ID_Usuario & "\S01_Cadastros.mdb"
End Function

Function Fechar_Conexao_Cadastros_Atual
		Conexao_Cadastros_Atual.Close
	Set Conexao_Cadastros_Atual = Nothing
End Function

 

Veja que pra mim fica simples, já que no login eu crio uma session que guarda a id, e então na chamada da função eu só coloco a sessão:

Call Abrir_Conexao_Cadastros_Atual(Session("ID"))

 

Super prático pra fazer esta alteração.

 

E como paleativo, tudo que eu for criando novo para o projeto já vou desenvolvendo em mysql, assim eu paro de utilizar o acess aos poucos e aprendo mais sobre mysql.

Quando eu tiver plena confiança no mysql e aprender direitinho como utilizar, posso ir migrando os bancos mais acessados (em acess) passando eles pra mysql, tornando o sistema cada vez mais rápido.

 

Você me falou exatamente do medo que eu tinha, ocupar os recursos do servidor com milhares de pequenos BD´s... Acho que ainda vou precisar dividir os bds em bancos menores pra ver se melhora um pouco a velocidade, ja que as consultas estão atualmente muito demoradas, mas como falei, acho que dessa forma vou conseguir me adaptar as novas mudanças.

 

Agradeço muito a atenção, e qualquer idéia é super bem vinda... =)

[xanburzum 169]

você também pode usar um servidor dedicado, um Oracle ou SQLServer, são os que uso para situações parecidas, com gerenciamento bem feito atraves de um DBA, com backup e tudo mais

[retrolink 0]

você também pode usar um servidor dedicado, um Oracle ou SQLServer, são os que uso para situações parecidas, com gerenciamento bem feito atraves de um DBA, com backup e tudo mais

 

kkkkk, você leu o tópico? viu que o camarada disse que não passa pra mysql e outros por falta de grana? kkkk e ainda indica um server dedicado...

 

kkkkkkkkk

[xanburzum 169]

kkkk, R$ faz falta para um projeto bem estruturado....

[Jean Franceschi 0]

Servidor dedicado eu já uso... problema é que meu conhecimento é zero em mysql e outros BD´s e por isso falei que pra mudar agora preciso de grana, de alguém pra reprojetar o que ja tem para estes novos bancos.

 

Neste server dedicado tenho acesso e suporte a mysql (bancos ilimitados e espaço ilimitado (2 HD´s de 1 terra cada é o limite)) e sql server, que se precisar instalar vão custar mais 140 reais mensais... é pouco a mais colocar o sql server, o problema é administrar =\

 

Por isso que falei que vou ir aprendendo mais até pegar confiança e fazendo as novas funções pra mysql (por enquanto). E as antigas vou manter em acess, mas em bancos menores. Já migrei de ontem pra hoje todos bancos grandes pra bancos pequenos, o bom é que um simples script de backup em asp remonta todos dados que estavam em grandes bds pra pequenos. Agora só falta aprender sobre mysql.

 

Como teste realmente melhorou a velocidade do site em cerca de 4 vezes migrando os bancos grandes em bancos pequenos (testei em horário de pico, quando tinha 700 usuários on naquele momento), mas vale lembrar que um usuário único acaba gerando cerca de 100 pageviews por hora, então o teste foi em meio a 7 mil visitas naquele momento, e com isso a velocidade ficou incrível, parecia que era só html, q nem acessava BD´s de tão rápido que ficou.

 

Eu achava que poderia diminuir a velocidade já que o servidor ia acabar abrindo mais bds nas consultas ao inves de abrir poucos e demorando nas consultas, mas até que ficou rápido, e olha que agora tem muitos bds, pela contagem no total tem cerca de 6 mil bds acess, e antes tinha só 15 =P

 

Acredito que pode realmente melhorar indo pra uma base de dados mysql ou alguma outra espe´cifica pra estas operações grandes, mas uma questão que gerou foi:

 

No acess ficou muito mais rápido dividindo os bds grandes em bds menores. No mysql tbm fica melhor dividir em bds menores ou o mysql suporta normalmente bds gigantes em consultas multiusuários (consultas e alterações simultâneas)? Pq se correr o risco de ficar lento devido ao número de consultas e a quantidade de registros, acho que mesmo passando pra mysql, acho que se torna viável subdividir os bds, ainda mais se ficar mais rápido como ficou no acess =)

 

Se alguém tiver interesse em como foi feito a divisão dos bancos em acess pra fazer projetos maiores como o meu e não ter condições de investir em outros BD´s me avisa q eu posto aqui como ficou o desenvolvimento e a idéia geral, pq pelo visto a velocidade ficou bem melhor) =)

 

E mais uma vez, só tenho a agradecer vocês aqui \o/

 

Uma pequena observação sobre o uso de backups...

Sempre que alguém fala em backup, significa que o que ta usando pode ser instável e isso não gera confiança... em acess, apesar de tudo ficar lento, até hoje nunca tive um banco de dados que "quebrou" ou "perdeu informações". Só acontece isso se der pau no hardware e comigo (sorte) nunca aconteceu...

 

Já ví relatos na net (nem sempre são verdadeiros, mas onde tem fumaça tem fogo) falçando que o sql server pode ser instável em algumas situações... já sobre oracle só ví comentários bons, assim como mysql. Alguém ja teve problema com algum destes 3 bancos? Só por motivo de curiosidade =)

 

Abraço gente =)

[retrolink 0]

Sinceramente, não vejo vantagens em utilizar um plano de servidor dedicado em uma aplicação que tem como banco de dados principal o access, não vejo a miníma vantagem nisso.

 

No caso dos erros nos bds, depende... dependo do programador ou do administrador responsável pelo bd, geralmente os erros são erros humanos, caso contrário dificilmente lhe dara dores de cabeça.

 

O processo que você disse que utilizou e poderia disponibilizar eu achei legal, caso tenha interesse, mostre o processo ai, quem sabe ainda possamos lhe da mais dicas para melhorar ainda mais o seu problema.

[Jean Franceschi 0]

Sobre a vantagem de usar um servidor dedicado, foi a necessidade, não a idéia... a necessidade de uma máquina inteira rodando só este projeto. Antes eu usava um plano de hospedagem, que limitava tudo, cada 3 acessos do usuário o server reiniciava. Mudei de provedor, melhorou um pouco, mas ainda estava difícil dividir uma máquina com outros clientes, passei pra um semidedicado (já que na época, clouds era apenas um sonho de consumo). No semi dedicado tbm lascou, provavelmente colocaram alguém "do outro lado" com um projeto grande tbm, e daí nas horas de pico travava geral pra todo mundo... Optei por um servidor dedicado e todos meus problemas se resolveram!! Chega de dividir máquina, chega de limites... agora o limite fica imposto pelo que eu uso e não mais pelo que eu uso + o que os outros clientes usam!

 

Agora a idéia é essa, se ficou lento eu preciso resolver de alguma forma, pq a culpa é toda minha, não tem ninguém pra culpar =P

E dessa forma que eu acabei vindo pedir ajuda, pra achar uma solução, na qual foi encontrada... inclusive já criei uma tabela mysql pra rodar uns testes... e pelo que percebi, ruim é só pra aprender a usar o phpmyadmin (pra criar os bancos), pq a inserção de dados, deletes, updates e selects são todos a mesma coisa... eu achei que ia me ferrar nessa parte, mas essa parte não mudou nada =P

Pelo visto mysql vai entrar como possibilidade bem antes do que eu previa =)

 

O que acho que falta do povo é respostas mais diretas... tudo que eu procurei sobre mysql vs acess pra saber o que mudaria ou o que muda, sempre ví respostas difícieis e nunca respostas fáceis... um exemplo, NUNCA achei uma resposta direta que disse que estes comando de acess e mysql são iguais no asp... nunca!! Se eu soubesse que seria igual, eu já teria começado a rever o conceito bem antes. Não sei se o povo gosta de enfeitar pra dizer: "é mais difícil por isso é melhor" ou se é pra dizer: "o que eu faço vale a mais pq eu sei fazer"... sério gente, quando perguntei alí em cima quais diferenças tinham, me mandaram um link pra um lugar que nem fala nada a respeito, era só dizer que "SELECT * FROM Tabela" do acess é o mesmo que o "SELECT * FROM Tabela" do mysql... de boa, acho q quando aprender direito como usar vou começar a ajudar quem precisa de verdade, pq o povo só tava complicando.

 

¬¬'

 

 

Vou fazer um exemplo aqui de como fiz pra usar bancos de dados menores, assim quem tiver pensando em usar acess em projetos grandes já pode ir pensando em dividir os bancos de forma simples. E acreditem, muita gente usa acess pq os provedores não dão suporte a outros bancos! Tem provedor por aí que só da uma base de dados mysql e cobra pro cara usar + de uma... é difícil pra todo desenvolvedor achar solução sem gastar muito... e os poucos que podem gastar, acabam gastando em outra saídas pra não ter muito prejuízo. E ja fica de dica... que acess é poderoso sim, basta saber usar as limitações q ele impõem, como todos os outros bd´s apesarem de ter limitações mais altas ^^

 

 

Guenta aí que vou fazer um exemplo fácil pra entender.

[retrolink 0]

beleza mano.