Meu raciocínio está correto ao dividir tabelas com estruturas semelhantes, pois contêm dados não relacionados?
Vou explicar a situação com um exemplo:
Suponha que haja um servidor que hospeda o banco de dados de um jogo online. O jogo tem vários mundos de jogo que operam em paralelo. O esquema para cada gameworld do jogo é o mesmo, digamos que haja 15 tabelas relacionais no design do banco de dados do jogo. Suponha também que o servidor decida não excluir os dados dos servidores antigos e, em vez disso, arquive-os.
Abordagem 1:
Agora, como os mundos do jogo estão hospedados em um servidor, pode parecer lógico colocar todos os dados do jogo em um banco de dados contendo 15 tabelas. A estrutura da tabela de uma tabela de exemplo pode ser assim:
CREATE TABLE `table` (
playerid ...,
score ....,
gameworldid ...,
PRIMARY KEY(gameworldid,playerid)
) ENGINE = InnoDB
Então, toda vez que eu precisar mostrar os 10 jogadores com mais pontuação, terei que fazer algo comoSELECT * FROM table WHERE gameworldid = {id} ORDER By score DESC LIMIT 10
Abordagem 2:
Uma vez que os dados de um gameworld não se relacionam com os dados do outro gameworld de forma alguma (exceto pela estrutura), podemos criar bancos de dados diferentes para diferentes gameworlds ou diferentes conjuntos de tabelas para cada gameworld. A estrutura da tabela ficará mais ou menos assim:
CREATE TABLE `gameworldid_table` (
playerid ...,
score ....,
PRIMARY KEY(playerid)
) ENGINE = InnoDB
Neste caso, os 10 melhores jogadores com mais scorequery serãoSELECT * FROM table ORDER BY score DESC LIMIT 10
A questão é: qual abordagem é melhor nessa situação? O mecanismo de armazenamento que está sendo usado é InnoDB, e ao todo , pode-se esperar 6 bilhões ou mais de linhas na maior tabela mesclada, e 500 ou mais mundos de jogo. (Desde que os dados antigos não são excluídos, então, quando um gameworld é reiniciado, um novo gameworld é criado.
Na minha opinião, as vantagens da Abordagem 2 sobre a Abordagem 1 são:
- Menos espaço consumido pela chave primária e índices, tornando-os mais eficientes
- Classificação, junção e outras coisas mais rápidas em comparação com a tabela mesclada na abordagem um, que contém muitos dados extras que podem atrapalhar essas operações.
- Inserções mais rápidas em comparação com tabelas maiores
- Os dados não vão continuar se acumulando para sempre na mesma tabela
E as vantagens do Approach 1 sobre o Approach 2 ?
- Melhor capacidade de gerenciamento: 15 mesas soam melhor em comparação com 500 * 15 mesas, se você precisar fazer alguma correção manual (raro).
- soa menos insano
- Muitas tabelas podem tornar o banco de dados mais lento (não sei de fato, não consigo encontrá-lo na internet)
Acho que minhas opiniões sobre vantagens e desvantagens podem ser tendenciosas, mas realmente quero saber quais problemas podem surgir se eu escolher uma Abordagem em detrimento da outra. Além disso, existe alguma outra solução possível para esta solução?
Seus problemas provavelmente são menos sobre desempenho, assumindo um equipamento razoável e uma boa estrutura de indexação, e mais sobre outros impactos que você enfrenta.
Abordagem 1 significa alguma complexidade de programação adicional para lidar com linhas de filtragem em cada tabela para restringir o acesso a um único mundo de jogo. Isso também significa que, se você precisar restaurar um gameworld, você terá que (a) restaurar todos os gameworlds (já que eles estão no mesmo banco de dados) ou (b) restaurar um banco de dados para um banco de dados de recuperação e, em seguida, criar o script dos dados apropriados do gameworld do Recovery para o banco de dados do Gameworlds.
A abordagem 2 significa que você precisa ser capaz de gerenciar alterações de esquema em muitos bancos de dados. Isso pode ser feito por script conforme necessário. Também é mais fácil escolher esquemas diferentes para alguns mundos de jogo, mas isso adiciona sobrecarga de gerenciamento. No entanto, se um único mundo de jogo travar, você pode restaurar o(s) backup(s) válido(s) mais recente(s) e fazê-lo funcionar novamente.
Alguns anos atrás, algumas pessoas da Microsoft escreveram sua opinião sobre bancos de dados multilocatários. Consulte: http://msdn.microsoft.com/en-us/library/aa479086.aspx
Ter mais tabelas não deve, por si só, causar problemas de desempenho dentro do intervalo de tamanho que você descreve.
A escolha de sua abordagem deve levar em consideração o aproveitamento de seus pontos fortes para que você tenha um sistema que você (e os membros de seu projeto) possa gerenciar prontamente.
Se você tem um pequeno número de palavras de jogo e não espera escalar massivamente nessa direção (permitindo que algumas ou todas as classes de usuários criem seu próprio mundo, por exemplo), o que você tem aqui é essencialmente o mesmo que um "padrão" escolha de arquitetura multi-inquilino - apenas cada inquilino é uma instância do jogo em vez de um cliente completamente diferente.
Supondo que os mundos do jogo não precisem compartilhar dados (os usuários existem em mais de um mundo e precisam/desejam compartilhar dados entre eles?) razões (com um bom design, incluindo opções de índice e hardware adequado, o desempenho não precisa ser diferente entre um mundo e vários no mesmo banco de dados). Dividir cada mundo em seu próprio banco de dados remove alguma complexidade de código, pois você nunca precisa estar ciente dos vários mundos (cada banco de dados tem apenas um) e permite uma opção de dimensionamento extra à medida que suas necessidades aumentam: você pode dividir a função do banco de dados entre vários máquinas (ou mais facilmente dividi-las entre diferentes conjuntos de fusos se a E/S for o gargalo, em vez de qualquer outra coisa, de modo que várias máquinas sejam um exagero) movendo os bancos de dados mundiais.
Pesquise por "arquitetura multilocatário", aqui e em geral, e você encontrará muitos bons artigos discutindo as abordagens comuns e seus prós e contras. Um exemplo de artigo para começar seria http://msdn.microsoft.com/en-us/library/aa479086.aspx