Arquitetura em aplicativo web multicliente

j0nny

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

[quote=rcerullo]j0nny

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

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.

[quote=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.[/quote]

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/

[quote=negovei][quote=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.[/quote]

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

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?[/quote]

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

[quote=j0nny]
É justamente essa questão que levantei.
Vou ter que ter alguma relação de cliente x database.[/quote]

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.

[quote=negovei][quote=j0nny]
É justamente essa questão que levantei.
Vou ter que ter alguma relação de cliente x database.[/quote]

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.[/quote]

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. :frowning:

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.

[quote=negovei][quote=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.
[/quote]

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.[/quote]

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… :wink:

ok

[quote=negovei][quote=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.
[/quote]

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.[/quote]

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.

[quote=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.[/quote]

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 :wink:

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.[/quote]

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!