Armazenamento e Estruturas de Indexação em Oracle, MySQL e PostgreSQL. Sistemas de Base Dados ( )

Transcrição

1 Armazenamento e Estruturas de Indexação em Oracle, MySQL e PostgreSQL Sistemas de Base Dados ( ) text Grupo: G Ricardo António de Oliveira Torres Jaquilino Lopes Silva Fernando Jorge Marques Alexandre 1

2 Conteúdo 1 Introdução 4 2 MySQL Introdução InnoDB Buffer Pool Armazenamento de Ficheiros Registos Tipo Compact Partições Range Partitioning List Partitioning Hash Partitioning Linear Hash Partitioning Key Paritioning Subpartitioning Estruturas de indexação Índices Ordenados Sintaxe Utilização das estruturas de indexação por parte do MySQL Índices compostos Bitmap Hashing Linear Hash Partitioning Hash Partitioning Sintaxe Tipo de hash e reashing Estruturas inconsistentes PostgreSQL Introdução Armazenamento de Dados Registo Write-Ahead Log TOAST Free Space Map Partições Range List Estruturas de Indexação B-Tree Hash Índices Parciais GiST GIN Clustering Estruturas de dados Inconsistentes Análise comparativa entre Oracle, MySQL e PostgreSQL Armazenamento dos dados Buffer management Índices suportados Partições suportadas Conclusões 20 2

3 6 Referências 21 3

4 1 Introdução Este relatótio foi escrito no âmbito do estudo feito sobre o tema Armazenanmento e Estruturas de Indexação em Oracle, MySQL e PostgreSQL. Actualmente o desempenho é um dos aspectos mais importante de um sistema de gestão de bases de dados (SGBD) e um dos principais objectivo de um SGBD é simplificar e facilitar o acesso aos dados. Cada vez mais as organizações procuram por um SGBD que fornece vários tipos de indexação, particionamento e uma boa forma de armazenar os dados, de forma a que o tempo de leitura e escrita seja minimizado. Neste relatório é feito comparações entre os modos de armazenamento (como é que os dados são armazenados na base de dados?), estruturas de indexação suportadas (B-/B + tree, Bitmap, etc) e tipos de particão (Hash, Range e List), entre o Oracle, MySQL e PostegreSQL. Ao longo das secções são dados exemplos de código SQL que permitem criar, consultar e apagar as partições e os índices. 4

5 2 MySQL 2.1 Introdução O MySQL está dividido por vários storage engines, cada um deles com as suas características, se bem que o mais interessante, na nossa opinião, para estudo é o InnoDB, e por consequência o estudo é mais centrado na storage InnoDB. 2.2 InnoDB Buffer Pool A engine InnoDB possui um buffer próprio, denominado Buffer Pool. Este buffer é responsável por guardar os dados e os índices na memória. A informação guardada no buffer é gerida segundo uma política de LRU, Least Recently Used, visto que quando é necessário libertar espaço para adicionar um novo bloco de informação no buffer, esta engine remove o bloco de informação que já não é utilizado à mais tempo e adiciona o novo bloco ao meio da lista. Este algoritmo LRU, faz com que o buffer seja tratado como uma lista, que é composta por duas sublistas, ou seja, a sublista da cabeça contém todos os blocos usados mais recentemente, e a sublista da cauda contém todos os blocos usados menos recentemente. Sendo que os blocos que fazem parte da sublista da cauda são os candidatos para serem removidos, em caso de necessidade de espaço para se adicionar um novo bloco. Por defeito o algoritmo LRU funciona da seguinte forma: 1. 3/8 do buffer pool são dedicados à sublista dos blocos menos usados; 2. O centro da lista delimita o fim da sublista dos mais recentes e o início da sublista dos menos recentes; 3. Quando o InnoDB lê um bloco para o buffer pool, o bloco é inserido na cabeça da sublista dos blocos menos usados; 4. Quando um bloco da sublista dos menos usados é acedido pela primeira vez, esse bloco é movido para a cabeça do buffer pool, sendo ao mesmo tempo a cabeça da sublista dos blocos mais recentes. Se o bloco foi lido pela primeira vez, ele é imediatamente necessário, logo passa para a cabeça do buffer pool. No entanto se o bloco foi lido antecipadamente, poderá ser necessário mais à frente para uma execução de uma query, esse bloco não passa imediatamente para a cabeça do buffer pool, podendo até mesmo ser removido do buffer antes da sua leitura. 5. Se um bloco permanecer inutilizável durante um determinado tempo, vai sendo movido para a cauda da lista, até que acabará por ser removido. 2.3 Armazenamento de Ficheiros Toda a informação, no InnoDB, é armazenada numa estrutura chamada Tablespace. Apenas existe um tablespace para todas as bases de dados, porém é possível ao utilizador mudar esse facto, através da opção innodb file per table. O tablespace é uma base de dados de páginas de 16KB. As páginas estão organizadas em extents com tamanho de 1 MB. Os ficheiros que estão no tablespace são segmentos no InnoDB, que contêm: dados, data dictionary, rollback segment, dois segmentos para cada índice e um doublewrite buffer. Quando um segmento aumenta, o InnoDB reserva 32 páginas, e sempre que houver um aumento de um segment, o espaço reservado é aumentado. Desta forma, consegue-se garantir sequencialidade dos dados em disco. Este sistema possui uma base de dados virtual, information schema, que guarda informação das tabelas existentes e dos respectivos schemas. Exemplificamos o comando para sabermos qual a engine da tabela uscensus : select table_name,engine from information_schema.tables where table_name="uscensus"; 5

6 Mas o InnoDB antes de guardar a informação em ficheiros, guarda a informação no Doublewrite buffer. Apenas, e somente, quando as operações de write e flush sobre o Doublewrite buffer estiverem completas é que o InnoDB faz uma cópia da informação para os ficheiros. 2.4 Registos Os registos de uma tabela, nomeadamente na engine storage InnoDB, têm por defeito o tipo Compact, no entanto, é possível ao utilizador mudar o tipo para Redundact, para garantir compatibilidade com versões mais antigas do sistema. Para se consultar o formato dos registos de uma tabela, tem de se fazer o que está exemplificado na imagem abaixo e olhar para a coluna row formart: show table status; Tipo Compact Este tipo reduz o espaço de armazenamento para os registos em vinte por cento, mas, em algumas operações, sobe o uso do CPU. Este tipo Compact tem um record header de 5 bytes, que por sua vez, pode ter um header de tamanho variável. Este header de tamanho variável é constituído por um vector de bits, que indica as colunas Null, sendo que este vector ocupa o valor inteiro arredondado para cima da expressão, N/8, sendo N o número de colunas no índice. Mas se, por acaso, as colunas no índice forem todas não nulas e tiverem um tamanho fixo, então o header não é consituido por nenhuma parte de tamanho variável. Mas no caso de cada coluna que não tem tamanho fixo e não é null, então o header guarda o comprimento de uma coluna num byte. Poderá ter de guardar em dois bytes se parte da coluna estiver guardada externamente nas páginas de overflow ou se o comprimento máximo exceder 255 bytes e o actual comprimento exceder 127 bytes. Os registos no clustered index são compostos por campos, sendo que existem tantos campos como as colunas definidas pelo utilizador. Existem ainda dois campos, transactionid e roll pointer. Adicionalmente, se não existir nenhum campo como chave primária, existirá mais um campo, row ID. Ora, podemos afirmar que os registos no storage engine InnoDB podem ter tamanho variável, devido a poderem existir campos de tamanho variável. Nesta engine, os registos são adicionados às páginas de dados, no primeiro espaço livre, sem seguir nenhuma ordem, mas são inseridos com um apontador que aponta para o registo que contém a próxima chave primária. A InnoDB não permite a organização de registos em multiable clustering. As páginas no InnoDB estão organizadas em extents de 1MB. O InnoDB funciona desta maneira com o intuito de alocar grandes espaços de memória e disco de uma vez só, para garantir que a informação fica o mais contígua possível no disco. Cada extent guarda informação de um só índice. Mas existe um extent global, que contém uma lista de apontadores para todos os extents existentes no tablespace. As páginas que são folha do índice contêm a informação mais recente do registo. Os índices secundários são construídos nas páginas dos clustered indexes. Um dos constituintes de uma página, é o Page Directory, que contém um número variável de apontadores, slots, para os registos. O InnoDB não tem um apontador para cada registo na página, mas sim um apontador por cada seis registos. Visto isto, e sabendo que os registos podem ter tamanho variável, então podemos concluir que o InnoDB utiliza slotted plages para implementar os registos de tamanho variável. 2.5 Partições É possível particionar tabelas, com o objectivo de melhorar a performance. No MySQL, algumas das engines existentes não suportam particionamento, no entanto, o InnoDB suporta todos os tipos, nomeadamente: Range, List, Hash, Linear Hash, Key e ainda a possibilidade de fazer uma partição para outra partição já existente. 6

7 2.5.1 Range Partitioning Este tipo de particionamento permite ao utilizador criar várias partições, sendo que cada partição terá valores segundo um intervalo. Agora apresentamos um exemplo deste tipo de particionamento. CREATE TABLE emplyees ( id INT NOT NULL, fname VARCHAR(30), lname VARCHAR(30), hired DATE NOT NULL DEFAULT , separated DATE NOT NULL DEFAULT , job_code INT, store_id INT ) PARTITION BY LIST(store_id) ( PARTITION p0 VALUES LESS THAN (6), PARTITION p1 VALUES LESS THAN (11), PARTITION p2 VALUES LESS THAN (16), PARTITION p3 VALUES LESS THAN (21) ); List Partitioning A única diferença deste tipo de particionamento para com o anterior é que neste o utilizador pode definir a lista dos valores do intervalo, enquanto que no tipo anterior isso não acontecia. CREATE TABLE emplyees ( id INT NOT NULL, fname VARCHAR(30), lname VARCHAR(30), hired DATE NOT NULL DEFAULT , separated DATE NOT NULL DEFAULT , job_code INT, store_id INT ) PARTITION BY LIST(store_id) ( PARTITION pnorth VALUES IN (3,5,6,9,17), PARTITION peast VALUES IN (1,2,10,11,19,20), PARTITION pwest VALUES IN (4,12,13,14,18), PARTITION pcentral VALUES IN (7,8,15,16) ); Com este particionamento podemos separar as lojas através do store-id, em lojas que pertencem a norte, este, oeste e centro, definindo a lista de valores que corresponde a cada zona Hash Partitioning Com este tipo de particionamento apenas temos de especificar o nome do campo que pretendemos que seja aplicada a função de hash e o número de partições. O particionamento por hash é utilizado para assegurar que o mesmo número de dados é dividido por um determinado número de partições. O exemplo em baixo exemplifica como usar este tipo de particionamento. CREATE TABLE emplyees ( id INT NOT NULL, name VARCHAR(30), 7

8 code INT ) PARTITION BY HASH (code) PARTITIONS 4; Linear Hash Partitioning A única diferença para o anterior é que aqui é utilizado um algoritmo linear de potências de 2. O utilizador pode especificar este tipo de particionamento da seguinte forma: CREATE TABLE exemplo2 ( id INT NOT NULL, data date not null default , code INT ) PARTITION BY LINEAR HASH (id) PARTITIONS 2; Key Paritioning O particionamento por KEY efectua o particionamento pela chave primária da tabela, caso exista alguma, caso contrário, utiliza como chave o atributo UNIQUE da tabela, caso este esteja definido como not null. CREATE TABLE k1 ( id INT NOT NULL PRIMARY KEY, name VARCHAR(30) ) PARTITION BY KEY() PARTITIONS 2; Linear Key Partitioning Esta variante apenas difere da anteior no algoritmo de particionamento por chave. Exemplificando: CREATE TABLE k1 ( id INT NOT NULL, name VARCHAR(30), UNIQUE KEY(id) ) PARTITION BY KEY() PARTITIONS 2; Subpartitioning No InnoDB também existe a possibilidade de criar uma partição para uma partição. exemplo disso. CREATE TABLE ts ( id INT, purchased DATE) PARTITION BY RANGE( YEAR(purchased) ) SUBPARTITION BY HASH (TO_DAYS(purchased) ) SUBPARTITIONS 2 ( PARTITION p0 VALUES LESS THAN (1990), PARTITION p1 VALUES LESS THAN (2000), PARTITION p2 VALUES LESS THAN MAXVALUE ); Em baixo, segue um 8

9 2.6 Estruturas de indexação Os algoritmos de indexação são usados para tornar as pesquisas sobre tabelas mais eficientes. O comportamento normal do MySQL sem indexação é iterar todas os tuplos da tabela e seleccionar os tuplos que têm o atributo passado como parâmetro. Quando fazemos uma indexação o algoritmo cria uma colecção dos elementos com os atributos que pretendemos pesquisar, quando executamos a pesquisa com um valor especifico no atributo, este vai iterar a colecção gerada do atributo em questão e devolve os tuplos que satisfizerem a(s) condição(ões). Os tipos de índices suportados são: R-Tree, Hash e B + T ree. Se bem que nem todas as storage engine suportam estas estruturas de indexação, nomeadamente: Storage Engine MyISAM InnoBD MEMORY/HEAP NDB Permissible Index Types BTREE BTREE HASH, BTREE HASH, BTREE Índices Ordenados A InnoDB suporta índices primários e secunários. Nos índices primários, clustured index, se tiver sido definida uma chave primária, na tabela em questão, então é usada a chave primária como clustured index, caso não esteja definida nenhuma chave primária, então é usado o primeiro atributo definido como UNIQUE, e que apenas contém colunas não nulas. Caso contrário, é gerado um clustured index interno sobre uma coluna que contém o rowid. Os índices secundários têm as colunas da chave primária para cada registo que não está no índice primário Sintaxe A sintaxe para criar índices é a seguinte: CREATE [UNIQUE FULLTEXT SPATIAL] INDEX index_name [index_type] ON tbl_name (index_col_name,...) [index_option]... index_col_name: col_name [(length)] [ASC DESC] index_type: USING {BTREE HASH} index_option: KEY_BLOCK_SIZE [=] value index_type WITH PARSER parser_name COMMENT string Porém, também podemos definir índices quando criamos tabelas, da seguinte forma: CREATE TABLE cursos ( cod_curso int not null auto_increment, nome varchar(35) not null, index using HASH (cod_curso) ) engine=innodb; 9

10 Também é possível adicionar um índice a uma tabela, usando a instrução Alter Table, da seguinte forma: ALTER TABLE cursos ADD INDEX exemplo USING BTREE(cod_curso); Utilização das estruturas de indexação por parte do MySQL 1. O MySQL utiliza índices para escolher as tabelas que contém o menor número de registos, para poder eliminar registos, com o intuíto de libertar memória. 2. Nas operações de join, se o tamanho e o tipo forem o mesmo. 3. Melhora a rapidez de uma querie na cláusula Where 4. Na realização de operações de Min, Max e ordenações. Exemplificando, primeiro sem índice nenhum. Mas se criarmos um índice, e depois fizermos a mesma consulta, verificamos que a pesquisa demorou menos Índices compostos Para além dos tipos de índices especificados acima, o MySQL suporta ainda índices compostos, ou seja, índices sobre múltiplos atributos, sendo que podem ser no máximo dezasseis atributos. Estes índices compostos são usados no MySQL para fornecer uma maior rapidez ao processamento de consultas Bitmap Os Bitmap não são suportados pelo MySQL, no entanto, recorrendo ao index merge podemos ter algo parecido a um bitmap. As duas funções principais deste index é optimizar a cláusula where e tratar mais eficientemente a análise e produção de resultados nas operações de joins. 10

11 2.7 Hashing O Hashing em MySQL usa o mecanismo de partições, estudado anteriormente, criando um distribuição equilibrada de dados de uma tabela. Para o utilizador poder criar um hashing, apenas tem de indicar quais os atributos que quer utilizar e o número de partições. O MySQL suporta hashing para múltiplos atributos, porém não é recomendado o seu uso porque torna o processamento de queries mais lento. Existem dois tipos de Hashing em MySQL, Linear Hash Partitioning e Hash Partitioning Linear Hash Partitioning Quando é aplicado um hashing em MySQL, quando é inserido um tuplo numa tabela, este determina para que partição vai o tuplo, e para encontrar a partição é usado a função MOD(expr, num). Em baixo exemplifica-se como criar uma tabela segundo o Linear Hash Partitioning. CREATE TABLE exemplo2 ( id INT NOT NULL, data date not null default , cod INT ) PARTITION BY LINEAR HASH (id) PARTITIONS 2; Hash Partitioning Assim se cria uma tabela usando o Hash Partitioning. CREATE TABLE exemplo ( id INT NOT NULL, name VARCHAR(30), cod INT ) PARTITION BY HASH (code) PARTITIONS 4; Para se calcular qual a partição de um tuplo que é inserido numa tabela é usado o seguinte algoritmo: 1. Temos de calcular o valor V = POWER(2;CEILING(LOG(2; num))), que representa o valor da potência de dois maior que o número num, que designa o número de partições; 2. Depois temos de encontrar N = F(column-list) and (V - 1); 3. Fazer um ciclo em enquanto N =num, e calcular V = CEIL(V=2), N = N and (V - 1); 4. Inserir o tuplo na respectiva partição. Agora exemplificamos com um exemplo: CREATE TABLE t1 ( col1 INT, col2 CHAR(5), col3 DATE ) PARTITION BY LINEAR HASH ( YEAR(col3) ) PARTITIONS 6; 11

12 Temos a tabela t1 e vamos inserir o seguinte tuplo (2, , ). V= POWER(2, CELLING (LOG(2,6) ) ) = 8 N=YEAR( ) & (8-1) =2003&7 =3 Portanto, o tuplo será inserido na partição número 3. A vantagem desde algoritmo reside no facto de fazer que as operações de adição, eliminação, junção e divisão de partições sejam muito mais rápidas. No entanto este tipo de hashing tem um desvantagem, os dados não estão distribuídos de uma forma muito equilibrada em comparação com o hashing regular Sintaxe É possível alterar, adicionar, apagar partições, com o comando ALTER TABLE table-name partitions-specification... Partition-specification: 1. ADD PARTITION (definição da partição) - Com este comando podemos adicionar uma nova partição; 2. DROP PARTITION (nome da partição) - Com este comando podemos apagar uma partição; 3. COALESCE PARTITION número - Este comando serve para reduzir o número de partições; 4. REORGANIZE PARTITION [nomes das partições INTO (definições das partições)] - Este comando serve para fazer uma organizaçao da partição; 5. REMOVE PARTITIONING - Este comando serve para remover todas as partições Tipo de hash e reashing O hashing do MySQL é dinâmico para a melhorar a gestão da memória, e o rehashing está activado by default, no entanto podemos desactivá-lo com o seguinte comando disable-auto-rehash, que faz com que haja um carregamento do sistema mais rápido. 2.8 Estruturas inconsistentes O MySQL tem o modo de autocommit activo by default, e por consequência deste facto, assim que seja modificada alguma coisa numa tabela, essa alteração é guardada em disco, passando a dados permanentes. Por sua vez, ao desactivar o modo de autocommit, o utilizador tem de fazer Commit para guardar as alterações. Ao fazer a verificação de restrições de chaves externas, o InnoDB analisa-as, nomeadamente, nas operações de inserção, remoção e update linha a linha, e por consequência não permite que haja violação dessas restrições durante a execução de uma transacção. 12

13 3 PostgreSQL 3.1 Introdução A versão de PostgreSQL apresentada nas próximas secções é 9.1. Este ao contrário do MySQL apenas fornece uma estrutura para armazenar os dados em memória persistente. 3.2 Armazenamento de Dados PostgreSQL utiliza as primitivas do sistema de operação para lidar com a interacção com a memória persistente. Cada tabela e índice tem um ficheiro associado, excepto quando exceder o limite de 1GB, nesse caso, estes são separados em secções de 1GB. A gestão de buffers consiste em guardar em buffer a informação recentemente utilizada da base de dados e quando este fica cheio (ou o Write-Ahead Log regista na memória persistente um certo número de operações) um checkpoint é desplotado. Um checkpoint consiste em sincronizar a uma pequena parte da informação do buffer com a informação da memória permanente e limpa-la do buffer para o espaço ser reutilizado. Cada registo tem um tamanho fixo (normalmente 8kB) e não admite que um tuplo use mais que um registo. Para ultrapassa esta limitação, campos de grande dimensão são comprimidos / separados fisicamente em diferentes tuplos de forma transparente ao utilizador. Esta técnica será melhor apresentada na secção TOAST Registo Um registo em PostgreSQL é constituído por: Cabeçalho do registo (20 Bytes). Um array com pares (offset, tamanho) que apontam para os itens (4 Bytes por elemento do Array). Espaço Livre. Itens em si. Espaço especial para dados específicos a alguns métodos. O registo é considerado cheio quando o array de pares e itens tornam-se vizinhos imediatos fisicamente Write-Ahead Log Para melhorar as garantias de integridade que é necessário num sistema de gestão de bases de dados o Write- Ahead Log é utilizado. Este consiste em apenas guardar em memória persistente o registo das transacções prioritariamente (ao contrário da informação em si que é normalmente mais volumosa) de forma a ser possível reproduzir o estado corrente da base de dados caso haja erros graves (ex. falta de electricidade) TOAST TOAST (The Oversized-Attribute Storage Technique) é a característica utilizada pelo PostgreSQL para suportar tuplos maiores que o tamanho fixo de um registo (normalmente 8kB) separando a informação em vários registos. Apenas os tipos de dados que podem produzir dados de grandes tamanhos podem ser TOASTed (porque necessitam de uma variável nova varlena (de 32 bits) que contém o tamanho físico do campo). Os dois high bits de varlena são utilizados para descrever o estado do campo, dois bits a zero implica que o campo não está TOASTed, se um dos bits está a um, significa que o campo está comprimido (com um algoritmo da família LZ), se o outro bit está a um significa que a informação do campo não está neste registo e o resto do valor é um apontador para a localização correcta da informação. Utilizando TOAST o tamanho máximo do valor de um campo é 1GB( bytes). 13

14 3.2.4 Free Space Map Todos os índices (excepto hash) e heaps têm um FSM (Free Map Space) associado que assinala quais são os espaços físicos livres na relação. Cada FSM está organizado como uma árvore de registos de FSM. As folhas guardam o estado de ocupação de cada heap (ou índice) usando um byte e os níveis superiores contém a informação agregada dos abaixo. 3.3 Partições O PostgreSQL apenas suporta partições do tipo Range e List. O modo de utilização é igual para ambos os tipos, apenas o tipo de condição é diferente: Criar uma tabela master que contém a estrutura da tabela (os campos). Criar n tabelas child (em que n é o número de partições) que irão INHERIT os campos da tabela master. Cada tabela terá um CHECK que verificará a condição de entrada numa dada tabela child (partição). Criar uma função em PL/PLPG SQL que irá ser chamada quando se tentar inserir na tabela master (utilizando um trigger) para decidir em que partição inserir os dados. Criar um trigger que será desplotado sempre que se tentar inserir na tabela master que invocará a função anterior Range Partições Range utilizam intervalos de valores para particionar. Sintaxe Um exemplo simples da sintaxe de criação de uma partição Range: CREATE TABLE counter ( a int not null ); CREATE TABLE counter_less ( CHECK ( a < 50); ) INHERITS (counter); CREATE TABLE counter_equal_higher ( CHECK ( a >= 50 ) ) INHERITS (counter); CREATE INDEX idx_counter_less on counter_less ( a ); CREATE INDEX idx_counter_equal_higher on counter_equal_higher( a ); CREATE OR REPLACE FUNCTION insert_counter() RETURNS TRIGGER AS $$ BEGIN IF ( NEW.a < 50 ) THEN INSERT INTO counter_less VALUES (NEW.*); ELSE INSERT INTO counter_equal_higher VALUES (NEW.*); END IF; RETURN NULL; END; $$ LANGUAGE plpgsql; 14

15 CREATE TRIGGER insert_counter_trigger BEFORE INSERT ON counter FOR EACH ROW EXECUTE PROCEDURE insert_counter(); List Partições List utilizam valores discretos para particionar. Sintaxe Um exemplo da criação de uma partição List: CREATE TABLE counter ( a int not null ); CREATE TABLE counter_50_51_52 ( CHECK ( a == 50 OR a == 51 OR a == 52); ) INHERITS (counter); CREATE TABLE counter_49 ( CHECK ( a == 49 ) ) INHERITS (counter); CREATE TABLE counter_else ( CHECK ( a!= 49 AND a!= 50 AND a!= 51 AND a!= 52) ) INHERITS (counter); CREATE INDEX idx_counter_50_51_52 on counter_50_51_52 ( a ); CREATE INDEX idx_counter_49 on counter_49( a ); CREATE INDEX idx_counter_else on counter_else ( a ); CREATE OR REPLACE FUNCTION insert_counter() RETURNS TRIGGER AS $$ BEGIN IF ( NEW.a == 50 OR NEW.a == 51 OR NEW.a == 52) THEN INSERT INTO counter_50_51_52 VALUES (NEW.*); ELSIF (NEW.a == 49) THEN INSERT INTO counter_49 VALUES (NEW.*); ELSE INSERT INTO counter_else VALUES (NEW.*); END IF; RETURN NULL; END; $$ LANGUAGE plpgsql; CREATE TRIGGER insert_counter_trigger BEFORE INSERT ON counter FOR EACH ROW EXECUTE PROCEDURE insert_counter(); 3.4 Estruturas de Indexação O PostgreSQL fornece várias estruturas de indexação e APIs para implementação de novos índices (GiST e GIN). Na versão 9.1 apenas B-Tree, GiST e GIN suportam índices com múltiplos atributos (com um limite até 32 atributos). É possível também definir um nível de ocupação no qual o sistema irá tentar juntar todas as pages que o índice está a utilizar para um acesso sequencial mais rápido. A sintaxe para esta opção é a seguinte: 15

16 Sintaxe CREATE INDEX idx_name ON tablename (fieldname) WITH (fillfactor = 70); O fillfactor pode ter um valor entre % B-Tree B-Tree é o tipo de índice utilizado por defeito visto fornecer a melhor combinação de performance e funcionalidade disponível. Este tipo de índice é o único que consegue utilizar o atributo UNIQUE tal como o único que tem um ordered scan implementado que permite alterar a ordem do índice com facilidade. Sintaxe CREATE INDEX idx_name ON tablename (fieldname) USING btree; Índices Reverse apenas a B-Tree tem a opção de criar índices invertidos pois só ela tem um ordered scan implementado. Pode ser criado um índice reverse da seguinte forma: Sintaxe CREATE INDEX idx_name ON tablename (fieldname DESC) USING btree; Hash Índices de hash, normalmente têm o mesmo nível de performance dos índices B-Tree excepto em casos relativamente específicos como por exemplo na pesquisa de valores únicos no índice em que no caso de hash tem complexidade constante e no caso das B-Tree tem uma complexidade O(n log(n)). CREATE INDEX idx_name ON tablename (fieldname) USING hash; Índices Parciais Índices parciais apenas abrangem parte dos tuplos possíveis. Este tipo de índice é conseguido através da utilização da cláusula WHERE. Só podem ser utilizados condições que utilizem colunas da tabela a ser indexada e sub-queries são proibidas. Sintaxe CREATE INDEX idx_name ON tablename (fieldname) WHERE condition; GiST O GiST (Generalized Search Tree), representa um método de acesso estruturado como uma árvore que é utilizado como uma interface para implementação de esquemas de indexação. Este nível de abstracção faz com que quem está a fazer o novo esquema de indexação não tenha de se preocupar com Write-Ahead Log, concorrência e procura a nível da estrutura da árvore. O GiST permite também indexação através de expressões. Em alguns casos o GiST obtém falsos positivos nas suas pesquisas necessitando que o PostgreSQL verifique os resultados para os eliminar, caso existam. Estes falsos positivos existem porque o GiST representa cada tuplo no índice como uma assinatura de tamanho fixo que provoca em algumas situações colisões de assinaturas. Sintaxe CREATE INDEX idx_name ON tablename USING gist (column); 16

17 3.4.5 GIN GIN (Generalized Inverted Index) é internamente uma B-Tree construído com chaves onde cada chave é um elemento de um ou mais itens indexados. Índices multi-coluna são implementados por construir a B-Tree sobre valores compósitos (número coluna, chave) onde os valores de chave para colunas diferentes podem ser de diferentes tipos. GIN tem uma técnica Fast Update que ajuda a acelerar as operações de UPDATE, atrasando a sua adição ao índice e adicionando invés a uma estrutura temporária para actualizações em espera. O problema com esta técnica é que em pesquisas, os resultados têm de ser pesquisados em dois sítios e caso a lista de actualizações à espera for grande, a pesquisa será bastante mais lenta. O método de procura em índices GIN varia de acordo com o que está disponível (implementado) visto o GIN, em grande similaridade ao GiST, oferece uma interface de alto nível que permite a implementação de métodos de procura para conjuntos específicos de índices. Sintaxe CREATE INDEX idx_name ON tablename USING gin (column) [WITH (fastupdate = on/off)]; 3.5 Clustering O PostgreSQL suporta single table clustering através do comando CLUSTER. Este apenas suporta clustering utilizando índices existentes (ordenando a tabela fisicamente de acordo com o índice). Quando a tabela é modificada, a ordenação física da tabela não se mantém (necessário executar outro comando de CLUSTER). Sintaxe CLUSTER [tablename [USING indexname]] Se indexname não seja definido, tenta aplicar o comando a tablename utilizando o índice anteriormente usado. O comando sem nenhum argumento faz recluster a todas as tabelas anteriormente clustered usando os mesmos indexname. 3.6 Estruturas de dados Inconsistentes As estruturas de dados (e views) inconsistentes no PostgreSQL não são admitidas, no entanto, antes da versão 9.1, era possível obter estados inconsistentes através de bugs do sistema então implementados para os prevenir (snapshot isolation) que provocara corrupção de informação em certas situações. Na versão 9.1 foi introduzido um nível de serialização total que fornece completa segurança contra estruturas de dados inconsistentes. 17

18 4 Análise comparativa entre Oracle, MySQL e PostgreSQL 4.1 Armazenamento dos dados O Oracle, MySQL e PostgreSQL usam a estrutura tablespace, que é uma unidade lógica de armazenamento das tabelas e índices. A ideia do tablespace é construir uma ponte entre a base de dados e o sistema de ficheiros onde estão armazenadas as tabelas e os índices. Estes três SGBDs (DBMSs) disponibilizam várias operações sobre a estrutura tablespace, como apagar uma tablespace da base dados, agrupar tablespaces, renomear, etc. Exemplo do comando para criar tablespace em Oracle: CREATE BIGFILE TABLESPACE bigtbs_01 DATAFILE bigtbs_f1.dat SIZE 20M AUTOEXTEND ON; Sintaxe em MySQL CREATE TABLESPACE tablespace_name ADD DATAFILE file_name USE LOGFILE GROUP logfile_group [EXTENT_SIZE [=] extent_size] [INITIAL_SIZE [=] initial_size] [AUTOEXTEND_SIZE [=] autoextend_size] [MAX_SIZE [=] max_size] [NODEGROUP [=] nodegroup_id] [WAIT] [COMMENT [=] comment_text] ENGINE [=] engine_name Sintaxe em PostgreSQL CREATE TABLESPACE tablespacename [ OWNER username ] LOCATION directory username: defeito. O dono da tabela. Se for omitido o username, o comando é executado para o utilizador por directory: A directoria que será usada para tablesapce. Deve estar vazia e deve pertencer ao utilizador do PostgreSQL. Deve ser especificada por um caminho absoluto. Exemplo: CREATE TABLESPACE dbspace LOCATION /data/dbs ; 4.2 Buffer management Os sistemas de gestão de base de dados analisados possuem todos, o controlo de buffer management próprios. A política de gestão do buffer é práticamente iguais para os três, ou seja, usam a técnica Least Recently Used (LRU) para gerir os blocos no buffer. 4.3 Índices suportados Os índices são estruturas que podem ser associados às tabelas e cluters para permitir que as queries SQL sobre uma tabela sejam mais rápidas. É análogo ao índice de um livro. Uma das vantagens dos índices, é que são lógicamente e físicamente independentes dos dados associados a uma tabela. Sendo estruturas independentes, eles precisam de ser armazenados. Podemos criar ou apagar um índice sem afectar as tabelas, aplicações, ou outros índices. Os três SGBDs analisados automaticamente mantém índices quando é efectuado as operações de insert, update e delete sobre as linhas de tabela. Na tabela seguinte apresentamos quais os índices suportados para os três sistemas analisados. 18

19 B-/B + tree é suportada por Oracle, MySQL e PostgreSQL. Oracle MySQL R-/R + tree Hash Expression Partial Reverse Bitmap GiST Sim Só Tabelas MyISAM Tabelas Cluster MEMORY, Cluster (NDB), InnoDB, tables only Full text Spatial Sim Sim Sim Sim Não Sim Sim Não Não Não Não Não PostgreSQL Só R- 1 Sim Sim Sim Sim Não Sim Só Tabelas MyISAM Módulo Extra Apenas Nota( 1 ): As árvores R- foram removidas no PostgreSQL 9.1 pois não tinham qualquer vantagem sobre os índices GiST. 4.4 Partições suportadas Particionar permite uma tabela ou um índice ser devidido em pequenas partes, onde cada parte de um objecto da base de dados é denominado de partição. Cada partição tem o seu próprio nome, e pode opcionalmente ter as suas próprias características. Do ponto de vista do administrador da base dados, um objecto particionado tem múltiplas partes que podem ser geridas colectivamente ou individualmente. Isto fornece ao administrador uma considerável flexibilidade em gerir objectos particionados. Porém, do ponto de vista da aplicação, uma tabela particionada é idéntica a uma tabela não-particionada; não é preciso nenhuma modificação nas queries SQL quando se pretende aceder uma tabela/relação particionada, ou seja, a forma de acesso é a mesma para uma tabela/relação não-particionada. Na tabela abaixo encontram-se quais as partições que cada um dos sistemas analisados suportam: Range Hash (Range+Hash) List Oracle Sim Sim Sim Sim MySQL Sim Sim Sim Sim PostgreSQL Sim Não Não Sim? PostGIS 19

20 5 Conclusões Depois de uma análise feita para os SGBDs, Oracle, MySQL e PostgreSQL, sobre o tema Armazenamento e Estruturas de Indexação, adquirimos mais conhecimento sobre como estes SGBDs armazenam os dados e como podem ser usados estruturas de indexação para optimizar as consultas. Em relação ao armazenamento e acesso aos dados, estes SGBDs usam seus próprios buffers management, o que achámos relevante, porque assim não dependem do sistema operativo. Relativamente aos índices, o Oracle disponibilisa vários tipos de índices, nomeadamente B-/B + tree, Bitmap, Hash, etc. O PostgreSQL suporta os mesmos índices que o Oracle, excepto Bitmap e R + tree e no caso do índice Spatial é suportada pela componente PostGIS, enquanto que o MySQL é que suporta menos estruturas de indexação. No que diz respeito às partições, o PostgreSQL é o que suporta menos tipos de partições. Suporta apenas o Range e o List. O Oracle e o MYSQL suportam Range, Hash, conbinações entre Range e Hash, e List. Todos eles oferecem vários tipos de operações para trabalhar com partições, o que achámos ser muito útil para o programador. Este trabalho fez-nos perceber melhor como os dados são armazenados para os três SBGDs analisados, perceber quais as estruturas de indexação oferecem e como trabalhar com essas estruturas. Foi um trabalho com o qual estamos satisfeitos e esperemos que nos venha a servir no desenvolvimento dos projectos de software. 20

21 6 Referências [1] [2] [3] [4] [5] [6] [7] [8] [9] [10] [11] [12] [13] [14] [15] [16] [17] [18] Internals InnoDB#Fil Header [19] Internals Files In InnoDB Sources [20] manual/ch14s02.html [21] [22] [23] [24] [25] [26] [27] 21

22 [28] [29] gsmith/gregsmith/content/postgresql/postgresqlbuffermanagement.htm [30] [31] [32] [33] [34] [35] [36] 01/server.102/b14231/indexes.htm [37] 01/server.111/b32024/partition.htm [38] 01/server.102/b14231/partiti.htm [39] [40] Database System Concepts, 6th edition, Abraham Silberschatz, Henry F. Korth, S. Sudarshan, McGraw- Hill, 2011, ISBN