Universidade Nova de Lisboa Faculdade de Ciências e Tecnologia Departamento de Informática

Transcrição

1 Universidade Nova de Lisboa Faculdade de Ciências e Tecnologia Departamento de Informática Trabalho Prático de Sistemas de Gestão de Base de Dados 1º Semestre, 2011/2012 Armazenamento e Estrutura de Indexação PosteGreSQL e SQL Server 2008 Bruno Santos Nº Márcio Medeiros Nº Renil Lacmane Nº Professor José Júlio Alferes 3 de Dezembro de 2011

2 Índice 1. Introdução Introdução Histórica PostGreSQL SQL Server 9 2. Armazenamento Sistema de Ficheiros PostGreSQL SQL Server Grupos de Ficheiros Buffer Management PostGreSQL VACUUM SQL Server Partições PostGreSQL SQL Server Partição de Índices Partition Aligned Index Views Outras operações sobre partições Execução paralela em partições 26 2

3 Sliding Window Technique Compressão Paginação e Organização de Tuplos PostGreSQL TOAST Clustering SQL Server Extents Gestão de Extents Gestão de Espaço Livre Gestão de Espaço de Objectos Conclusão Indexação Estrutura de Indexação Suportados B-tree PostGreSQL Gist Gin Índices únicos Índices parciais Índices com funções Índices espaciais SQL Server XML Indexes 44 3

4 Estruturas para Indexação e Organização de Ficheiros Índices Múltiplos Tabelas de Hash Suporte para Estruturas Temporalmente Inconsistentes Conclusão Bibliografia 55 4

5 Índice de Figuras Fig. 1 - Logotipo do PostGreSQL 8 Fig. 2 - Logotipo do Microsoft SQL Server 9 Fig. 3 - Sub-conjunto de resultados de uma consulta á tabela pg_class 11 Fig. 4 - Exemplo de ficheiros do SQL Server 13 Fig. 5 - Transição de estados de um buffer 15 Fig. 6 - Clock Replacement Policy 17 Fig. 7 - Query para efeitos de comparação de performance 18 Fig. 8 - Comparação entre Tabelas Particionadas e Não Particionadas 19 Fig. 9 - Comparação de duas queries, com e sem paralelismo 27 Fig Estimativa de compressão de partições 28 Fig Erro devido á violação do tamanho máximo de um tuplo 30 Fig exemplo da criação de um índice GIN 40 Fig índice com uma função 42 Fig Exemplo da criação de um índice clustered 43 Fig B-tree de um índice clustered 44 Fig B-tree de um índice nonclustered 44 Fig Organização de uma tabela em SQL Server 45 Fig Exemplo índices multicoluna 46 Fig bitmap em PostgreSQL 47 5

6 Fig Exemplo Índices Múltiplos 48 Fig Exemplo com índice hash 50 Fig Erro na validação das restrições 52 Fig Restrições de integridade diferidas 52 6

7 1. Introdução Como nota introdutória é importante ter uma noção geral sobre o que é um Sistema de Gestão de Base de Dados (SGBD), que não é nada mais que um conjunto de programas que tem como grande objectivo retirar do utilizador a responsabilidade de gerir o acesso, manipulação e organização dos dados presentes numa base de dados. Assim estes sistemas permitem criar e manipular bases de dados, onde estruturação dos dados é independente dos programas ou aplicações que os manipulam. Um SGBD age como interface entre os programas de aplicação e os ficheiros de dados físicos e separa as visões lógica e de concepção dos dados. Assim sendo, são basicamente três as componentes de um SGBD: Linguagem de definição de dados (especifica conteúdos, estrutura a base de dados e define os elementos de dados); Linguagem de manipulação de dados (para poder alterar os dados na base); Dicionário de dados (guarde definições de elementos de dados e respectivas características descreve os dados, quem os acede, etc. [questões de informação]). Ainda sobre a estrutura de um Sistema de Gestão de Base de Dados é de notar que normalmente seguem uma arquitectura baseada em três níveis principais: 1. Nível Físico: nível que armazena fisicamente os dados pertencentes á base de dados, 2. Nível Lógico: responsável pela organização da informação em tabelas e relações, 3. Nível de Visualização: nível referente á apresentação dos dados ao utilizador através de interfaces gráficas. Neste trabalho será feita uma análise dos Sistemas de Gestão de Base de Dados (SGBD) PostGreSQL e SQL Server, no âmbito de armazenamento e estruturas de indexação e respectiva comparação de ambos com o SGBD Oracle. 7

8 1.1 Introdução Histórica PostGreSQL Originalmente criou-se o sistema Ingres, desenvolvido pelo professor Michael Stonebraker, na Universidade de Berkeley na Califórnia por volta de Na altura Michael Stonebraker tentou comercializar o Ingres, mas voltou para a universidade para resolver problemas com o modelo de base de dados relacional, resultante da incapacidade de compreender tipos. Em 1986 passou a chamar-se Postgres (Post gres), pois era uma evolução do projecto anterior e já compreendia tipos e relações. Em 1994 dois estudantes de Berkeley, Andrew Yu e Jolly Chen, adicionaram um interpretador SQL, e passou a chamar Postgres95, ano em foi divulgado para a net, como software open-source. Em 1997 foi lançado a primeira versão do PostgreSQL, já renomeado para reflectir a nova linguagem de consulta. Desde então é mantido por um grupo de desenvolvedores e voluntários de todo o mundo. Actualmente o PostgreSQL vai na versão lançada a O PostgreSQL sendo um sistema robusto, é usado por grandes e pequenas empresas da actualidade e tem vindo a arrecadar diversos prémios. Fig. 1 - Logotipo do PostGreSQL 8

9 1.1.2 SQL Server A produção do SQL Server começou por ser uma parceria da Microsoft com a companhia Sybase, sendo que a primeira versão do Microsoft SQL Server era idêntica ao sistema Sybase SQL Server 3.0 que era usado em sistemas UNIX e VMS. Esta primeira versão saiu em meados do ano 1989, designando-me SQL Server v1.0. Várias versões seguiram-se, mas foi com o lançamento do Windows NT que a parceria entre Microsoft e Sybase começou a deteriorar até chegar a fim previsível. Assim a Microsoft desenvolveu o primeiro SGBD sem qualquer influência da Sybase, construído a pensar no então novo sistema operativo Windows NT, o SQL Server v6.0. Em 1996 foi lançado o SQL Server v6.5 que continha melhorias e novas funcionalidades em relação ao seu antecessor, sendo que no ano seguinte a Microsoft lançou uma versão Entreprise do mesmo. Passados dois anos do lançamento da versão 6.5 a Microsoft lançou o SQL Server v7.0, que se caracterizou por ser uma rescrita completa de todo o código legacy vindo da antiga parceria com a Sybase. Esta versão iria abrir caminho para o lançamento mais importante para a empresa nesta área denominado SQL Server 2000, a primeira edição com uma variante para a arquitectura computacional IA-64. Seguiram-se o SQL Server 2005 e o SQL Server 2008, ambos com melhorias significativas em relação aos seus antecessores suportando como principais linguagens de queries a TQ-SQL e ANSI SQL. Está ainda programado o lançamento do SQL Server Ao contrário do PostGreSQL, este SGBD não é opensource possuindo uma variedade de edições destinadas a vários tipos de utilizadores / organizações. Fig. 2 - Logotipo do Microsoft SQL Server 9

10 2. Armazenamento Neste capitulo irá ser feito um estudo sobre as abordagens do PostgreSQL e do SQL Server no que toca ao armazenamento de informação. Apresentar-se-á como está organizado o sistema de ficheiros, o funcionamento do buffer management e dos ficheiros criados para o armazenamento de informação das tabelas. Será também mencionado o funcionamento do mecanismo de partições suportado com exemplos práticos. 2.1 Sistema de Ficheiros PostGreSQL O PostgreSQL utiliza o sistema de ficheiros do sistema operativo para guardar os dados. Toda os dados e meta-dados encontram-se localizada numa única directoria designada como PGDATA, sendo que esta informação determina um cluster de base de dados. A organização dos ficheiros baseia-se em sub-directorias, conforme ilustrado na tabela seguinte: Item PG_VERSION base global pg_clog pg_multixact pg_notify Descrição Ficheiro que contem o número da versão do PostgreSQL Sub-directoria que contem as sub-directorias de cada base de dados Sub-directoria que contem tabelas partilhadas por todas as base de dados de um cluster Sub-directoria que contem dados referentes ao estado de cada transacção Sub-directoria que contem dados referentes ao estado de multi-transacções Sub-directoria que contem dados referentes ao sistema de notificação (LISTEN / NOTIFY) 10

11 Item pg_stat_tmp pg_subtrans pg_tblspc pg_twophase pg_xlog postmaster.opts Descrição Sub-directoria que contem dados temporários usados no sub-sistema de estatísticas. Sub-directoria que contem dados referentes ao estado de sub-transacções Sub-directoria que contem symbolic links para tablespaces (localização do armazenamento da base de dados) Sub-directoria que contem ficheiros referentes ao estado das transacções que foram afectadas com o comando Prepare Transaction Sub-directoria que contem ficheiros WAL (Write Ahead Log) Ficheiro que regista as opções com que o servidor iniciou pela última vez. Todas as bases de dados criadas encontram-se localizadas na directoria./data/base, contidas numa pasta própria cujo nome representa um identificador único associado a cada uma delas. É possível consultar a lista de identificadores (base de dados) no ficheiro pg_database. Por seu lado todas as tabelas e índices estão guardados num ficheiro com o nome do seu identificador único, podendo ser consultados através da tabela pg_class. Fig. 3 - Sub-conjunto de resultados de uma consulta á tabela pg_class 11

12 Cada tabela e índice está guardada num ficheiro distinto em disco. A estes está ainda associado um free space map e um visibility map. É no free space map que são guardadas as informações sobre o espaço livre. Já no visibility map é mantida informação sobre as páginas que contêm tuplos visíveis a todas transacções activas. Tanto as tabelas como os índices estão limitados a um tamanho máximo de 1GB (valor por defeito, podendo ser alterado através da opção de configuração --with-segsize). Assim quando este valor é ultrapassado o ficheiro é guardado em disco em segmentos de 1GB, nomeados como filename.1, filename.2,..., filename.n evitando assim problemas em plataformas com restrições de tamanho. Na representação de tabelas, o PostgreSQL utiliza páginas de tamanho fixo de 8KB e não permite que um tuplo se encontre dividido por mais do que uma página, impedindo assim guardar directamente campos de grandes dimensões. Para contornar este problema o PostgreSQL recorre a uma técnica denominada TOAST (The Oversized-Attribute Storage Technique), que ocorre de forma transparente ao utilizador e que será explicada com detalhe na secção correspondente. Ainda é interessante ter conhecimento que os ficheiros temporários são armazenados numa directoria distinta./data/base/pgsql_tmp SQL Server O SQL Server mapeia as base de dados com base no sistema de ficheiros do sistema operativo. Estes ficheiros englobam-se em três tipos distintos: a) Ficheiros de dados primários (.mdf): ficheiros principais de uma base de dados, contendo apontadores para outros ficheiros da mesma. Todas as base de dados possuem um ficheiro de dados primário. b) Ficheiros de dados secundários (.ndf): conjunto de todos os outros ficheiros de dados numa base de dados á excepção dos ficheiros de dados primários, ou seja, são os 12

13 ficheiros que contém os meta-dados de uma base de dados. Uma base de dados pode conter zero ou mais ficheiros deste tipo. c) Ficheiros de Log (.ldf): os ficheiros de log contém toda a informação necessária para recuperar uma base de dados, tendo de existir pelo menos um em cada uma. Fig. 4 - Exemplo de ficheiros do SQL Server É pertinente ter em atenção que as extensões colocadas na descrição dos tipos de ficheiros não têm um formato obrigatório, sendo apenas recomendado o uso com o formato apresentado anteriormente. Embora as localizações de todos os ficheiros estejam armazenadas nos ficheiros de dados primários estas também são guardados na master database (base de dados que guarda toda a informação do SQL Server), sendo esta última o ponto de acesso preferencial do SQL Server salvo algumas excepções onde são acedidos os ficheiros primários: Restauro da master database, Actualização da versão SQL Server 2000 ou 7.0, Criação de uma base de dados com o recurso ás cláusulas FOR ATTACH ou FOR ATTACH_REBUILD_LOG. Em SQL Server os ficheiros possuem dois tipos de nomes: logical_file_name e os_file_name. Os nomes lógicos são usados para fazer referência aos ficheiros físicos presentes em todas as expressões Transact-SQL, por sua vez os nomes de sistema operativo não são mais que o nome do ficheiro físico incluindo a sua directoria. 13

14 Grupos de Ficheiros No SQL Server os ficheiros e objectos podem ser colocados em grupos tendo em vista objectivos administrativos e de alojamento, existindo dois tipos de grupos: - Primários: estes grupos contém o ficheiro de dados primários e os ficheiros que não pertencem especificamente a nenhum grupo. É importante também referir que todas as páginas referentes ás tabelas de sistema estão alocadas neste grupo. - Definidos pelo Utilizador: grupos definidos pelo utilizador, ou que foram especificados usando a cláusula FILEGROUP no momento de criação ou alteração de uma base de dados. De notar ainda que os ficheiros de Log não pertencem a nenhum grupo de ficheiros, visto que, estes são geridos separadamente do espaço da base de dados. Por fim é importante referir que os ficheiros de dados e de log podem ser guardados tanto num sistema de dados NTFS como em FAT, embora seja recomendado o primeiro por motivos de segurança. 2.2 Buffer Management PostGreSQL Uma vez que os acessos ao disco rígido acarretam custo elevados, é necessário utilizar um mecanismo que permita armazenar temporariamente dados na memória do computador. Neste âmbito o PostgreSQL implementa um sistema de buffer management, usando buffers apenas com o intuito de criar um sistema de cache, ou seja, são usados para gerir a transição de dados entre o disco rígido e o backend do Sistema de Gestão de Base de Dados. O sistema de cache não é mais que uma lista circular de shared buffers, onde a maior parte das operações navega escolhendo um ponto de partida e incrementando-o, sendo que se 14

15 chegar ao final da lista o valor a incrementar passa a zero. Este processo tem o nome de clock-sweep. Assim quando uma operação necessitar de um bloco de dados, este será guardado num buffer e o número de clientes a aceder a esse buffer é incrementado. Sempre que informação é escrita para um buffer este é marcado como dirty, se um buffer está referenciado por pelo menos um cliente este é marcado como pinned, sendo que não poderá ser usado por outro processo tendo este de encontrar outro buffer disponível. De seguida é apresentado um exemplo de uma possível transição de estados de um buffer: Fig. 5 - Transição de estados de um buffer Por norma todos os buffers cache são rapidamente ocupados após o arranque do sistema, sendo necessário que exista uma maneira de descartar a informação menos necessária para dar lugar a novos blocos de dados. O PostgreSQL usa uma política de Least Recently Used (LRU) para saber que blocos de informação descartar, assim quando é requisitado o armazenamento de um novo conjunto de blocos de dados o buffer management, estes irão substituir aqueles que tiverem o menor número de acessos. De notar que antes de descartar blocos de dados, o sistema verifica se foram feitas modificações nos mesmos e caso tal aconteça são efectuadas nos blocos correspondentes no disco rígido. Apesar de seguir uma política LRU, a verdade é que não existe uma implementação de um mecanismo próprio para tal efeito. O que acontece é que o sistema de clock-sweep em conjunto com os mecanismos de bloqueio de acessos (pinned / unpinned), originam uma estrutura semelhante a um mecanismo LRU. 15

16 De notar ainda que por defeito o PostgreSQL aloca 1000 shared buffers, tendo cada um deles 8KB, podendo este valor ser configurado pelo utilizador através do comando: shared_buffers(integer); VACUUM Normalmente no PostgreSQL os tuplos que foram removidos ou que se tornaram obsoletos, não são removidos das tabelas correspondentes. Para tal acontecer é necessário executar a rotina VACUUM, que actua como um garbage collector. VACUUM uscensus; Quando executado desta maneira o processo apenas reclama o espaço dos tuplos obsoletos, ou removidos, e torna-o reutilizável. VACUUM FULL uscensus; Quando executado com a opção Full, a tabela em questão será rescrita sem o espaço extra que estava destinado aos tuplos obsoletos, ou removidos. Esta opção embora retorne memória ao Sistema Operativo, é muito mais lenta que a anterior e requer que sejam efectuados bloqueios exclusivos em cada tabela enquanto é processado. VACUUM FULL ANALYZE uscensus; A rotina VACUUM pode ainda ser utilizada para actualizar estatísticas e consequentemente optimizar a melhor maneira de efectuar uma determinado query. 16

17 2.2.2 SQL Server O SQL Server usa um sistema de gestão de buffer constituído por dois mecanismos: Gestor de buffer, utilizado para os acessos e actualizações das páginas da base de dados; Buffer Cache, utilizado para reduzir as operações de I/O na base de dados. Este sistema tem um comportamento parecido com o gestor de Buffer do PostgreSQL, discutido anteriormente. O buffer cache também é constituído por páginas de 8KB, que são usadas para carregar dados fazendo com que não seja necessário efectuar acessos ao disco para manipular os mesmos. Quando a informação presente nas páginas do buffer sofre alterações, e é removida do mesmo, é escrita para disco. Quando o espaço em buffer se esgota, a substituição das páginas é feita com base numa política de clock replacement, que é uma aproximação da política LRU, usada pelo PostgreSQL. D(1) B(0) Fig. 6 - Clock Replacement Policy Esta política caracteriza-se por: Páginas organizadas em forma de ciclo (lista circular), armazenado um bit de referência por página, Quando o contador chega a zero o bit de referência é ligado (dirty), Quando é necessário fazer uma substituição: - Se o contador for zero e o bit de referência ligado, desliga-se o bit. - Se o contador for zero e o bit de referência estiver desligado, a página em causa é escolhida para ser substituída no buffer. 17

18 O espaço reservado ao buffer é determinado tendo em conta a capacidade do sistema onde está inserido o SQL Server, embora não o use na sua totalidade. Este SGBD permite ainda que se adicione memória física ao sistema sem reiniciar o servidor (Hot Add Memory). De notar ainda que as operações de escrita e leitura são feitos de forma assíncrona, este comportamento permite que o processamento de uma query não tenha de ser interrompido. 2.3 Partições O particionamento refere-se à capacidade de dividir uma tabela de grandes dimensões em outras de menor dimensão. A utilização desta técnica apresenta várias vantagens, nomeadamente em termos de performance, gestão e escalabilidade. À medida que as tabelas crescem as queries efectuadas sobre estas acabam por ser afectadas, mesmo utilizando índices. É possível melhorar a eficiência destas queries se os tuplos mais acedidos se encontrarem numa única partição ou num pequeno número de partições. Isto possibilita uma pesquisa sequencial nessa partição, em contraste com leituras aleatórias espalhadas por toda a tabela. A utilização de partições facilita as operações de adição e remoção de dados, uma vez que as operações de manutenção tais como vacuum, reindex ou cluster podem se focar em dados activos. Por fim o particionamento de tabelas permite um grande escalabilidade, mantendo um nível de performance aceitável e uma maior facilidade em gerir uma grande quantidade de dados. Em particular atinge-se maiores benefícios quando a dimensão da tabela excede o total de memória física da maquina onde a base de dados se encontra alojada. Em forma de exemplo, efectuando a seguinte query: Fig. 7 - Query para efeitos de comparação de performance 18

19 e para diferentes volumes de dados, verifica-se uma grande variação de performance á medida que a quantidade de tuplos aumenta. Fig. 8 - Comparação entre Tabelas Particionadas e Não Particionadas Demonstra-se assim que o correcto particionamento de uma tabela poderá ter uma grande incremento na performance para grandes quantidades de dados. No entanto deve se ter em conta que o particionamento de tabelas incrementa complexidade e custos de administração, pelo que a decisão deverá ser correctamente equacionada PostGreSQL No PostgreSQL o particionamento de tabelas é suportado através do mecanismo de herança. Durante a criação de uma partição esta será catalogada como filha de outra. Geralmente a partição pai encontra-se vazia, existindo apenas para representar a estrutura completa de dados. O particionamento de tabelas poderá ser efectuado de duas formas: Range Partitioning: A tabela é particionada numa gama de valores definida por uma coluna chave ou num conjunto de colunas. Por exemplo é possível particionar com base num intervalo de datas ( ). 19

20 List Partitioning: A tabela é particionada indicando explicitamente que valores entram em cada partição. Por exemplo uma lista de cidades (Lisboa, Porto, Coimbra). É importante garantir que não existe sobreposição de chaves em diferentes partições. A criação de uma partição implica as seguintes operações: 1. Criar a tabela pai por qual todos os filhos vão herdar: CREATE TABLE shipment ( id SERIAL PRIMARY KEY, address TEXT NOT NULL, shipping_date TIMESTAMP NOT NULL); 2. Criar as tabelas filhos definindo o conjunto de chaves permitidas para cada partição: CREATE TABLE shipment_part_2008 ( CHECK (shipping_date >= DATE ' ' AND shipping_date < DATE ' ') ) INHERITS (shipment); CREATE TABLE shipment_part_pre2008 ( CHECK (shipping_date < DATE ' ') ) INHERITS (shipment); 3. Criar os índices nas colunas chave de cada partição: CREATE INDEX shipping_date_2008 ON shipment_part_2008 (shipping_date); CREATE INDEX shipping_date_pre2008 ON shipment_part_pre2008 (shipping_date); 4. Garantir que a opção constraint exclusion se encontra activa. Se estiver desactivada cada query irá analisar por todas as tabelas filho. SET constraint_exclusion = ON; 20

21 5. Opcionalmente pode-se definir triggers para redirecionar os dados inseridos na tabela pai, para a correcta tabela filho. CREATE OR REPLACE FUNCTION shipment_insert() RETURNS TRIGGER AS $$ BEGIN IF (NEW.shipping_date >= DATE ' ' AND NEW.shipping_date < DATE ' ') THEN INSERT INTO shipment_part_2008 VALUES (NEW.*); ELSIF (NEW.shipping_date < DATE ' ') THEN INSERT INTO shipment_part_pre2008 VALUES (NEW.*); ELSE RAISE EXCEPTION 'Date out of range. Fix the shipment_insert() function!'; END IF; RETURN NULL; END; $$ LANGUAGE plpgsql; CREATE TRIGGER shipment_insert_trigger BEFORE INSERT ON shipment FOR EACH ROW EXECUTE PROCEDURE shipment_insert(); SQL Server Desde a versão 2005 que o SQL Server suporta partitionamento de tabelas e índices. No entanto apenas suporta um tipo de particionamento, range particioning. Apesar disso é possível simular uma list particioning especificando os valores pretendidos com a clausula LEFT. Posteriormente adiciona-se uma restrição com o comando CHECK de modo a que não seja possível adicionar valores que não pertençam à lista definida. De forma a criar uma partição é necessário seguir os seguintes passos: 1. Criar função de partição. 2. Criar esquema da partição. 3. Criar tabela particionada. No primeiro ponto (função de partição) é definido como serão particionados os dados. Nesta fase não é especificado que tabela será particionada, sendo apenas indicado a técnica usada para dividir os dados. Segue-se um exemplo de uma função de partição: 21

22 CREATE PARTITION FUNCTION salesyearpartitions (datetime) AS RANGE RIGHT FOR VALUES ( ' ', ' ') Neste exemplo serão definidos conjuntos para as 3 partições. Na primeiro estarão todas as datas menores que Na segundo as datas compreendidos entre (inclusive) e e por fim na terceira todas as datas maiores ou iguais que No anterior exemplo utilizou-se um range right, mas também poderia ter sido utilizado um range left. A diferença estaria na restrição dos conjuntos para as 3 partições. Na primeira seriam todas as menores ou iguais a na segunda as datas maiores que e menores ou iguais a e por fim na terceira todas as datas maiores que O SQL Server possui alguns comandos que permitem listar todas as funções de partição, SELECT * FROM sys.partition_functions testar as restrições de particionamento, nomeadamente verificar a que partição pertence um dado valor, SELECT $PARTITION. salesyearpartitions(' ') ou listar os intervalos definidos nas funções de partição SELECT * FROM SYS.PARTITION_RANGE_VALUES Uma vez definido como se quer particionar é necessário criar um esquema para onde se quer criar as partições. Este é um simples processo que liga as partições a filegroups. CREATE PARTITION SCHEME Test_PartitionScheme AS PARTITION salesyearpartitions TO (FG1, FG2, FG3 ) 22

23 Neste exemplo a cada partição está ligada um filegroup. Este esquema permite benefícios em operações de load e delete. De forma a melhor ainda mais a performance seria benéfico que os filegroup s estivessem localizados em diferentes discos numa máquina multi-core. No entanto é possível ligar várias partições a um filegroup. Para listar todos os esquemas de partição pode se utilizar o seguinte comando: SELECT * FROM SYS.PARTITION_SCHEMES Finalmente é possível criar a tabela particionada. Esta é a etapa mais simples do processo. CREATE TABLE SalesArchival (SaleTime datetime PRIMARY KEY, ItemName varchar(50)) ON Test_PartitionScheme (SaleTime) Para criar a partição é apenas necessário adicionar a clausula ON na criação da tabela especificando o esquema de partição (Test_PartitionScheme) e a coluna da tabela a qual a partição se aplica (SaleTime). De raiz o SQL Server não permite particionamento usando múltiplas colunas. Porem existem mecanismo que permitem simular esta situação. De notar que não é necessário referir a função de partição uma vez que o esquema de partição já a identifica Partição de Índices Um possível incremento de performance pode ser atingido através do particionamento de índices. De realçar que os índices podem ser particionados usando uma diferente chave da usada na tabela. O índice pode também ter um diferente número de partições do que a tabela. No entanto não é possível particionar um índice clustered de forma diferente da tabela. Para particionar um índice é necessário especificar o esquema de partição assim como a coluna do índice: 23

24 CREATE NONCLUSTERED INDEX MyNonClusteredIndex ON dbo.salesarchival(saletime) ON MyPartitionScheme(ItemName) Neste exemplo a tabela SalesArchival é indexada na coluna SaleTime, no entanto o índice é particionado pela coluna ItemName. A uma tabela e um índice que utilizam a mesma função de particionamento da-se o nome de aligned. Por sua vez se também utilizarem o mesmo esquema de partição são conhecidos por storage aligned. Geralmente consegue-se uma melhor performance utilizando a mesma função de partição para a tabela e para o índice Partition Aligned Index Views Definir aligned index views em dados particionados pode aumentar a performance e eficiência de queries. Os resultados destas queries são imediatamente materializadas em disco na base de dados. As aligned index views são uma extensão das indexed views existentes no SQL Server 2005, que apresentavam um elevado grau de dificuldade em gerir os mesmo em tabelas particionadas. O problema residia no facto de não ser possível navegar entre partições, uma vez que os dados não eram distribuídos de forma particionada na indexed view. A partir da versão 2008 este problema ficou resolvido com a introdução das partições aligned index views. De forma a garantir o correcto funcionamento algumas condições têm que ser respeitadas: As funções de partição dos índices, dos indexed views e da tabela devem definir o mesmo número de partições e as suas condições de particionamento devem ser baseadas na mesma coluna. A lista de projecção definida na view deverá incluir a coluna de particionamento da tabela. A coluna de particionamento deverá ser uma das colunas incluídas no agrupamento (group by) definida na view. 24

25 Outras operações sobre partições O SQL Server suporta algumas operações uteis para a gestão de dados particionados, tais como split, merge e switch. Se uma dada partição atingir um tamanho considerável é possível dividir a mesma com o seguinte comando: ALTER PARTITION FUNCTION MyPartitionFunction() SPLIT RANGE (boundary_value) Tendo em conta o boundary_value o SQL Server irá dividir uma das condições (range) existentes em duas. Deverá se ter o cuidado de previamente criar um novo filegroup e adiciona-lo ao esquema de partição, caso contrário este comando lançará um erro de execução. Do mesmo modo é também possível remover uma partição. ALTER PARTITION FUNCTION MyPartitionFunction() MERGE RANGE (boundary_value) Neste caso a partição é eliminada e os dados nela contida são copiadas para uma das partições existentes. De notar que o filegroup ao qual estava ligado o boundary_value é removido do esquema de partição a não ser que esteja a ser usado por outra partição. Por vezes é necessário redefinir as partições para acomodar novos dados, mover dados correntes ou mesmo elimina-los. Para tal existe o comando switch que permite mover partições entre tabelas particionadas. ALTER TABLE MyNewPartTable switch TO MyPartitionedTable PARTITION 4 Neste exemplo está-se a mover a MyNewPartTable como a quarta partição da MyPartitionedTable. A introdução de vários índices permite melhorar a performance, no entanto adiciona custos (tempo) na adição de dados em tabelas de grande dimensão. Uma 25

26 melhor solução passaria por adicionar os dados numa tabela vazia (igual à particionada) movendo mais tarde esta partição para a tabela particionada. A mudança de uma tabela para um partição implica que ambas possuam as mesma restrições e os mesmo índices (clustered e non-clustered) Execução paralela em partições Existindo um servidor com multi-core é possível optimizar os planos de execução de tabelas particionadas. No SQL Server 2005 era criado no máximo um thread por cada partição. Se o número de processadores for maior que o número de partições então existiria um desperdício de recursos. Na versão de 2008 esta restrição foi retirada, significando que todos os processadores podem ser utilizados para satisfazer a query. Na prática existirão várias threads a trabalhar em diferentes partições da tabela, garantindo que cada partição é processada por uma única thread. É possivel controlar o plano de paralelismo das queries utilizando o comando MAXDOP - Maximum Degree of Parallelism. Este comando especifica o número máximo de processadores que podem ser utilizados na execução de uma query. SELECT * FROM MyPartitionedTable ORDER BY OrderDate DESC Neste exemplo é explicitamente definido o uso máximo de 4 processadores. É possível remover o paralelismo declarando MAXDOP 1. 26

27 Fig. 9 - Comparação de duas queries, com e sem paralelismo Analisando o anterior exemplo verifica-se um menor custo de execução quando se utiliza paralelismo. No entanto isto não é regra geral, podendo se obter melhores custos não utilizando paralelismo, pelo que se deverá utilizar este comando com cuidado Sliding Window Technique Uma possível limitação do SQL Server prende-se com o número máximo de partições (1000 na versão 2005). Para contornar esta limitação é utilizada a sliding window technique. Segundo esta técnica uma tabela tem um número especificado de partições. Sempre que é adicionada uma nova partição, a mais antiga é movida da tabela e arquivada. Este processo pode ocorrer indefinidamente e não deverá acarretar grandes custos uma vez que é uma operação sobre metadata. 27

28 Compressão O SQL Server suporta a compressão de partições, inclusive é possível definir diferentes níveis de compressão para diferentes partições. Possui igualmente um procedimento bastante util, que produz informação sobre os benefícios de comprimir uma partição - sp_estimate_data_compression_savings, EXEC sp_estimate_data_compression_savings 'Schema', 'Partition', NULL, NULL, 'ROW' ; onde o primeiro argumento representa o esquema, o segundo o nome, o terceiro índice, o quarto o id da partição e por fim o último o tipo de compressão. Fig Estimativa de compressão de partições É possível verificar que nem sempre é benéfico comprimir uma partição. Por fim resta referir que existem dois tipos de compressão: Row Compression: Esta compressão tem em conta o tipo de dados definidos por coluna. Por exemplo definindo uma coluna do tipo char(100), mas se só utilizar tuplos de 20 caracteres, consegue-se ganhos de 80%. Page Compression: Esta compressão é uma superset (superconjunto) da row compression e tem em conta os dados redundantes de uma ou mais linhas de uma dada página. NOTA: O particionamento de tabelas apenas se encontra disponível na versão Enterprise. 28

29 2.4 Paginação e Organização de Tuplos PostGreSQL As páginas são estruturas utilizadas para armazenar tabelas e índices. Os ficheiros que armazenam estes dados são vistos como vectores de páginas, tipicamente com tamanho de 8KB (valor que pode ser alterado). Estas páginas adoptam uma estrutura do tipo slotted-page. Isto permite reorganizar os registos armazenados na pagina de forma simples e apresenta uma eficiência equivalente a um acesso directo aos registos. Uma vez que as paginas das tabelas são logicamente equivalentes, uma determinada linha (row) pode ser armazenada em qualquer página. Já para os índices, a primeira página é tipicamente reservada para armazenar informação de controlo e as restantes poderão ser de diferentes tipos. Segue uma tabela ilustrando a disposição de uma página: Item PageHeaderData ItemIdData Free Space Items Special Space Descrição Contém informação geral sobre a página, incluindo apontadores para espaço livre. 20 bytes Vector de pares (offset, tamanho) que aponta para os tuplos. 4 bytes por tuplo Espaço disponível. Apontadores para novos tuplos são alocados no principio, enquanto novos tuplos são colocados no fim Onde se encontram os tuplos Espaço contendo informação de acesso aos índices. Vazio no caso de tabelas comuns. 29

30 Em relação aos item identifiers (ItemIdData), estes contêm um byte-offset para o inicio do item e o seu tamanho. Novos item identifiers podem ser acrescentados no espaço disponível, e é possível determinar o número de item identifiers existentes através do atributo pd_lower presente no pageheaderdata. Por fim os tuplos (Items) são armazenados em sentido contrário ao espaço disponível, ou seja, começam a ser organizado do fim ( special space ) para o principio. A estrutura usada para organizar os tuplos é HeapTupleHeaderData TOAST O PostgreSQL não permitem que os registos ocupem múltiplas páginas, ou seja, no máximo um registo ocupa uma página. Esta limitação impossibilita o armazenamento de atributos de grande dimensão. Para contornar este problema é utilizada uma ferramenta - The Oversized Attribute Storage Technique (TOAST) - que resolve o problema comprimindo e decompondo os valores de campos potencialmente maiores que uma página em tabelas TOAST, cuja a gestão é realizada de forma transparente. É possível consultar as tabelas criadas para este efeito com o comando: SELECT relname, reltoastrelid, relpages FROM pg_class; No entanto esta técnica não resolver todos os problemas, uma vez que o tamanho máximo para os tuplos encontra-se fixado em 1GB: CREATE TABLE oversize(bigchar varchar( )); Fig Erro devido á violação do tamanho máximo de um tuplo 30

31 O PostgreSQL permite quatro opções para armazenar entradas TOAST, as quais podem ser alteradas pelo comando: ALTER TABLE tabela SET STORAGE tipo onde tipo pode ser uma das seguintes: PLAIN: previne a compressão e decomposição de entradas. É a única opção para tipos de dados que não necessitam de TOAST. EXTENDED: permite a compressão e decomposição de entradas. É a estratégia por omissão dos tipos de dados compatíveis com TOAST. EXTERNAL: permite a decomposição de entradas mas não a compressão. Esta estratégia optimiza a manipulação de dados com custo na utilização de mais espaço em disco MAIN: permite a compressão e apenas em ultimo recurso a decomposição de entradas Clustering Clustering em base de dados não é mais que o agrupamento de dados em espaços contínuos dos componentes de armazenamento, isto é, conjuntos de dados bastante requisitados serão guardados em disco na mesma região, possibilitando um acesso mais rápido aos mesmos. Uma operação de clustering consiste assim em reordenar uma tabela com base num índice. O conceito de clustering é suportado pelo PostgreSQL através do comando CLUSTER. Para executar este comando é necessário especificar a tabela alvo, assim como o respectivo índice. De notar que o índice a utilizar na operação de clustering terá que ter sido previamente definido na tabela. CLUSTER uscensus USING age; Esta operação não é recursiva, ou seja, depois de uma tabela ter sido ordenada, se existir alguma actualização na tabela, esta não será reordenada. Para tal terá que ser efectuada uma 31

32 nova instrução CLUSTER para a reordenar. Depois de uma tabela ter sido clustered, o utilizador poderá efectuar nova operação sem se referenciar ao índice a utilizar, referindo-se apenas á tabela, que esta será reordenada segundo o índice previamente definido. CLUSTER uscensus; É também possível ao utilizador utilizar o comando CLUSTER sem qualquer parâmetro, o que levará a que todas as tabelas que tenham sido anteriormente clustered, sejam novamente reordenadas. CLUSTER Nota: No decurso da nosso trabalho não encontra-mos qualquer referência ao PostgreSQL suportar multitable clustering SQL Server Ao contrário do PostgreSQL, o SQL Server não disponibiliza nenhuma opção para alterar o tamanho de uma página, pelo que se está limitado ao valor por defeito - 8KB. A cada página é atribuído um identificador (começando no 0) e é possível determinar o identificador da última página através do tamanho da base de dados. Cada página tem um cabeçalho de 96 bytes e contem informações de sistema, tais como o número da página, o tipo, a quantidade de espaço livre e o ID da unidade de afectação do objecto que possui a página. Os dados encontram-se imediatamente a seguir e no final da página existe uma tabela de deslocamento de cada linha em ordem inversa, onde cada entrada corresponde à distância em bytes do inicio da página. A nível de organização de páginas, o SQL Server suporta dois modos: 32

33 HEAP: As páginas não estão organizadas. Os dados são inseridos em qualquer espaço livre sem qualquer tipo de ordenação. Este é o modo utilizado por defeito. Clustered index: As páginas são ligadas através de uma lista duplamente ligada, usando um índice como chave. O índice é guardado numa árvore B+ ordenada Outros tipos de organização, tais como multi-table clustering ou hash, não são suportados pelo SQL Server Extents Em termos de espaço, as paginas são geridas com medida em extents que consiste em 8 paginas, pelo que cada extent terá 64KB. O SQL Server implementa duas classes de extents: Uniform: Dedicados a um único objecto. Tipicamente o SQL Server disponibiliza vários uniform extents para cada tabela. Mixed: Usado em pequenas tabelas. Devido ao seu pequeno tamanho um extent é partilhado por várias tabelas. Inicialmente na criação de uma nova tabela o SQL Server atribui á página a classe de mixed extent. Mas assim que a tabela tenha dados capaz de preencher uma extent, é lhe atribuído uma uniform extent. O processo é semelhante para os índices. Quando é criado um indice numa tabela que preencha pelo menos 8 páginas, o SQL Server irá atribuir um uniform extent para guardar os dados dos índices Gestão de Extents A gestão das extensões é feita através de dois tipos de mapas: Global Allocation Map (GAM): É utilizado para verificar se uma uniform extent está livre ou não. Utiliza um bit para cada extensão indicando se está livre ( 1 ) ou se está afectada ( 0 ). Cada página GAM cobre extensões (~ 4GB). 33

34 Shared Global Allocation Map (SGAM): Indica se uma extensão é do tipo mixed ou não. Um bit a 1 indica que se trata de uma mixed extent e que tem uma ou mais páginas livres. Se o bit estiver a 0 significa que não se trata de uma mixed extent, ou sendo deste tipo tem todas as suas páginas preenchidas. Extent GAM SGAM mixed extent totalmente preenchida mixed extent com pelo menos uma página livre Não está a ser usada (livre) 1 0 Inválido Gestão de Espaço Livre O SQL Server implementa um mecanismo para a gestão do espaço livre disponível numa página - Page Free Space. Quando uma página é preenchida por registros é possível que esta não fique totalmente ocupada, pelo que o PFS regista o estado afectado em cada página, assim como o espaço livre. Este processo é inicializado após a organização das páginas em extents. As páginas PFS são organizados em intervalos ( 8088 páginas), usando para tal uma estrutura do tipo byte-map, correspondendo 1 byte para cada página do intervalo. Os bits de cada byte são organizados da seguinte forma: bits 0-2: Quantidade de espaço disponível na pagina vazia % de ocupação % a 80% de ocupação % a 95% de ocupação 34

35 100-96% a 100% de ocupação bit 3 : Existe algum registro fantasma na página? bit 4: A página é do tipo IAM? bit 5: A página é do tipo mixed extent? bit 6: A página encontrasse alocada? Este mecanismo apenas é implementado para páginas contendo dados do tipo LOB e páginas organizadas em heap. Isto deve-se ao facto de neste tipo de páginas os dados são inseridos de forma não organizada em qualquer espaço vazia. Não é utilizado em índices uma vez que os dados já são inseridos de forma ordenada. É possível analisar o conteudo das páginas FPS executando o seguinte comando: dbcc page ( {'dbname' dbid}, filenum, pagenum [, printopt={ } ]) O filenum e o pagenum são calculados com base no ID da página. Por exemplo se o ID fosse 1:123, então o filenum seria 1 e o pagenum seria Gestão de Espaço de Objectos Um conjunto de páginas usadas para guardar dados de tabelas ou indices numa única partição são mapeados usando uma allocation unit. Estas poderão ser de um dos seguintes tipos: In-row data: Para a maior parte dos tipos de dados. Large object (LOB) data: Para os tipos de dados de grande dimensão, tais como TEXT, NTEXT, IMAGE, VARCHAR(MAX), XML, etc. Row-overflow data: Para os dados (tamanho variável) cujo o tamanho excede o tamanho máximo de uma linha (8KB). Quando isto acontece os dados são movidos ficando um apontador na allocation unit in_row data de 24 bytes. Posteriormente se estes dados diminuírem de tamanho serão deslocados para a página original. A gestão dum conjunto de extents é realizada através de uma pagina Index Allocation Map (IAM). Estas páginas guardam informação sobre os extents usados por tabelas 35

36 organizadas em heap ou por índices na mesma allocation unit. As páginas IAM são representadas em bitmap, onde a cada bit corresponde uma extent. Por exemplo quando se efectua uma operação de inserção num determinada tabela, o SQL Server verifica as extents que foram atribuídas á mesma. Posto isto, o SGBD vai aceder ás páginas PFS para verificar se a informação poderá ser inserida na página alocada anteriormente. Por fim são usadas as páginas IAM para determinar que extents estão alocados para uma determinada partição (allocation unit), se não houver suficiente para guardar a nova informação o SQL Server aloca um novo extent. 2.5 Conclusão Neste capítulo podemos verificar que o PostGreSQL e o SQL Server são semelhantes em bastante aspectos, variando mais na implementação do que no resultado final. Quando comparados com o Sistema de base de dados Oracle as diferenças são mais vincadas. Na temático de Sistema de Ficheiros o Oracle é o único com um sistema próprio (OCFS), ao contrário do PostGreSQL e do SQL Server que baseiam no do Sistema Operativo. Em relação ao buffer management são todos algo semelhantes, apesar do Oracle ter um sistema mais sofisticado. É ainda possível verificar que o SGBD Oracle disponibiliza um maior leque de opções ao nível do particionamento de tabelas. É igualmente rico nas configurações disponíveis para a organização de tuplos, sendo o único SGBD a permitir multitable clustering. De seguida é representado em tabela um resumo da comparação entre os três SGBDs no âmbito de Armazenamento. 36

37 PostgreSQL SQL Server Oracle Sistema de Ficheiros Usa o do Sistema Operativo Usa o do Sistema Operativo Não depende do Sistema Operatico, tem um próprio - OCFS Buffer Management Próprio, política LRU Próprio, política clock replacement Próprio, mas mais sofisticado que os restantes Particionamento Range Partition Sim Sim Sim List Partition Sim Não Sim Hash Partition Não Não Sim Interval Partition Não Não Sim Reference Partition Não Não Sim System Partition Não Não Sim Composite Partition Não Não Sim Split partition Sim Sim Sim Merge Partition Sim Sim Sim Switch Partition Não Sim Sim Row Compression Não Sim Sim Page Compression Não Sim Sim Tuplos e Paginação Páginas de tamanho fixo Não Sim Não Organização de tuplos Heap Heap, clustered index Heap, sequencial, hashing Registos de tamanho variável Sim Sim Sim Multi-table clustering Não Não Sim 37

38 3. Indexação Indexação serve o propósito de permitir o sistema de gestão encontrar e fornecer dados mais rapidamente, no entanto esta técnica introduz overhead (armazenamento em excesso) ao sistema, e deve ser usado com cuidado. Estrutura da criação de um índice em PostgreSQL: CREATE [ UNIQUE ] INDEX [ CONCURRENTLY ] [ name ] ON table [ USING method ] ( { column ( expression ) } [ COLLATE collation ] [ opclass ] [ ASC DESC ] [ NULLS { [ WITH ( storage_parameter = value [,... ] ) ] [ TABLESPACE tablespace ] [ WHERE predicate ] Estrutura da criação de um índice em SQLServer: CREATE [ UNIQUE ] [ CLUSTERED NONCLUSTERED ] INDEX index_name ON <object> ( column [ ASC DESC ] [,...n ] ) [ INCLUDE ( column_name [,...n ] ) ] [ WHERE <filter_predicate> ] [ WITH ( <relational_index_option> [,...n ] ) ] [ ON { partition_scheme_name ( column_name ) filegroup_name default }] [ FILESTREAM_ON { filestream_filegroup_name partition_scheme_name "NULL" } ] 38

39 3.1 Estrutura de Indexação Suportados Nos sistemas estudados notou-se que estes diferem nos tipos ou métodos de índices implementados. Apesar disso este índice é comum aos sistemas: B-tree B-tree são estruturas de dados que mantém dados ordenados e permitem p e s q u i s a s, inserções e remoções, entre outros, em tempo logarítmico. Estas são optimizadas leitura e escrita de grandes blocos de data. Suportam igualdade e pesquisa em intervalos de dados que podem ser ordenados. Para o planeador será considerado o índice B-tree, quando uma coluna indexada está envolvida numa comparação usando um destes operadores: <, <=, =, >=, >. Por omissão o comando CREATE INDEX, nos 3 SGBD s, PostgreSQL, SQLServer e Oracle, cria índices B-tree, que são adequados ás situações mais comuns PostGreSQL Gist Em PostgreSQL índices GiST (Generalized Search Tree ) não são um tipo único de índices, mas sim uma infrastructura onde muitas estratégias de indexação podem ser implementadas. Os operadores em que o GiST pode ser usado, são: <<, &<, &>, >>, <<, &<, &>, <@, ~=, &&. No entanto o seu uso varia consoante a estratégia adoptada. O GiST pode também ser capaz de optimizar procuras "nearest-neighbor" (vizinho-mais-próximo). 39

40 Gin Estes índices GIN (Generalized Inverted Index), são índices invertidos que suportam valores com mais que uma chave, arrays por exemplo. Também dependendo da estratégia, os operadores a ser considerados variam. Em Postgres o GIN pode ser usado nestes <@, =, &&. Fig exemplo da criação de um índice GIN Há dois tipos de índices que podem ser usados para acelerar as pesquisas de texto. Note que índices não são mandatórios para estas pesquisas, mas em casos onde a coluna é procurada constantemente, um índice é normalmente desejado. O comando seguinte cria um índice GiST podendo a coluna pode ser do tipo tsvector ou tsquery. CREATE INDEX name ON table USING gist(column); O tipo tsvector representa um documento com formato apropriado para pesquisa textual, enquanto o tsquery similarmente representa uma pergunta. 40

41 De seguida é apresentado o comando para criar um índice do tipo GIN, tendo em atenção que a coluna terá de ser do tipo tsvector. CREATE INDEX name ON table USING gin(column); Há diferenças substanciais na performance entre os dois tipos de índices. O GiST é pouco preciso, o que significa que devolve falsos positivos (PostgreSQL elimina estes de forma automática). Assim esta imprecisão causa degradação de performance devido a retornar alguns valores que na realidade são falsos. Nos índices GIN para pesquisas standard são mais precisos, mas a sua performance depende logaritmicamente no número de palavras únicas. Na escolha dos tipos de índice deve-se considerar as diferenças de performance. Como norma, considera-se os índices GIN serem melhores para dados estáticos porque os lookups são mais rápidos. Para dados dinâmicos, os índices GiST são mais fáceis de actualizar Índices únicos Tanto em PostgreSQL como em Oracle, são possíveis criar índices únicos. Estes índices garantem que nenhumas 2 linhas de uma tabela tenha valores duplicados na coluna(s) chave(s). Para a criação deste índice os comandos entre os SGBDs estudados, serão similar a este: CREATE UNIQUE INDEX idx_name ON table (column) 41