Quais são as vantagens da utilização de um único banco de dados para CADA cliente?

Question

Em um banco de dados centrada no aplicativo que foi projetado para vários clientes, eu sempre pensei que era "melhor", para usar um banco de dados único para TODOS os clientes - associar registros com a devida índices e chaves.Ouvir o Estouro de Pilha podcast, ouvi Joel mencionar que FogBugz usa um banco de dados por cliente (por isso, se houvesse de 1000 clientes, não seria de 1000 bases de dados).Quais são as vantagens de utilizar essa arquitetura?

Eu entendo que, para alguns projetos, clientes precisam de acesso direto a todos os seus dados - no como um aplicativo, é óbvio que cada cliente precisa de seu próprio banco de dados.No entanto, para projetos onde o cliente não precisa acessar diretamente o banco de dados, existem vantagens de se utilizar um banco de dados por cliente?Parece que em termos de flexibilidade, é muito mais simples usar um único banco de dados com uma única cópia das tabelas.É mais fácil adicionar novas funcionalidades, é mais fácil criar relatórios, e é mais fácil de gerenciar.

Eu estava muito confiante no "banco de dados único para todos os clientes" método até que eu ouvi Joel (um desenvolvedor experiente) menção de que o seu software usa uma abordagem diferente-e eu estou um pouco confuso com a sua decisão...

Eu já ouvi pessoas citam que as bases de dados lento com um grande número de registros, mas de qualquer banco de dados relacional, com algum mérito, não vai ter esse problema - especialmente se adequada índices e chaves são usadas.

Qualquer entrada é muito apreciada!

Answer 1

Suponha que não há nenhuma penalidade de escala para armazenar todos os clientes em um banco de dados;para a maioria das pessoas, e bem configurado bases de dados/consultas, isso vai ser bastante verdadeiro nos dias de hoje.Se você não for uma dessas pessoas, bem, o benefício de um único banco de dados é óbvio.

Nesta situação, os benefícios vêm de o encapsulamento de cada cliente.A partir do código de perspectiva, cada cliente existe em isolamento - não é possível situação em que uma atualização do banco de dados pode substituir, corruptos, recuperar ou alterar dados pertencentes a outro cliente.Isso também simplifica o modelo, como você não precisa sempre considerar o fato de que registros podem pertencer a outro cliente.

Você também obter benefícios de separabilidade - é trivial para receber os dados associados a um determinado cliente ,e movê-los para um servidor diferente.Ou restaurar uma cópia de segurança do cliente quando a chamada até a dizer "Temos apagar alguns dados da chave!", usando o logon builtin mecanismos de banco de dados.

Você obtém fácil e gratuito servidor de mobilidade, se você outscale um servidor de banco de dados, você pode simplesmente hospedar novos clientes em outro servidor.Se estivessem todos em um banco de dados, você precisará obter beefier de hardware ou executar o banco de dados através de várias máquinas.

Fácil controle de versão - se um cliente quer ficar na versão 1.0 do software, e outra quer 2.0, onde o 1.0 e 2.0 usar diferentes esquemas de banco de dados, não há problema - você pode migrar sem ter que puxá-los para fora de um banco de dados.

Eu posso pensar de uma dúzia de mais, eu acho.Mas no todo, o conceito-chave é "simplicidade".O produto gere um cliente, e, portanto, um banco de dados.Nunca há qualquer complexidade do "Mas o banco de dados também contém outros clientes" problema.Ele se encaixa com o modelo mental do usuário, onde eles existem sozinho.Vantagens como ser capaz de fazer e fácil de relatórios sobre todos os clientes de uma só vez, são mínimos - com que frequência você quer um relatório sobre todo o mundo, em vez de apenas um cliente?

Answer 2

Aqui está uma abordagem que eu tenha visto antes:

• Cada cliente tem uma única seqüência de caracteres de conexão armazenados em um mestre de banco de dados de clientes.
• O banco de dados é projetado de modo que tudo é segmentado por CustomerID, mesmo se houver um único cliente em um banco de dados.
• Scripts são criados para migrar todos os dados do cliente para um novo banco de dados, se necessário e, em seguida, só que de um cliente de seqüência de caracteres de conexão precisa ser atualizado para apontar para o novo local.

Isso permite a utilização de um único banco de dados primeiro e, em seguida, facilmente segmentação mais tarde, uma vez que você tem um grande número de clientes, ou mais comumente quando você tem um casal de clientes que o uso excessivo do sistema.

Eu descobri que a restauração de determinados dados do cliente é realmente difícil quando todos os dados no mesmo banco de dados, mas gerenciando atualizações é muito mais simples.

Quando a utilização de um único banco de dados por cliente, você pode executar em um enorme problema de manter todos os clientes que executam a mesma versão do esquema, e mesmo que não considere trabalhos de backup em um monte de clientes, bancos de dados específicos.Naturalmente restauração de dados é mais fácil, mas se você certifique-se de não excluir permanentemente os registos (marcar com um excluído bandeira ou mover um arquivo de tabela), você terá menos necessidade de restauração de banco de dados em primeiro lugar.

Answer 3

Mantê-lo simples.Você pode ter certeza de que seu cliente é só ver seus dados.O cliente com menos registros não tem para pagar a pena de ter que competir com centenas de milhares de registros que pode ser no banco de dados, mas não a deles.Eu não me importo o quão bem tudo é indexado e otimizado haverá consultas que determinam o que eles têm a varredura de cada registro.

Answer 4

Bem, o que aconteceria se um de seus clientes, diz a você para restaurar uma versão anterior de seus dados devido a alguns fracassada trabalho de importação ou semelhante?Imagine como seus clientes se sentem, se você disse a eles "você não pode fazer isso, desde que os seus dados são compartilhados entre todos os nossos clientes" ou "Desculpe, mas o seu alterações foram perdidos porque o cliente X exigiu uma restauração do banco de dados".

Answer 5

Como para a dor de atualização de 1000 servidores de banco de dados de uma só vez, alguns bastante simples de automação deve tomar cuidado com isso.Contanto que cada banco de dados mantém um esquema idêntico, em seguida, ele realmente não vai ser um problema.Nós também podemos usar a base de dados do cliente por abordagem, e que funciona bem para nós.

Aqui está um artigo sobre este mesmo tópico (sim, é MSDN, mas é uma tecnologia independente de artigo): http://msdn.microsoft.com/en-us/library/aa479086.aspx.

Outra discussão de multi-tenancy como ele se relaciona com o seu modelo de dados aqui: http://www.ayende.com/Blog/archive/2008/08/07/Multi-Tenancy--The-Physical-Data-Model.aspx

Answer 6

Escalabilidade.Segurança.Nossa empresa usa 1 DB por abordagem de clientes bem.Ele também torna o código um pouco mais fácil de manter bem.

Answer 7

Eu só estou adicionando esta resposta para incluir a palavra "multi-tenant" aqui.Eu estava procurando por isso, o uso de "multi" como a consulta, e este não aparecia.

Answer 8

Obrigado pelo seu contributo -- todos excelentes e muito válido pontos.Eu suponho que eu estou olhando mais em atualização de flexibilidade.Se você precisar modificar o esquema para adicionar um novo recurso (digamos para um aplicativo da web) ou para aumentar os recursos existentes, é simples para fazer em um único banco de dados.Se você tivesse replicar essa alteração em 1000 bancos de dados separados, a chance de erro aumenta.O que acontece se uma operação falhar?Quanto tempo demora para atualização a cada cliente?

Se as cópias de segurança são mantidas (ou se o seu banco de dados foi estruturado de forma que os dados eram, na verdade, nunca substituídos), restaurar os dados de um determinado cliente é trivial.

A simplicidade do código, embora importante, não é extremamente complicado.Dependendo do idioma utilizado e as metodologias, é simples para criar objetos que representam apenas que o cliente específico (que armazenam um determinado ID de Cliente) e o resto do projeto, apenas tem de ser codificado para um único objeto (como uma espécie de cliente único).

A escalabilidade é algo a considerar - você está certo de que é fácil pegar um único isolado de banco de dados e movê-lo para outro servidor físico;no entanto, está se tornando cada vez mais fácil para servidores de cluster juntos - e mesmo sem clusters, parece que seria uma pequena mudança de ponto de cada cliente em um SERVIDOR de banco de dados que hospeda o banco de dados universal (assim você pode ter duas ou três servidores de banco de dados que hospeda apenas um único banco de dados, cada, por exemplo).Esta abordagem mantém o processo de atualização limitado a apenas três bancos de dados.

Answer 9

Nos setores regulados, tais como cuidados de saúde pode ser um requisito de um banco de dados por cliente, possivelmente até mesmo um banco de dados separado do servidor.

A resposta simples para atualização de vários bancos de dados durante a atualização é para fazer a atualização como uma transação, e tirar um snapshot antes de atualizar, se necessário.Se você estiver executando suas operações, bem, então você deve ser capaz de aplicar a atualização para qualquer número de bancos de dados.

O agrupamento não é realmente uma solução para o problema de índices e completo verificações de tabela.Se você mover para um cluster, muda muito pouco.Se você tiver vários bancos de dados menores para distribuir em vários computadores, você pode fazer isso de forma mais barata, sem um cluster.A confiabilidade e a disponibilidade são considerações, mas pode ser tratada de outras maneiras (algumas pessoas ainda precisam de um cluster, mas a maioria provavelmente não).

Eu estaria interessado em ouvir um pouco mais do contexto do que você pensa sobre isso, porque o agrupamento não é um simples tópico e é caro para implementar no RDBMS mundo.Há um monte de falar/bravata sobre os clusters não-relacional do mundo, o Google Bigtable etc.mas eles estão resolvendo um conjunto diferente de problemas, e perder algumas das funcionalidades úteis, a partir de um RDBMS.

Answer 10

Há um par de significados de "banco de dados"

• a caixa de hardware
• o software em execução (por exemplo,"oracle")
• o determinado conjunto de arquivos de dados
• o início de sessão específico ou esquema

É provável que Joel significa uma das camadas inferiores.Neste caso, é apenas uma questão de gerenciamento de configuração de software...você não precisa de patch 1000 software de servidores para corrigir um bug de segurança, por exemplo.

Eu acho que é uma boa idéia, de modo que um erro de software não vazamento de informações entre clientes.Imagine o caso com um errôneo cláusula where, que me mostrou os dados de seu cliente, bem como a minha.