Artigo SQL Magazine 62 - Fragmentação no SQL Server 2005

Você precisa estar logado para dar um feedback. Clique aqui para efetuar o login
Para efetuar o download você precisa estar logado. Clique aqui para efetuar o login
Confirmar voto
0
 (0)  (0)

Este artigo apresenta um pequeno projeto de distribuição de dados envolvendo as unidades de uma instituição de ensino.

Esse artigo faz parte da revista SQL Magazine edição 62. Clique aqui para ler todos os artigos desta edição

imagem_pdf.jpg

SQL Server

Fragmentação no SQL Server 2005 – Parte 1

Este artigo apresenta um pequeno projeto de distribuição de dados envolvendo as unidades de uma instituição de ensino. O foco da distribuição se refere ao cadastramento de inscrições para o vestibular, onde os candidatos se inscrevem para o vestibular de uma determinada localidade (por meio de um site localizado no servidor da FATEC Indaiatuba) e o sistema armazena os dados da inscrição na instância do SQL Server correspondente, isto é, quando um candidato se inscreve para o vestibular da FATEC Indaiatuba, os dados serão armazenados no servidor local. De outra forma, quando um candidato se inscreve para o vestibular da FATEC Sorocaba (usando o mesmo site da FATEC Indaiatuba), os dados serão armazenados no servidor localizado na cidade de Sorocaba e assim por diante.

Para esse sistema, simulamos em laboratório sete unidades da FATEC, ou seja, o sistema reconhece sete instâncias diferentes do SGBD (SQL Server 2005) como se estivessem dispersos por diversas cidades do estado de São Paulo. O artigo está dividido em duas partes: a primeira apresenta alguns conceitos de distribuição e os scripts usados na elaboração do projeto; a segunda apresenta um roteiro para a elaboração de um software, codificado em Java, que acessa o sistema distribuído. A Figura 1 ilustra o projeto de distribuição entre as instâncias do SQL Server.

Em nosso projeto, a distribuição dos dados será realizada por meio da fragmentação. A fragmentação é um processo de criar fragmentos (pedaços) de uma tabela. Em outras palavras, uma mesma tabela é dividida em fragmentos e cada fragmento pode ser armazenado em um local diferente. Na verdade, a mesma tabela é criada nas diferentes instâncias do SGBD e cada tabela mantém uma parte dos dados, ou seja, a união dos dados presentes em cada uma das instâncias irá compor o conjunto total dos dados. Para o SGBD, não existe diferença entre uma tabela e um fragmento, já que o fragmento é a própria tabela. Como veremos ao longo deste artigo, a fragmentação utilizada nesse artigo foi a horizontal, ou seja, cada fragmento representa um conjunto de registros da tabela.

 

Figura 1. Distribuição entre as instâncias do SQL Server

 

Definição de Banco de Dados Distribuídos

Banco de Dados Distribuídos (BDD) se refere a uma coleção de vários bancos de dados logicamente inter-relacionados e distribuídos por uma rede de computadores. Existem dois tipos de BDD, os homogêneos e os heterogêneos. Os homogêneos são compostos por apenas um tipo de Sistema Gerenciador de Banco de Dados (SGBD), por exemplo, vários servidores SQL Server. Esse artigo apresenta um exemplo de sistema distribuído homogêneo, pois no caso todas as instâncias serão do SQL Server 2005. Os heterogêneos são compostos por mais de um tipo de SGBD, ou seja, em um mesmo ambiente distribuído pelo menos um dos SGBDs é diferente em relação aos demais. Os SGBDs que suportam distribuição são conhecidos como SGBDD (Sistema Gerenciador de Banco de Dados Distribuídos). O próximo tópico apresenta algumas características dos SGBDDs.

 

Principais características de um SGBDD

De acordo com Date (2004), um SGBDD deve conter diversas características para ser considerado como tal. Os itens seguintes abordam essas características de forma resumida.

1.      Autonomia local: cada nó participante de um sistema distribuído (cada SGBDD) deve ser independente dos outros nós e prover mecanismos de segurança, bloqueio, acesso, integridade e recuperação após falha;

2.      Independência de um nó central: um SGBDD não deve depender de um nó central. Se a dependência ocorrer, o sistema fica menos robusto, já que possui um único ponto de falha. Isso afetaria todos os outros nós. Um nó central pode acarretar perda de desempenho do sistema, já que tende a ficar muito “carregado”;

3.      Operação contínua: um sistema distribuído não deve necessitar desativação. As operações de backup e a recuperação devem ter suporte on-line. As operações devem ser rápidas o bastante para não afetarem o funcionamento do sistema (backup incremental, por exemplo);

4.      Transparência e independência de localidade: os usuários do sistema não precisam ter ciência do local onde os dados estão armazenados. Para o usuário, os dados devem ser vistos como se fossem locais.

5.      Independência de fragmentação: as tabelas do sistema de banco de dados distribuído podem estar fragmentadas e localizadas fisicamente em diferentes nós, de forma transparente para o usuário. Usuários e aplicações não devem saber que as tabelas estão armazenadas em nó diferente do nó onde são feitas as operações. A fragmentação pode ser horizontal (fragmentação em linhas) ou vertical (fragmentação em colunas). Maiores detalhes serão apresentados na continuidade deste artigo;

6.      Independência de replicação: dados replicados em vários nós da rede, de forma transparente. Assim como nas regras de independência de localização e fragmentação, a independência de replicação é projetada para livrar os usuários de preocupações relacionados com o local onde os dados estão armazenados. No caso da replicação, os usuários e as aplicações não precisam saber que réplicas de dados são mantidas e sincronizadas automaticamente pelo SGBDD;

7.      Processamento de consultas distribuído: o desempenho de uma consulta deve ser independente do local onde a mesma é executada. O SGBDD deve possuir um otimizador que possa selecionar não apenas o melhor caminho para o acesso a um determinado nó da rede, mas também otimizar o desempenho de uma consulta distribuída, levando em conta a localização dos dados, utilização de CPU e I/O e ainda o tráfego da rede;

8.      Gerenciamento de transações distribuídas: Em um sistema distribuído, uma única transação pode envolver a execução de código de vários sites. A transação, nesse caso, consiste em vários agentes. O sistema precisa saber quando dois agentes são partes da mesma transação; esses agentes não devem ter impasses entre eles (deadlock).

9.      Independência de hardware: é uma característica desejável que um SGBDD não dependa de um determinado hardware, nem deve ser limitado a uma determinada plataforma;

10.  Independência de sistema operacional: da mesma forma que o item anterior, é desejável que um SGBDD não dependa de um sistema operacional em especial;

11.  Independência de rede: um SGBDD deve ser projetado para executar independente do protocolo de comunicação e da topologia de rede;

12.  Independência de SGBD: um SGBDD ideal deve possuir capacidades para se comunicar com outros sistemas de banco de dados executando em nós diferentes, ainda que heterogêneos.

 

Vantagens dos Bancos de Dados Distribuídos

Quais motivos levam uma empresa a utilizar um BDD? Para responder essa pergunta, vamos apresentar algumas características que justificam a utilização da distribuição dos dados.

Primeiramente, as empresas são distribuídas geograficamente (matriz, filiais etc). Da mesma forma, um banco de dados pode ser distribuído fisicamente em várias instâncias, onde cada qual armazena os dados que dizem respeito a si. Em nosso caso, cada unidade da FATEC possui candidatos ao vestibular para uma determinada localidade (Indaiatuba, São Paulo, etc.). Sendo assim, é mais sensato armazenar os candidatos no servidor local de cada unidade da FATEC. Dessa forma, o BD passa a refletir a estrutura física da instituição.

Além disso, através do uso de SGBDDs é possível acessar os dados localizados em sites próximos aos usuários e, ao mesmo tempo, compartilhar dados armazenados em outros sites. Em organizações descentralizadas, o gerenciamento dos dados pode ser delegado aos administradores locais, permitindo maior autonomia e responsabilidade.

Considerando-se a replicação de dados, se houver problemas com a perda de dados de uma localidade, é possível recuperar esses dados a partir de outras localidades. Em nosso projeto, não estaremos considerando a utilização da replicação de dados.

Por fim, ao utilizar um SGBDD, os esforços e custos associados ao aumento no número de sites em uma rede podem ser menores quando comparados com os custos associados à expansão de um banco de dados centralizado. Provavelmente, a expansão do banco centralizado necessitaria de atualização do hardware e incrementaria os custos do sistema como um todo. A facilidade de inserção de um novo nó (nova instância) no sistema distribuído aumenta a potencialidade de expansão do sistema. De forma semelhante, em organizações geograficamente distribuídas e muito distantes entre si, a distribuição de dados pode apresentar benefícios, já que manter dados centralizados pode envolver um custo muito alto. Na maioria das vezes, os dados distribuídos podem ser compartilhados por vários locais a um custo bem inferior."

A exibição deste artigo foi interrompida :(
Este post está disponível para assinantes MVP

 
Você precisa estar logado para dar um feedback. Clique aqui para efetuar o login
Receba nossas novidades
Ficou com alguma dúvida?