É uma boa ideia usar um banco de dados para mais de 50.000 lojas?

Eu sei que o Shopify usa apenas um banco de dados para todas as lojas. Mas como eles podem lidar com seu banco de dados com um volume tão grande de dados? É uma boa ideia usar um banco de dados único para mais de 50.000 lojas?

Observe: estou respondendo da perspectiva do SQL Server, portanto mencionei alguns conceitos específicos do SQL Server, mas acredito que todos esses conceitos tenham equivalentes em outras plataformas principais de RDBMS, com benefícios e limitações semelhantes.

Provavelmente também continuarei editando esta resposta enquanto penso em outros possíveis prós / contras.

Bem, isso realmente depende do esquema, volume, etc. O que exatamente é uma loja armazenando? Como é diferente de armazenar dados sobre 50.000 gatos ou 50.000 produtos ou 50.000 nozes?

Há vários motivos (além do aspecto do tamanho por si só) por que você pode não querer armazenar dados para 50.000 clientes diferentes em um único banco de dados, se os dados podem ser completamente segregados pelo cliente (sem incluir tabelas de pesquisa como códigos postais ou tabelas específicas do aplicativo, que podem ser inseridas em um único banco de dados central):

• se um cliente supera o aplicativo, não há uma maneira fácil de extrair apenas os dados e movê-los para outra instância, servidor etc. para expandir, a menos que você planeje com antecedência e particione em algo como CustomerIDe tenha 50.000 grupos de arquivos (você é limitado de qualquer maneira para 15.000 partições ou 1.000 se você estiver em uma versão mais antiga do SQL Server e ter muitos grupos de arquivos pode ser desastroso ). Observe também que o particionamento requer o Enterprise Edition.

• se todos os seus clientes forem grandes demais para essa instância, escalar significa obter novo hardware e mover todo o banco de dados para lá (e potencialmente fazer isso novamente no futuro).

• excluir um cliente pode ser igualmente doloroso, pois você terá que excluir alguns% de linhas de tabelas muito grandes e isso não será barato.

• você provavelmente terá ampla distribuição de dados do cliente (um cliente com um bilhão de linhas, outro cliente com 5.000). Isso pode levar a coisas como detecção de parâmetros e desempenho prejudicial que envolvem cardinalidade e qualidade do plano (já que você provavelmente estará reutilizando os mesmos planos para as mesmas consultas em conjuntos de dados muito diferentes).

• todos os seus clientes estão sujeitos aos mesmos planos de SLAs e HA / DR. Você possui todo o banco de dados no modo de recuperação completa com backups de log de n minutos ou é simples e depende de backups completos + diff. Se você precisar reverter devido a um erro do cliente ou precisar recuperar o banco de dados em um determinado momento, isso afeta todos os clientes.

• existe potencial para erros na recuperação de dados - bugs nas cláusulas where, por exemplo, podem levar um cliente a ver os dados de outro cliente ou a todos os dados de outros clientes.

• pode haver implicações legais (algumas empresas terão requisitos rígidos em vigor para que você não coloque seus dados no mesmo banco de dados de qualquer outra empresa, e particularmente nos de seus concorrentes).

• se a segurança dos dados de qualquer cliente é importante, é muito mais fácil usar a separação do banco de dados do que a separação dentro de uma tabela.

Algumas vantagens de ter cada cliente em um banco de dados separado (ou pelo menos ter vários bancos de dados, cada um para um grupo de clientes):

• em termos de tamanho, levará aproximadamente o mesmo tamanho no disco.
• a expansão é mais fácil, pois você pode simplesmente mover um banco de dados (ou muitos) para um servidor diferente.
• excluir um cliente e todos os seus dados equivalem aproximadamente a DROP DATABASE.
• você está usando mais memória para planos (ou possui menos planos em cache por cliente), mas pelo menos esses planos são relevantes para os dados em seus respectivos bancos de dados e são menos propensos a problemas de estatísticas / detecção de parâmetros.
• você pode facilmente ter diferentes SLAs e planos de recuperação de desastres, colocando alguns bancos de dados completos e outros simples. Também reverter ou restaurar para um ponto no tempo afeta apenas esse cliente.
• você pode facilmente colocar diferentes bancos de dados (por exemplo, seus clientes de alta prioridade) em E / S mais rápidas. Você poderia fazer isso em um único banco de dados com grupos de arquivos, mas isso é muito mais difícil de gerenciar (pelo menos IMHO).

Algumas desvantagens:

• Além do tamanho, você provavelmente não desejará ter 50.000 bancos de dados em uma única instância do SQL Server; portanto, isso provavelmente significará a expansão para vários servidores.
• o tempo de inicialização aumenta porque há alguma sobrecarga inerente na inicialização de cada banco de dados.
• o aplicativo deve ser um pouco mais inteligente - em vez de apenas ter o CustomerID na cláusula where, ele deve se conectar dinamicamente ao banco de dados do CustomerID. Isso não é difícil com uma camada intermediária adequada, mas é uma mudança.
• sim, você tem muitas cópias das mesmas tabelas e procedimentos, mas o código e o esquema são idênticos nos bancos de dados, apenas os dados são diferentes. Portanto, implantar alterações de código / esquema agora é apenas um loop, em vez de uma única execução.
• a manutenção é um pouco diferente quando você gerencia 50.000 bancos de dados - novamente o tamanho geral é aproximadamente o mesmo, mas o processo precisa mudar - você não pode simplesmente desfragmentar / reindexar / fazer backup de todos os 50.000 bancos de dados de uma só vez. Dito isto, no meu trabalho anterior, gerenciei instâncias com 500 a 1.000 bancos de dados idênticos, e a diferença entre gerenciar 3 bancos de dados idênticos e 750 bancos de dados idênticos é simplesmente o tempo que leva.