Arquitetura para sistema de grande porte

[Leo limas]

Olá pessoal, sou novo no grupo e gostaria de começar com uma dúvida.

Estamos criando um projeto de grande porte na empresa que trabalho. O banco de dados a ser utilizado ainda não foi escolhido.
Gostaria de saber qual a opinião de vocês a isso. SQL, Oracle ou Postgres?
OBS: Estamos falando de uma base que rapidamente irá alcançar a casa dos GB (poucas semanas).

Outra coisa, do ponto de vista de arquitetura, nesse tipo de sistema, compensa usar ORM? Como otimizar as consultas?
Qual ORM utilizar? NHibernate, Entity Framework, Linq to Sql? ADO ?

Aceito as mais diversas sugestões e conselhos.

Desde já agradeço.
Leo

[Juan Lopes]

Falta um pouco de informação, creio.

Casa dos GB em poucas semanas significa o que, exatamente? Dados relacionais? Grafos? Full-text? 

2013/6/4 Leo limas <leol...@gmail.com>

Leo

--
Você recebeu esta mensagem porque faz parte do grupo .Net Architects hospedado no Google Groups.
Para postar envie uma mensagem para dotnetar...@googlegroups.com
Para sair do grupo envie uma mensagem para dotnetarchitec...@googlegroups.com
Para mais opções visite o grupo em http://groups.google.com/group/dotnetarchitects?hl=pt-br
---
Você está recebendo esta mensagem porque se inscreveu no grupo ".Net Architects" dos Grupos do Google.
Para cancelar a inscrição neste grupo e parar de receber seus e-mails, envie um e-mail para dotnetarchitec...@googlegroups.com.
Para obter mais opções, acesse https://groups.google.com/groups/opt_out.
 
 

--
https://github.com/juanplopes

[Marcelo Acioli Bastos]

Nobre Leo,

Existem umas combinações boas....

EX: SQL com Entity Framework 4.5

Oracle com NHibernate

com relação ao postgree voce pode usar o NHibernate, mas eu particularmente não usaria este Banco de dados. Eu me limitaria ao Oracle ou SQL. Se vc vai trabalhar com .net e no framework 4.5 aproveita o que ha de melhor com SQL e o Entity... Mas o Oracle com NHIbernate é uma boa e se voce usar o Add on Fluent NHibernate melhor ainda...lembro que voce pode usar o NHibernate - Fluent e o SQL também.

Marcelo

Leo

--

Você recebeu esta mensagem porque faz parte do grupo .Net Architects hospedado no Google Groups.
Para postar envie uma mensagem para dotnetar...@googlegroups.com
Para sair do grupo envie uma mensagem para dotnetarchitec...@googlegroups.com
Para mais opções visite o grupo em http://groups.google.com/group/dotnetarchitects?hl=pt-br
---
Você está recebendo esta mensagem porque se inscreveu no grupo ".Net Architects" dos Grupos do Google.
Para cancelar a inscrição neste grupo e parar de receber seus e-mails, envie um e-mail para dotnetarchitec...@googlegroups.com.
Para obter mais opções, acesse https://groups.google.com/groups/opt_out.
 
 

--
Marcelo Bastos
Analista de sistemas
85-9997-3280
http://www.marceloaccioly.blogspot.com/

[Leo limas]

@Juan, este tamanho é esperado para o modelo relacional.

[Marcelo Acioli Bastos]

Leo,

Tenta levar em consideração o que te indiquei, um dos ultimos projetos em que participei, NHibernat com SQL, tinha na faixa de 1 milhão de cliente e era um sistema de crédito bancário. Acho que o caminho é este.

Marcelo

[Victor Arias]

Não faça o "sistema de grande porte".

Faça varios microsistemas que interagem e use o banco de dados que quiser em cada um deles.

[Leo limas]

@Victor, na verdade trata-se de um sistema de grande porte por ser a junção de vários outros sistema.. por isso a massa de dados é grande.

[Leo limas]

@Marcelo, trabalhei uma vez em um sistema com o Fluent NHibernate com Postgres e não gostei muito do resultado.. sempre que tínhamos dúvidas tínhamos que recorrer a fóruns e o grupo do NhibernateBR que nem sempre encontrava as soluções.

Os mapeamentos eram gerados utilizando uma ferramenta que se chama MyGeneration... e sempre vinham com problemas e tínhamos que ficar arrumando...

tivemos problemas também com algumas referências cíclicas que não conseguíamos resolver totalmente (a base de dados era de cliente e não conseguíamos mudar)

[Marcelo Acioli Bastos]

Leo,

Ta ai a grande diferença na nossa experiência... MyGeneration...eu não utilizei ele, pois isso só tende a acontecer. No meu caso especificamente as referencias ciclicas foram evitadas com uma boa arquitetura que em conjunto com nosso projetista evitamos. Da sim pra voce fazer na boa e evitar estes problemas.

Quanto ao Banco, ha quem goste do postgres, porem num sistema como este eu não utilizaria ele, pois os riscos são grandes. Não quero aqui dizer que o postgres não presta, mas sabemos que Oracle e SQL são sim superiores.

Marcelo

[Vinícius Ribeiro]

Quando comecei os estudos com nhibernate o mygeneration ajudou e muito no entendimento do mapeamento. Na epoca o script melhorzinho era do lujan. Depois removi os mapeamentos bidirecionais e ajustei os relacionamentos.

Enfim ela te ajuda mas vc tem q fazer os 'finalmente'

[Vinícius Ribeiro]

Gostaria de saber. Do nobre colega q risco grande se teria com o postgres, principalmente com a versao 9. Nunca tive problema com ele. Poderia compartilhar sua experiencia ?

Em 05/06/2013 08:44, "Marcelo Acioli Bastos" <bast...@gmail.com> escreveu:

[Marcelo Acioli Bastos]

Vinicius,

Eu trabalhei em projetos com oracle e projetos com SQL e um dos projetos que trabalhei usamos os dois. No projeto que participei, em que tivemos que utilizar Oracle e SQL foi sugerido que o Postgres fosse usado no lugar do SQL, porém o SQL se mostrou mais completo com relação a nossa realidade. Na época tinhamos uma aplicação em Java com Base oracle e estavamos projetando uma outra com .net e no momento a versão do postgres não era tão completa quanto o SQL que escolhemos para utilizar.

Eu não tenho nenhum problema em utilizar o Postgres, porém para o nosso caso especifico e no momento em que estávamos o SQL foi a melhor alternativa.

Peço desculpas se me expressei mal com relação ao postgres. Gostei do oracle, apesar da complexidade, adoro o SQL, mas não cheguei a trabalhar am grandes projetos com o postgres e hoje no que estou a Base de dados é Postgres e os DBA´s estão com alguns problemas....

Marcelo

[daniel carli]

No mundo fora do .net existem muitos projetos grandes e sérios utilizando Postgres.

Daniel Carli

dcrlz.tumblr.com

[João Bateloche]

Não sei se ainda é assim, mas até um tempo atrás o maior bd relacional do mundo era o da Yahoo e rodava no Postgres...

Não da pra falar que o BD não presta ou que não é completo.

Também dou preferencia à Oracle ou SQL, o problema aí é só o motivo.

[Vinícius Ribeiro]

Oi Marcelo. Nao sou romantico com nenhuma tecnologia entao nao precisa de 'pedir desculpas' hehe.

Te perguntei quais foram os seus problemas com relacao ao postgres para ver se eu ja tinha passado ou se era uma situacao nova para mim.

Na minha vida com este BD eu nunca tive problemas. A massa de dados era na casa dos milhares de registros, ou seja, pequena.

Vc disse q sua equipe enfrentou problemas. Poderia citar quais?

Abs.

[Marcelo Acioli Bastos]

Prezados,

Vou esclarecer de uma vez por todas, não tenho nenhuma restrição com o postgres, e não digo nem que ele não presta, pois sabemos que hoje o soft livre não deixa a desejar. Só quero que fique claro que se houver oportunidade de desenvolver um projeto começo, meio e fim com o Postgres eu poderei dar uma avaliação mais complexa.

Concordo com qualquer tecnologia desde que esta atenda a sua necessidade. No meu caso, em um determinado momento precisamos de algumas coisas do Postgres que não atenderam ao projeto e como não tinhamos o Oracle, este era do sistema legado do cliente, usamos o SQL. Foi uma coisa pontual, mas eu não sou um Opositor do postgres. Acho até que por ser Microsoft no momento, e eu não me recordo muito bem, isso pesou muito também.

Marcelo

[Marcelo Acioli Bastos]

Vinicius,

Já tem um tempinho em que atuei no projeto...não me recordo muito bem, mas vou rever minhas anotações e arquivos de projetos e te falo com mais precisão. Mas lembro que um dos fatores foi a urgência e naquele momento o sql seria mais fácil....

Em 5 de junho de 2013 13:03, Vinícius Ribeiro <vini...@alicersis.com.br> escreveu:

[Vinícius Ribeiro]

Blz Marcelo.

Abs.

[daniel carli]

Marcelo,

o único problema é que da forma como você disse, parecesse que você tem evidencias que o Postgres deu problema na sua app, por isso a galera estranha.

Daniel Carli

dcrlz.tumblr.com

[Marcelo Acioli Bastos]

Daniel,

Como falei anteriormente foram coisas pontuais. Eu particularmente só recomendo o que eu fiz inicio meio e fim. Quando eu não tenho uma experiência mais afundo eu não recomendo. Com relação a problemas de entrave na aplicação o postgres não causou nenhum, mas como falei pro Vinicius uma coisa que pesou foi estarmos usando .net e termos a licença do sql. Existiu sim um ou outro ponto que me recordo com tipos que precisamos utilizar, mas no nosso caso era pontual mesmo do projeto. Então não me leva a mal, pois não sou nenhum fanatico religioso defendendo o SQL ou desmerecendo o PostGres.

Marcelo

[Renato Cantarino]

Marcelo, pq vc nao gosta do Postgres?

Att,

Renato Cantarino

[Marcelo Acioli Bastos]

Renato,

Ja me desculpei, eu me expressei mal. Não é uma questão de não gostar eu só não desenvolvi nenhum projeto com inicio, meio e fim utilizando o Postgres, só. Como não o conheço a fundo, não o recomendo. Voce ja trabalhou com ele e deve ter tido boas experiências e no meu caso nós fizemos uns testes e desistimos e usamos o sql. Voce concorda que voce não recomenda aquilo que voce não conhece? Pois é..quando voce ouve falar que é bom é uma coisa e quando voce vai e usa ai é outra coisa. Desculpe cara se causei um mal entendido, pois não era minha intenção.

[Marcelo Acioli Bastos]

Prometo que na primeira oportunidade que aparecer vou usar o Postgres...depois falarei se foi boa ou não.

Em 5 de junho de 2013 14:21, Renato Cantarino <renato.c...@gmail.com> escreveu:

[daniel carli]

AHUAUHAUHAHUAUAUHUHAHHAUHAUHAUHAUHUAHHAHAUHAHAAUHAHUAUHAUAHUHAUH

Em 5 de junho de 2013 14:21, Renato Cantarino <renato.c...@gmail.com> escreveu:

--
Daniel Carli

dcrlz.tumblr.com

[Marcelo Acioli Bastos]

Daniel,

O

 que eu fiz agora?

[daniel carli]

Eu tava rindo do Cantarino, foi engraçado esse lance do "Porque você não gosta do Postres"

[Marcelo Acioli Bastos]

Pois é, quando a gente não se expressa bem acontece isso. Da próxima vou ler e vou revisar bem antes de enviar uma resposta. Mas ta de boa.

[Renato Cantarino]

Fique triste nao Marcelo.

Como prova de minha amizade, segue um presente...

[daniel carli]

AHUAUHAHUAAHUHAHAUHAUHAUHUAHAHAHUAHUAUHAHUAHUAHUAHU

[Marcelo Acioli Bastos]

Renato,

Ca pra nós....até que é bonitinho....hauhauhauahuahauha......

Em 5 de junho de 2013 14:42, Renato Cantarino <renato.c...@gmail.com> escreveu:

[Marcelo Acioli Bastos]

Daniel,

Ce viu ai...o cara mandou uma pelúcia...huahauauahuahauhauhau

[daniel carli]

Foi meio estranho ! ahahahaaha, é o mascote do postgres?

[Marcelo Acioli Bastos]

kkkkkkkkkkkkkkkkkkkkkkk pois é, ta perdoado pq é o mascote do postgres.....

[Renato Cantarino]

é o mascote ne.

[Rodrigo Magalhães dos Santos]

Olá Leo,

seu cenário está bem geral, então também vou falar em termos gerais.

Uma vez tive a oportunidade de trabalhar em um sistema cuja base de dados crescia rápido. Não tenho números oficiais, mas falava-se em cerca de 2GB por semana e, mais do que isso, o volume de consultas e transações por minuto era bastante elevado.

A solução que adotaram, e que dava conta do recado muito bem, foi a de concentrar a lógica de negócio em stored procedures (SQL Server) e uma camada "fina"  de componentes gerenciados VB6 e C++ no COM+ que faziam a interface do sistema com o mundo exterior através de XML. Nada de ORM.

O ponto negativo desse sistema era a dificuldade de manutenção. O debug no SQL 2005 era sofrível, quando não impossível (deve estar melhor agora no 2012). Acabava-se fazendo muito uso de logs para fins de diagnóstico e depuração.

Não tenho conhecimento sobre, mas certamente havia muito trabalho dos DBAs, fazendo particionamento de tabelas, otimização de consultas e muitas outras coisas do gênero.

Se eu tivesse que lidar com um cenário parecido hoje, acho que eu usaria componentes WCF com protocolos tão leves quanto possíveis, lógica de negócio em stored procedures, uma pessoa encarregada pela Análise de Dados, que funcionaria como "autoridade" na definição de dados e queries e um DBA para o indispensável tunning.

Desculpe estar falando em termos meio "difusos" mas, como eu disse, quis mesmo falar em noções gerais.

Abraços,

Rodrigo.

[Leo limas]

@Rodrigo, obrigado pela troca da sua experiência.

 

Em outras reuniões sobre o projeto foi decidido que será utilizado o Postgres como banco de dados oficial do projeto por ser free e podermos utilizar o investimento em outros pontos (treinamento da equipe, etc)..

 

Nossos diretores da área ainda são a favor da utilização de ADO. Estou procurando algum ORM que seja rápido com o Postgres e a melhor forma de trabalhar com ele.

 

O Entity tem o provider para Postgres pago, mas sempre tivemos problema com o primeiro acesso a base. Já fiz algumas pesquisas e algumas pessoas disseram que era devido ao tamanho do modelo (300 tabelas+). Li também que alguns pontos que poderiam melhorar isso serial trabalhar com modelos por módulos.

 

Já tive a oportunidade de trabalhar com o Fluent NHibernate com o Postgres mas passávamos muitas dificuldades nos mapeamentos.

 

Alguém tem alguma sugestão de melhora? Existe algum software que gere a "base" para realizar o pente fino depois?

Compensaria utilizar o Entity Framework com provider pago (devart)? Será que ficaríamos na mão?

[Vinícius Ribeiro]

Usei o pgsql com o nh por 4 anos sem problemas.

Se souber como entao faca o mapeamento na mao.

--

[Priscila Mayumi Sato]

@Leo

quando você disse que o problema era o modelo de 300 tabelas eu me assustei. Você perguntou se há como trabalhar sem EDM, correto? Code First, apesar do nome, pode ser usado com base existente, usando o Power Tools. Você só precisa ter um driver/provider.

Te confesso que nunca usei Firebird (taí um desafio que vou tentar em breve).

Há o provider oficial também...

--

Você recebeu esta mensagem porque faz parte do grupo .Net Architects hospedado no Google Groups.
Para postar envie uma mensagem para dotnetar...@googlegroups.com
Para sair do grupo envie uma mensagem para dotnetarchitec...@googlegroups.com
Para mais opções visite o grupo em http://groups.google.com/group/dotnetarchitects?hl=pt-br
---
Você está recebendo esta mensagem porque se inscreveu no grupo ".Net Architects" dos Grupos do Google.
Para cancelar a inscrição neste grupo e parar de receber seus e-mails, envie um e-mail para dotnetarchitec...@googlegroups.com.
Para obter mais opções, acesse https://groups.google.com/groups/opt_out.
 
 

--

Priscila Mayumi Sato

Twitter: @MayogaX

[Luiz Carlos Faria]

Bom dia Galera,

estava de ouvinte e agora vou falar um pouco sobre minhas experiências:

1) Uso bastante NHibernate com FluentNHibernate e geração de código.

2) O MyGeneration é uma solução muito interessante, mas fa pelo menos uns 5 anos que ele já não me atende e por volta deste período criei um gerador por cima dele.

3) Quanto à qualidade da geração de código, não culpem a estratégia ou a ferramenta: Quase em 100% dos casos a culpa é do template.

4) Com geração de código consigo garantir de forma coerente a compatibilidade de um código com um banco. Essa garantia é uma das melhores, ao meu ver. 

5) O nível de maturidade na geração de código é tamanho, que me permite usá-la como uma task da integração contínua e deploy contínuo.

Aqui está uma apresentação sobre a forma como desenvolvo acesso a dados com NH, Fluent NH http://www.youtube.com/watch?v=WZhEZSfu4Gc

Deixando o acesso a dados de lado, vou citar algumas dicas mais abrangentes:

6) Use padrões e princípios: (SOLID, KISS, EAI, EA)

7) Conheça os problemas "comuns" e atenda-os prioritariamente.

8) Seja flexível: Você não é dono da verdade, use um desenho de arquitetura que se adeque às mudanças e que assim possa ser evoluído.

9) Entre as diversas opções de banco citadas aqui, não há nada a deflagrar, mas adicione ao seu pipe de escolha a proficiência do seu time, da sua equipe de infra.

10) Não escolha unica e exclusivamente por purismo, não adianta você ter um sistema que faça tudo o que o cliente deseja, seja performático, com um código de ótima qualidade sendo que sua entrega aconteceu 3 anos após o target desejado. Leve em consideração custo de implementação.

11) Antecipe problemas: NHibernate é mt legal, mas trabalhar com seu XML custa caro para o dia-a-dia, o FluentNH ajuda nessa linha. Use mais estratégias desse tipo. 

12) Uma arquitetura ela não é nem boa nem ruim intrinsecamente: Ela atende ou não a um determinado senário.

13) Suporte e abrace a mudança: Muitas aplicações são tão complexas que uma mudança, seja ela qualquer, custam muito caro. Em virtude da complexidade, nascem os puxadinhos. Se você facilita e incentiva essa mudança, as pessoas vão criando confiança e cada vez mais prefere-se fazer "direito" a fazer puxadinho.

Nada mais me vem a cabeça agora. 

Citei individualmente, e enumerando, para simplificar o debate posterior. Sei que tem muita gente aqui no grupo que discorda.

Grande abraço

[Rafael Mueller]

+1 para uma arquitetura voltada a serviços, onde cada um tem sua base de dados própria.

2013/6/5 Victor Arias <aria...@gmail.com>

Não faça o "sistema de grande porte".

Faça varios microsistemas que interagem e use o banco de dados que quiser em cada um deles.

Além disso, sobre a discussão OraclexPGSQLxMSSQL, aposto que qualquer um deles resolve com muita folga teu problema, mas se você não entender como funciona o mapeamento nhibernate, ficar dependendo de ferramentas para mapear seu domínio para o banco, também aposto que você consegue ter uma performance horrível com qualquer um dos bancos.

Seu maior problema não é a seu RDBMS, é a arquitetura que você vai fazer para suportar esses dados.

[Luiz Carlos Faria]

+1