Trabalho de SBD Estudo do sistema POSTGRESQL

Transcrição

1 Trabalho de SBD Estudo do sistema POSTGRESQL João Miguel Vaz, Ricardo Vaz Alves, Vasco Jorge Pessanha, 31235

2 Índice 1. Introdução: História dos SGBDs História do PostgreSQL Aplicabilidade e Actualidade do PostgreSQL Cobertura do SQL Cobertura DDL Cobertura DML Armazenamento e file structure File System Paginação Partições Clustering Buffer Management Indexação e Hashing Introdução Tipos de Índices Índices para organização de ficheiros Outras Informações Processamento e Optimização de Perguntas Percurso de Uma Interrogação Ligação ao Servidor Etapa de Parsing Planificador / Optimizador Executor Algoritmos para operações básicas Mecanismos de Avaliação de Expressões Complexas Tabelas e Views Estatísticas Mais estimativas Como é que o Planificador Utiliza as Estatísticas (Estimativas de Linhas) Mecanismos de Visualização de Planos de Perguntas Gestão de transacções e controlo de concorrência Definição de transacção Propriedades ACID das transacções

3 6.3. Estado de uma transacção Controlo de Concorrência Transacções e Gestão de Concorrência no PostgreSQL Consistência de Dados no PostgreSQL Atomicidade e Durabilidade no PostgreSQL Mecanismos de Rollback e recuperação no PostgreSQL Diferir a verificação para o final das transacções Suporte para bases de dados distribuídas Outras características do sistema estudado XML Procedimentos / Triggers Segurança Tipos de Dados Ferramentas Adicionais Conclusão Bibliografia

4 1. Introdução: O sistema de gestão de bases de dados (SGBD) que iremos abordar será o PostgreSQL (muitas vezes referido apenas como Postgres). Como tal, faremos primeiro uma pequena abordagem à história dos SGBD, seguida duma introdução ao sistema acima referido, nomeadamente à sua criação e desenvolvimento, aplicabilidade e capacidades. Note-se que não será referido qualquer tipo de instalação do sistema, já que a mesma é trivial, bastando-se fazer o download do site oficial (gratuito), e seguir as instruções da instalação (semelhante à instalação de qualquer outra aplicação) História dos SGBDs Os SGBDs (Sistemas de Gestão de Bases de dados) apareceram nos anos 60, à medida que a capacidade e velocidade dos computadores aumentavam. São constituídos por software que é responsável pela manutenção, gestão de acessos, e organização de dados, oferecendo uma agradável abstracção ao cliente, tal como mostra a Figura 1. Figura 1 Esquema de um SGBD, fazendo a ponte entre as aplicações e a base de dados Ao longo do tempo, os SGBD foram-se tornando cada vez mais eficientes, fornecendo inúmeras particularidades que melhoram a utilização das bases de dados, aumentando a velocidade, consistência, e segurança dos acessos. Os SGBDs actuais oferecem segurança, backups e replicações para recuperação de falhas do equipamento como discos, implementação de restrições (como primary e foreign keys), optimização de perguntas, modelos para definir esquemas de dados armazenados no sistema, estruturas de dados preparadas para suportar grandes quantidades de dados, etc. Para além de implementarem isto tudo, fazem-no quase sempre de forma automática, simples e transparente para o utilizador (mesmo que o utilizador não refira como quer aceder aos 4

5 dados, os SGBD usam optimizações baseadas em estatísticas no acesso dos mesmos, que aumentam a eficiência e rapidez das queries) História do PostgreSQL O PostgreSQL é hoje constituído por uma comunidade de pessoas que são responsáveis pela manutenção do sistema (incluindo manutenção do site, da documentação, e das FAQs), tradução, correcção de bugs, testes de performance, etc. A primeira referência que há do PostgreSQL é o INGRES (INteractive Graphics REtrieval System), um projecto de investigação da Universidade de Berkeley (Califórnia) do final dos anos 70, que desenvolvia um SGBD Relacional Open Source desenhado para suportar grandes aplicações comerciais e governamentais. Em 1986, o professor Michael Stonebraker liderou o projecto POSTGRES que não era mais do que o sucessor do primeiro ( POST Ingres ). Este projecto conseguiu grandes patrocinadores fazendo com que o sistema aumentasse a sua robustez e crescesse bastante, passando a implementar um grande número de funcionalidades novas. Desse conjunto de patrocinadores destacam-se: Defense Advanced Research Projects Agency (DARPA), Army Research Office (ARO), National Science Foundation (NSF). Nos dez anos seguintes (até 1995), o Postgres foi crescendo exponencialmente sendo constantemente alterado em sucessivas versões que tentaram focar-se na portabilidade, versatilidade e fiabilidade do sistema. Só em 1993, a comunidade de utilizadores externos do Postgres duplicou. Em 1994 Andrew Yu e Jolly Chen adicionaram um interpretador da linguagem SQL ao sistema. Este feito foi de tal maneira importante que viria a mudar o nome do SGBD para POSTGRES95 (lançado, como o nome indica, no ano de 1995). Esta nova versão incluiu importantes mudanças no que diz respeito a correcção de erros, melhoramentos da performance e da facilidade de manutenção, e ainda foram adicionados vários recursos (exemplo disso foi a introdução da cláusula vulgar groupby). Esta versão foi disponibilizada na Web como opensource juntamente com um tutorial que agrupava funcionalidades regulares do SQL e do Postgres95. Esta decisão viria a impulsionar drasticamente o crescimento deste sistema. No ano seguinte, o nome Postgres95 tornou-se obsoleto, pelo que passou a ser intitulado PostgreSQL, para realçar a interacção do antigo sistema com a linguagem SQL. A primeira versão com este nome correspondeu à versão 6.0 do antigo sistema e, ao contrário das primeiras versões que se baseavam na correcção de falhas e optimização de código, nesta versão os esforços foram canalizados para a expansão do sistema melhorado com a implementação de novos recursos. Desde esta última versão, o Postgres (nome pelo qual também é reconhecido ainda hoje) foi crescendo tornando-se um dos grandes nomes no que toca a sistemas de gestão de bases de dados, servindo desde pequenos programadores, até grandes empresas. A última versão deste sistema (versão 8.4.1) data de 09/09/2009, oferecendo uma panóplia de funcionalidades novas, mantendo porém compatibilidade com versões mais antigas. 5

6 1.3. Aplicabilidade e Actualidade do PostgreSQL Como foi visto anteriormente, o PostgreSQL é hoje em dia um sistema muito poderoso, sofisticado, estável, com alta performance, implementando praticamente todas as funcionalidades requeridas pelos clientes. Por outro lado é um sistema Open Source gratuito, acessível e de fácil utilização e instalação. Este sistema suporta bases de dados bastante extensas, adequadas ao uso de uma grande empresa. No quadro seguinte podemos observar as capacidades do PostgreSQL, percebendo assim que não existe qualquer tipo de limitação para grandes bases de dados: Tamanho máximo da Base de Dados Ilimitado * Tamanho máximo de uma tabela 64 TB Tamanho máximo de uma linha de uma tabela 1.6 TB Número máximo de indexes por tabela Ilimitado * * - Note-se que ilimitado significa que não há qualquer restrição por parte do PostgreSQL ou seja, tendo apenas as limitações do espaço livre em disco. Actualmente, a solução PostgreSQL+Linux é muito utilizada pelas mais variadas empresas. Esta constitui um exemplo de como os produtos Open Source podem oferecer um grande serviço a pequenas e grandes empresas evitando custos de licenças, ajudando-as assim a racionalizar os custos das tecnologias de informação. O PostgreSQL é ainda um sistema bastante versátil, suportando praticamente todos os sistemas operacionais tais como Linux, Mac OS, Solaris, Windows, etc. É usado ainda por grandes empresas no mundo da informática tais como Apple ou Cisco, e noutros ramos como é o caso da OMS (Organização Mundial de Saúde). Na figura seguinte podemos observar alguns dos maiores patrocinadores do projecto PostgreSQL: Figura 2 Logótipos de alguns dos maiores patrocinadores do PostgreSQL Concluímos assim, que a nível da aplicabilidade do sistema, o PostgreSQL é potente o suficiente para ser usado por grandes empresas que precisam de grande estabilidade por parte do SGBD, mas por outro lado é fácil de usar, leve e prático para uma gestão de uma base de dados 6

7 caseira. O sistema é por isso muito completo, podendo ser usado para praticamente qualquer situação. 7

8 2. Cobertura do SQL Como já foi referido e o próprio nome indica, o PostgreSQL utiliza um interpretador de SQL, pelo que para além da linguagem de perguntas usada pelo utilizador ser o SQL, praticamente todas as operações do SQL são suportadas pelo PostgreSQL Cobertura DDL Por definição, o DDL (Data Definition Language) é uma linguagem que disponibiliza comandos que permitem ao utilizador criar estruturas de dados. Em base de dados é usado portanto para criar as estruturas que irão suportar os dados guardados pela mesma, disponibilizando para isso uma panóplia de comandos tais como a criação, remoção e alteração de tabelas, triggers ou regras Criação de Tabelas A sintaxe do comando que permite a criação de uma tabela é bastante complexa já que suporta diversas opções para o utilizador, tais como definição directa de restrições sobre um ou mais atributos, chaves primárias e estrangeiras, se as operações sobre a tabela têm de ser verificadas ou não aquando de uma operação, etc. A sintaxe completa é mostrada de seguida (tal como na documentação do PostgreSQL, a sintaxe foi repartida em diversas partes para tornar a sua leitura mais perceptível): CREATE [ [ GLOBAL LOCAL ] { TEMPORARY TEMP } ] TABLE table_name ([ { column_name data_type [ DEFAULT default_expr ] [ column_constraint [... ] ] table_constraint LIKE parent_table [ { INCLUDING EXCLUDING } { DEFAULTS CONSTRAINTS INDEXES } ]... } [,... ] ] ) [ INHERITS ( parent_table [,... ] ) ] [ WITH( storage_parameter [= value][,... ]) WITH OIDS WITHOUT OIDS] [ ON COMMIT { PRESERVE ROWS DELETE ROWS DROP } ] [ TABLESPACE tablespace ] Sendo que column_constraint corresponde a: [ CONSTRAINT constraint_name ] { NOT NULL NULL UNIQUE index_parameters PRIMARY KEY index_parameters CHECK ( expression ) REFERENCES reftable [ ( refcolumn ) ] [ MATCH FULL MATCH PARTIAL MATCH SIMPLE ] [ ON DELETE action ] [ ON UPDATE action ] } [DEFERRABLE NOT DEFERRABLE] [INITIALLY DEFERRED INITIALLY IMMEDIATE] Sendo que table_constraint corresponde também a: [ CONSTRAINT constraint_name ] { UNIQUE ( column_name [,... ] ) index_parameters PRIMARY KEY ( column_name [,... ] ) index_parameters 8

9 CHECK ( expression ) FOREIGN KEY ( column_name [,... ] ) REFERENCES reftable [ ( refcolumn [,... ] ) ] [ MATCH FULL MATCH PARTIAL MATCH SIMPLE ] [ ON DELETE action ] [ ON UPDATE action ] } [ DEFERRABLE NOT DEFERRABLE ] [ INITIALLY DEFERRED INITIALLY IMMEDIATE ] Nas cláusulas UNIQUE e PRIMARY KEY, índex_parameters corresponde ainda a: [ WITH ( storage_parameter [= value] [,... ] ) ] [ USING INDEX TABLESPACE tablespace ] Em seguida abordaremos algumas das cláusulas que nos parecem mais úteis e importantes. Uma delas é a cláusula UNIQUE que permite criar uma restrição que obriga a que uma determinada coluna ou um conjunto de colunas só suportem valores únicos (pelo que a inserção de um valor repetido é detectada, e rejeitada). Outra propriedade interessante é a possibilidade de herança de colunas de outras tabelas sendo que são suportadas duas abordagens distintas: cópia, e apontador. A primeira é feita através da cláusula LIKE onde as colunas de determinada tabela são simplesmente copiadas (juntamente com as restrições, tipos e propriedades associadas). A segunda é conseguida com o uso da cláusula INHERITS que, não só copia as colunas das outras tabelas tal como a primeira, como garante que alterações na definição dessas colunas são propagadas para as colunas da tabela a ser criada. Por outro lado, todas as colunas das tabelas, por defeito, tomam o valor null se este for permitido. No entanto, pode ser utilizada a cláusula DEFAULT que atribui por defeito um valor definido aquando da declaração da tabela ou ainda, de forma mais sofisticada, um valor retirado de uma determinada sequência previamente declarada. O exemplo seguinte mostra os vários tipos de aplicações desta cláusula: CREATE TABLE countries ( name varchar(40) DEFAULT 'Portugal', id integer DEFAULT nextval('people_id_sequence'), time timestamp DEFAULT current_timestamp ); O PostgreSQL suporta ainda outro tipo de criação de tabela, através de subqueries. Para isso é usado o comando CREATE TABLE AS que, tal como o nome indica, cria uma tabela que é construída através do resultado de uma determinada pesquisa (que pode ser feita numa ou mais tabelas): CREATE [ [ GLOBAL LOCAL ] { TEMPORARY TEMP } ] TABLE table_name [ (column_name [,...] ) ] [WITH(storage_parameter[=value][,...]) WITH OIDS WITHOUT OIDS] [ ON COMMIT { PRESERVE ROWS DELETE ROWS DROP } ] [ TABLESPACE tablespace ] AS query [ WITH [ NO ] DATA ] 9

10 Alterações de Tabelas O PostgreSQL permite inúmeros tipos de alterações de tabelas, desde renomeações da própria tabela ou de colunas, alterações nos tipos e restrições de cada coluna, até mesmo à criação ou remoção de uma coluna. Observando as seguintes sintaxes, percebemos que a alteração de dados é conseguida de forma perceptível e trivial: ALTER TABLE [ ONLY ] name [ * ] action [,... ] ALTER TABLE [ ONLY ] name [ * ] RENAME [ COLUMN ] column TO new_column ALTER TABLE name RENAME TO new_name ALTER TABLE name SET SCHEMA new_schema Sendo que o parâmetro action corresponde a: ADD [ COLUMN ] column type [ column_constraint [... ] ] DROP [ COLUMN ] column [ RESTRICT CASCADE ] ALTER [ COLUMN ] column [ SET DATA ] TYPE type [ USING expression] ALTER [ COLUMN ] column SET DEFAULT expression ALTER [ COLUMN ] column DROP DEFAULT ALTER [ COLUMN ] column { SET DROP } NOT NULL ALTER [ COLUMN ] column SET STATISTICS integer ALTER [ COLUMN ] column SET STORAGE {PLAIN EXTERNAL EXTENDED MAIN} ADD table_constraint DROP CONSTRAINT constraint_name [ RESTRICT CASCADE ] DISABLE TRIGGER [ trigger_name ALL USER ] ENABLE TRIGGER [ trigger_name ALL USER ] ENABLE REPLICA TRIGGER trigger_name ENABLE ALWAYS TRIGGER trigger_name DISABLE RULE rewrite_rule_name ENABLE RULE rewrite_rule_name ENABLE REPLICA RULE rewrite_rule_name ENABLE ALWAYS RULE rewrite_rule_name CLUSTER ON index_name SET WITHOUT CLUSTER SET WITH OIDS SET WITHOUT OIDS SET ( storage_parameter = value [,... ] ) RESET ( storage_parameter [,... ] ) INHERIT parent_table NO INHERIT parent_table OWNER TO new_owner SET TABLESPACE new_tablespace Remoção de Tabelas A remoção de uma tabela é bastante simples, permitindo apenas propagar ou não essa remoção para objectos dependentes da mesma, recusar a operação caso existam 10

11 dependências entre esta tabela e outros objectos, ou ainda evitar o lançamento de um erro no caso de não haver qualquer tabela com o nome referido: DROP TABLE [ IF EXISTS ] name [,...] [ CASCADE RESTRICT ] Note-se que este comando não se limita a remover apenas os dados de uma tabela, destruindo a sua estrutura também. Se o utilizador pretender esvaziar uma tabela poderá usar o comando TRUNCATE que automaticamente eliminará todos os tuplos pertencentes àquela tabela mantendo, no entanto, a sua estrutura Criação de triggers Um trigger corresponde à definição de uma acção cuja iniciação é desencadeada por um determinado evento definido na criação do próprio trigger. Entre as várias utilidades dos triggers podem-se destacar a criação de mecanismos de validação que envolvem pesquisa em mais que uma tabela, inserção de dados de uma coluna através da combinação de outras, actualização de tabelas aquando da alteração de outra, criação de logs e registos de criações ou alterações de utilizadores, etc. A criação de um trigger é feita da seguinte forma: CREATE TRIGGER name { BEFORE AFTER } { event [ OR... ] } ON table [ FOR [ EACH ] { ROW STATEMENT } ] EXECUTE PROCEDURE funcname ( arguments ) Com este comando, é criado um trigger de nome name, que vai executar a função funcname quando for detectado o evento event na tabela table. De frisar que o nome do trigger tem de ser único já que este nome representa um identificador do mesmo, permitindo posteriormente que este possa ser removido através do seu nome. As cláusulas BEFORE e AFTER permitem executar a função referida antes ou depois do evento. Isto permite, por exemplo, fazer validações antes de uma inserção e inserir dados em tabelas depois de uma ter sido actualizada. A opção FOR EACH ROW permite executar a função para cada linha alterada/inserida/removida enquanto, por contraste, FOR EACH STATEMENT executa a função para cada operação efectuada (mesmo que essa operação não chegue de facto a modificar nenhuma linha da tabela. Note-se que neste capítulo temos uma funcionalidade bastante útil do SQL que não é implementada pelo PostgreSQL: INSTEAD OF. Esta é usada em vez das cláusulas AFTER e BEFORE, e permite efectuar uma operação em vez de uma outra que constitui o evento. Isto permite, por exemplo, depois da criação de uma view que é obtida através da fusão de duas tabelas, dizer que quando o utilizador tenta inserir na view, o sistema de bases de dados, em vez disso, insere directamente nas duas tabelas. Apesar de não fazer parte da criação de triggers, esta operação pode ser feita através da criação de uma regra (referido mais à frente) Remoção de triggers Tal como aconteceu com a remoção de tabelas, a sintaxe da remoção de triggers também é bastante simples: 11

12 DROP TRIGGER [ IF EXISTS ] name ON table [ CASCADE RESTRICT ] Este comando permite remover o trigger de nome name aplicado à tabela table. Mais uma vez, é usada a cláusula IF EXISTS que evita que um erro seja lançado caso estejamos a tentar remover um trigger não existe (recebendo assim apenas um aviso). Para além disso, as cláusulas CASCADE e RESTRICT permitem, respectivamente, remover todos os objectos que dependerem deste trigger, e anular esta operação caso isso aconteça Criação de Regras Embora muitas vezes se considere que regras e triggers são exactamente a mesma coisa, isso não é verdade. Por exemplo, um trigger, ao contrário de uma regra, não funciona se for criado numa table view já que a informação que aparenta estar nessa, está de facto espalhada em tabelas, pelo que o trigger não consegue aceder a esses dados. Por outro lado, não é possível criar algum tipo de restrições tais como foreign keys com regras, sendo que o mesmo já possível com triggers. Percebido isto, a sintaxe da criação de regras é a seguinte: CREATE [OR REPLACE] RULE name AS ON event TO table[ WHERE condition ] DO[ ALSO INSTEAD ] {NOTHING command (command ; command... )} Este comando cria uma regra de nome name na tabela table que, executa um determinado comando em vez de (INSTEAD), ou para além de (ALSO) executar um determinado evento event, caso a condição condition se verifique. Note-se que, combinando as cláusulas NOTHING e INSTEAD, pode-se implementar uma regra que, por exemplo, anula a inserção de certos dados se estes não satisfizerem uma determinada condição. Note-se também que esta definição de regra permite que, quando detectado o evento referido, pode não ser executado nada (NOTHING), pode ser executado um comando command, ou pode ainda ser executada uma lista de comandos separados por ; Remoção de Regras A sintaxe da remoção de regras é idêntica à remoção de triggers ou mesmo de tabelas: DROP RULE [ IF EXISTS ] name ON relation [ CASCADE RESTRICT ] As cláusulas IF EXISTS, CASCADE e RESTRICT, já foram apresentadas anteriormente pelo que não haverá necessidade de tornar a fazê-lo, sob pena de ter redundância de informação Informação Adicional Não foi encontrada qualquer informação sobre implementação de assertions em PostgreSQL pelo que se assume que este Sistema de Gestão de Base de Dados não implementa esse tipo de operações. O único tipo de assertions permitido é usado para efeitos de debugging, nas seguintes situações: 12

13 Execução do comando postgres (utilizado para correr o servidor) Configuração do servidor Note-se também que não foram abordados os comandos DDL respectivos à criação de estruturas de dados em índices, já que isto irá ser abordado na secção 4 (Indexação e Hashing) Cobertura DML O DML (Data Manipulation Language) define, por oposição ao DDL, os comandos responsáveis pela modificação, remoção, inserção, recuperação e inclusão de informações em bases de dados, ou seja, em tudo o que é relativo aos dados em si. Os quatro comandos que serão abordados nesta secção, e que correspondem aos quatro comandos DML mais importantes, são: Select utilizado para seleccionar dados Insert utilizado para introduzir novos dados Update utilizado para alterar dados Delete utilizado para remover dados Selecções de dados A selecção de dados tem-se tornado cada vez mais complexa, sendo que o utilizador pode optar por inúmeras opções, que permitem agrupar os dados, filtrando-os através de restrições, combinar várias tabelas e views, etc. A sintaxe do comando SELECT é a seguinte: [ WITH [ RECURSIVE ] with_query [,...] ] SELECT [ ALL DISTINCT [ON(expression [,...]) ]] * expression [ [ AS ] output_name ] [,...] [ FROM from_item [,...] ] [ WHERE condition ] [ GROUP BY expression [,...] ] [ HAVING condition [,...] ] [ WINDOW window_name AS ( window_definition ) [,...] ] [ { UNION INTERSECT EXCEPT } [ ALL ] select ] [ ORDER BY expression [ASC DESC USING operator ] [ NULLS { FIRST LAST } ] [,...] ] [ LIMIT { count ALL } ] [ OFFSET start [ ROW ROWS ] ] [ FETCH { FIRST NEXT } [ count ] { ROW ROWS } ONLY ] [ FOR {UPDATE SHARE}[OF table_name[,...] ][NOWAIT][...]] Sendo que from_item corresponde a: 13

14 [ ONLY ] table_name [ * ] [ [ AS ] alias [ ( column_alias [,...] ) ] ] ( select ) [ AS ] alias [ ( column_alias [,...] ) ] with_query_name [ [ AS ] alias [ ( column_alias [,...] )]] function_name ( [ argument [,...] ] ) [ AS ] alias [ ( column_alias [,...] column_definition [,...] ) ] function_name ( [ argument [,...] ] ) AS ( column_definition [,...] ) from_item [ NATURAL ]join_type from_item[ ON join_condition USING ( join_column [,...] )] Como muitas vezes temos selecções de colunas com o mesmo nome de tabelas diferentes, podemos fazer renomeação com o parâmetro with_query que corresponde a: with_query_name [ ( column_name [,...] ) ] AS ( select ) TABLE { [ ONLY ] table_name [ * ] with_query_name } Uma das cláusulas interessantes é a cláusula WITH que permite definir subperguntas que poderão ser posteriormente usadas na selecção principal. Isto permite simplificar a leitura deste comando, e permite que uma subpergunta seja usada mais que uma vez sem que para isso seja preciso repetir código. Outra cláusula bastante útil é a DISTINCT que permite filtrar duplicados de forma a obter tuplos únicos duma selecção. Para além de possibilitar limitar, ordenar e agrupar os dados, a selecção de dados ainda permite fazer uniões, intercepções e filtragens através das cláusulas UNION, INTERSECT e EXCEPT respectivamente. Estas cláusulas aumentam, por essa razão, a expressividade das perguntas, podendo-se relacionar inúmeras tabelas Inserção de dados O método mais conhecido de inserção de dados no SQL é o método INSERT. A sua sintaxe é a seguinte: INSERT INTO table [ ( column [,...] ) ] { DEFAULT VALUES VALUES ({ expression DEFAULT } [,...]) [,...] query } [ RETURNING * output_expression[[ AS ]output_name][,...]] Basicamente, este método insere na tabela table a sequência de valores definida em VALUES (cujos valores estão separados por virgulas). Se por defeito VALUES tem de definir e instanciar todos os atributos de uma tabela, o mesmo não se passa se definirmos em column um conjunto de atributos que serão afectados (os outros serão introduzidos a null ou com o valor default definido). 14

15 Note-se ainda que podem ser introduzidos dados através de uma pergunta a outras tabelas com o parâmetro query, ou com o seu valor default com a cláusula DEFAULT. Pode ainda ser retornado um output que pode ser um valor fixo, ou uma expressão envolvendo as colunas usadas, através da cláusula RETURNING. O resultado da utilização desta é idêntico, por isso, ao resultado de uma selecção. A inserção de dados pode ser feita no entanto, com outro método: COPY. Este método permite a utilização de dados de um determinado ficheiro, para serem introduzidos numa tabela tornando a inserção mais rápida e simples para o utilizador. A sintaxe deste método é: COPY tablename [ ( column [,...] ) ] FROM { 'filename' STDIN } [ [ WITH ] [ BINARY ] [ OIDS ] [ DELIMITER [ AS ] 'delimiter' ] [ NULL [ AS ] 'null string' ] [ CSV [ HEADER ] [ QUOTE [ AS ] 'quote' ] [ ESCAPE [ AS ] 'escape' ] [ FORCE NOT NULL column [,...] ] Note-se que este método permite fazer a operação inversa, ou seja, seleccionar dados de uma tabela para um ficheiro, com uma sintaxe muito parecida, alterando a cláusula FROM para TO Remoção de dados A remoção de dados é feita através do comando DELETE FROM, de forma bastante simples, sendo que a sua sintaxe é a seguinte: DELETE FROM [ ONLY ] table [ [ AS ] alias ] [ USING usinglist ] [ WHERE condition WHERE CURRENT OF cursor_name ] [ RETURNING * output_expression[[ AS ] output_name ][,...]] Este método elimina todos os tuplos da tabela table que satisfaçam a condição condition. Note-se que se não for usada a cláusula WHERE, então serão eliminados todos os tuplos da tabela, sendo que o resultado seria igual ao produzido pela execução do comando TRUNCATE anteriormente referido. De notar ainda que a cláusula RETURNING é idêntica à mesma no método de inserção de dados, e que a cláusula USING permite usar múltiplas tabelas na cláusula WHERE ou seja, a condição de eliminação de tuplos pode ser mais complexa, envolvendo outras tabelas. 15

16 Actualização de dados Finalmente, para actualizar os dados de uma tabela, o postgresql utiliza o comando UPDATE cuja sintaxe é a seguinte: UPDATE [ ONLY ] table [ [ AS ] alias ] SET { column = { expression DEFAULT } (column [,...]) = ({expression DEFAULT}[,...])} [,...] [ FROM fromlist ] [ WHERE condition WHERE CURRENT OF cursor_name ] [ RETURNING * output_expression[[ AS ] output_name][,...]] Este comando permite alterar todos os dados que satisfaçam uma condição condition duma tabela table, alterando os atributos indicados na cláusula SET. Naturalmente, todos os valores dos atributos não mencionados nessa cláusula serão mantidos. Mais uma vez, DEFAULT permite instanciar um atributo com o seu valor por defeito, enquanto o parâmetro fromlist permite definir nomes de outras tabelas que poderão ser usados na cláusula WHERE tal como na remoção de dados. Note-se ainda que quer esta operação, quer a operação de remoção de dados, permitem o uso de cursores, permitindo operações mais complexas. 16

17 3. Armazenamento e file structure 3.1. File System O PostgreSQL utiliza, para guardar os dados, o sistema de ficheiros do sistema operativo. Todas as bases de dados criadas encontram-se guardada na directoria /data/base divididas por pastas, ou seja, cada base de dados está contida numa pasta cujo nome é um identificador único. A lista de Bases de Dados / Identificadores pode ser consultada no ficheiro pg_database. As tabelas podem ter vários GB de tamanho, sendo que a partir de 1GB são divididas em segmentos de 1GB (este é o valor default e pode ser alterado) e que são identificados pelo identificador do seu filenode. Se uma tabela estiver dividida em vários segmentos os nomes serão filenode1, filenode2, etc. Caso uma tabela tenha campos muito grandes ser-lhe-á associada ainda uma tabela TOAST. O PostgreSQL usa páginas de tamanho fixo, geralmente 8kb, e não permite que um tuplo se divida por mais que uma página. O TOAST (The Oversized-Attribute Storage Technique) ajuda a resolver este problema comprimindo ou dividindo um tuplo em várias linhas. Isto é totalmente transparente para o utilizador e não causa grandes transtornos a nível de código. Obviamente o TOAST só pode ser utilizado em tipos que possam atingir valores grandes, em termos de espaço. Os ficheiros temporários encontram-se guardados numa pasta aparte, /data/base/pgsql_tmp Paginação Como já foi referido acima, o PostgreSQL utiliza tipicamente páginas de 8KB. Tanto as tabelas como os índices estão guardados em arrays de páginas, isto é, cada tabela corresponderá a uma posição do array. Os tuplos estão guardados num Heap (HeapTupleHeaderData) Partições É possível particionar tabelas no PostgreSQL, isto é, dividir as tabelas em várias 'partes' a um nível físico, de modo a melhorar o desenho da base de dados. Particionar os dados pode trazer vários benefícios, por exemplo, se uma grande percentagem das pesquisas forem efectuadas sobre um conjunto de dados, e esses dados estiverem separados numa partição, as pesquisas serão bem mais eficientes. Outra vantagem importante é a de podermos guardar informação pouco acedida em dispositivos de armazenamento mais lento e mais barato. O particionamento é implementado por herança, isto é, todas as partições são 'filhos' de uma 'tabela-pai', que geralmente se encontra vazia. O PostgreSQL permite a uso de Range Partitioning (por gamas de valores) e List Partitioning (indicando explicitamente que valores entram em que partições). Para criar partições é necessário criar a tabela principal e de seguida as 'tabelasfilho', que serão as partições. Em seguida podemos definir os valores que poderão existir em qualquer partição. Por exemplo para definir que uma partição conterá os valores do atributo x que tenham o valor 1, fazemos CHECK (x = 1). É possível ainda criar índices para cada tabela, o que é bastante aconselhável, e também triggers de 17

18 inserção, para quando um valor é inserido na tabela principal ser direccionado para a sua partição. Por fim, convém verificar se o parâmetro constraint_exclusion no ficheiro postgresql.conf, de modo a optimizar as pesquisas Clustering O conceito de cluster em bases de dados consiste na aglomeração de dados em determinados pontos contíguos dos dispositivos de armazenamento. A grande vantagem desta técnica é poupar acessos e leituras de disco. Supondo que queremos encontrar todos os tuplos de uma tabela cujo atributo x é maior que 100, ao encontrar o primeiro tuplo, caso estes se encontrem ordenados, basta continuar a ler os seguintes blocos. O PostgreSQL implementa esta técnica através do comando CLUSTER. Exemplo: CLUSTER country USING code; 3.5. Buffer Management O PostgreSQL está, em grande parte, dependente do sistema operativo. Apenas usa buffers para fazer a transição dos dados entre o disco rígido e o backend do sistema, isto é, servindo como cache. Assim, quando um processo precisa de um bloco de disco, este será guardado num buffer. Se ao ser efectuado um pedido, o bloco se encontrar na cache, é marcado como pinned, isto é, mais nenhum processo o poderá usar, caso contrário será preciso encontrar um buffer para guardar o bloco. Esta selecção é feita através de clock sweep que, basicamente, trata a cache como uma lista circular, percorrendo-a à procura de blocos disponíveis. Um bloco não está disponível quando está a ser referenciado por algum processo. 18

19 4. Indexação e Hashing 4.1. Introdução Os índices são usados em bases de dados para facilitar o acesso às tabelas, aumentando a rapidez das queries, tal como o objectivo de um índice num livro. Consoante o Sistema de Gestão de Base de Dados, os índices podem ser criados em função de um ou mais atributos ou mesmo em função de uma determinada expressão, e podem ser guardados em diferentes estruturas de dados. Sendo o PostgreSQL um SGBD bastante completo, implementa inúmeras opções de tipos de índices nomeadamente variadas estruturas de dados, índices multi-coluna ou mesmo indexação múltipla. Depois de criado um índice, o administrador não tem de ter mais intervenções, sendo que o próprio sistema irá manter o índex actualizado (sempre que a tabela é alterada), e irá usar o índice sempre que achar que a sua utilização irá melhorar o desempenho da query. Devido a esta autonomia do sistema, o uso de índices deve ser bastante cuidadoso para que não sejam criados índices que tragam computações desnecessárias relativas à manutenção dos mesmos que acabam por não ser aproveitados. Note-se que o uso inapropriado de um índice pode baixar a performance de um sistema. O sistema utiliza ou não os índices consoante a análise de estatísticas de acesso guardadas pelo próprio, pelo que esporadicamente deve-se correr o comando ANALYSE que permite a actualização dessas mesmas estatísticas. A sintaxe deste comando é: ANALYZE [ VERBOSE ] [ table [ ( column [,...] ) ] ] Enquanto o parâmetro verbose permite a observação deste comando através de mensagens de progresso, os parâmetros table e column permitem restringir as estatísticas produzidas à análise da tabela e colunas correspondentes. Visto isto, passaremos então à sintaxe da criação e remoção de um índice. O comando de criação de um índice veio-se a alterar ao longo das versões tendo cada vez mais parâmetros, oferecendo também cada vez mais opções e possibilidades. A sintaxe deste comando da versão do PostgreSQL é a seguinte: CREATE[ UNIQUE ] INDEX [ CONCURRENTLY ] name ON table [ USING method ] ({ column ( expression ) } [ opclass ] [ ASC DESC ] [ NULLS { FIRST LAST } ] [,...] ) [ WITH ( storage_parameter = value [,... ] ) ] [ TABLESPACE tablespace ] [ WHERE predicate ] Este comando irá criar um índice de nome name na tabela especificada pelo parâmetro table, implementado na estrutura de dados method (árvore B+ por defeito). A chave do índice (atributo pelo qual um tuplo é identificado), corresponde ao conjunto de colunas da tabela identificadas em column ou ainda através duma expressão identificada entre parênteses, expression, que corresponde a uma função de um ou mais atributos da 19

20 tabela. O PostgreSQL suporta índices múlti-coluna (com chaves compostas por vários atributos) desde que a estrutura de dados o permita, sendo que para isso basta identificar as várias colunas separadas por vírgulas, tal como mostra o seguinte exemplo: CREATE INDEX index_name ON table (col1, col2); Se na criação do índice for usada a cláusula UNIQUE então o sistema vai garantir que todos os tuplos da tabela têm uma key única, sendo que isto também é verificado aquando da inserção e alteração de um tuplo. Por outro lado, a cláusula CONCURRENTLY permite criar um índice sem que o sistema bloqueie quaisquer alterações ou inserções que aconteçam durante a sua criação (como aconteceria por defeito). Os parâmetros asc, desc, nulls first, nulls last, entre outros, limitam-se a especificar a ordem pela qual os nós serão apresentados no índice. A cláusula WITH permite definir opções de armazenamento (storage_parameter) do índice, sendo que cada estrutura de dados (method) pode ter o seu conjunto de opções permitidas. As estruturas de dados B-tree, Gist e hash aceitam um único parâmetro, FILLFACTOR, que corresponde ao grau de ocupação das páginas de indexação, enquanto os índices Gin utilizam o parâmetro booleano FASTUPDATE cujo valor por defeito é a true. Por fim, a cláusula WHERE permite criar um índice parcial. Um índice parcial é um índice que, em vez de indexar todas os tuplos de uma tabela, indexa apenas os tuplos que satisfaçam uma determinada condição (predicate). Note-se portanto que a introdução desta cláusula nunca poderá aumentar o tamanho do índice tendo tendência a diminui-lo. Actualmente não são permitidas subqueries e agregações nem na cláusula WHERE nem mesmo nos atributos que são expressões (expression). A sintaxe da remoção de um índice é bastante mais simples e intuitiva: DROP INDEX [ IF EXISTS ] name [,...] [ CASCADE RESTRICT ] A cláusula IF EXISTS evita que o sistema lance uma excepção no caso de não existir nenhum índice com o nome indicado, enquanto as cláusulas CASCADE e RESTRICT especificam diferentes tipos de abordagens no caso de existirem dependências em relação ao índice em questão. Enquanto a primeira elimina para além do índice, todos os objectos que dependiam deste, a segunda recusa-se a remover o índice se existir um ou mais objectos dependentes do mesmo Tipos de Índices O PostgreSQL suporta quatro tipos de estruturas de dados, para guardar os índices: BTree, HASH, GIST e GIN. Cada uma optimiza um determinado tipo de pesquisas, pelo que a estrutura de dados usada por defeito é a Btree, já que é a mais promissora na maioria dos tipos de pesquisa mais frequentes. 20

21 Btree Em primeiro deve-se focar que, apesar do nome geralmente utilizado ser Btree, quando se fala neste tipo de árvores neste contexto refere-se, na verdade, a outro tipo de árvores ligeiramente mais complexas de nome B+ Tree ou BplusTree. Uma árvore B+, ao contrário de um Btree normal, guarda a totalidade dos dados no último nível, ou seja, nas folhas. Estas folhas estão ligadas entre si, estabelecendo uma lista ligada. Uma das propriedades que faz com que esta estrutura de dados seja bastante útil para guardar índices, é o facto de cada nó que não é folha ter entre n+1 e n filhos (excepto a raiz da árvore). Isto faz com que a árvore B+ não tenha muitos níveis fazendo com que a consulta de dados atinja rapidamente o nível das folhas (dados) fazendo o mínimo de seek s no disco possíveis. O PostgreSQL usa o algoritmo de Lehman e Yao para criar e gerir este tipo de árvore que, devido à sua implementação, fazem com que a indexação com este tipo de estrutura de dados seja mais eficaz em pesquisas que usam igualdades. A figura seguinte representa uma possível instância exemplificativa deste tipo de estrutura de dados: 2 Figura 3 Exemplo de uma instância de uma árvore B Hash Os índices baseados em estruturas de dados e funções de Hash acabam por ser limitativos já que só suportam comparações simples de igualdades. O algoritmo de Hashing usado pelo PostgreSQL foi desenvolvido por W. Litwin para sistemas baseados em discos com um processador. Este hashing é dinâmico, e não tem qualquer tipo de rehashing que permita a eliminação dos buckets de overflow, diminuindo também o número de seeks do disco. O algoritmo de W.Litwin efectua a divisão de buckets por ordem (primeiro o bucket 0, depois o bucket 1, etc.) em vez de dividir o bucket que excedeu a capacidade, se bem que essa divisão é efectuada quando um bucket qualquer excede a capacidade. Como possivelmente este último bucket não é o bucket que foi dividido, então podem-se aplicar técnicas de overflow. Como a indexação não é melhor que a indexação com árvores B+ (que também suportam as comparações de igualdade), utilizando mais recursos do sistema que a segunda, o uso deste tipo de indexação é actualmente desencorajado. Para além disto, o Hash é o único method do PostgreSQL que não suporta índices de múltiplas colunas. De qualquer forma, para criar um índice com esta estrutura de dados utiliza-se o seguinte comando: CREATE INDEX nome_index ON nome_tabela USING hash (nome_coluna); 21

22 Note-se finalmente que o PostgreSQL só implementa hashing a nível da indexação, não implementando hashing de dados Gist Os índices Gist (Generalized Search Tree) não são um tipo específico de estruturas de dados, constituindo uma abstracção ou interface que pode ser utilizada para a implementação de vários tipos de árvores tais como B+ trees, R-trees, hb-trees, RD-trees. Os operadores particulares de cada índice GIST podem variar bastante consoante a estratégia de indexação (opclass no método CREATE INDEX). O PostgreSQL tem, por defeito, inúmeras classes de operadores GIST específicas para tipos de dados geométricos bidimensionais. Para a criação de um índice GIST têm de ser definidas as classes de operadores, incluindo operadores de comparação e estratégias de pesquisa. Depois de criados, os nomes destes operadores têm de ser incluídos na função CREATE INDEX. Devido à complexidade e pouca relevância deste procedimento, não será apresentada a sintaxe da criação deste índice Gin Os índices GIN suportam uma indexação invertida que permite o uso de chaves múltiplas, identificadas através de um array. Tal como o Gist, suporta que o utilizador utilize várias estratégias de indexação, com os seus operadores específicos. Porém, ao contrário do primeiro, o GIN por defeito inclui classes de operadores para arrays de apenas uma dimensão. A sintaxe da criação deste tipo de índices não será apresentada pela mesma razão que a dos índices GIST Índices para organização de ficheiros A organização de ficheiros em PostgreSQL é feita em Heap, sem que haja nenhum sistema de clustering automático. Em vez disso, o sistema fornece um comando que permite reorganizar os dados de uma determinada tabela de acordo com um índice previamente criado. A sintaxe deste comando é a seguinte: CLUSTER [VERBOSE] tablename [ USING indexname ] Este comando reestrutura os dados da tabela tabelaname podendo, para isso, usar o índice indexname através da cláusula USING. A cláusula VERBOSE permite obter informação sobre o clustering de cada tabela. Como este comando cria uma cópia temporária dos dados (quer da tabela quer do índice) para fazer a operação, é necessário ter espaço de disco livre equivalente ou superior ao espaço ocupado por ambos. Importante realçar que este comando é uma operação que se limita a reorganizar o ficheiro num determinado instante, não sendo responsável pela manutenção desta estrutura (se houver alterações ou inserções de dados, estes serão colocados em qualquer espaço livre do ficheiro mantendo a organização em Heap). Para além deste comando, o parâmetro de armazenamento FILLFACTOR, já abordado anteriormente, pode também ser usado para reajustar os dados periodicamente de forma automática, aquando da alteração dos dados (se o seu valor for inferior a 100%). 22

23 Como foi referido anteriormente, o sistema vai tomando opções (por exemplo na optimização de perguntas) baseado em estatísticas produzidas ao longo do tempo. Assim, é aconselhado que, depois de executar o comando CLUSTER, se execute o comando ANALYSE forçando a actualização das estatísticas, ou o sistema poderá tomar decisões erradas com base em informação desactualizada. Para terminar, a documentação do PostgreSQL refere ainda um possível atalho na organização de ficheiros com índices de ordenação, podendo obter o mesmo resultado de forma mais rápida. Em vez de usarmos um índice para ordenar uma tabela, este procedimento rudimentar passa por criar uma tabela idêntica usando a cláusula ORDERBY da selecção: CREATE TABLE newtable AS SELECT * FROM table ORDER BY columnlist; De seguida seria apenas remover a tabela antiga e alterar o nome da nova. No entanto, esta solução não é prática, ou mesmo viável apesar de poder ser mais eficiente. 23

24 4.4. Outras Informações Múltiplos ficheiros de índices para os mesmos atributos Uma das questões abordadas no enunciado é a possibilidade de serem criados vários ficheiros de índices para o mesmo conjunto de atributos, implementados ou não nas mesmas estruturas de dados. O PostgreSQL não tem qualquer tipo de restrição no número de índices por tabela, ou por conjunto de atributos. Para demonstrar o referido anteriormente, o exemplo seguinte mostra a criação de dois índices semelhantes sobre o mesmo atributo: Figura 4 Criação de dois ficheiros de índex idênticos, para o mesmo conjunto de atributos Bitmap (Combinação de múltiplos índices) Como pôde ser observado na sessão 4.2 (tipos de índices), o PostgreSQL não implementa qualquer tipo de índice em Bitmaps. Em vez disso, o PostgreSQL só utiliza bitmaps em duas situações: valores nulls, e combinação de múltiplos índices. A primeira consiste na criação automática de um bitmap para cada atributo de cada tabela, desde que estes não tenham já uma imposição not null (especificada directamente, pelo facto de serem chaves primárias, etc). Cada bitmap consiste assim, numa lista de bits que tomam o valor 0 se o atributo for nulo nesse tuplo, e o valor 1 caso contrário. O PostgreSQL utiliza ainda bitmaps para combinar múltiplos índices numa determinada pesquisa. Se por um lado um índice sobre os atributos (at1, at2) pode ser usado numa pergunta do estilo WHERE at1 = V1 AND at2 = V2, por outro lado se em vez de uma conjunção, tivermos uma disjunção, o uso deste índice será desnecessário e contraproducente. Para tratar destas e de outras situações, o PostgreSQL suporta utilização de múltiplos índices, sendo que para cada um é criado um bitmap cujos bits representam o resultado de uma sub-condição. No exemplo anterior da disjunção, seria criado um bitmap com o resultado de at1 = V1 e outro para at2 = V2. Depois, a operação lógica é aplicada aos bitmaps independentemente de ser uma conjunção, disjunção, negação, XOR, etc. Só no final é que as tabelas são de facto visitadas e retornadas pelo que este processo se torna bastante eficiente. No caso da disjunção referida anteriormente, seriam seleccionados os tuplos que tivessem pelo menos uma célula do bitmap de valor 1. 24

25 Estruturas temporariamente inconsistentes para lidar com verificação diferida de restrições de integridade O PostgreSQL permite que os tipos de índices abordados anteriormente fiquem inconsistentes temporariamente através da cláusula DEFERRED aplicada a restrições) nos comandos CREATE e ALTER TABLE. Constituindo este facto uma necessidade para algumas operações no âmbito das transaccoes, este tópico será abordado mais à frente na secção 6.9 ( Diferir a verificação para o final das transacções ). 25

26 5. Processamento e Optimização de Perguntas Esta secção de processamento e optimização de perguntas pode ser uma ferramenta muito forte num sistema de gestão de bases de dados. Através desta ferramenta, podem-se determinar os modos mais eficazes de executar determinada pergunta ao sistema. O optimizador do sistema verifica os planos de execução possíveis dada uma pergunta, e tenta descobrir qual o plano mais eficaz para a pergunta dada. Estes custos são utilizados para estimar o custo de avaliação de uma pergunta, em termos de operações I/O pretendidas, requisitos de CPU e outros factores. Em geral não é possível aceder-se directamente a este optimizador, sendo que em alguns sistemas de gestão de bases de dados o permitem, através da utilização de hints. No PostgreSQL, não é possível utilizar explicitamente estes hints. O que é possível fazer é, alterando certos parâmetros no ficheiro de configuração do PostgreSQL, (posgresql.conf), autorizar ou impedir a utilização de certos algoritmos. Porém, podem existir situações em que, mesmo estando o algoritmo desactivado, este é utilizado na mesma. Para esta questão, é importante compreender um pouco melhor o caminho percorrido por uma interrogação ao sistema. Na imagem seguinte apresenta-se um esquema da questão referida, numa situação geral: Figura 5 - Percurso de uma interrogação ao sistema Como se pode observar, uma pergunta passa por vários passos antes de ser efectivamente executada Percurso de Uma Interrogação Na imagem anterior, explicava-se no caso geral o percurso de uma pergunta no sistema. Nesta secção vamos ver de forma mais aprofundada esta questão. No PostgreSQL, uma pergunta passa pelos seguintes passos: 1 Estabelece-se uma ligação da aplicação para um servidor do PostgreSQL. A aplicação transmite a pergunta e espera por uma resposta por parte deste. 26

27 2 O parser verifica que a pergunta está correcta (a nível de sintaxe) e cria uma query tree. 3 - O rewrite system pega nesta árvore criada e verifica se existe alguma regra a aplicar nesta árvore. 4 O planificador/optimizador do sistema pega na árvore reescrita e cria um plano de execução que servirá de input para o executador. 5 O executor pega nestes dados e executa-os retornando os tuplos na forma representada na árvore. O executor usa o storage system enquanto percorre relações, executando sorts e joins, avaliando qualifications e retornando os resultados pretendidos. PARSER Optimizador Transformações Procura o Plano de Execução Compila o Plano de Execução Execução Retorno dos Dados Figura 6 - Figura Representativa do Esquema de Vida de um Pergunta 5.2. Ligação ao Servidor As ligações ao servidor são estabelecidas utilizando um mecanismo de processo por utilizador, através de um modelo cliente/servidor. Neste modelo, um processo de um cliente está ligado a um, e só um, servidor. É necessário ter um servidor mestre que cria um novo processo de servidor. Este servidor é chamado postgres e recebe pedidos numa porta específica de TCP/IP Etapa de Parsing Parser O parser numa primeira fase, recebe a pergunta, uma String (em texto ASCII), e verifica a sua validade a nível de sintaxe. Se esta for correcta, gera-se uma parse tree. Caso contrário, é retornada uma mensagem de erro. 27

28 O lexer esta definido no ficheiro scan.l e é responsável por reconhecer identificadores, SQL key words. etc... Para cada key word ou identificador encontrados, um token é gerado e passado para o parser. Este está definido no ficheiro grammar.y e consiste um conjunto de regras de gramática e acções que são executadas quando uma regra é "disparada". O código das acções (escrito em C) é utilizado para construir a árvore. O ficheiro scan.l é transformado para o ficheiro fonte scan.c utilizando o programa lex e o gram.y é transformado em gram.c. Após estas transformações, um compilador normal de C pode ser utilizado para criar o parser Processo de Transformação No processo anterior cria-se uma parse tree usando regras sobre estruturas sintáticas do SQL. Após se utilizar o parser, utiliza-se a árvore gerada e faz uma interpretação semântica necessária para saber que tabelas, funções e operadores estão referenciados na pesquisa. A estrutura de dados criada neste passo é a chamada query tree. Há dois processos de parsing que são necessários. O primeiro só faz sentido em caso de transacções, em que simplesmente identifica palavras como BEGIN, ROLLBACK, etc, podendo estas ser imediatamente executadas sem qualquer análise adicional. Após se saber que se está a lidar com uma interrogação propriamente dita (SELECT ou UPDATE) podemos iniciar a transacção (se não se estiver já dentro de uma). Aqui sim é invocado o processo de transformação. De acordo com a interrogação: select customer_name, balance, from customers where balance > 0 ORDER BY balance a a árvore gerada pode ser a seguinte: Figura 7 Parse Tree gerada para uma determinada query 5.4. Planificador / Optimizador A tarefa do planificador/optimizador é a de criar um plano de execução óptimo. Um interrogação SQL pode ser executada de várias formas diferentes, sendo que cada forma tem custos associados, sendo umas melhores que outras, produzindo-se os mesmos resultados em qualquer um dos casos. Se for possível a nível computacional, o 28

29 planificador/optimizador olha para todas as possibilidades, elegendo a mais vantajosa. Podem haver situações em que verificar todas as possibilidades é muito dispendioso tanto a nível de tempo como de recursos e, por isso, quando o número de joins de uma interrogação ultrapassa um determinado limite, PostgreSQL utiliza uma ferramenta chamada Genetic Query Optimizer por forma a conseguir criar um plano em tempo útil. Em seguida mostra-se um possível plano de execução, no formato de árvore: Figura 8 Exemplo de um plano de execução Geração de Possíveis Planos Os planos criados estão directamente relacionados com os índices disponíveis. Se uma interrogação tiver uma restrição de atributo (cláusula WHERE, pesquisa por um determinado atributo, etc ), e este atributo coincidir com o atributo chave de um índice, é criado um plano de execução para esse índice. Se houve mais índices e/ou mais restrições de atributos, são criados vários planos de execução para cada índice. Criam-se também planos para índices quando as interrogações têm também cláusulas de ordenação (ORDER BY). Um exemplo disto é o caso dos índices B-Tree. Se houver uma pesquisa de ordenação, basta chegar às folhas da árvore e percorre-las. Neste caso, a utilização do índice é útil. Independentemente dos índices utilizados, é sempre criado um índice para pesquisa sequencial, o Seq Scan. Este é sempre criado em qualquer situação. Se a interrogação requer junção de duas ou mais tabelas, planos para a junção de tabelas também são utilizados. Há três planos de junção possíveis (hash join, merge join, nested loop join), como veremos na secção seguinte, relativa à implementação das operações básicas. Quando uma interrogação envolve mais do que duas tabelas, o resultado tem de ser construído a partir de uma árvore de junção de vários passos. O planificador examina as diferentes possibilidades de junção e escolhe a mais barata. Caso a interrogação use menos que um determinado número de tabelas (por defeito é 12), uma pesquisa quase exaustiva é levada a cabo para tentar seleccionar a melhor opção possível. O planificador costuma considerar junções entre tabelas entre as quais existe uma relação de junção com a cláusula WHERE, por exemplo, rel1.attr1=rel2.attr2 como prioritárias. Juntar pares, sem que exista a cláusula 29

30 WHERE sobre os mesmos, só é considerado em último caso. Se o número de tabelas intervenientes numa junção for pequeno, então é possível assumir-se que todas as combinações de junção são analisadas. Mais à frente falaremos dos diferentes tipos de junção que o PostgreSQL tem e como se fazem as junções nestes. Caso a interrogação implique a utilização de mais tabela que o limite considerado, as sequências de junção são determinadas por heurística, utilizando o Genetic Query Optimizer Genetic Query Optimizer De entre as várias operações de uma base de dados, a mais complicada de tratar é sem dúvida a operação de junção. O número de possíveis planos aumenta exponencialmente com o número de tabelas intervenientes no processo. É preciso ainda mais esforço devido aos vários tipos de junção que o PostgreSQL permite (nested loop, hash join, merge join) e pela diversidade de índices. O optimizador realizar uma pesquisa quase exaustiva de todas a combinações possíveis, sendo que quanto maior fosse a pesquisa, mais tempo e mais recursos seriam gastos para fazer esta pesquisa exaustiva. Desta forma, decidiu-se que o ideal para estes casos grandes, era utilizar algoritmos genéticos para ajudar a resolver a situação, sendo que, nem sempre estes retornam a melhor solução possível, mas retornam-na num espaço de tempo muito mais reduzido Executor O executor pega no plano dado pelo planeador e recursivamente processa-o para extrair os tuplos pretendidos. Aqui tem-se essencialmente um mecanismo de demandpull pipelining. Sempre que um nó do plano é chamado, este tem de devolver um ou mais tuplos, ou reportar que já terminou Algoritmos para operações básicas Como se viu anteriormente, a função do planificador é escolher as operações que menos custos têm. Se apenas existisse um algoritmo para cada operação básica, não haveria necessidade da existência do optimizador. Porém, como existem vários algoritmos distintos, cada um deles bom numas situações e maus noutras, é necessário então a intervenção deste optimizador. Em seguida, demonstrar-se-ão os vários tipos de algoritmos possíveis para cada tipo de operação Algoritmos Utilizados a Nível de Selecção Seq Scan este é o algoritmo de pesquisa mais básico. Um query plan para este algoritmo é sempre gerado. Pode não ser o melhor muitas das vezes, mas este é sempre gerado. Tal como o nome indica, o modo de funcionamento do Sequencial Scan passa por percorrer todas as linhas de uma tabela, e, por cada linha, verifica se a condição é respeitada. Repare-se que se a pesquisa for efectuada numa chave primária, quando o algoritmo encontra o tuplo desejado, este pode parar imediatamente. 30

31 Bitmap Scan é um tipo de pesquisa diferente da sequencial. Enquanto este último percorre todas as entradas de uma tabela, o bitmap scan utiliza os diferentes índices criados numa dada tabela para optimizar e aumentar a velocidade de pesquisas mais complexas. Dá uso da indexação múltipla (ver secção Bitmap Combinação de Múltiplos Índices). É de notar que se poder-se-ão realizar bastantes mais seeks, por isso, este apenas deve ser utilizado com um pequeno conjunto de valores. Index Scan o index scan baseia-se numa pesquisa sobre um índice. Se for dado um valor inicial de pesquisa, o index scan apenas começará nesse valor, e se for dado um valor final, o index scan parará nesse valor. Relativamente ao seq scan, apresenta algumas vantagens e desvantagens. A pesquisa sequencial percorre todas as entradas de uma tabela, enquanto uma pesquisa por índice apenas percorre alguns valores (não os percorre todos). Porém, a pesquisa sequencial retorna os valores por ordem de entrada na tabela, e a pesquisa por índice retorna os valores de acordo com a ordem no índice (o que poderá querer dizer que se terão de realizar mais seeks). De seguida apresentaremos um exemplo em que os três diferentes tipos de scan são utilizados, variando apenas a pesquisa introduzida. create table test (a int primary key, b int unique, c int); insert into test values (1,1,1),(2,2,2),(3,3,3),(4,4,4),(5,5,5); explain select * from test where a!= 4 explain select * from test where a = 4 explain select * from test where a = 4 or a=3 31

32 É importante realçar que estes resultados não são os correctos. Em casos de experimentação, é muito importante primeiro utilizar a instrução ANALYZE, actualizando os dados estatísticos. Se executássemos os mesmos comandos após tal, todas as pesquisas utilizariam uma pesquisa sequencial, visto que o número de entradas na tabela é bastante reduzido. TID scan o operador TID Scan é raramente utilizado. Cada tuplo tem um identificador que é único na tabela, que é chamado Tuple ID. É possível fazer-se uma pesquisa pelo ID do tuplo. Existe um atributo especial para cada tabela, que corresponde ao id do tuplo, identificador este denominado por ctid Algoritmos Utilizados a Nível de Ordenação Sort após uma interrogação ter gerado um conjunto de resposta (output table), esta pode opcionalmente ser ordenada. Se tal não for pedido, a tabela será retornada tal como está, sendo que pode não ser o resultado pretendido. Para se ter algo ordenado, é preciso explicitar o comando ORDER BY na interrogação. A sua especificação é a seguinte: SELECT select_list FROM table_expression ORDER BY column1 [ASC DESC] [, column2 [ASC DESC]...] Em cada especificação de coluna, podemos ainda escolher a ordem pela qual queremos ver os resultados, se crescente ou decrescente (ASC, DESC). A ordem crescente está escolhida por defeito. Há duas formas de ordenação possíveis, ordenação em memória e ordenação em disco. Estas opções são escolhidas de acordo com um parâmetro denominado: work_mem(integer), chamado previamente de sort_mem. Isto determina o espaço de memória gasto para se realizar um algoritmo de ordenação. Se o conjunto de resultados tiver um tamanho inferior a work_mem, ordenação em memória será feita através do algoritmo quicksort. Caso contrário, o conjunto de entrada será dividido, ordenando cada parte, procedendo-se depois a uma junção dos vários componentes, utilizando o external merge sort. Em seguida mostramos dois exemplos: no primeiro ordenação em memória é realizado, no segundo, memória em disco. explain analyze select * from country order by name; explain analyze select * from uscensus order by occupation; 32

33 Apesar de em grande parte os algoritmos de ordenação serem chamados através da cláusula ORDER BY, há outras cláusulas de também necessitam destes tipos de algoritmos, tais como: UNIQUE, INTERSECT, UNION ou mesmo EXCEPT. A ordenação pode também ser efectuada utilizando as propriedades dos índices. O índice B-Tree é bastante utilizado para este caso também (basta apenas percorrer as folhas da árvore) Algoritmos Utilizados a Nível de Junção Nested-Loop Join a relação da direita é vista uma vez por cada tuplo encontrado na relação da esquerda. Esta estratégia é muito simples de implementar, sendo que é também muito dispendiosa. É importante salientar que esta operação é sempre executada entre duas tabelas. Para tal, uma terá que a tabela exterior e outra a interior. Regra geral, escolhe-se a que tem menos tuplos para ser a tabela exterior. Porém, se a tabela mais pequena couber toda em memória, é preferível tê-la como tabela interior. Merge-Sort Join tal como o algoritmo anterior, este é suposto ser um algoritmo utilizado para juntar duas tabelas. Antes da junção começar, é necessário ordenar cada uma das tabelas, de acordo com os atributos de junção. Então, procede-se à junção das tabelas, tendo em conta que as tabelas estão ordenadas de acordo com os mesmos atributos. Esta ordenação é mais interessante, visto que cada tabela só tem de ser percorrida uma vez. Em seguida mostra-se um passo intermédio deste algoritmo, em que as duas tabelas estão ordenadas de acordo com o atributo de junção, a1. Figura 9 Esquema gráfico de um merge-sort join Hash-Join este algoritmo é substancialmente diferente dos outros. Em primeiro lugar, é feito um hash dos atributos de junção da tabela da direita. De seguida, 33

34 a tabela do lado esquerdo é percorrida e os valores apropriados de cada tuplo encontrados são utilizados como hash keys para localizar os tuplos do lado direito. Este algoritmo é um candidato muito forte para a utilização de paralelização, porém, em nenhuma versão do PostgreSQL, este mecanismo de paralelização não foi implementado. Figura 10 Esquema gráfico de um hash join Mostraremos agora um exemplo deste algoritmo em funcionamento: explain select * from country co, city ci where co.area< and co.name = ci.name; Outros algoritmos Aggregate as funções de agregação computam um único valor de um conjunto de valores de input. Estas funções são chamadas quando inseridas instruções do estilo: AVG(), COUNT(), MAN(), MIN(), etc O operador hashaggregate também é utilizado em expressões com Group By. 34

35 explain select count(*) from country; Unique este operador é utilizado para remover duplicados, que necessita de estar ordenado por coluna, sendo estas únicas. É esta a forma como o operador DISTINCT está definido. De seguida mostra-se um exemplo: explain select distinct age from uscensus; Append este operador é utilizado sempre que é detectada uma cláusula de união. É necessária a intervenção de duas tabelas. São ambas ordenadas, e depois ao juntar vão-se eliminando os duplicados. Repare-se no exemplo em seguida: explain select name from country where name='portugal' intersect select name from city; Note-se na figura anterior que é perfeitamente visível a remoção de duplicados. Setop(Intersect, IntersectAll, Except, Except All) há quarto operadores do setop: intersect, intersect all, except e except all. Estes operadores são produzidos somente quando o optimizador/planificador encontra qualquer dessas operações. O modo de funcionamento é semelhante. São sempre necessários dois conjuntos de entrada, combinando os inputs em listas ordenadas e depois em grupos de linhas idênticas. explain select name from country intersect select name from city; 35

36 Scan. Como se pode observar, também é utilizado mais um operador, o subquery 5.7. Mecanismos de Avaliação de Expressões Complexas De acordo com a secção anterior, apenas vimos algoritmos para operações individuais. Estes têm depois de ser combinados para avaliar expressões complexas, com algumas operações. Algumas alternativas para tal são: Materialização consiste em analisar as expressões (de baixo para cima) guardando o seu resultado em relações temporárias guardadas na base de dados. Os resultados de cada operação intermédia são armazenados e utilizados em avaliações de operações nos níveis superiores. Pipelining consiste na passagem de tuplos para as operações pai, mesmo enquanto uma operação esteja a ser executada. Paralelização tal como o nome indica, consiste em executar várias tarefas paralelamente. Relativamente ao sistema de gestão de bases de dados PostgreSQL, podemos ver que nem todas estas propriedades são utilizadas. A materialização é utilizada para algumas operações de subselecção. O planificador/optimizador por vezes decide que é menos caro materializar uma subselecção do que repetir o trabalho em níveis superiores da árvore. É também utilizado em algumas operações de merge-join. O pipelining também é utilizado, mais concretamente, demand-pull pipelining. A paralelização é óptima para o algoritmo hash join, mas, o PostgreSQL não a implementa Tabelas e Views Estatísticas Como seria de esperar, o planificador tem de estimar o número de linhas devolvidas por uma pergunta de forma a conseguir fazer boas estimativas e aproximações. Assim, surge a necessidade de termos dados estatísticos sobre dados do sistema, de maneira a que esta questão seja resolvida. Um dos componentes das estatísticas é o número de entradas em cada tabela e em cada índice, bem como o número de blocos de disco ocupados por cada tabela (com dimensão BLOCKSIZE, que, em geral, é 8K por tabela) e índices. Esta informação é guardada na tabela pg_class, nas colunas reltuples e relpages. A definição da tabela é a seguinte: 36

37 CREATE TABLE pg_class ( relname name NOT NULL, relnamespace oid NOT NULL, reltype oid NOT NULL, relowner oid NOT NULL, relam oid NOT NULL, relfilenode oid NOT NULL, reltablespace oid NOT NULL, relpages integer NOT NULL, reltuples real NOT NULL, reltoastrelid oid NOT NULL, reltoastidxid oid NOT NULL, relhasindex boolean NOT NULL, relisshared boolean NOT NULL, relistemp boolean NOT NULL, relkind "char" NOT NULL, relnatts smallint NOT NULL, relchecks smallint NOT NULL, relhasoids boolean NOT NULL, relhaspkey boolean NOT NULL, relhasrules boolean NOT NULL, relhastriggers boolean NOT NULL, relhassubclass boolean NOT NULL, relfrozenxid xid NOT NULL, relacl aclitem[], reloptions text[] ) Por cada linha da tabela apresenta-se informação relativa a uma tabela do sistema. A tabela inclui informação sobre índices, sequências, views, tipos compostos, e tabelas TOAST. Em seguida apresenta-se um exemplo de uma pesquisa com estas informações: select reltuples, relpages from pg_class where relname =country; Como podemos observar, a tabela tem 195 tuplos também: select count(*) from country; Por defeito, os valores são inicializados a 0 aquando da construção de uma nova tabela. 37

38 É importante dizer que estes valores não são afectados instantaneamente, ou seja, é possível existir alturas em que estes estejam ligeiramente desactualizados. Para tal, é possível, através de certos comandos, actualizar estes dados estatísticos, tais como VACUUM, ANALYZE e CREATE INDEX. O VACUUM serve para limpar tuplos que foram apagados mas que efectivamente ainda continuam a ocupar espaço em memória. Muitas das pesquisas a uma base de dados retornam apenas um conjunto de resultados, muito em parte devido à cláusula WHERE. Assim, o planificador necessita de fazer uma estimativa aos dados selectivos da cláusula WHERE. A informação usada para esta tarefa guarda-se na tabela pg_statistics. Esta guarda informação detalhada sobre os dados das tabelas. Os dados nesta são actualizados também com ANALYSE e VACUUM ANALYZE, e são sempre aproximados, mesmo com updates recentes. Para além dos dados relativos ao conteúdo de tabelas, guardam-se também dados estatísticos sobre os valores de expressões de índices. A tabela pg_statistics tem o seguinte formato: CREATE TABLE pg_statistic ( starelid oid NOT NULL, staattnum smallint NOT NULL, stanullfrac real NOT NULL, stawidth integer NOT NULL, stadistinct real NOT NULL, stakind1 smallint NOT NULL, stakind2 smallint NOT NULL, stakind3 smallint NOT NULL, stakind4 smallint NOT NULL, staop1 oid NOT NULL, staop2 oid NOT NULL, staop3 oid NOT NULL, staop4 oid NOT NULL, stanumbers1 real[], stanumbers2 real[], stanumbers3 real[], stanumbers4 real[], stavalues1 anyarray, stavalues2 anyarray, stavalues3 anyarray, stavalues4 anyarray ) Apesar da tabela pg_statistics guardar informação preciosa para consultar estes dados de uma forma mais legível, consulta-se a tabela pg_stats. Esta última é lida por todos, enquanto a primeira apenas é lida pelo supervisor do sistema. Uma consulta a esta tabela pode apresentar os seguintes resultados: SELECT attname, n_distinct, most_common_vals FROM pg_stats WHERE tablename = 'country'; 38

39 Most_common_vals representam, tal como o nome indica, os valores mais comuns que se encontram em determinada tabela. Este valor, com a instrução ANALYZE é por defeito 10. Porém, é possível alterar este número manualmente, com a instrução ALTER TABLE SET STATISTICS. O limite por defeito é 100. Aumentando este valor, temos resultados mais correctos, mas temos também mais entradas na tabela, aumentando a memória consumida. Se por outro lado tivermos poucas entradas, não temos os dados tão correctos. Um outro atributo que entra para esta problemática é o chamado histogram_bounds. Esta coluna contém um vector com os valores para cada coluna da tabela, servindo depois para particionar os dados. Eis um exemplo: SELECT histogram_bounds FROM pg_stats WHERE tablename = 'country' and attname = 'name'; Pg_stats também possui informação sobre correlações, fornecendo correlações estatísticas entre a ordenação física dos tuplos e a ordenação lógica das colunas de valores. Isto cobre as áreas das tabelas estatísticas, mas, o PostgreSQL ainda implementa mais. Implementa também estatísticas sobre o uso de tabelas, como veremos a seguir Mais estimativas Como seria de esperar, para executar perguntas o mais rápido possível, o planificador do PostgreSQL tem de ter informação precisa sobre as tabelas na base de dados em questão, visto que cada operação pode utilizar diferentes algoritmos, sendo necessários dados estatísticos para que se possam fazer aproximações mais precisas. Para que tal seja possível, o PostgreSQL dispõe de um Statistics Collector. Este é um sub-sistema que suporta a recolha de informação sobre a actividade no servidor. O Collector pode contar acessos a tabelas e índices em blocos de disco ou em tuplos individuais. Configuração dado que a recolha de dados estatísticos pode trazer um overhead muito elevado, o sistema pode ser configurável para permitir a recolha ou não destes dados. Isto é controlável através de parâmetros editados no ficheiro postgresql.conf. O parâmetro stats_start_collector tem de estar a true para que tal seja 39

40 possível (o que já está por defeito). Os parâmetros stats_block_level e stats_row_level controlam o fluxo de informação que é enviado para o servidor. O parâmetro stats_command_string permite a monitorização do comando corrente, sem haver necessidade do collector esta a funcionar. É de salientar que os parâmetros stats_block_level e stats_row_level inicialmente estão a false de forma a que o overhead não seja demasiado elevado. É importante saber onde o sistema guarda estas informações. Para tal, existem views próprias que guardam a informação destas estatísticas. É possível também criarem-se views para guardar essas estatísticas. De seguida apresentam-se as várias views onde são guardados os dados: pg_stat_activity, pg_stat_database, pg_stat_all_tables, pg_stat_sys_tables, pg_stat_user_tables, pg_stat_all_indexes, pg_stat_sys_indexes, pg_stat_user_indexes, pg_statio_all_tables, pg_statio_sys_tables, pg_statio_user_tables, pg_statio_all_indexes, pg_statio_sys_indexes, pg_statio_user_indexes, pg_statio_all_sequences, pg_statio_sys_sequences, pg_statio_user_sequences. Estas tabelas podem fornecer variadas informações, desde quais as tabelas mais utilizadas, quais os índices mais utilizados e quão efectivos eles são, quais as estimativas do I/O, entre outras estimativas bastante relevantes para o sistema. Uma outra forma de olhar para as estatísticas é realizando interrogações específicas à base de dados, que seguem o mesmo raciocínio estatístico da secção anterior. Algumas dessas perguntas consistem no seguinte: pg_stat_get_db_numbackends(oid), pg_stat_get_db_xact_commit(oid), pg_stat_get_db_xact_rollback(oid), pg_stat_get_db_blocks_fetched(oid), pg_stat_get_db_blocks_hit(oid), pg_stat_get_numscans(oid), pg_stat_get_tuples_returned(oid), pg_stat_get_tuples_fetched(oid), pg_stat_get_tuples_inserted(oid), pg_stat_get_tuples_updated(oid), pg_stat_get_tuples_deleted(oid), pg_stat_get_blocks_fetched(oid), pg_stat_get_blocks_hit(oid), pg_stat_get_backend_idset(),pg_backend_pid(),pg_stat_get_backend_pid(integer), pg_stat_get_backend_dbid(integer), pg_stat_get_backend_userid(integer), pg_stat_get_backend_activity(integer), pg_stat_get_backend_activity_start(integer), pg_stat_get_backend_start(integer), pg_stat_get_backend_client_addr(integer), pg_stat_get_backend_client_port(integer), pg_stat_reset() Através destas interrogações, podemos obter informação específica sobre, por exemplo, o número de processos de servidores activos, o número de transacções committed na base de dados, o número de transacções rolled back na base de dados, entre outras Estas questões das transacções serão abordadas no capítulo seguinte. Assim sendo, conclui-se a secção das estimativas e estatísticas de uma base de dados. É importante dizer que são guardadas estatísticas sobre custos para determinadas 40

41 operações. Estes custos podem ser manualmente alterados, porém tal não se aconselha, parametrizando-se assim as estatísticas utilizadas Como é que o Planificador Utiliza as Estatísticas (Estimativas de Linhas) Nesta secção vamos ver alguns exemplos de como o Planificador utiliza as estatísticas para determinar a cardinalidade dos valores devolvidos. Para tal, utilizaremos alguns as tabelas das tabelas de regressão da base de dados do PostgreSQL. EXPLAIN SELECT * FROM tenk1; QUERY PLAN Seq Scan on tenk1 (cost= rows=10000 width=244) O número de páginas e de linhas é verificado na tabela pg_class falada anteriormente. Estes números são correntes desde o último ANALYZE ou VACUUM à tabela (comandos de limpeza de estatísticas). Passemos para um exemplo com a condição WHERE. EXPLAIN SELECT * FROM tenk1 WHERE unique1 < 1000; QUERY PLAN Bitmap Heap Scan on tenk1 (cost= rows=1007 width=244) Recheck Cond: (unique1 < 1000) -> Bitmap Index Scan on tenk1_unique1 (cost= rows=1007 width=0) Index Cond: (unique1 < 1000) O planificador examina a cláusula WHERE e vê a função de selecção para o operador < na tabela pg_operator. Isto é guardado na coluna oprrest e na entrada scalarltsel. Esta última devolve um histograma para unique1 de pg_statistics. De acordo com este histograma, e assumindo uma distribuição linear dos valores em cada bloco, é possível calcular a selecção através da seguinte expressão matemática: selectivity = (1 + ( bucket[2].min)/(bucket[2].max - bucket[2].min))/num_buckets O número estimado de linhas pode depois ser calculado como o produto da selecção com a cardinalidade de tenk1: rows = rel_cardinality * selectivity 41

42 Vejamos agora um exemplo em que existe uma cláusula WHERE com uma restrição de igualdade: EXPLAIN SELECT * FROM tenk1 WHERE stringu1 = 'CRAAAA'; QUERY PLAN Seq Scan on tenk1 (cost= rows=30 width=244) Filter: (stringu1 = 'CRAAAA'::name) Novamente, o planificador examina a condição WHERE e verifica a função de selecção para o operador =. Para questões de igualdade, o histograma não é utilizado. Ao invés utiliza-se a lista de most common values (MCV). Vejamos um exemplo de MCV s. SELECT null_frac, n_distinct, most_common_vals, most_common_freqs FROM pg_stats WHERE tablename='tenk1' AND attname='stringu1'; null_frac 0 n_distinct 676 most_common_vals {EJAAAA,BBAAAA,CRAAAA,FCAAAA,FEAAAA,GSAAAA,JOAAAA,MCAAAA,NAAAAA,WGAAAA } most_common_freqs { ,0.003,0.003,0.003,0.003,0.003,0.003,0.003,0.003,0.003} Visto que CRAAAA aparece na lista de MCV s, a selecção corresponde meramente à entrada correspondente à lista de most commons frequencies (MCF): selectivity = mcf[3] = Tal como anteriormente, o número estimado de linhas é calculado pela multiplicação disto com a cardinalidade de tenk1. Para um caso em que o valor não esteja na lista de valores mais comuns, é aplicada uma diferente estratégia. Tira-se proveito de se saber que o valor não é muito comum, e aplica-se a seguinte fórmula: selectivity = (1 - sum(mvf))/(num_distinct - num_mcv) Depois, multiplica-se pela cardinalidade e obtemos o número de linhas pretendido. Para valores únicos (como é o exemplo das chaves primárias), não são guardadas entradas em MCV (obviamente, nenhum valor é mais comum que outro), nem histogramas. Para um valor não único, é guardado um histograma e uma lista de MVC. Observemos agora um exemplo com mais do que uma condição na cláusula WHERE. 42

43 EXPLAIN SELECT * FROM tenk1 WHERE unique1 < 1000 AND stringu1 = 'xxx'; QUERY PLAN Bitmap Heap Scan on tenk1 (cost= rows=1 width=244) Recheck Cond: (unique1 < 1000) Filter: (stringu1 = 'xxx'::name) -> Bitmap Index Scan on tenk1_unique1 (cost= rows=1007 width=0) Index Cond: (unique1 < 1000) O planificador assume que as duas condições são independentes, de forma a que as selecções individuais das cláusulas possam ser multiplicadas juntas. selectivity = selectivity(unique1 < 1000) * selectivity(stringu1 = 'xxx') Por último, vejamos um exemplo de uma interrogação que envolva uma operação de junção. EXPLAIN SELECT * FROM tenk1 t1, tenk2 t2 WHERE t1.unique1 < 50 AND t1.unique2 = t2.unique2; QUERY PLAN Nested Loop (cost= rows=50 width=488) -> Bitmap Heap Scan on tenk1 t1 (cost= rows=50 width=244) Recheck Cond: (unique1 < 50) -> Bitmap Index Scan on tenk1_unique1 (cost= rows=50 width=0) Index Cond: (unique1 < 50) -> Index Scan using tenk2_unique2 on tenk2 t2 (cost= rows=1 width=244) Index Cond: (t2.unique2 = t1.unique2) A restrição tenk.unique1 < 50 é avaliada antes do Nested-Loop-Join. Isto é feito analogamente às análises anteriores. A restrição para a junção é t1.unique1=t2.unique2. A operação = já é conhecida, porém, a função de selecção é obtida na coluna oprjoin em pg_operator. Visto que são ambos valores únicos, utiliza-se um algoritmo que se baseia no número de valores distitintos para ambas as relações juntamente com as suas fracções nulas. selectivity = (1 - null_frac1) * (1 - null_frac2) * min(1/num_distinct1, 1/num_distinct2) O número de linhas é então calculado pela cardinalidade do produto cartesiano dos dois inputs, multiplicados pela selecção: rows = (outer_cardinality * inner_cardinality) * selectivity Note-se que os atributos de junção eram ambos atributos únicos. Caso não fosse, um algoritmo diferente seria utilizado (sendo na mesma muito semelhante a este). 43

44 5.11. Mecanismos de Visualização de Planos de Perguntas No sistema do PostgreSQL, o mecanismo utilizado para ver os planos de perguntas é o comando EXPLAIN. EXPLAIN [ ANALYZE ] [ VERBOSE ] statement Este comando mostra o plano que o PostgreSQL gera para determinada pergunta. Mostra como a tabela vai ser pesquisada, se por pesquisa sequencial, se por pesquisa por índex e, se múltiplas tabelas forem referenciadas, que algoritmos de junção vão ser utilizados. A parte mais crítica é o custo estimado de execução da pergunta (medido em unidades de disk page fetches). São mostrados dos números, o tempo de começo e o tempo total de devolução dos dados, sendo que estes tempos são medidos em milissegundos. Na maior parte dos casos o mais importante é o tempo total de duração, mas existem situações particulares em que o tempo inicial também entra em conta. Parâmetros: Analyze a opção analyze causa a execução da query, não somente a sua planificação. Verbose mostra a representação interna da árvore de planificação, ao invés de apenas um sumário. Esta opção é mais utilizada para propósitos de debugging. Statement qualquer SELECT, INSERT, UPDATE, DELETE, EXECUTE, DECLARE, cujo plano de execução deseje ser visto. De seguida é mostrado um exemplo de um plano de execução para a instrução: explain analyze select * from country; Passamos agora a explicar um pouco melhor os resultados obtidos na imagem anterior. Tipo de operação requisitada, neste caso, Seq Scan. Custo estimado de execução, apresentando-se na forma de intervalo, em que o primeiro valor mostra a rapidez com que a primeira linha no conjunto de resultados é devolvida e o segundo o tempo total da operação. Número de linhas (rows) esperado. Tamanho em bytes médio dos tuplos no conjunto de resultados (bytes). Custo real de execução caso o comando ANALYZE tenha sido introduzido. 44

45 Apresenta-se de seguida um exemplo um pouco mais complexo, por forma a que uma melhor percepção deste mecanismo seja compreendido: explain analyze select * from country order by name ASC; Como se pode observar através da imagem anterior, é simples reparar que há dois processos distintos em causa. Primeiramente é efectuada uma ordenação e depois é efectuada uma selecção de dados, tal como se pode constatar na imagem anterior. 45

46 6. Gestão de transacções e controlo de concorrência 6.1. Definição de transacção Num sistema de bases de dados, existem muitas operações que podem ser executadas (select, insert, update ). Podemos assumir também que as bases de dados não estão, na maior parte dos casos, projectadas para serem utilizadas por uma pessoa em particular, mas sim por várias pessoas. Consideremos o exemplo de um banco: várias pessoas podem fazer depósitos, levantamentos, consultas, etc, e podem-no fazer concorrentemente. É então importante ter um sistema que proteja a base de dados de erros que possam ocorrer devido a esta concorrência. É no âmbito desta protecção que surgem as transacções, que permitem que haja um controlo grande nestas questões de concorrência, fornecendo ferramentas fiáveis de recuperação de dados em casos de falhas, mantendo a base de dados consistente, fornecendo também isolamento entre programas a aceder a uma base de dados. De seguida apresentaremos as propriedades chave que uma transacção deverá ter. Uma má gestão destas pode levar uma base de dados a guardar dados inconsistentes ou simplesmente errados. Retomando o exemplo do banco, uma má gestão da base de dados aqui pode comprometer seriamente as economias das pessoas, o que não é de todo desejado Propriedades ACID das transacções Todas as transacções de um sistema de base de dados devem respeitar as propriedades ACID (atomicidade, consistência, isolamento e durabilidade). Atomicidade (A) a atomicidade corresponde a uma política de all or nothing. Atomicidade diz que uma operação não pode ser partida em várias sub-operações, sendo que se esta falha, nada é executado. Ou a operação é executada toda com sucesso ou não é sequer executada. Pegando novamente no exemplo do banco, imaginemos que o cliente A está a fazer uma transferência para o cliente B. Não se quer que a operação termine a meio, sendo que já foi debitado dinheiro da conta de A, apesar de não ter sido aumentado o saldo de B. Assim, ou se faz a transferência por completo ou não se faz de todo. Consistência (C) a consistência garante que a base de dados se apresenta consistente antes e depois da transacção (independentemente do sucesso desta). Para tal, na base de dados só podem ser introduzidos valores válidos. Caso tentem ser inseridos valores não válidos, a operação voltará atrás, deixando a base de dados no estado consistente original. Porém, em estado intermédio, é possível que a transacção esteja num estado inconsistente. Isolamento (I) o isolamento refere-se ao requisito de que certas operações não podem aceder nem ver dados num estado intermédia de uma transacção. Esta propriedade por ser assegurada correndo transacções serialmente, ou seja, uma depois da outra, por vezes perdendo a capacidade de concorrência que pode ser muito útil em certas ocasiões. Durabilidade (D) a durabilidade é algo que garante ao utilizador que, assim que este for notificado do sucesso da transacção, as alterações feitas na base de dados têm de persistir mesmo havendo falhas a nível de software ou hardware. 46

47 Geralmente, os sistemas de bases de dados implementam transacções que obedecem a este conjunto de regras, porém, existem aplicações em que tais propriedades não são sempre desejadas. Tomemos como exemplo uma transacção significativamente grande (long duration transactions). Neste caso, pode-se não querer, ou conseguir, que o isolamento seja garantido, devido ao longo tempo de execução da transacção. Sem este isolamento, a atomicidade por ser comprometida. Uma solução para este problema é definir acções de compensação, ou seja, definir um conjunto de regras do que fazer no caso de, mais tarde, a transacção falhar. O PostgreSQL não tem suporte para long-duration transactions. A implementação das transacções não é trivial, sendo que mais à frente serão abordados alguns métodos aplicados a estas Estado de uma transacção Na ausência de falhas, todas as transacções são concluídas com êxito. Contudo, uma transacção pode nem sempre ser concluída com sucesso. Quando tal acontece, dizse que a transacção foi abortada (aborted). De acordo com as propriedades ACID, a atomicidade implica que se a transacção não foi concluída, então nada dela foi concluída, sendo necessário cancelar tudo o que foi feito. Tal processo chama-se rollback. Se uma transacção foi executada com sucesso, diz-se que foi committed. De acordo com isto, é possível estabelecer variados estados para as transacções: Active corresponde ao estado inicial. A transacção fica neste estado enquanto está a ser executada. Partially Committed após a última instrução ter sido executada Failed depois de se descobrir que a execução normal não pode continuar Aborted quando a transacção foi rolled back e a base de dados voltou ao estado antes da transacção Committed como dito antes, após uma conclusão da transacção com êxito. 47

48 partially commited committed active failed aborted Figura 11 Esquema dos vários estados das transacções 6.4. Controlo de Concorrência Após uma abordagem inicial sobre transacções, é fácil verificar que estas fazem sentido num âmbito concorrente. O controlo de concorrência é uma das coisas mais importantes em bases de dados grandes. Tomemos novamente como exemplo o caso de um banco, em que várias pessoas podem aceder aos mesmos dados em simultâneo, fazendo várias operações iguais ou diferentes. Caso não haja um controlo de concorrência forte, poderiam existir problemas sérios. Para lidar com este problema, foram desenvolvidas técnicas específicas, de acordo a conseguir lidar com esta concorrência. Antes de passarmos para o PostgreSQL, em seguida falamos de algumas técnicas mais comuns, sendo elas as seguintes: Protocolos Baseados em Locks estes protocolos baseiam-se, tal como o nome indica, na utilização de locks. Através destas propriedades, podemos garantir que o acesso a determinados dados são feitos de acordo com estes locks, mas basicamente a ideia é que se uma transacção está a aceder a determinados dados, mais nenhuma transacção pode aceder a estes (modo exclusivo). Através de propriedades de locks e unlocks conseguimos estabelecer estas regras. Note-se que estes locks podem ser do tipo exclusivo, em que se uma transacção obtém um exclusive-mode lock mais nenhuma transacção poderá ler ou escrever sobre esses dados, ou também podem ser do tipo shared, em que se uma transacção obtém o shared-mode lock qualquer outra transacção poderá ler os mesmos dados, mas nunca escrever neles. Um protocolo deste género muito conhecido é o Two-Phase Locking Protocol, que consiste em duas fases distintas, Growing phase, onde são obtidos os locks sem nunca os libertar, e a shrinking phase, onde uma transacção liberta os locks, não os podendo obter mais. 48

49 Protocolos Baseados em Time-Stamps para cada transacção no sistema, é atribuído um time-stamp, antes de esta começar a execução. Há então duas formas de funcionamento: a atribuição do time-stamp pode ser com a utilização do clock do sistema ou utilizando um contador lógico, que é incrementado sempre que uma nova transacção entra no sistema. Através destes time-stamps consegue-se fazer um controlo de concorrência. Protocolos Multi-Versões De forma a maximizar ainda mais a concorrência, este tipo de protocolo cria várias cópias do mesmo item. Assim, cada write (Q) cria uma nova versão de Q e quando Q é chamado para leitura, o sistema elege a versão do Q mais apropriada, garantida a serialização. É neste âmbito que surgem então os protocolos Multiversion Timestamp Ordering e o conhecido Two-Phase Locking. É de notar que existem outros protocolos, mas estes são dos mais conhecidos e dos mais utilizados, razão pela qual não são apresentados os restantes Transacções e Gestão de Concorrência no PostgreSQL Definição de Transacção - para começar este tema, é importante primeiro dizer que o PostgreSQL, por defeito, implementa uma política de auto-commit. Desta forma, cada instrução é tratada como uma transacção. Um read é uma transacção, um write é outra, etc Há então duas formas de contornar esta situação: uma é simplesmente desligar o auto-commit, através da instrução \SET AUTOCOMMIT OFF. Assim, é tudo considerado uma transacção até que a instrução commit seja executada. A outra solução passa por indicar explicitamente o início e o fim de uma transacção usando o comando BEGIN no início da transacção e o comando COMMI; no final desta. Caso se pretenda anular a transacção, ao invés do comando COMMIT é possível introduzir o comando ROLLBACK. Poderia existir a possibilidade de o PostgreSQL permitir a ocorrência de nested transactions. Tal não é possível neste sistema. A sua gestão não é trivial, e pode não ser aconselhada em muitas situações. Postgres =# begin; Postgtes =# begin; WARNING: there is already a transaction in progress. Como se pode observar, não é possível a ocorrência de nested transactions. Garantia de Isolamento O PostgreSQL, ao invés de muitos outros SGBD s, mantém os dados coerentes através da utilização de modelos multi-versão (Multiversion Concurrency Control, MVCC). Assim, cada transacção vê uma versão da base de dados (snapshot) tal como era em algum tempo atrás, independentemente do estado actual dos dados, evitando assim o problema de uma transacção poder ver os dados incoerentes. Protocolos a nível de locks de tabela e tuplo também são possíveis no PostgreSQL, para aplicações que não se adaptem bem ao funcionamento do modelo MVCC, sendo que é necessário estabelecer manualmente o nível de granularidade desejado. Contudo, um uso cuidado no MVCC é melhor que a utilização de locks. 49

50 Isolamento nas Transacções o SQL standard define quatro níveis de isolamento de transacções de acordo com três fenómenos que não devem acontecer entre transacções concorrentes, sendo os fenómenos os seguintes: dirty reading, nonrepeatable read e phantom read. Dirty reading uma transacção lê dados que foram entretanto modificados por uma outra transacção concorrente que ainda não realizou o comando commit; Nonrepeatable read uma transacção re-lê dados e descobre que os estes foram modificados por uma outra transacção; Phantom read uma transacção executa novamente uma pergunta e descobre que os valores que satisfazem a pergunta são diferentes da anterior, devido a um commit de uma outra transacção. Os quatro níveis de isolamento das transacções SQL são as seguintes: Figura 12 Vários níveis de isolamento das transacções SQL O PostgreSQL suporta o Read Commited e o Serializable. Para então se determinar qual o nível de isolamento pretendido, devem-se utilizar uma das seguintes operações: SET TRANSACTION transaction_mode [,...] SET SESSION CHARACTERISTICS AS TRANSACTION transaction_mode [,...] Sendo que transaction_mode pode ser um dos seguintes: ISOLATION LEVEL { SERIALIZABLE REPEATABLE READ READ COMMITTED READ UNCOMMITTED } READ WRITE READ ONLY Nota: para se utilizar o comando SET TRANSACTION sem que seja inicializada uma transacção especificamente com o comando START TRANSACTION ou BEGIN (no caso de estarmos perante um sistema em auto-commit), então não haverá qualquer efeito sobre esta, visto que a transacção acabará imediatamente. Se o comando SET TRANSACTION for utilizado correctamente, este também só afectará a actual transacção, enquanto o comando SET SESSION CHARACTERISTICS AS TRANSACTION afectará todas as transacções da sessão, sendo que SET TRANSACTION pode subscrever as transacções da sessão para uma transacção em particular. Como já foi dito, o PostgreSQL implementa o Serializable e o Read Commited. Como o standard SQL tem mais dois elementos, o Read Uncommitted é tratado como um Repetable Read é tratado como Serializable. É de nota que o Read Commited é o grau de isolamento standard do sistema em questão. Níveis de Granularidade (Locks) o PostgreSQL permite a utilização de locks com vários níveis de granularidade (explicit locking), a nível de tabela, a nível de 50

51 tuplos e, em versões mais recentes, os chamados advisory locks. Para criar locks a nível de tabela, a instrução utilizada é a seguinte: LOCK [ TABLE ] [ ONLY ] name [,...] [ IN lockmode MODE ] [ NOWAIT ] Sendo que lock mode é um dos seguintes: ACCESS SHARE ROW SHARE ROW EXCLUSIVE SHARE UPDATE EXCLUSIVE SHARE SHARE ROW EXCLUSIVE EXCLUSIVE ACCESS EXCLUSIVE Cada um destes lock modes corresponde a um tipo de lock diferente. Se o no wait for introduzido, se a tabela não consegue obter o lock desejado, o comando é abortado e uma mensagem de erro é emitida. Quando obtido, o lock dura até ao final da transacção. Note-se que não há nenhum comando do tipo unlock table, já que o lock dura somente até ao final de transacção em questão. É de notar também que duas transacções não podem conter locks em modo conflituoso. Caso se tente ter lock de uma tabela num modo conflituoso, o último processo fica bloqueado até que um dos modos seja libertado. Em seguida apresentaremos um quadro onde estão indicados os vários tipos de conflito que podem existir no sistema: Figura 13 Níveis de granularidade e tipos de conflito possíveis entre eles Relativamente aos locks por tuplo, estes podem ser shared ou exclusive. Um exclusive lock é obtido automaticamente aquando de um update ou de um delete. Um lock a nível de tuplo não afecta as perguntas. Para se obter um lock sem que haja alteração dos dados, é possível faze-lo explicitamente, através dos seguintes comandos: SELECT FOR SHARE SELECT FOR UPDATE A primeira cria locks exclusivos enquanto que a segunda cria locks partilhados. Como seria de esperar, ao utilizarmos um sistema de locks podemos introduzir deadlocks no sistema. Todavia, o PostgreSQL contém mecanismos que conseguem detectar um deadlock, abortando uma das transacções intervenientes, permitindo a outra transacção avançar. Quando acontece o deadlock, a transacção mais recente é desbloqueada, sendo a última a terminada, surgindo uma mensagem de erro semelhante à seguinte: Process 5136 waits for ShareLock on transaction 756; blocked by process 1424 waits for ShareLock on transaction 755; blocked by process