Início / dba / Perguntas / 7924
Accepted
KM.
Asked: 2011-11-16 13:16:53 +0800 CST

Um grande banco de dados versus vários menores

  • 772

Temos uma situação em que podemos (A) implantar instâncias de um aplicativo em um banco de dados MySQL usando prefixo de tabela ou (B) usar bancos de dados MySQL diferentes para cada instância do aplicativo, por exemplo,

Configurar um":

central_database
  app1_table1
  app1_table2
  app1_tablen
...
  appn_table1
  appn_table2
  appn_tablen

O resultado final é um banco de dados grande com muitas tabelas.

Configuração "B":

app1_db
  table1
  table2
  tablen

...

appn_db
  table1
  table2
  tablen

O resultado final são muitos bancos de dados com algumas tabelas.

Todas as coisas iguais (por exemplo, quantidade de dados, número de instâncias de aplicativos etc.), quais são os prós e contras de usar qualquer uma das abordagens? O que seria prejudicial para o desempenho e a manutenção do banco de dados? O aplicativo é baseado em PHP 5, executado no Apache 2.x, e estamos executando o MySQL 5.x.

Muito obrigado pelo seu tempo e pensamentos!

mysql database-design

4 respostas

  1. Best Answer

    Eu executei um sistema com a melhor parte de mil bancos de dados, espalhados por vários servidores. Eles eram todos de uma estrutura idêntica e estavam sincronizados com um banco de dados de modelo que estava em cada uma das máquinas.

    Isso me permitiu a capacidade de migrar bancos de dados de um banco de dados para outro se um estava ficando excessivamente sobrecarregado e, à medida que o mix de clientes mudava, eu podia criar novos bancos de dados em servidores diferentes para balancear a carga entre os servidores. Essa foi a maior vantagem que obtive do sistema, pois tinha vários pedaços grandes de estanho realizando várias consultas complicadas simultaneamente em servidores separados.

    O melhor disso é que você pode adicionar servidores à configuração na sua própria velocidade, à medida que cada servidor começa a ficar sobrecarregado, adicionar outro à mistura, migrar alguns dbs para o novo servidor e terminar com um bom conjunto de servidores com balanceamento de carga. Uma maneira muito legal e simples de adicionar escala ao sistema como e quando for necessário!

    A razão pela qual optei por essa abordagem em vez da abordagem de banco de dados enorme e único foi o tamanho do banco de dados potencial que teria sido criado... cada um dos 1.000 bancos de dados tinha 200 tabelas e muitas das tabelas individuais bancos de dados compreendiam muitas centenas de milhões de linhas de dados!

    Uma única configuração de banco de dados exigiria que certas tabelas (aproximadamente 8 delas) tivessem vários bilhões de linhas de dados, e o tamanho total do banco de dados teria sido superior a 10 TB. Conseguimos ter vários servidores com 5 TB de armazenamento RAID 10, com muitos bancos de dados em cada um.

    Isso é o que eu faria! Espero que ajude na sua tomada de decisão... :)

    • 15

  2. O aplicativo que você está construindo é um aplicativo SaaS? Nesse caso, sugiro que você considere uma terceira abordagem - tenha um banco de dados, com uma estrutura comum para todas as instâncias do aplicativo com uma diferença - adicione uma coluna userid/applicationid em todas as tabelas. Isso reduzirá bastante os custos de desenvolvimento/manutenção de aplicativos. Isso, na minha experiência, é uma das melhores abordagens para armazenar dados de vários locatários.

    Veja também este excelente white paper da Microsoft sobre arquitetura de dados multilocatário

    Também destaca as vantagens/desvantagens das abordagens que você mencionou.

    • 11

  3. A configuração B é muito mais fácil de gerenciar

    Cada um tablenfica em uma pasta diferente. Isso pode ser muito benéfico se você não quiser testar os limites do SO .

    Por exemplo, meu empregador hospeda o MySQL para um sistema de CRM de concessionárias de automóveis. Cliente tem 800 concessionárias. Cada banco de dados da concessionária possui 160 tabelas. São 128.000 mesas.

    • Na Configuração A, todas as 128.000 tabelas ficariam em um banco de dados.
    • Na Configuração B, cada conjunto de 160 tabelas fica em uma subpasta em /var/lib/mysql.

    Do ponto de vista do sistema operacional e sua capacidade de lidar com i-nodes (ou tabelas FAT para Windows), o que inclui ter um número máximo de arquivos por pasta:

    • Na Configuração A, você se preocuparia com 128.000 arquivos em uma pasta. Seu sistema operacional pode suportar tantos arquivos em uma única pasta?
    • Na configuração B, não se preocupe.

    Se você tivesse que ajustar as estruturas da tabela usando ALTER TABLEou algum outro DDL:

    • Na Configuração A, você teria que fazer o script do DDL necessário usando PHP (ou scripts MySQL especializados) em relação ao nome da tabela específica e consultas correspondentes antes de acessá-lo e fazer alterações
    • Em Configuração B, conecte-se ao banco de dados correto e acesse sempre a mesma tabela nomeada. O paradigma de acesso seria sempre limpo:
      • Banco de dados específico
      • Pasta específica em/var/lib/mysql
      • Nome de tabela específico.

    Se você quiser colocar bancos de dados diferentes em discos diferentes:

    • Na configuração A, os links simbólicos para cada tabela movida para um disco separado só agravarão o problema "número de inodes em uma pasta". A E/S de disco e o acesso geral à tabela complicam mais e aumentam a carga geral do servidor, pois os .frmarquivos são acessados ​​repetidamente.
    • Em Configuração B, basta mover uma pasta de banco de dados inteira para uma montagem de dados separada. A E/S de disco pode ser distribuída sob demanda.
    • CAVEAT: Altamente desencorajado para InnoDB

    Falando metaforicamente, qual você preferiria ter?

    • um apartamento gigantesco com um quarto, um banheiro e uma cozinha (SetupA)
    • vários apartamentos, cada um com seu próprio quarto, banheiro e cozinha (SetupB)

    Quando se trata de consertar um radiador em um apartamento:

    • Com a Configuração A, cada inquilino pode ser incomodado e deve ser envolvido porque você precisa conversar com os inquilinos afetados na frente de todos como se fosse da conta de todos
    • Com a configuração B, além de ouvir algumas batidas na parede ou nos canos, os inquilinos podem continuar com suas vidas privadas
    • Esta lista e suas metáforas podem continuar e continuar

    IHMO Embora os orçamentos possam ser uma força motriz para decisões de projeto/infraestrutura, eu seria facilmente a favor de bancos de dados separados por cliente.

    • 9

  4. Eu também tenho um produto SaaS e uso a mesma configuração que Dave Rix mencionou.

    Cada cliente tem seu próprio banco de dados

    Eu faria mais algumas sugestões:

    • Você deve ter um banco de dados "controlador" com balanceamento de carga (mestre-mestre), que armazena a localização do banco de dados (ip), o nome do banco de dados e o nome do cliente. Este controlador é onde sua aplicação sabe onde está cada banco de dados de clientes.

    • Seu aplicativo pode estar onde você quiser - você pode ter bancos de dados para muitos datacenters ao redor do mundo.

    • Seu aplicativo pode crescer o quanto você quiser. Se for um Web SaaS, você pode fazer um farm de servidores web com balanceamento de carga apontando para cada banco de dados, conforme o login do cliente.

    • Você pode criar VIEW/Database customizados para alguns clientes - sem impactar outros. Isso é importante se você tentar oferecer personalização como parte do seu negócio.

    • Você pode configurar dois web farms + farms de banco de dados: um para versões "EDGE" e outro para versões "STABLE". Em seguida, você precisará ter um pequeno grupo de clientes dispostos a testar as coisas e confirmar se tudo está funcionando conforme o esperado (em outras palavras, garantia de qualidade [QA]), antes de aplicar a todos os seus clientes.

    • Você deve ter um trabalho de backup automatizado por banco de dados pelo menos uma vez por dia.

    • Você deve ter outro servidor para fazer a replicação. Um mesmo host pode replicar muitos bancos de dados (use portas diferentes para cada servidor no mesmo host) se você não puder pagar a mesma quantidade de servidores host "mestre" e "escravo".

      Por exemplo, 5 servidores master + 1 servidor slave com 5 bancos de dados rodando em portas diferentes - basta ter RAM suficiente para isso.

    • Você deve fazer uma ferramenta de "migração" para mover um banco de dados para outro servidor sempre que quiser.

    • Você deve migrar os clientes VIP para um servidor de banco de dados mais seguro/disponível para manter sua receita protegida. Lembre-se, muitas vezes 20% dos clientes representam 80% de sua receita. Cuide de clientes especiais.

    • Você deve ter um coletor de "lixo" de exclusão de backup, para fazer um "último backup" e excluir o banco de dados quando um cliente sair de sua empresa.

    • Você deve ter uma imagem de banco de dados para exportar e usar para novas contas.

    • Você deve ter uma ferramenta de correção de banco de dados para aplicar novos patches a contas existentes.

    • Mantenha versões de todos os seus patches SQL, usando uma ferramenta de versionamento como subversion ou git e crie sua própria numeração também. xxx-4.3.0.sql - às vezes o patching dá errado e você deve saber como recuperar/completar a tarefa de patching.

    Bom, isso é tudo que eu faço na minha empresa com um produto que tem cerca de 5k bancos de dados com cerca de 600 tabelas cada.

    • 3

relate perguntas