Devo usar uma configuração de banco de dados único ou múltiplo para uma aplicação multi-cliente?

Question

Eu estou trabalhando em uma aplicação PHP que tem a intenção de facilitar o fluxo de trabalho da empresa e gerenciamento de projetos, vamos dizer algo como Basecamp GoPlan .

Eu não tenho certeza sobre o que a melhor abordagem é, banco de dados-wise. Devo usar um único banco de dados e adicionar colunas específicas do cliente para cada uma das tabelas, ou devo criar uma base de dados para cada novo cliente? Um fator importante é a automação:. Eu quero que seja absolutamente simples para criar um novo cliente (e, talvez, abrindo a possibilidade de inscrever-se para si mesmo)

contras possíveis eu posso pensar em usar um banco de dados:

• A falta de extensibilidade
• Os problemas de segurança (embora erros não deveria estar lá em primeiro lugar )

Quais são seus pensamentos sobre isso? Você tem alguma idéia do que solução as empresas acima são mais susceptíveis de ter escolhido?

Answer 1

Eu costumo acrescentar ClientID a todas as tabelas e ir com um banco de dados. Mas desde que o banco de dados é geralmente difícil de escala também irá torná-lo possível para rodar em diferentes instâncias de banco de dados para alguns ou todos os clientes.

Dessa forma, você pode ter um monte de pequenos clientes em um banco de dados e os grandes em servidores separados.

Um fator-chave para a manutenção, porém, é que você mantenha o esquema idêntico em todos os bancos de dados. Haverá dor de cabeça o suficiente para gerenciar o controle de versão sem a introdução de esquemas específicos de clientes.

Answer 2

Ouça o podcast StackOverflow onde Joel e Jeff falam sobre a mesma questão. Joel está falando sobre sua experiência oferecendo uma versão hospedada do seu software. Ele ressalta que a adição de cliente ids todo o seu DB complica o design eo código (você tem certeza que não acidentalmente se esqueça de adicioná-lo a alguma cláusula WHERE?) E complica recurso de hospedagem, como backups específicos do cliente.

Foi no episódio # 20 ou # 21 (confira as transcrições para detalhes).

Answer 3

A meu ver, isso vai depender de sua base de clientes provável. Se você pudesse entrar em uma situação onde o arqui-rival são ambos usando seu sistema, então você seria melhor fora com bancos de dados separados. Também depende de como os bancos de dados múltiplos se implementado por seu DBMS. Se cada banco de dados tem uma cópia separada da infra-estrutura, em seguida, que sugere uma única base de dados (ou uma mudança de SGBD). Se vários bancos de dados pode ser servido por uma única cópia da infra-estrutura, então eu iria para bancos de dados separados.

Pense backup de banco de dados. Cliente Um diz: "Por favor, me envie uma cópia dos meus dados". Muito, muito mais fácil, em uma configuração de banco de dados separado do que se um único banco de dados é compartilhado. Pense de remoção de um cliente; novamente, muito mais fácil com bancos de dados separados.

(A parte 'infra-estrutura' é eloquente porque existem grandes diferenças entre as diferentes SGBD sobre o que constitui um 'banco de dados' versus 'instância do servidor', por exemplo, Adicionar :. A questão é Tagged 'mysql', então talvez esses pensamentos não são completamente relevante.)

Adicionar : Mais uma questão - com vários clientes em um único banco de dados, todas as consultas SQL vai necessidade de garantir que os dados para o cliente correto está escolhido. Isso significa que o SQL vai ser mais difícil de escrever e ler, e o SGBD vai ter que trabalhar mais no processamento dos dados e índices serão maiores, e ... Eu realmente iria com um banco de dados separado por cliente para muitas finalidades.

Claramente, StackOverflow (como exemplo) não ter uma base de dados separada por utilizador; todos nós usamos o mesmo banco de dados. Mas se você estava executando sistemas de contabilidade para empresas diferentes, eu não acho que seria aceitável (para as empresas e, possivelmente, não para as pessoas jurídicas) às bases de dados de acções.

Answer 4

• DESENVOLVIMENTO Para o desenvolvimento rápido, use um banco de dados por cliente. Pense quão fácil será para backup, restaurar ou excluir dados de um cliente. Ou para monitorar o uso medida / / conta. Você não vai precisar escrever código para fazê-lo por si mesmo, é só usar suas primitivas de banco de dados.

• DESEMPENHO Para o desempenho, use um banco de dados para todos. Pense sobre o pool de conexão, memória compartilhada, caching, etc.

• BUSINESS Se o seu plano de negócios é ter lotes de pequenos clientes (pense hotmail) você provavelmente deve trabalho em um único DB. E ter todas as tarefas administrativas, tais registo eo cancelamento, migração de dados, etc. totalmente automatizados e expostos em uma interface amigável. Se você pretende ter dezenas ou até algumas centenas de grandes clientes, então você pode trabalhar em um DB por cliente e têm scripts de administração do sistema em vigor que podem ser operados por sua equipe de suporte ao cliente.

Answer 5

A seguir screencast explica como é feito na salesforce.com. Eles usam um banco de dados com uma coluna especial OrgID que identifica os dados de cada inquilino. Há muito mais para que então você deve olhar para isso. Eu iria com sua abordagem.

Há uma outra grande artigo sobre isso no MSDN. Ele explica em profundidade quando você deve usar uma abordagem comum ou isolado. Lembre-se que ter um DB compartilhada para todos os seus inquilinos tem algumas implicações de segurança importantes e se todos eles compartilham mesma DB objetos que você pode querer usar [a segurança nível de linha] - dependendo das DBMS que você usa (eu tenho certeza que é possível em MS SQL Server e Oracle, provavelmente em IBM DB2 também). Você pode usar truques como segurança em nível de linha na mySQL para alcançar resultados semelhantes (visualizações + gatilhos ).

Answer 6

Para multitenancy, o desempenho será tipicamente aumentam quanto mais recursos você gerencia a participação de toda a inquilinos, veja

http://en.wikipedia.org/wiki/Multitenancy

Então, se você puder, vá com o único banco de dados. Concordo que os problemas de segurança só ocorreria devido a bugs, como você pode implementar todo o controle de acesso no aplicativo. Em alguns bancos de dados, você ainda pode usar o controle de acesso do banco de dados através do uso cuidadoso de pontos de vista (de modo que cada usuário autenticado recebe uma visão diferente).

Existem maneiras de fornecer extensibilidade também. Por exemplo, você pode criar uma única tabela com atributos de extensão (introduzidos pelo inquilino, ficha base, e extensão id atributo). Ou você pode criar tabelas de extensão por-tenant, de modo que cada inquilino tem seu próprio esquema de extensão.

Answer 7

Quando você está projetando um banco de dados multi-tenant, você geralmente tem três opções:

1. ter um banco de dados por inquilino
2. Tem um esquema por inquilino
3. Ter todos os inquilinos compartilhar a mesma mesa (s)

A opção que você escolhe tem implicações sobre escalabilidade, extensibilidade e isolamento. Estas implicações têm sido amplamente discutido em todo e artigos de banco de dados.

Na prática, cada uma das três opções de design -com suficientes perguntas esforço- endereço pode redor escala, dados que varia entre inquilinos e isolamento. A decisão depende da dimensão primária que você está construindo. O resumo:

• Se você está construindo para a escala: Ter todos os inquilinos compartilhar a mesma mesa (s)
• Se você está construindo para o isolamento: Criar um banco de dados por inquilino

Por exemplo, Google e Salesforce siga o primeiro padrão e têm seus inquilinos compartilham as mesmas tabelas. Stackoverflow por outro lado, segue o segundo padrão e mantém um banco de dados por inquilino. A segunda abordagem é também mais comum em setores regulados, como a saúde.

A decisão se resume à dimensão primária que você está otimizando seu projeto de banco de dados para. Este artigo no design de seu banco de dados de SaaS para conversações escala sobre os trade-offs e fornece um resumo no contexto do PostgreSQL.

Answer 8

Outro ponto a considerar é que você pode ter uma obrigação legal de manter uma empresas de dados separado do anothers'.

Answer 9

Ter um banco de dados por cliente geralmente não escala bem. MySQL (e provavelmente outros bancos de dados) detém recursos abrir por tabela, este não se presta bem a 10k + tabelas em uma instância, o que aconteceria em uma situação multitenancy em grande escala.

Claro que, se você tem algum outro problema que faz com que outros problemas antes de chegar a este nível, isso pode não ser relevante.

Além disso, "sharding" uma aplicação multi-tenant é provável € para ser a coisa certa a fazer, eventualmente, como seu aplicativo se torna maior e maior.

Sharding não faz no entanto base de dados média um (ou exemplo) por inquilino, mas um fragmento ou por conjunto de fragmentos, que pode ter vários inquilinos cada. Você vai precisar para descobrir os parâmetros de ajuste certo para si mesmo, provavelmente na produção (daí provavelmente precisa ser muito ajustável desde o início)

€ Eu não posso garanti-lo.

Answer 10

Você pode começar com um único banco de dados e particionar-la como a aplicação cresce. Se você fizer isso, há algumas coisas que eu recomendaria:

1) Projete o banco de dados de uma forma que pode ser facilmente dividido. Por exemplo, se os clientes estão indo para compartilhar dados, certifique-se que os dados são facilmente replicados em cada banco de dados.

2) Quando você tem apenas um banco de dados, verifique se ele está sendo feito backup para outro servidor físico. No caso de um failover pode reverter o tráfego para esse outro servidor e ainda ter seus dados intactos.