Arquitetura em aplicativo web multicliente

Bem,
você não disse qual seria
o porte dos clientes, mas
sugiro que você use
uma arquitetura que permita
que o banco seja configurado
programaticamente, quando
o usuario acessar, pois a url do banco
será de acordo com o cliente.
Aqui no guj tem esse assunto
(como definir dinamicamente o banco
de dados).
Dessa maneira, voce vai ter uma base
de dados para cada cliente.
Sugestão: jsf, hibernate, mysql, spring.

Espero ter ajudado.

Primeiramente obrigado pelas dicas.

Os clientes são de pequeno porte, mas podem ser muitos (100-200). Quanto ao banco estou pensando em ser configurável mesmo.

Mas quanto ao site acessar o banco no servidor do cliente, o que acha?

vlw

Bom,
a arquitetura proposta dá suporte
a este acesso. A aplicação ficaria
em um servidor e a base de dados
em cada cliente.
Problema seria performance,
sugiro que no inicio as bases sejam por
cliente, mas no mesmo servidor da aplicação,
ou então na mesma rede.

horacio_barros:

Bom,
a arquitetura proposta dá suporte
a este acesso…

Na verdade a performance é minha maior preocupação.

Obrigado.

Ola

Restrição de cada usuario acessar apenas os seus dados é uma restrição de dominio e isso deveria ser parte do seu Modelo (MVC, lembra?).

Nenhuma arquitetura vai impor isso a menos que vc tenha uma JVM para cada usuario, como se funcionasse a lá CGI-BIN.

A sua preocupação com performance é interessante porém se vc medir desde o começo vai ter alguma ideia dos gargalos. Boa parte deles podem se resolver com cache (seja de dados, seja cache do front-end) se o sistema for web e não exigir (quase) nada em tempo real. Por exemplo um forum é diferente de um home banking.

Se vc pensar em ter algo como 2 servidores web com um balanceador de carga na frente, compartilhando sessão via memcached, usando Hibernate e usando alguma solução para obter second level cache nas suas consultas ao banco de dados, vc tem uma receita que atende bem a boa parte dos sistemas web que precisam de escalabilidade e disponibilidade. Entretanto depende do que vc quer fazer.

Por exemplo, ja tive um sistema que era apenas uma “pagina”. usei sessão salva no cookie (criptografado) e cacheando toda a pagina. O que era diferente para cada usuario eu acessava via javascript e alterava o dom da pagina. Foi razoavelmente interessante. Tudo depende.

Então, usarei MVC sim, na verdade minha dúvida era se separava o banco ou deixava os dados de todos os clientes no mesmo banco (na realidade já pensava em bancos separados).

Desculpa a falta de conhecimento, mas não entendi muito bem. Então para cada cliente acessar o site, que direciona para o banco correto de acordo com o login, teria que rodar uma JVM separada? :S

Poderia indicar alguma documentação em java que possa ajudar?

Obrigado pela contribuição.

Olá Nevogei,

vc está procurando por MULTITENANCY.

Quanto vc usa uma ferramenta de plataforma como serviço (PaaS) como o GAE, setar um novo banco para um cliente é tão simples quanto:

Se quiser daber mais: https://developers.google.com/appengine/docs/java/multitenancy/multitenancy

Então, seja feliz, fuja de abordagens hosteadas onde vc precisa configurar um banco para cada cliente ou de ferramentas que não suportem esse atributo.

Tenho interesse em parcerias com projetos desse tipo.

Se quiser entrar em contato, fique à vontade.

O Hibernate 4 oferece suporte nativo a multitenancy, através da separação de schemas de bancos de dados. Dê uma olhada em http://www.infoq.com/br/news/2012/01/hibernate-4

[]'s

asaudate:

O Hibernate 4 oferece suporte nativo a multitenancy, através da separação de schemas de bancos de dados. Dê uma olhada em http://www.infoq.com/br/news/2012/01/hibernate-4

[]'s

Hibernate é passado, meus dados não precisam de colunas, meu banco tem o mesmo tempo de resposta para qualquer quantidade de registros…

Então, já tinha visto falar sobre mas não conheço. Vou dar uma olhada na documentação!

Estou tentando mostrar, na empresa, uma nova visão de trabalho, pois já estou cansado de trabalhar com tanta gambiarra e problemas, provenientes de desenvolvedores ruins

Gostaria de ter a oportunidade de iniciar o projeto do zero, e o dono da empresa tem esse desejo, mas fazendo uma aplicação boa, manutenível.
Quem sabe não rola uma consultoria, para definir arquitetura e guiar um bom desenvolvimento.

Você conhece algo desenvolvido com multitenancy para servir como exemplo?

Obrigado pelas dicas.

asaudate:

O Hibernate 4 oferece suporte nativo a multitenancy…

Caramba, muito bom, o que você usa? NoSQL?
Você acha que essa forma de tratar os dados se encaixa em todo cenário?

Mais uma vez, obrigado pelas dicas.

Boa tarde, pessoal!
Vocês já viram o tanto de vídeo que tem aqui:
http://aprendacomigo.com.br/videos/category/java/82

Bom dia pessoal.

Estou iniciando no java e estou com a mesma situação do negovei
Vou desenvolver uma aplicação com as mesmas necessidades do sistema que o negovei postou.

Tenho uma dúvida que acredito que não tenha sido respondida ainda:
:arrow: No momento que o usuário acessar a URL do sistema e informar o usuário e senha, nesse exato momento, como o sistema saberia a qual cliente esse usuário pertence para ser direcionado para a base de dados do respectivo cliente?
O sistema teria que ter uma base de dados intermediária que fizesse a relação usuário X cliente? Teria algum número identificador no código do usuário que identificasse o código do cliente?

andre_salvati
Não entendi o que você quis dizer em "fuja de abordagens hosteadas onde vc precisa configurar um banco para cada cliente"
Você é de SP?

acho que vc confunde a logica orientada a objetos com a logica do banco de dados.

imagine que o banco de dados é um diretorio e nesse diretorio vc tem n fotos, dos seus clientes. como vc vai saber que foto é de que cliente?

vc pode criar sub diretorios para cada cliente, pode colocar o nome do cliente como prefixo das fotos, vc pode ter uma tabela que mapeie cliente -> foto. são varias abordagens diferentes mas elas devem ser transparente para o usuario pq o que ele quer é a foto dele.

modele os seus objetos.

vc tem um usuario e este usuario tem COISAS. logo vc pode ter uma tabela usuario e uma tabela de coisas onde uma coluna dessa tabela é um id de usuario. na hora que o cara logar vc pesquisa as COISAS daquele usuario. é a forma mais comum.

mas se vc usa um banco nosql vc pode ter um documento para cada usuario, etc. são varias possibilidades.

o problema de vc criar diferentes databases para isso é que não existe motivo para vc adicionar esta complexidade ao seu sistema. criar uma nova database é dificil, geralmente vc tem rotinas de backup e replicação de dados que dependem dos nomes de databases (logo vc pode perder dados fazendo isso de qq jeito). só faria isso se precisasse de alguma coisa muito hardcore e as soluções NOSQL podem ser melhores.

rcerullo,
vc pode fazer de varias formas:

Sugestão 1: Crie um banco de dados intermediario no qual vc teria
uma tabela com todos os usuarios, outra com as empresas que
comprarem o sistema, inclusive controlando um contas a receber.
Este banco seria acessado inicialmente pela aplicação.
Cada usuario cadastrado apontaria para uma determinada empresa
dona da copia do sistema.
Quando o usuario fosse autenticado, vc saberia qual base de dados
ativar.
Ou seja, teria uma base de dados para cada empresa.
Sugestão 2: Vc faria o usuario digitar uma chave de ativaçao,
com base nesta chave vc montaria o nome da base de dados,
tipo: se o usuario digitar 123456 vc inseria db antes, mais alguma coisa depois e
criaria a url do banco, fazendo a conexão.
Tem varias maneiras de resolver isso e fica simples e muito seguro.

Estou à disposição para ajudar se precisar.

Obrigado pelo retorno peczenyj

Acredito que não seja nem questão de eu estar confundindo… eu tinha planejado uma tabela num database de uso comum onde pudesse fazer a relação usuário X cliente.
Não fiquei muito confortável com essa solução pelo seguinte fato: se esse banco de dados ficar indisponível por algum motivo qualquer nenhum dos meus clientes irão se logar no sistema.
Imaginei que pudesse ter uma solução onde essa tabela no database de uso comum não fosse necessária.

Uma amiga minha deu a seguinte sugestão: colocar o id do cliente antes do id do usuário. Ex.:
id cliente = 01
id do usuário = 01.001
Assim, ao logar no sistema, o conteúdo antes do ponto seria o id do cliente, não precisando acessar nenhuma base de dados para saber a relação usuário X cliente.

Quanto a sua sugestão do banco nosql não tenho muito conhecimento a respeito. Como minha experiência em java é quase nada, acredito que lidar com banco nosql agora seja muita coisa para mim… prefiro focar no aprendizado do java primeiro e mais a diante ver a possibilidade de utilizar o banco nosql.

As condições principais que eu pensei em utilizar um database para cada cliente são:

:arrow: o tempo de transação de um cliente não concorrer com as transações dos demais clientes;

:arrow: se um database de um cliente estiver indisponível, não afeta a operacionalidade dos demais clientes;

:arrow: um cliente pode solicitar para o database dele ficar no servidor de sua responsabilidade e não no servidor da aplicação;

:arrow: entre outras.

Aproveitando a discussão…
Tenho um sistema que será migrado e será todo SAAS, uma app e um banco para todos clientes.
Porém, há clientes (a princípio seria só um), que, por causa das normas da empresa multinacional, precisa que o BD fique no servidor interno deles.
Qual seria a melhor abordagem?

PS: Acho que cai bem dentro do assunto do tópico.
PS: Abri anteriormente uma discussão sobre isso.
http://guj.com.br/java/270990-saas-e-bd-por-cliente

Obrigado pelo retorno horacio_barros

Coloquei um post um pouco antes do seu… acredito que já está contemplando o que você citou.

j0nny
Se este banco de dados ficar indisponível nenhum de seus clientes acessará o sistema… não é muito arriscado?

rcerullo:

Obrigado pelo retorno horacio_barros

Coloquei um post um pouco antes do seu… acredito que já está contemplando o que você citou.

j0nny
Se este banco de dados ficar indisponível nenhum de seus clientes acessará o sistema… não é muito arriscado?

Não, salesforce, SAP, e outras trabalham assim.
A questão é vc precisar trabalhar em uma base só para manter ela funcional para que não tenha problemas.
PS: Nosso sistema hj é uma base para cada cliente, é uma dor de cabeça desgraçada. Por isso quero uma base separada apenas para clientes muito “chatos”.

j0nny

Quais foram os problemas que você enfrentou sendo uma base de dados para cada cliente?

rcerullo:

j0nny

Quais foram os problemas que você enfrentou sendo uma base de dados para cada cliente?

A principal delas, manutenção.
Pense vc liberando um novo release que tem alteração na estrutura da base de dados, e vc tem 100 clientes.

j0nny:

A principal delas, manutenção.
Pense vc liberando um novo release que tem alteração na estrutura da base de dados, e vc tem 100 clientes.

Mas nesse caso, não seria interessante o controle de versão do banco? E de rotinas que executem essa tarefa automaticamente?

http://itweb.com.br/56377/google-encerra-mais-produtos/

negovei:

j0nny:

A principal delas, manutenção.
Pense vc liberando um novo release que tem alteração na estrutura da base de dados, e vc tem 100 clientes.

Mas nesse caso, não seria interessante o controle de versão do banco? E de rotinas que executem essa tarefa automaticamente?

Ainda assim não vejo vantagem.

Não estou julgando qual é mais vantajoso, apenas citei uma forma automatizada de trabalhar e não arcaica. E da mesma forma como você não vê vantagens em multibanco, vejo muitos problemas em um banco centralizado!

Alias como seria uma solução plausível quando em um banco centralizado um cliente exige que o banco fique em um servidor próprio?

Não estou julgando qual é mais vantajoso, apenas citei uma forma automatizada de trabalhar e não arcaica. E da mesma forma como você não vê vantagens em multibanco, vejo muitos problemas em um banco centralizado!

Alias como seria uma solução plausível quando em um banco centralizado um cliente exige que o banco fique em um servidor próprio?

É justamente essa questão que levantei.
Vou ter que ter alguma relação de cliente x database.

j0nny:

É justamente essa questão que levantei.
Vou ter que ter alguma relação de cliente x database.

Entendi, parece legal, mas de acordo com o numero de clientes isso também não se tornaria problema na manutenção?
E pior, esse trabalho daria pra automatizar?

Gostei muito dos posts do ‘andre_salvati’ falando do AppEngine e de multitenancy, estou estudando a possibilidade.

negovei:

j0nny:

É justamente essa questão que levantei.
Vou ter que ter alguma relação de cliente x database.

Entendi, parece legal, mas de acordo com o numero de clientes isso também não se tornaria problema na manutenção?
E pior, esse trabalho daria pra automatizar?

Gostei muito dos posts do ‘andre_salvati’ falando do AppEngine e de multitenancy, estou estudando a possibilidade.

Não, pq a maioria dos clientes vai optar por deixar o bd por conta da aplicação, então por padrão, essa relação cliente x bd vai apontar pro bd da aplicação.

A conclusão que tiro desses posts é a seguinte: não tem certo ou errado, melhor ou pior… o que temos é a necessidade de cada um.

:arrow: Se o foco é ter mais facilidade na manutenção, por exemplo, o ideal seria ter um banco centralizado.

:arrow: Se o foco é ter mais segurança em termos de indisponibilidade do banco, por exemplo, o ideal seria ter um banco para cada cliente.

Concordam?

As soluções corporativas estão caminhando para a primeira opção (vide Salesforce, Gmail, Netsuite, etc).

Um banco para cada cliente não implica necessariamente em mais segurança ou disponibilidade. Na realidade, o mito de que “um banco no meu datacenter é mais seguro” está caindo. A simplicidade e a padronização que vc tem para administrar um ambiente mais centralizado podem te garantir mais disponibilidade/segurança.

Vejo trabalho extra da mesma forma. Estou vendo problemas em ambos.

Verdade.

Se você estiver falando de NOSQL concordo, mas se esta falando em banco relacional discordo.

Alias como fica em um banco relacional, em uma base centralizada, a questão das transações?
E a questão de uso x performance, como posso garantir que o serviço será melhor para um cliente que paga mais?
Como não prejudicar clientes pequenos que usam a mesma base?

A decisão técnica deve ser uma consequência da sua estratégia de produto.

Primeiro vc define se o seu modelo de negócios coloca todos os clientes no mesmo app/banco ou não.

Depois vc escolhe o banco, que é uma decisão técnica que leva em conta diversos fatores, podendo ser ele relacional ou não.

Entendo isso, vou mas direto aos pontos de dúvida:
Vou desenvolver um app web, e este terá um banco para todos os clientes, toda regra de negócio e estratégia de produto está pronta, para iniciar o desenvolvimento (parte técnica).

Digamos que eu defina um banco relacional, os pontos citados são importantes?

A questão das transações concorrentes entre clientes acessando o banco, terei problemas?
E a questão de performance, como não prejudicar clientes pequenos que usam a mesma base?

E caso eu escolha NOSQL, esses problemas são minimizados?

Obrigado.

negovei:

andre_salvati:

A decisão técnica deve ser uma consequência da sua estratégia de produto.
Primeiro vc define se o seu modelo de negócios coloca todos os clientes no mesmo app/banco ou não.
Depois vc escolhe o banco, que é uma decisão técnica que leva em conta diversos fatores, podendo ser ele relacional ou não.

Entendo isso, vou mas direto aos pontos de dúvida:
Vou desenvolver um app web, e este terá um banco para todos os clientes, toda regra de negócio e estratégia de produto está pronta, para iniciar o desenvolvimento (parte técnica).

Digamos que eu defina um banco relacional, os pontos citados são importantes?

A questão das transações concorrentes entre clientes acessando o banco, terei problemas?
E a questão de performance, como não prejudicar clientes pequenos que usam a mesma base?

E caso eu escolha NOSQL, esses problemas são minimizados?

Obrigado.

Tudo tem suas vantagens e desvantagens.

Qual é o seu app? Quanta informação vc precisa armazenar? Quantos acessos concorrentes?? É crítico escalar?? E daí por diante…

Aí entra meu trabalho…

ok

negovei:

andre_salvati:

A decisão técnica deve ser uma consequência da sua estratégia de produto.
Primeiro vc define se o seu modelo de negócios coloca todos os clientes no mesmo app/banco ou não.
Depois vc escolhe o banco, que é uma decisão técnica que leva em conta diversos fatores, podendo ser ele relacional ou não.

Entendo isso, vou mas direto aos pontos de dúvida:
Vou desenvolver um app web, e este terá um banco para todos os clientes, toda regra de negócio e estratégia de produto está pronta, para iniciar o desenvolvimento (parte técnica).

Digamos que eu defina um banco relacional, os pontos citados são importantes?

A questão das transações concorrentes entre clientes acessando o banco, terei problemas?
E a questão de performance, como não prejudicar clientes pequenos que usam a mesma base?

E caso eu escolha NOSQL, esses problemas são minimizados?

Obrigado.

Ainda tenho minhas dúvidas da aplicação de NoSQL em apps comerciais, acho que ele é mais vantajoso somente em algoritmos de processamento.
Ao menos é isso que ouvi muito. Nunca testei, por isso não afirmo.

j0nny:

Ainda tenho minhas dúvidas da aplicação de NoSQL em apps comerciais, acho que ele é mais vantajoso somente em algoritmos de processamento.
Ao menos é isso que ouvi muito. Nunca testei, por isso não afirmo.

NoSQL não é “um” banco. Vários são bons para algoritmos de processamento, vários são bons para performance com volume de dados pequeno, vários são bons com dados distribuídos em larga escala. É questão de analisar a necessidade

E sobre todos os dados dos clientes em um banco, o que você acha? Já desenvolveu algo desse tipo? Teve problemas?

Como fica a questão de performance, como não prejudicar clientes pequenos que usam a mesma base?

Obrigado.

E sobre todos os dados dos clientes em um banco, o que você acha? Já desenvolveu algo desse tipo? Teve problemas?

Como fica a questão de performance, como não prejudicar clientes pequenos que usam a mesma base?

Obrigado.

Nunca precisei desenvolver usando multi-tenancy, mas já ouvi vários relatos de prós e contras (nesse mesmo tópico, inclusive).

Acho que tudo é questão de desenvolver orientado a evolução. O pessoal do twitter desenvolveu a coisa toda usando MySQL. Quando precisou, eles mudaram, escalaram, enfim… tudo é questão de como você desenvolve. Se você souber que existe uma chance de ter que modificar sua infra-estrutura, não seja dependente dela!

asaudate:

Nunca precisei desenvolver usando multi-tenancy, mas já ouvi vários relatos de prós e contras (nesse mesmo tópico, inclusive).
Acho que tudo é questão de desenvolver orientado a evolução. O pessoal do twitter desenvolveu a coisa toda usando MySQL. Quando precisou, eles mudaram, escalaram, enfim… tudo é questão de como você desenvolve. Se você souber que existe uma chance de ter que modificar sua infra-estrutura, não seja dependente dela!

É verdade, separando as camadas e usando um ORM, na hora de uma migração muita coisa é aproveitado.

Concordo com o asaudate
Se necessário mais para frente, mude !!!

E é o que eu falei antes… não tem certo ou errado… melhor ou pior…
Tem o que melhor se adequa às suas nececidades no momento.

Por exemplo a minha:

:arrow: Não quero que um cliente concorra com as transações dos demais clientes;

:arrow: Minha aplicação, depois de estabilizada, não tende a ter muitas atualizações;

:arrow: Alguns clientes poderão solicitar que o banco de dados fique em seu servidor e não no da aplicação;

:arrow: Entre outros.

Por esses motivos vou planejar o meu sistema tendo um banco de dados intermediário que fará a autenticação do usuário (relação de cliente x usuário) e depois de autenticado vou direcionar cada cliente para o seu bando de dados.

Futuramente, se o sistema der certo no mercado, posso pensar em um banco só se esta for a necessidade.

Mudar sempre vai, o problema é prestar uma qualidade minima no serviço, e que essa mudança seja a longo prazo.

Também creio que não tem certo ou errado, só não posso aceitar métodos/soluções sem argumentos realmente válidos.

Minha dúvida sobre performance, por exemplo, quando o banco é centralizado não foi respondida!
Simplesmente pq é um problema, e fica dependendo do servidor para disponibilizar um bom serviço.

Mas o tópico foi muito bom, agradeço a todos pelas respostas e contribuições.

Vou estudar mais antes de propor algo para a empresa.

A performance, obviamente, fica abaixo do que em bancos separados. O ponto central continua sendo sua necessidade. Se fosse ótimo ficar no mesmo banco, essa discussão não teria motivo para existir.

[]'s

Essa questão sobre compartilhamento de transações num banco único me alertou, vou pesquisar mais sobre isso.
Pq estou prestes a iniciar uma app SAAS, e essas discussões são muito valiosas.

É sim… foi um tópico muito bom !!!

Também agradeço a participação de todos !!!

Mas a discussão não pode parar.
Por exemplo, quais seriam as soluções para evitar esse problema de performanace com um banco compartilhado?

j0nny:

Mas a discussão não pode parar.
Por exemplo, quais seriam as soluções para evitar esse problema de performanace com um banco compartilhado?

Solução mega-ultra-master-power-final não existe. O que sempre dá pra fazer é tunar o banco (aumentar número de transações disponíveis, máquina dedicada, etc.). Mas isso, dá pra fazer em qualquer tipo de aplicação =)

asaudate:

negovei:

Minha dúvida sobre performance, por exemplo, quando o banco é centralizado não foi respondida!

A performance, obviamente, fica abaixo do que em bancos separados. O ponto central continua sendo sua necessidade. Se fosse ótimo ficar no mesmo banco, essa discussão não teria motivo para existir.
[]'s

Estou em busca de informação, por isso a discussão existe! Podia ser ótimo ficar no mesmo banco, e eu estar querendo saber disso!

O interessante é que em nenhum outro post ninguém falou sobre. E se estamos comparando temos que ver os dois lados da moeda.

Mas vou resolver essas dúvidas com testes.

asaudate:

negovei:

Minha dúvida sobre performance, por exemplo, quando o banco é centralizado não foi respondida!

A performance, obviamente, fica abaixo do que em bancos separados. O ponto central continua sendo sua necessidade. Se fosse ótimo ficar no mesmo banco, essa discussão não teria motivo para existir.

[]'s

Aí discordo.

Facebook, Twitter (como vc mesmo disse), Salesforce, Gmail, etc trabalham num único banco e a performance é semelhante (ou até melhor!!!) à de uma aplicação equivalente rodando em um servidor dedicado.

Perfomance de banco depende mais de escolher a ferramenta certa para o problema e de contruir um bom modelo do que uma simples decisão SQL/NoSQL.

Performance mede-se em tempo de resposta (latência) do app e não em tempo de acesso a banco.

Mas o Facebook, Twitter, Salesforce, Gmail usam banco relacional?

Então com um bom modelo tenho a mesma (ou quase) performance do NOSQL?

Se sim, e a sua afirmação quanto o hibernate?

Obs: Não estou criticando, apenas querendo entender/aprender.

Eu acho que a a questão não é nem ser SQL / NOSQL e sim um banco ou “n” bancos de dados.

No meu caso o importante é definir qual a melhor solução, com relação a custos, performance, disponibilidade, tempo de vida do projeto, etc.

Se desenvolver pra Cloud e NOSQL for o melhor, e estou vendo que sim, vou optar por ele!

Não entendi sua dúvida.

Não há contradição no que eu disse, foram afirmações feitas em contextos diferentes e sobre “coisas” diferentes.

Na primeira eu estava comparando duas soluções que possibilitam Multitenancy (Hibernate e GAE).

Na segunda (mais genérica) eu disse que a performance depende mais da ferramenta e de uma implementação adequada do modelo de dados do que o banco ser NoSQL/SQL. Ou seja, vc pode ter uma implementação “porca” de modelo (e isso é bem comum por aí) no GAE (NOSQL) que apanha de uma boa implementação em MYSQL.

Na maior parte das vezes tb acaba acontecendo do caboclo só arranhar a superfície da ferramenta e, quando a coisa degrada em produção, colocar a culpa nela.

Ficou confuso em alguns momentos, pois foi citado exemplos de aplicativos que usam NOSQL, comparando performance (relacional/multitenancy/hibernate).

Então, o que ficou em dúvida foi isso: é possível duas aplicações bem desenvolvidas, o banco relacional dar o mesma performance do NOSQL?

Não vejo sentido nisso. Como você mesmo citou “Hibernate é passado, meus dados não precisam de colunas…”.

Mas, entendi melhor seu ponto de vista.

Obrigado.

negovei:

andre_salvati:

Não entendi sua dúvida.

Ficou confuso em alguns momentos, pois foi citado exemplos de aplicativos que usam NOSQL, comparando performance (relacional/multitenancy/hibernate).

Então, o que ficou em dúvida foi isso: é possível duas aplicações bem desenvolvidas, o banco relacional dar o mesma performance do NOSQL?

Não vejo sentido nisso. Como você mesmo citou “Hibernate é passado, meus dados não precisam de colunas…”.

Mas, entendi melhor seu ponto de vista.

Obrigado.

Cuidado com o modismo.
NoSQL nem sempre vai ser a melhor solução, e sendo uma aplicação comercial, tenho grandes dúvidas se NoSQL é a melhor solução. Nesse caso acho que ainda se aplica melhor o relacional.
Leia mais sobre NoSQL.

j0nny:

Cuidado com o modismo.
NoSQL nem sempre vai ser a melhor solução, e sendo uma aplicação comercial, tenho grandes dúvidas se NoSQL é a melhor solução. Nesse caso acho que ainda se aplica melhor o relacional.
Leia mais sobre NoSQL.

Ainda não define nada, vou estudar mais e fazer muitos testes. Tenho tempo para desenvolver o projeto.

Por isso pergunto tanto!

Vlw.

:arrow: negovei,

já decidiu sobre a estrutura do seu banco de dados? quais foram suas conclusões :?:

já decidiu sobre o serviço de cloud :?:
este link pode ajudar:

:arrow: andre_salvati
pelo que percebi vc utiliza e recomenda o Google App Engine, certo ?!
Se eu compreendi certo, existem algumas limitações e vai depender muito da aplicação para sua utilização.
Creio que não roda uma aplicação JBoss Seam (por exemplo) no GAE. Correto?
Quais são as características da app, o framework e as bibliotecas que vc utilizou :?:

Na verdade apenas apresentei as opções para desenvolvimento do projeto, e a necessidade de uma consultoria.
Atualmente estamos trabalhando na documentação da regra de negócio e correções no sistema.

Obrigado pelo link, muito interessante.