Postgres Storage Tecnologia de Base de Dados Nuno Costa – Nº 50099.

Apresentação em tema: "Postgres Storage Tecnologia de Base de Dados Nuno Costa – Nº 50099."— Transcrição da apresentação:

1 Postgres Storage Tecnologia de Base de Dados Nuno Costa – Nº 50099

2 Tópicos Estrutura BD (directoria/ficheiros) Sistema de Armazenamento Objectivos BD principal Transacção Tabelas/Índices Tuplos BD secundária Utilidade: execução de querys Vaccum cleaner

3 Estrutura de BD Um cluster de BD, a nível de ficheiros e directorias, encontra-se em /var/lib/pgsql/data, vulgarmente denominado PGDATA. Para cada BD do cluster, existe uma sub-directoria em PGDATA/base, havendo uma série de ficheiros de controlo e sub-directorias comuns ao cluster.

4 Estrutura de BD PG_VERSION: ficheiro que contém a versão do POSTGRES relativa ao cluster base: sub-directório contendo as várias BDs do cluster pg_clog: sub-directório contendo informação do estado das transacções pg_xlog: sub-directório contendo os ficheiros WAL(Write Ahead Log) postmaster.opts: ficheiro que grava os vários comandos executados pelo utilizador da passada sessão A adicionar, existem uma série de ficheiros de configuração que habitualmente se encontram na PGDATA:postgresql.conf, pg_hba.conf e pg_ident.conf

5 Storage Manager - Objectivos O Storage Manager consiste numa colecção de módulos que permitem gestão de transacções e acesso a objectos da base de dados. Os módulos foram desenhados com 2 objectivos: Suporte gestão transacional tendo muito pouco código de recuperação. Tal código seria difícil de implementar, fazer debug e não poderia ter qualquer tipo de erro. A quase inexistência de código de recuperação deve-se ao facto de todos os updates feitos à BD serem na realidade insertions; O Storage Manager permite ao utilizador guardar todo o historial da BD ao integrar um sistema de arquivo no qual é feito o backup. O backup feito recorre a dispositivos WORM (write-once-read-many).; Descrito em: src/backend/storage/smgr/smgr.c smgrinit() smgrshutdown()

6 Transacção É sequencialmente atribuído a cada transacção um identificador (XID) com 40 bits, começando no 1. Os comandos executados numa transacção terão cada um CID (Comand Identifier) de 8 bits, limitando o número de comandos a 256 por cada transacção. O log de transacção terá 2 bits por transacção, indicando o estado desta: Commited Aborted In progress

7 Tabelas/Índices Sempre que é criada uma tabela e/ou índice, é igualmente criado um ficheiro contendo os seus tuplos. O tamanho de uma tabela/índice tem um limite de 1GB, que caso seja ultrapassado é dividido em vários segmentos. Descrito em: src/backend/storage/page/bufpage.c PageInit() PageIndexTupleDelete() PageAddItem()

8 Tuplos (cont.) Cada tuplo terá 8 campos, identificando-o univocamente: OID : identificador único atribuído pelo sistema; Xmin : identificador da transacção a inserir o registo Tmin : o tempo do commit de Xmin Cmin : o CID (relativo a uma determinada transacção) inserindo o registo Xmax : identificador da transacção a apagar o registo Tmax : o tempo do commit de Xmax Cmax : o CID (relativo a uma determinada transacção) apagando o registo PTR : apontador

9 Tuplos - Operações (cont.) As variáveis de cada tuplo são actualizadas consoante o tipo de operação: Insertion: sempre que adicionarmos um tuplo, é-lhe atribuído um OID único e Xmin e Cmin identificam a transacção responsável, sendo os restantes 5 campos a null Update: Xmax e Cmax são actualizados e identificam a transacção responsável pela operação. É inserido o novo registo com o OID do original. Delete: Xmax e Cmax são actualizados e identificam a transacção responsável pela operação

10 BD Secundária Para além da BD principal, um dos principais objectivos do POSTGRES é assegurar a existência de uma BD secundária que serve não só de backup para recuperação de acidentes mas também para execução de querys recorrendo à sua informação de histórico.

11 Execução de querys recorrendo ao histórico O POSTQUEL (linguagem SQL do POSTGRES) permite executar querys recorrendo ao histórico. Exemplo: retrieve (EMP.salary) where EMP.name = “Mike” Usando histórico: Onde T é uma data específica: retrieve (EMP.salary) using EMP[T] where EMP.name = “Mike” Entre 2 datas: retrieve (EMP.Tmin, EMP.Tmax, EMP.salary) using EMP[Tl,T2] where EMP.name = “Mike”

12 Execução de querys recorrendo ao histórico (cont.) Uma das desvantagens deste tipo de querys é o facto de haver duplicação do acesso a cada tuplo para verificação temporal. Um tuplo é válido para um determinado valor T se Tmin < T e Xmin é referente a uma transacção commited e se verificar uma das seguintes condições: Xmax é null Tmax > T

13 Processo de backup Existe um processo denominado “vaccum cleaner” responsável pela migração de dados da BD principal para a de backup O processo consiste em 3 fases: Cópia do registo e possíveis indíces associados a este Escrita de um novo “anchor point” na BD Remoção do antigo “anchor point” e respectivos “delta records” Exemplo em POSTQUEL: vaccum EMP after “30 days” Descrito em: /commands/vaccum.c

14 Bibliografia http://www.postgresql.org/docs/8.0/static/st orage.html http://db.cs.berkeley.edu/papers/ERL-M87- 06.pdf http://www.physiol.ox.ac.uk/Computing/Onli ne_Documentation/postgresql/history.html PostgreSQL 8.1.0 Documentation - The PostgreSQL Global Development Group