Quais problemas vou obter ao criar um banco de dados por cliente?

Lembro-me dos podcasts de stackoverflow que o Fog Creek usa um banco de dados por cliente para o Fogbugz . Suponho que isso signifique que os servidores Fogbugz On Demand tenham 10s de milhares de bancos de dados.

Estamos apenas começando a desenvolver um aplicativo Web e temos um problema semelhante a ser resolvido (muitos clientes com seus próprios dados isolados).

Quais problemas devo esperar com o uso de um banco de dados por cliente? Como posso resolvê-los?

Meus pensamentos iniciais

Vantagens de um banco de dados por cliente

• Esquema de banco de dados mais simples
• Backups mais simples - você pode fazer backup de cada cliente por vez, sem realmente impactar outros clientes.
• Facilita a exportação de dados de um determinado cliente.
• Melhor desempenho do cache - uma gravação em uma das tabelas mais ativas afeta apenas o cliente único que executou a gravação.
• Mais fácil de escalar no hardware. Por exemplo, quando precisamos passar de 1 para 2 servidores, apenas movemos metade de nossos clientes para o novo servidor.

Desvantagens

• O MySQL pode lidar com 5.000 bancos de dados? O desempenho seria péssimo?
• As alterações no esquema podem ser difíceis de replicar em todos os bancos de dados. Realmente teríamos que ter um plano automatizado para isso, como versionar o esquema e um script que entenda como levar um banco de dados de uma versão para outra.
• Fazer tudo o que é comum a todos os nossos clientes pode ser estranho ou impossível
• Semelhante ao anterior, mas qualquer análise que desejamos executar em todos os nossos clientes pode ser impossível. Como devemos rastrear o uso em todos os clientes, por exemplo?

Essa solução é chamada de design de multilocatário, em que cada inquilino (cliente) tem seu próprio banco de dados. Dado isso, existem outras considerações sobre a abordagem alternativa, que é um único banco de dados:

1. Com um único banco de dados, todos devem estar na mesma versão, não importa o quê. Não é possível atualizar alguns clientes e outros não. Isso pode ser problemático se um cliente desejar um hotfix de um aplicativo que não esteja pronto para uma liberação ampla.
2. Com um único banco de dados, quando você faz um upgrade, todos os clientes estão inativos. Se algo der errado, todo cliente está ferrado.
3. Com um único banco de dados, é muito mais difícil controlar recursos. Ou seja, se um cliente está martelando o banco de dados, é mais difícil fornecer mais recursos separados dos demais.
4. É muito mais difícil permitir que os usuários hospedem suas próprias versões do seu aplicativo. Se você estiver criando uma solução que será usada por grandes empresas, isso geralmente não é necessário. Seu departamento de TI deseja controle total sobre o acesso ao sistema.
5. Provavelmente, é mais barato escalar bancos de dados em vez de escalá-los. Ou seja, ter que investir em hardware mais rápido para hospedar um banco de dados para controlá-los é provavelmente mais caro do que poder escalar clientes para servidores de banco de dados menores e mais baratos. Não posso dizer isso definitivamente porque depende muito do software do servidor. Se você seguir o MySQL, isso provavelmente é verdade porque os custos de licenciamento são insignificantes. No entanto, se você mudar para o SQL Server, por exemplo, a expansão se torna muito mais cara, a menos que você use um ambiente VPS e o custo-benefício da expansão contra as alterações. No entanto, posso dizer que, uma vez que seu banco de dados fica muito grande, o gerenciamento exige níveis cada vez maiores de conhecimento. Bancos de dados muito grandes exigem a reprodução de vários grupos de arquivos e a inserção de determinados índices em eixos diferentes para obter melhor desempenho. Em suma, eles conseguem latas complicadas muito rapidamente.

Ter bancos de dados separados significa que você precisa criar um mecanismo de atualização que corresponda à versão do banco de dados com a versão do aplicativo / site. No entanto, bancos de dados separados fornecem isolamento superior de dados e o IMO tem um custo mais baixo de hospedagem. Não é uma solução para todos os cenários. Se o seu sistema nunca seria hospedado fora da sua hospedagem e precisava aumentar rapidamente os clientes e era desejável ter todos os usuários na mesma versão do esquema de aplicativo e banco de dados, certamente ter um único banco de dados é uma abordagem melhor.

Na minha experiência, você não deve criar um banco de dados por cliente. Deixe-me lhe dar um exemplo:

No ano passado, trabalhei com 70 bancos de dados (muito menos que 5000), cada um com o mesmo esquema e tudo. Em teoria, as coisas iriam conforme o planejado (como você menciona na seção de vantagens), mas na realidade nem tanto. Tivemos muitos problemas com a atualização de esquemas, suporte ao usuário, atualização de software, etc. Foi terrível.

Usamos o Firebird e fui contratado após o envio do produto, mas isso me deu o conhecimento de nunca trabalhar com bancos de dados separados.

Não estou dizendo que você não consegue, estou dizendo que as coisas podem dar muito errado e, para ser sincero, sua lista de vantagens não parecia atraente o suficiente para correr o risco. A maioria deles pode ser realizada com um único banco de dados.

Você provavelmente desejaria manter outro banco de dados para rastrear em qual versão cada cliente está, para poder acompanhar quais sofreram ou não a última rodada de modificações.

Criar scripts para as atualizações não seria tão difícil ... você poderia escrever algo que analisasse o catálogo de bancos de dados e aplicasse as alterações necessárias para obter cada banco de dados para a versão mais recente, possivelmente ignorando aqueles que não deveriam ser atualizados por algum motivo.

Como os 'bancos de dados' do mysql são apenas esquemas, como Gaius apontou, se tudo estiver sendo executado na mesma instância do servidor, você pode qualificar o nome das tabelas que está tentando modificar ou obter informações:

alter schema.table ...
select ... from schema.table

...

Se você começar a dividir as coisas em vários servidores, ainda poderá criar um script para fazer conexões com vários servidores para poder aplicar todas as alterações; para a análise, novamente, você pode definir vários links de banco de dados usando tabelas federadas em seu banco de dados mestre para acessar os dados de um local, pois você está lendo as tabelas.

...

Além disso, esteja ciente de que eles não estão usando o mySQL para troca de pilhas, eles estão usando o SQL Server.

E eu não tenho idéia de que tipo de sobrecarga de desempenho haveria no mysql nessa escala, acho que nunca passei de 30 'bancos de dados' no mysql.

Eu tenho um cliente de hospedagem na Web / DB que possui mais de 750 bancos de dados de clientes com o mesmo número de tabelas (162) e as mesmas estruturas de tabela. Combinados, todos os dados de clientes do meu cliente totalizam 524 GB (95% InnoDB)

Imagine todos esses bancos de dados competindo por 13G de buffer pool innodb em nove servidores de banco de dados por meio de replicação circular. Escalar com essa configuração de hardware não foi suficiente. Imediatamente, recomendamos que o cliente aumente a escala.

Recentemente, migramos esse cliente para 3 servidores de banco de dados com muito mais potência (a todo custo, fique longe do SSD em ambientes de alta gravação, SEMPRE !!!). Nós os atualizamos do MySQL 5.0.90 para o MySQL 5.5.9. Diferenças dramáticas foram vistas quase instantaneamente.

A expansão também deve ser considerada, pois se você tiver centenas de clientes atingindo os mesmos recursos de memória e disco, a expansão reduzirá seu uso linearmente (O (n)), onde n é baseado no número de servidores de banco de dados em um ambiente multimaster.

No caso do meu cliente, minha empresa está reduzindo-o de 9 servidores de banco de dados (Quad Code, 32 GB de RAM, 824G RAID10) para servidores de banco de dados mais rápidos (Dual HexaCore [isso mesmo, 12 CPUs], 192 GB de RAM, 1,7 TB de RAID10) do MySQL 5.5 .9 (para tirar proveito das múltiplas CPUs). Além disso, imagine um buffer pool de 150 GB innodb em 50 partições de 3 GB cada (vários buffer pools do InnoDB são um novo recurso do MySQL 5.5). Uma escala menor, mas em escala maciça, funcionou para a infraestrutura exclusiva do meu cliente.

MORAL DA HISTÓRIA : Aumentar ou diminuir o tamanho nem sempre é a solução se você tiver tabelas mal projetadas. O que quero dizer é o seguinte: se as páginas de índice tiverem população de chaves desequilibrada para índices com várias colunas, a consulta de chaves nas partes desequilibradas dos índices levará à verificação de tabela após verificação de tabela ou pelo menos índices que nunca são usados ​​devido à exclusão da Consulta MySQL Optimizer. Simplesmente não há substituto para o design adequado.

O MySQL cria bancos de dados em diretórios separados, portanto depende muito do sistema operacional subjacente e de quantas pastas / arquivos manipuladores ele pode manipular. Não deve ser um problema com os sistemas operacionais modernos, mas é daí que muitos gargalos surgirão.

Não há nada dizendo que você precisa hospedar versões diferentes do banco de dados ou aplicativo. O que há de errado em simplesmente isolar os dados executando um banco de dados por cliente e tendo uma versão do banco de dados e do aplicativo? É claro que cada banco de dados do cliente precisaria ser clonado a partir de um modelo da versão atual de trabalho. Do ponto de vista de segurança e isolamento de dados, acho que isso é ideal.

A única desvantagem que vejo é que você precisaria atualizar manualmente cada banco de dados ao criar uma nova versão. Isso pode ser facilmente automatizado.