Armazenamento de Dados e Indexação em PostgreSQL e MySQL

Transcrição

1 Armazenamento de Dados e Indexação em PostgreSQL e MySQL Tiago Almeida André Machado de Dezembro, 2011

2 Conteúdo 1 PostgreSQL Armazenamento Armazenamento Físico das Bases de Dados Clustering Sistema de gestão do buffer Particionamento Indexação e Hashing Tipos de índice Índices multi-coluna Os índices e a ordenação Combinação de índices Índices únicos Indexação em expressões Índices parciais Classes de operadores MySQL Armazenamento Armazenamento Físico das Bases de Dados Sistema de gestão do buffer Particionamento Indexação e Hashing Estruturas de dados de indexação Tipos de índice Notas sobre indexação Hashing Estruturas temporariamente inconsistentes

3 Capítulo 1 PostgreSQL 1.1 Armazenamento Armazenamento Físico das Bases de Dados O PostgreSQL não implementa um sistema de ficheiros. Em vez disso, usufrui do sistema de ficheiros do Sistema Operativo para gerir as suas directorias e ficheiros. O Layout das directorias e ficheiros é explicado já na secção Layout Físico da Base de Dados Todos os dados necessários para um sistema de bases de dados fica guardada dentro da directoria desse sistema. Normalmente, denominada de PGDATA. Multiplos sistemas podem existir na mesma máquina. A directoria PGDATA contém várias subdirectorias e ficheiros de controlo, como se pode ver alguns na tabela 1-1, abaixo. Item PG_VERSION base global pg_clog pg_stat_tmp pg_tblspc pg_xlog Descrição Um ficheiro que contém a versão do PostgreSQL Subdirectoria que contém as subdirectorias de cada base de dados Subdirectoria que contém tabelas comuns aos sistema, tal como a "pg_database" Subdirectoria que contem informação relativa a transações Subdirectoria que contém ficheiros temporários para o subsistema de estatistica Subdirectoria que contém links para tablespaces Subdirectoria que contém ficheiros WAL (Write Ahead Log) 2

4 Para cada base de dados, existe uma subdirectoria na PGDATA/base, denominada através do seu OID na pg_database. Esta subdirectoria é o local, por omissão, para os ficheiros da base de dados. Cada tabela e cada índice são guardados em ficheiro diferentes. O respectivo FSM (Fre Space Map) é guardado num ficheiro com o mesmo nome que a tabela, com o sufixo "_fsm". O VM (Visibility Map) é feito da mesma maneira, mas o sufixo é "_vm". O VM é descrito na secção O "Initization Fork"de tabelas e índices pontuais é guardado com sufixo "_init". Será falado sobre isso na secção Tabela com colunas potencialmente grandes demais, terão uma tabela TOAST (ver secção ) associada. O conteúdo das tabelas e índices será discutido na secção Cada tablespace definido pelo utilizador tem um "atalho"dentro da directoria PGDATA/pg_tblspc, que dirige para directoria onde está a informação o tablespace. Tabelas e índices são guardados dentro dessa directoria. A função pg_relation_filepath() mostra o caminho completo (relativo à directoria PGDATA) de qualquer relação. Os ficheiros temporários são guardados dentro de "PGDATA/base/pgsql_tmp", ou dentro da subdirectoria "pgsql_tmp"da directoria de um tablespace TOAST - The Oversized-Attribute Storage Technique O PostgreSQL tem uma tamanho fixo por página (8 kb, normalmente) e não permite que os túplos se expandam para outro páginas. Então, não permite guardar valores muito grandes directamente. Para superar esta limitação, os dados são compridos ou divididos. Tudo isto de forma transparente ao utilizador. Nem todos os tipos são "TOAST-able". Isto porque há certos tipos que nunca vão produzir grandes valores (booleanos, por exemplo), logo não há necessidade de overhead. Para permitir TOAST, o tipo de dados deve ter uma representação do comprimento da variável (varlena), que é uma palavra de 32-bits, contendo o tamanho total do valor, em bytes. O TOAST usa dois bits da varlena para verificação, limitando o tamanho de qualquer valor em 1 GB. Estes dois bits são usados para definir o tipo e/ou estado do valor. Há quatro estratégias para guardar colunas em TOAST: 3

5 PLAIN Não permite compressão nem divisão. Os dados são guardados da mesma forma. É a única estratégia para "non-toast-able data" EXTENDED Primeiro comprime os dados e, se ainda não couber, divide-os em múltiplas linhas EXTERNAL Não permite compressão, apenas divisão em múltiplas linhas MAIN Permite compressão, mas não permite divisão. No entanto, apenas como último recurso, poderá haver a necessidade de dividir Cada tipo de dados (TOAST-able) especifíca uma estratégia a ter, por omissão, para cada coluna desse tipo de dados. Ainda assim, a estratégia pode ser alterada utilizado o comando "ALTER TABLE SET STORAGE". Para mais informação, visite " Free Space Map Todas as relações, excepto índices Hash, têm uma FSM para guardar informação sobre espaço livre na relação. O FSM é organizado como uma árvore de páginas FSM. As páginas FSM, no nível mais profundo (leafs), guarda o espaço livre em cada relação, usando um byte para representar cada página. Os níveis de cima servem para agregar a informação vinda de baixo Visibility Map Cada relação tem também um VM para guardar informação sobre quais páginas têm tuplos visíveis a todas as transações activas. O VM só guarda um bit por cada página. Um bit com valor 1 significa que todos os túplos da página são visíveis a todas as transações. O VM é conservativo de forma que, quando o bit estiver a 1, sabemos que a condição é verdadeira mas, quando está a 0, pode, ou não, ser verdade Initialization Fork Cada tabela definida como "unlogged", e respectivos índices, têm um IF (Initialization Fork). O Initialization Fork é um tabela vazia, ou índice vazio, do tipo apropriado. Quando acontece um "crash"e a tabela precisa de ser reiniciada, o Initialization Fork é copiado para o fork principal Layout das Páginas Todas as tabelas e índices são guardados como arrays de páginas de tamanho fixo (normalmente, 8 kb, como já havia sido referido). Numa tabela, todas 4

6 as páginas são equivalentes, ao nível lógico. Portanto, cada linha pode ser guardado em qualquer página. No que toca aos índices, a primeira página é usada como uma página que guarda informação de controlo. Tabela 1-2: Overral Page Layout Item PageHeaderData ItemIdData Free space Items Special space Descrição 24 bytes; Contém informação geral sobre a página, incluindo apontadores para espaços vazios Array de pares (offset,length) que apontam para os items em si; 4 bytes por item O espaço livre. Os apontadores para novos items são alocados no início deste espaço e os items em si no fim Os items em si Dados de especificação sobre os métodos de acesso dos índices Os primeiros 24 bytes de cada página consistem no cabeçalho da página. Guardam informação como a data da última alteração, o "offset"para o ínicio e fim do espaço livre, entre outros. Depois do cabeçalho, vem os identificadores dos items. Guardam o offset para o início do item, o seu comprimento em bytes e alguns bits que afectam a sua interpretação. Por último, vem a secção "especial", que pode conter tudo o que o método de acesso deseje escrever. Por exemplo, índices B-Tree guardam links para os filhos esquerdo e direito de uma determinada página. Tabelas básicas não usam esta secção. Para mais detalhes, visitar " Clustering Quando uma tabela é agrupada, é fisicamente reordenada, com base na informação do índice. Agrupamento de tabelas é uma operação pontual. Isto é, quando é feito um "update"a uma tabela, as mudanças não são agrupadas. Se se quiser, pode-se reagrupar periodicamente, bastando apenas correr o comando novamente. Durante uma operação de agrupamento, obtém-se acesso exclusivo, o que previne que qualquer outra operação seja efectuada na tabela, até o agrupamento terminar Sistema de gestão do buffer As versões anteriores à 8.0 usavam uma cache LRU (Least Recently Used) para guardar em memória as páginas mais recentes. O algoritmo URL não 5

7 tinha em consideração o número de vezes que uma cache em específico era acedida. Isto era mau, porque um scan muito grande poderia forçar a saída de páginas úteis. O novo algoritmo de caching usa quatro listas em separado para guardar informação das páginas visitadas mais recentemente e as páginas visitadas mais frequentemente e, dinamicamente, optimiza a substituição de páginas com base na carga de trabalho Particionamento Particionamento no PostgreSQL O PostgreSQ tem um mecanismo de particionamento que é bastante útil e oferece vários benefícios, tais como melhorar a performance das queries, melhores a performance de updates, dividir um bloco de dados muito grande em vários blocos pequenos, entre outros. O sistema de particionamento do PostgreSQL trabalha através de herança de tabelas. Cada partição deve ser criada como "filha"de apenas uma tabela "mãe". A tabela "mãe", normalmente, é uma tabela vazia; existe apenas para representar o conjunto de dados. Em PostgreSQL, existem as seguintes formas de particionamento: Particionamento por intervalos, definido através de intervalos de valores disjuntos para atributos chave da tabela a particionar; Particionamento por listagem, definido através duma listagem explícita de que valores duma chave da tabela pertencem a que partição; Como particionar Um utilizador pode definir uma tabela particionada da seguinte forma: 1. Criar uma tabela "mestre", da qual todas as partições vão herdar, não contendo quaisquer dados e sem restrições definidas (a não ser que o utilizador queira aplicar estas restrições igualmente a todas as partições); 2. Criar várias tabelas "filhas"(partições) que irão, todas elas, herdar da tabela mestre"; 3. Adicionar restrições para cada partição para definir os valores permitidos na chaves, assegurando que os intervalos abrangidos são disjuntos entre as várias partições; 4. Para cada partição, criar um índice na coluna chave, bem como quaisquer outros índices desejados; 5. Opcionalmente, definir "triggers"ou regras para que os dados inseridos na tabela mestre sejam "redirecionados"para a partição apropriada; 6

8 6. Assegurar que o parâmetro de configuração "constraint_exclusion"não está desligado no postgresql.conf. Se estiver, as queries não vão ser optimizadas como desejado Gerir partições Normalmente, não se pretende que as partições criados na definição da tabela se mantenham estáticas. É bastante comum querer apagar partições antigas e, periodicamente, adicionar novas. A maneira mais simpes para apagar dados antigos consiste em apagar a tabela da partição que já não é necessária: DROP TABLE measurement_y2006m02; Esta operação permite apagar milhões de registos muito rápidamente, visto que não é preciso apagar cada registo individualmente. Outra solução, que muitas vezes é preferível, é remover a partição da tabela particionada mas continuar a ter acesso à mesma e aos seus dados: ALTER TABLE measurement_y2006m02 NO INHERIT measurement; Isto permite fazer operações futuras nos dados antes de os apagar Particionamento e exclusão de partições Exclusão de Restrições é uma optimização de queries que melhora a performance em tabelas particionadas definidas da forma descrita acima. Numa query com a cláusula "WHERE", com "constraint_exclusion"activada, o planeador vai examinar as restrições de cada partição e tentar provar que a partição não precisa ser "scaneada"porque não iria conter nenhuma linha que correspondesse com a cláusula WHERE. Quando o planeador consegue comprovar isto, exclui a partição do plano da query. Mas a optimização de queries não será explorada neste relatório Métodos de particionamento alternativo Uma maneira diferente de "redirecionar"inserções para a partição apropriada consiste em definir regras, em vez de triggers, na tabela mestre. Por exemplo: CREATE RULE measurement_insert_y2006m02 AS ON INSERT TO measurement WHERE ( logdate >= DATE AND logdate < DATE ) DO INSTEAD INSERT INTO measurement_y2006m02 VALUES (NEW.*); 7

9 Atenção que a operação "COPY"ignora estas regras. Se quiser usar a operação "COPY"para inserir dados, é fulcral que se copie os dados para a partição correcta, em vez de copiar para a tabela mestre. A operação "COPY", no entanto, dispara triggers, logo se se prentender usá-la, usar triggers é uma aproximação aceitável Avisos Não existe uma maneira automática de verificar que todas as restrições são disjuntas. Por exemplo, temos uma partição <pt1> com a restrição "CHECK ( outletid BETWEEN 100 AND 200 )"e uma partição <pt2> com a restrição "CHECK ( outletid BETWEEN 200 AND 300 )". Não é óbvio a que partição pertence a chave com valor 200. E não há forma de verificar isto. Os esquemas mostrados aqui partem do principio que a coluna chave de uma partição nunca muda ou, pelo menos, não muda o suficiente de forma a obrigar a mudar a linhar para outra partição. Um UPDATE que tente fazer isso vai falhar por causa das restrições. Uma boa solução seria implementar triggers para UPDATE. 8

10 1.2 Indexação e Hashing Tipos de índice Há quatro tipos de índice suportados pelo PostgreSQL. ELes são: B-Tree, Hash, GiST e GIN. Cada tipo usa um algoritmo diferente que se adequa melhor a determinado tipo de query. Por omissão, os índices criados são do tipo B-Tree. Internamente, o PostgreSQL também usa bitmaps para operações binárias (como AND e OR). Contudo, não é possível o utilizador definir índices do tipo bitmap Índices B-Tree Os índices do tipo B-Tree suportam igualdades e ordenação. O "query planner"do PostgreSQL usará (ou considerará usar) B-Tree s sempre que uma coluna indexada esteja envolvida numa comparação de um dos tipos <, <=, =, >= e >. Os índices B-Tree também funcionam para as combinações destas várias operações, como "IN"e "BETWEEN". As condições "IS NULL"e "IS NOT NULL", usadas em colunas indexadas, também podem ser usados com B- Tree s. Índices B-Tree também podem ser usados para obter dados ordenados. Nem sempre é mais rápido que um "scan & sort"puro, mas pode ser útil Índices Hash Os índices Hash só suportam igualdade. O "query planner"só considerará usar um índice Hash quando as colunas indexadas estejam envolvidas numa comparação de igualdade (=). Além disso, ao contrário dos índices B-Tree, os índices Hash não actualizam o WAL, o que obriga a que os índices sejam "refeitos"depois de um crash. Nota: WAL (Write Ahead Log) é uma sistema de logs no qual são mantidas todas as alterações feitas à base de dados, a fim de conseguir recuperar o estado da base de dados antes de ocorrer o crash Índices GiST GiST não são índices básicos, mas sim uma estrutra onde se podem ter várias estratégias diferentes de Indexação. Os tipos de query para os quais são usados os índices GiST dependem da estratégia de indexação que se está a adoptar. Por exemplo, a versão Standard do PostgreSQL vem com índices GiST para dados geométricos a duas dimensões, que suportam as operações «, &<, &>,», «, &<, <@, = e &&. 9

11 Os índices GiST também podem ser usados para optimização de queries por "nearest-neighbor". Exemplo: SELECT * FROM places ORDER BY location <-> point (101,456) LIMIT 10;" Esta query procura os 10 (dez) "places"mais perto de um determinado "point" Índices GIN Os índices GIN são índices invertidos que lidam (ou podem lidar) com valores com mais do que uma chave. Tal como os GiST, os GIN permitem diferentes estratégias e os operadores com os quais são usados os GIN também depende da estratégia que esteja a ser usada. Para exemplificar, a versão Standard do PostgreSQL vem com índices GIN para lidar com arrays unidimensionais, que suportam os operadores = e && GiST vs. GIN Estes índices podem ser usados para acelerar pesquisas em texto. Não é estritamente necessário, mas é útil. GiST > Pode, por vezes, apresentar resultados errados (false matches), o que obriga a que o PostgreSQL faça um verificação para eliminar as linhas onde isto acontece. Isto causa uma degradação na performance porque obriga a fazer acesso ao disco (fetch) de registos que, na verdade, são "false matches". GIN > O mesmo não acontece (tão frequentemente) no uso de índices GIN, mas a sua performance depende do número de "unique words". Uma procura por um índice GIN é 3 (três) vezes mais rápida que uma procura por um índice GiST. No entanto, um índice GIN demora o triplo do tempo a ser criado, em comparação ao índice GiST. Assim como na criação, o update de um índice GIN também é mais lento. Para terminar, os índices GIN são cerca de 3 vezes mais maiores, em termos de memória, em comparação aos índices GiST Índices multi-coluna Um índice pode ser definido em mais do que uma coluna. Até agora, apenas os índices B-Tree, GiST e GIN suportam mais do que uma coluna e estão limitados a 32 colunas (parametrizável na compilação do PostgreSQL). Não, os índices Hash não suportam mais do que uma coluna. Exemplo: 10

12 CREATE INDEX <index\_name> ON <table_name> USING BTREE(<at1\_name>, <at2\_name>); No entanto, índices multi-coluna têm as suas limitações e devem ser usados com moderação. Na maioria dos casos, um índice por coluna é suficiente e poupa espaço e tempo. Índices com mais do que três colunas não são muito úteis, a menos que o uso da tabela seja muito especializado Os índices e a ordenação Além de encontrar as linhas que respondem a uma query, os índices também são capazes de as retornar numa determinada ordem. Isto permite que uma especificação "ORDER BY"numa query possa ser realizada sem ser necessária fazer um passo só para ordenação. Dos tipos falados previamente, apenas os índices B-Tree permite ordenação. A ordenação feita pelos GiST e GIN depende da estratégia dos mesmos. Por omissão, as índices B-Tree guardam as entradas numa ordem ascendente. Assim, uma pesquisa de um índice duma determinada coluna x produz um output equivalente a "ORDER BY x", ou "ORDER BY x ASC", ou até mesmo "ORDER BY x ASC NULLS LAST". Temos também as especificações "DESC"e "NULLS FIRST" Combinação de índices Um índice multi-coluna só consegue processar queries nas quais, na clausula WHERE, as operações às suas colunas estão ligadas por AND. Imaginando um índice (x,y), não podemos usar directamente o índice para processar a query "WHERE x=11 OR y=23". O PostgreSQL goza de um mecanismo que é a combinação de índices. Se por exemplo, tivermos um índice na coluna x e um índice na coluna y e fizermos a query "SELECT * FROM <table_name> WHERE x=11 AND y=23", o PostgreSQL usa, separadamente, o índice em x, para buscar as linhas que passam a condição x=11, e o índice em y, par abuscar as linhas que passam a condição y=23. Para cada resultado, o PostgreSQL prepara um bitmap que diz quais as linhas que respondem à condição. Depois, é aplicar o AND (ou o OR, se for o caso) a cada elemento do bitmap. É, no entanto, de salientar que esta combinação de índices estraga a ordenação dos mesmos, dado que os bitmaps estão ordenados de acordo com a ordenação física (em disco) dos dados. Se um "ORDER BY"for requerido na query, é preciso fazê-lo no final Índices únicos Os índices podem forçar a unicidade do valor de uma coluna, ou a unicidade do valor combinado de mais de uma coluna. 11

13 Actualmente, apenas os índices B-Tree podem ser declarados como únicos. Quando é declarado um índice sobre uma determinada coluna, não há repetição de valores na mesma. Os valores NULL não são considerados únicos, pelo que pode haver mais que um. Um índice multi-coluna único impede que as colunas cobertas pelo índice tenham o mesmo valor em múltiplas linhas. O PostgreSQL já cria índices únicos automáticamente quando são definidos "unique constraints"ou chaves primárias. É a unicidade do índice que assegura a unicidade da chave primária ou que satisfaz a "constraint" Indexação em expressões É possível criar índices como expressões das colunas. Por exemplo, se quisermos fazer testes "case-insensitive", normalmente passamos tudo para lowercase. Em vez disso, podemos criar um índice assim: CREATE INDEX test1\_lower\_col1\_idx ON test1 (lower(col1)); Outro exemplo. Se quisermos fazer uma query SELECT * FROM people WHERE (first\_name last\_name) = John Smith ; então vale a pena criar um índice que faça isto por nós. Exemplo: CREATE INDEX people\_names ON people ((first\_name last\_name)); Assim, basta-nos fazer a query SELECT * FROM people WHERE indexed\_expression = John Smith Índices parciais Um índice parcial é um índice que é apenas mantido para um subconjunto de uma tabela. Por exemplo, é possível definir um índice parcial através de um predicado de selecção na criação do mesmo. Assim, estes índices só manterão entradas que satisfaçam a condição. Temos a tabela "tests", criada da seguinte forma: CREATE TABLE tests ( subject text, target text, success boolean,... );" 12

14 Pretendemos que, para um dado subject e target, só exista uma entrada com sucesso (isto é, success = true). Criamos um índice com da seguinte forma: CREATE UNIQUE INDEX tests\_success\_constraint ON tests (subject, target) WHERE success; Neste caso em particular, é bastante útil quando temos poucas entradas com sucesso e muitas sem sucesso. Além de unicidade, também podemos criar índices parciais para excluir valores que não nos interessem, apenas adicionando a cláusula "WHERE <condicao\_desejada>". Exemplo: "CREATE INDEX rich\_accounts ON accounts WHERE balance > 1000" Classes de operadores No PostgreSQL é possível definir uma classe de operadores para uma determinada coluna do índice. Esta classe de operadores define que operadores podem ser utilizados naquela coluna do índice. É claro que os tipos de dados já têm um grupo de operadores associados por omissão. A grande utilidade desta funcionalidade baseia-se na possibilidade de definir operadores para tipos de dados complexos, cujos operadores por omissão podem não ser adequados. Uma classe de operadores é um subconjunto duma estrutura denominada de família de operadores, a qual serve para definir classes de operadores de tipos de dados semelhantes, permitindo a inter-utilização desdes tipos nos índices e consultas sobre os mesmos. 13

15 Capítulo 2 MySQL 2.1 Armazenamento O MySQL suporta vários motores de armazenamento (storage engines), que servem de suporte para diferentes tipos de tabelas. Existem dois tipos de storage engines, que são: Transacionais Não-Transacionais Ao longo do relatório vamo-nos focar no storage engine InnoDB, mas existem mais: MyISAM motor de armazenamento por defeito do MySQL, e consequente o mais utilizado. InnoDB motor transacional (compatível com ACID), assim possui commit, rollback e recuperação de falhas. Memory Os dados são todos guardados em RAM, possuindo um acesso extremamente rápido. Merge Útil para bases de dados bastante grandes, pois possibilita juntar várias tabelas de MyISAM num único objecto. Apenas para citar alguns Armazenamento Físico das Bases de Dados O InnoDB armazena toda a sua informação (tabelas, índices...) num tablespace, que por defeito apenas existe um para guardar toda a informação relativa a todas as bases de dados. O tablespace consiste numa base de dados de páginas onde cada página tem 16KB de tamanho. As páginas estão 14

16 organizadas em extents com 1MB de tamanho (64 páginas consecutivas). Os ficheiros que estão contidos no tablespace são denominados de segments. Desde que o InnoDB utiliza uma organização baseada em clustered indexes, as páginas que são folha do índice contêm a informação actual do record. Os índices secundários são construídos nas páginas dos clustered indexes. Uma página tem a seguinte estrutura: Fill Header, conté a informação sobre a directoria da página dentro do segmento Page Header, contém meta informação acerca da própria página Infimum and Supremum records User Records, contém os registos inseridos pelos utilizadores. Free Space, espaço livre em cada página como o próprio nome diz Page Directory, parte da página que tem um número variável de apontadores para os records. Por vezes estes apontadores são chamados de "slots". O InnoDB não tem um slots para cada record na página, pois em vez disso numa página inteira existe um slot para cada seis records. Fill Trailer,esta secção da página contém a checksum da informação da página, para usar no caso de ter que verificar erros no conteúdo da mesma. Visto que os record no InnoDB podem ter tamanho variável, podemos dizer é usado slotted pages para implementar este tipo de registos Tuplos Tuplos são as linhas de uma tabela onde estão os dados, são guardados em páginas de um tablespace. O tamanho máximo que cada cada tuplo pode ter é de aproximadamente metade de uma página, ou seja, 8000 bytes, não contando com objectos variáveis (VARBINARY, VARCHAR, BLOB e TEXT). Uma curiosidade é que para colunas LONGBLOB e LONGTEXT o tamanho tem que ser inferior a 4GB, e o tamanho de todo o tuplo tem de ser inferior 4GB. Outro aspecto é que se o tamanho de um tuplo for inferior a metade de uma página, então esse tuplo é guardado todo numa só página. Se assim não for, as colunas que forem variáveis são divididas por várias páginas até o tuplo caber na metade de uma página (overflow-pages). 15

17 2.1.2 Sistema de gestão do buffer O InnoDB possui o seu próprio buffer, para guardar a informação e os índices na memória, denominado buffer pool. Este buffer funciona como uma lista, usando o algoritmo LRU (least recently used), mas com uma pequena variante utiliza o midpoint insertion strategy que divide a lista em duas sublistas: À cabeça da lista, uma sublista de blocos que foram acedidos recentemente (denominados "young ). Na cauda da lista, uma sublista com os blocos que foram menos acedidos recentemente. Com isto, ficam na primeira sublista os blocos que são constantemente usados por queries e na segunda sublista ficam os blocos menos usados e com maior probabilidade de serem removidos. Algoritmo LRU do InnoDB em detalhe: 3/8 do buffer pool é dedicado à segunda sublista, ou seja, dos blocos menos usados. O centro da lista marca o ponto onde a cauda da sublista dos blocos mais usados coincide com a cabeça da sublista dos blocos menos usados. Quando o InnoDB lê um bloco para o buffer, esse bloco é inserido no ponto médio (cabeça da sublista dos blocos menos usados) Ao fazer um acesso a um bloco da sublista dos blocos menos usados, esse mesmo bloco é movido para a cabeça do buffer pool, ou seja, para a cabeça da sublista dos blocos mais recentemente usados. Conforme forem feitas operações na base de dados, os blocos que não são acedidos são movidos para a cauda da respectiva sublista. Eventualmente, um bloco (da sublista dos menos recentemente usados) que se mantenha inutilizado por um largo período de tempo, é descartado. Através das instruções Insert e Delete o buffer pool guarda os dados alterados para que a escrita no disco seja bastante mais rápida Particionamento No MySQL existem motores de armazenamento que não suportam o particionamento, mas o motor que estamos a estudar (InnoDB) suporta. A partição de tabelas tem apenas a função de optimizar as querys, e os tipos de partição são: Range (Intervalo) - secção

18 List (Lista) - secção Hash (Hash) - secção Key (Chave) - secção Columns (Colunas) - secção Subpartitions (Sub partições) - secção Iremos usar a seguinte tabela como exemplo, para explicar cada tipo de partição. CREATE TABLE employees ( id INT NOT NULL, fname VARCHAR(30), lname VARCHAR(30), hired DATE NOT NULL DEFAULT , separated DATE NOT NULL DEFAULT , job_code INT NOT NULL, store_id INT NOT NULL ); Partição por intervalo Permite criar várias partições que vão conter valores que estão dentro de um intervalo, através do comando VALUES LESS THAN para especificar esses mesmos valores, que não se sobrepõem. Exemplo: PARTITION BY RANGE ( store\_id ) ( PARTITION p0 VALUES IN (1, 4, 7, 10), PARTITION p1 VALUES IN (2, 5, 8, 11), PARTITION p2 VALUES IN (3, 9, 14, 17), PARTITION p3 VALUES IN (6, 12, 13, 15, 18) ); Partição em lista Método bastante parecido ao Range, com a diferença de neste modo se poder definir uma lista de valores específicos que se pretende em cada partição. Exemplo: PARTITION BY LIST(store\_id) ( PARTITION pnorth VALUES IN (3,5,6,9,17), PARTITION peast VALUES IN (1,2,10,11,19,20), PARTITION pwest VALUES IN (4,12,13,14,18), PARTITION pcentral VALUES IN (7,8,15,16) ); 17

19 Partição em Hash Neste caso temos de escolher o nome do campo no qual queremos que seja aplicada a função de hashing e o número de partições. Exemplo: PARTITION BY HASH(store_id) PARTITIONS 4; Partição em chave O particionamento é feito através da chave primária, no caso de estar definida, se não usa o atributo UNIQUE da tabela se estiver definido como NOT NULL. Exemplo: PARTITION BY KEY() PARTITIONS 2; Partição em colunas Variantes das partições Range e List: Range Column (Colunas por intervalos) Método de partição semelhante ao Range, com as seguintes diferenças: Não aceita expressões, só nomes de colunas Aceita uma lista de uma ou mais colunas É baseado em comparações entre tuplos em vez comparações entre valores escalares. Não está restrito a colunas de inteiros, podendo-se usar colunas de strings, DATE e DATETIME. Exemplo: PARTITION BY RANGE COLUMNS(a,d,c) ( PARTITION p0 VALUES LESS THAN (5,10, ggg ), PARTITION p1 VALUES LESS THAN (10,20, mmmm ), PARTITION p2 VALUES LESS THAN (15,30, sss ), PARTITION p3 VALUES LESS THAN (MAXVALUE,MAXVALUE,MAXVALUE) ); List Column (Colunas por intervalos) Método de partição semelhante ao List, as seguintes diferenças: Aceita o uso de múltiplas colunas como chave. 18

20 Não está restrito a colunas de inteiros, podendo-se usar colunas de strings, DATE e DATETIME. Exemplo: PARTITION BY LIST COLUMNS(city) ( PARTITION pregion_1 VALUES IN( Oskarshamn, Högsby, Mönsterås ), PARTITION pregion_2 VALUES IN( Vimmerby, Hultsfred, Västervik ), PARTITION pregion_3 VALUES IN( Nässjö, Eksjö, Vetlanda ), PARTITION pregion_4 VALUES IN( Uppvidinge, Alvesta, Växjo ) ); Partição em subpartições Este método não é mais do que voltar a particionar uma partição que seja feita anteriormente, ou seja, ao fazer uma partição de qualquer tipo (List, Range, Key...) pode-se voltar a particionar usando o subpartition. Exemplo: PARTITION BY RANGE( YEAR(purchased) ) SUBPARTITION BY HASH( TO_DAYS(purchased) ) SUBPARTITIONS 2 ( PARTITION p0 VALUES LESS THAN (1990), PARTITION p1 VALUES LESS THAN (2000), PARTITION p2 VALUES LESS THAN MAXVALUE ); Vantagens do uso de partições As vantagens do uso de partições assentam essencialmente em 3 aspectos: Armazenar mais dados numa determinada tabela. Remoção e inserção facilitada, bastando remover/inserir a(s) partição(ões). Otimização nas consultas à base de dados, podendo-se fazer os acessos somente às partições certas, excluindo dados que sejam desnecessários. 19