Temos um banco de dados de nível empresarial de escala muito grande. Como parte do nosso modelo de negócios, todos os usuários da Web acessam nossos servidores da Web ao mesmo tempo todos os meses, o que, por sua vez, martela nossa caixa sql. O tráfego é muito pesado e continua aumentando, quanto maior a empresa crescer. A otimização do proc sql foi realizada e o hardware já foi escalado para um nível muito alto.
Estamos procurando fragmentar o banco de dados agora para garantir que possamos lidar com o crescimento da empresa e com as cargas futuras.
Decidimos quais dados específicos devem ser fragmentados. É um subconjunto do nosso banco de dados que é altamente utilizado.
No entanto, minha pergunta é sobre os dados não fragmentados que são comuns / universais. Um exemplo de dados como esse pode ser uma tabela de inventário, por exemplo, ou possivelmente uma tabela de funcionários, tabela de usuários etc.
Vejo duas opções para lidar com esses dados comuns / universais:
1) design 1 - Coloque os dados comuns / universais em um banco de dados externo. Todas as gravações ocorrerão aqui. Esses dados serão replicados para cada fragmento, permitindo que cada fragmento leia esses dados e junte-os a esses dados em procs t-sql.
2) design 2 - Dê a cada fragmento sua própria cópia de todos os dados comuns / universais. Deixe cada shard gravar localmente nessas tabelas e utilizar a replicação de mesclagem sql para atualizar / sincronizar esses dados em todos os outros shards.
preocupações com o design nº 1
1) Problemas transacionais: se você tiver uma situação em que deve gravar ou atualizar dados em um shard e depois gravar / atualizar uma tabela comum / universal em 1 processo armazenado, por exemplo, não será mais possível fazer isso facilmente. Os dados agora existem em instâncias e bancos de dados sql separados. Pode ser necessário envolver o MS DTS para verificar se é possível agrupar essas gravações em uma transação, pois elas estão em um banco de dados separado. O desempenho é uma preocupação aqui e possíveis reescritas podem estar envolvidas para procs que gravam em dados compartilhados e comuns.
2) perda de integridade referencial. Não é possível fazer integridade referencial entre bancos de dados.
3) Recodificação de grandes áreas do sistema para que ele saiba gravar dados comuns no novo banco de dados universal, mas leia dados comuns dos shards.
4) aumento de viagens de banco de dados. Como no 1 acima, quando você se deparar com uma situação em que deve atualizar dados fragmentados e dados comuns, fará várias viagens de ida e volta para fazer isso, pois os dados agora estão em bancos de dados separados. Alguma latência de rede aqui, mas não estou preocupada com esse problema tanto quanto as anteriores 3.
preocupações sobre o projeto nº 2
No projeto nº 2, cada shard obtém sua própria instância de todos os dados comuns / universais. Isso significa que todo o código que une ou atualiza dados comuns continua a funcionar / executar exatamente como hoje. Há muito pouca recodificação / reescrita necessária da equipe de desenvolvimento. No entanto, esse design depende completamente da replicação de mesclagem para manter os dados sincronizados em todos os shards. os dbas são altamente qualificados e estão muito preocupados que a replicação de mesclagem possa não ser capaz de lidar com isso e que a replicação falhe, que a recuperação dessa falha não é boa e pode nos impactar muito negativamente.
Estou curioso para saber se alguém optou pela opção de design nº 2. Também estou curioso para saber se estou com vista para uma terceira ou quarta opção de design que não vejo.
Agradeço antecipadamente.