Grupo 14 Márcio Sousa (41074) Filipe Milheiro (41338) João Marques (40354)

Transcrição

1 MySql Análise de Sistema de Gestão de Base de Dados Grupo 14 Márcio Sousa (41074) Filipe Milheiro (41338) João Marques (40354)

2 Índice Índice Introdução Introdução histórica e aplicabilidade do sistema estudado Notas sobre instalação do sistema Cobertura de SQL Extensões do MySQL Diferenças entre MySQL e o SQL padrão Linguagem de manipulação de dados (DML) Declaração INSERT Declaração SELECT Declaração UPDATE Linguagem de definição de Dados Armazenamento e Estrutura de Ficheiros InnoDB Buffer Pool Sistema dos ficheiros Indexação e Hashing Estruturas de Dados de Indexação Tipos de Indices Clustered Index Secondary index (Nom-Clustered Index) FullText Index Hashing Adapatvid Index Rehashing Processamento e optimização de perguntas Operações básicas Junção Nested-Loop Join Algorithm Block Nested-Loop Join Algorithm Ordenação

3 The Index Merge Intersection Access Algorithm The Index Merge Sort-Union Access Algorithm The Index Merge Union Access Algorithm Mecanismos para expressões complexas Materialização Planos de execução Estimativas Gestão de transacções e controlo de concorrência transacções Nested transactions Tratamento das transacções Isolamento Tipos de Locks Tratamento aos pedidos de lock Detecção e Recuperação Níveis de granularidade Row-level Locking Table-level Locking Níveis de Isolamento Sintaxe do isolamento Consistência Atomicidade e Durabilidade Rollback segment Sintaxe de Savepoints Suporte para Bases de Dados Distribuídas Outras características do sistema estudado Web Semântica Segurança e Multi-utilizador Comparação com o Oracle 11g Armazenamento e file structure Indexação e Hashing Processamento e optimização de perguntas

4 9.4 - Gestão de transacções e controlo de concorrência

5 1. Introdução Este relatório foi elaborado no âmbito da cadeira de Sistemas de Base de Dados, e é apresentado o MySQL, um dos sistema de gestão de base de dados mais populares mundialmente. O MySQL está divido por vários motores de armazenamento diferentes. O InnoDB é o motor de base de dados atualmente implementado por default pelo MySQL. Neste relatório é abordado várias das características deste motor de armazemanento. No capítulo 2 é abordado a cobertura que o sistema faz do standard SQL. É referido a sua cobertura a nível de DML (o que suporta no select, no insert, no update) e DDL (que tipo de restrições suporta, suporta ou não assertions, trigger, chaves estrangeiras,etc). No capítulo 3 é explicado a estrutura dos ficheiros e armazenamento no InnoDB, enquanto que no capítulo 4 incide-se mais na indexação e hashing. No capítulo 5 são descritos o processamento e optimização de perguntas realizadas, enquanto que no capítulo 6 abordamos a gestão de transacções e controlo de concorrência. No capítulo 7 suporte para bases de dados distribuidas, seguida de outras caracteristicas do sistema estudado. E por último é efetuada a comparação com o Oracle11g no capítulo Introdução histórica e aplicabilidade do sistema estudado O MySQL é um Sistema de Gestão de Base de Dados (SGBD) que utiliza a linguagem SQL (Structured Query Language) como interface. Teve origem na década de 90 por três escandinavos: David Axmark, Allan Larsson e Michael Widenius, devido a necessitarem de de uma interface SQL compatível o um sistema de rotinas ISAM que utilizavam. Inicialmente tentaram msql, mas depressa concluiram que msql não era adequado após uns testes. Foi daí que resultou uma nova interface, o SQL, desenvolvida por eles próprios, chamada de MySQL. O MySQL cresceu em parte devido à sua capacidade de operar em várias linguagens de programação, C, C++, Java, PHP, etc... O MySQL por permite também um rápido acesso, portabilidade (devido à sua compatibilidade com vários drivers) e tornou-se cada vez mais utilizado, especialmente no desenvolvimento de aplicações WEB, embora possa ser usado em qualquer outra área. O MySQL é desenvolvido e distribuído por meio de duas licenças (dependendo do uso da ferramenta), sendo a sua maioria de uso livre. Esta é baseada nas cláusulas da GNU- GPL(General Public License), que estabelece o que se pode ou não fazer com a ferramenta. 4

6 1.2 Notas sobre instalação do sistema A MySQL encontra-se disponível online em vários formatos e é possível aceder ao código fonte. A instalação deste é bastante simples. Neste momento o MySQL apresenta suporte para uma grande variedade de sistemas operativos (Windows, Oracle Linux, Solaris, FreeBSD, Mac OS X, etc..). 5

7 2.Cobertura de SQL Neste capítulo iremos descrever a cobertura que o MySQL faz do Standard SQL, assim como a sintaxe dos vários comandos, ou seja, tomando como partida o nível DML (comandos select, insert, update e delete) e o nível DDL (procedures, triggers, chaves estrangeiras, etc), abordaremos os principais aspectos a ter em conta na implementação do MySQL. 2.1 Extensões do MySQL O MySQL fornece extensões que poderão estar indisponíveis noutros sistemas de base da dados. Caso não sejam tomadas precauções, a portabilidade do código para outros servidores SQL poderá ficar comprometida. /*! MySQL-specific code */ Para ajudar na resolução de problemas deste tipo, pode-se comentar código específico do MySQL da forma acima (com um caracter! logo a seguir à inicialização da zona comentada). Um servidor MySQL continuará a correr o que está comentado, como se fosse código normal, enquanto que os outros tipos de servidores ignoram essa secção. Se for adicionado um número a seguir a!, o código dentro da secção comentada apenas será executado por servidores MySQL com versão superior ao número especificado 2.2 Diferenças entre MySQL e o SQL padrão O MySQL executa algumas operações de forma diferente dos padrões ANSI SQL e ODBC SQL em alguns casos. Algumas das diferenças mais marcantes são: Suporta chaves estrangeiras. Suporta transacões e operações atómicas. Declaração UPDATE: Se uma coluna de uma tabela for acedida para a atualização, o UPDATE utiliza o valor atual da coluna. Este comportamento difere da do SQL padrão: UPDATE t1 SET col1 = col1 + 1, col2 = col1; 6

8 2.3 Linguagem de manipulação de dados (DML) DML não é mais do que o sub conjunto de funcionalidades do SQL que permitem manipular dados, neste caso, as suportadas pelo MySQL. Em seguida, faremos a abordagem à parte de DML coberta pelo MySQL, para os casos do SELECT, INSERT e UPDATE Declaração INSERT O INSERT é uma declaração SQL que adiciona um ou mais registos a uma tabela numa base de dados relacional. No MySql, o comando INSERT possui várias formas de syntaxe: INSERT [LOW_PRIORITY DELAYED HIGH_PRIORITY] [IGNORE] [INTO] tbl_name [PARTITION (partition_name,...)] [(col_name,...)] {VALUES VALUE} ({expr DEFAULT},...),(...),... [ ON DUPLICATE KEY UPDATE col_name=expr [, col_name=expr]... ] No caso acima, o utilizador explicita os valores que estão inseridos numa trabela pela instrução. Também se pode utilizar INSERT.. SET, uma extensão do MySql sobre o Sql. INSERT [LOW_PRIORITY HIGH_PRIORITY] [IGNORE] [INTO] tbl_name [PARTITION (partition_name,...)] [(col_name,...)] SELECT... [ ON DUPLICATE KEY UPDATE col_name=expr [, col_name=expr]... ] Neste caso seguinte, o INSERT.. SELECT, o utilizador cria novos registos com base em valores já existente numa tabela na base de dados. Por fim no terceiro caso os novos registos vão ser criados a partir de uma expressão que especifica os registos a criar. Se for especificada a opção ON DUPLICATE KEY UPDATE, e uma linha inserida possui um valor duplicado num índice único ou numa chave primária, o UPDATE será efetuado na mesma Declaração SELECT O Select é usado para obter registos seleccionados de pelo menos uma tabela. 7

9 2.3.3 Declaração UPDATE O Update atualiza uma coluna de registos já existentes numa tabela com valores novos. 2.4 Linguagem de definição de Dados O Linguagem de definição de dados é o que permite controlar as tabelas e indices presentes na base de dados. Funções como CREATE, DROP, TRUNCATE e RENAME, que conduzem alterações nos esqumas das tabelas na base de dados, são suportados. Triggers estão disponiveis. Um trigger é ativado quando aum evento especifico ocorre na tabela associada. Restrições de vários tipos são suportadas: Restrições para chaves estrangeiras, no caso da InnoDB Restrições para dados erróneos ou invalidados. Este tipo de restrições podem só funcionar caso o modo SQL esteja strict. Resrições para a avaliação de chaves primárias e indices únicos. 3 Armazenamento e Estrutura de Ficheiros Neste capitulo é abordado.o armazenamento e estruturamento de ficheiros do InnoDB. 3.1 InnoDB Buffer Pool O InnoDB mantém uma área de armazenamento denominada de buffer pool que funciona como uma cache para dados e indices na memória. Esta área é gerida como se fosse uma lista, utilizando o método do least recently used (LRU). Quando é necessário espaço para adicionar um novo bloco à pool, InnoDB remove o bloco menos uado recentemente and insere o novo bloco na lista. Quanto maior for a buffer pool, mais o InnoDB actua como uma base de dados na memória. Alguns outros detalhes internos: Na cabeça da pool, existe uma sublista de blocos que foram acedidos recentemente. Na cauda, uma sublista de blocos antigos que foram menos acedidos recentemente. 3/8 da pool é dedicada à sublista dos blocos menos usados. 8

10 3.2 Sistema dos ficheiros Os dados são guardados em tablespaces. O tablesapce 4 Indexação e Hashing Os índices são usados com o objectivo de tornar as pesquisas sobre as tabelas mais rápidas e robustas. As pesquisas no MySQL sem indexação são caras porque resultam a uma procura linear, o não é nada eficiente para base de dados gigantescas e não só. Existem vários tipos de índices. O MySQL armazena as suas informações dos dicionários de dados das tabelas nos ficheiros com extensão frm. Isto é horizontal a todos os store engines que o MySQL possui, todas as tabelas do InnoDB também têm a sua própria entrada no dicionário de dados interno do InnoDB dentro do tablespace. Quando o MySQL elimina uma tabela ou uma base de dados, ele tem de eliminar um ou mais ficheiros.frm de acordo com as correspondentes entradas no dicionário interno do InnoDB. 4.1 Estruturas de Dados de Indexação No InnoDB os índices são todos do tipo B-Tree, onde os registos são armazenados nas paginas das folhas da arvore. O tamanho por omissão de uma página de índice é de 16 KB. Após a inserção de um novo registo, o InnoDB tenta deixar 1/16 de páginas livres para futuras inserções e de seguida actualiza o ficheiro de índices. O InnoDB não suporta operação de alteração do tamanho das páginas dos índices. Versões diferentes do InnoDB podem ter páginas de tamanhos diferentes, o que leva ou não a algumas incompatibilidades entre versões. 4.2 Tipos de Indices O InnoDB suporta especificar 3 tipos que indicies sobre as tabelas: clustered index. É como são chamadas as chaves primarias no innodb. sencondary index. FullText Index. só a partir da versão Clustered Index Todas a tabelas no InnoDB têm um index espatial conhecido como de clustered index. O innodb usa este tipo de índice para optimizar a maioria das operações de pesquisa e de DML (operação de manipulação dos dados) sobre cada tabela. Este tipo índice é usado nas seguintes situações: 9

11 Se o utilizador criar uma tabela com a chave primária o InnoDB vai usar a chave primária como clustered index. Se o utilizador criar uma tabela sem chave primária o MySQL escolhe o primeiro unique index que tenha apenas colunas NOT NULL como chave primária e por sua o InnoDB usa a chave primária como clustered index. Se o utilizador criar uma tabela sem chave primária e nem unique index o InnoDB gera internamente um hidden clustered index numa coluna contendo os valores ID das Entradas. As Entradas são ordenadas pelo ID que o InnoDB atribui automaticamente. O ID de cada entrada é um campo de tamanho 6 bytes que aumenta automaticamente quando adicionada uma nova entrada na tabela. As entradas são fisicamente ordenadas pela ordem de inserção; Os acessos as entradas de uma tabela através do clustered index são mais rápidos porque, a procura através do índice leva directamente a pagina com os registos da entrada Secondary index (Nom-Clustered Index) No InnoDB todos índices que não são Clustered Index são Secondary Index que são os índices que podem ser criados sobre um subconjunto de colunas de uma tabela. Todos os índices deste tipo contêm as colunas da chave primária da entrada e também as colunas especificadas na criação do Secondary index. A necessidade de adicionar as colunas da chave primária juntamente com as colunas sobre as quais queremos criar o (s) secondary index tem a ver com a forma com que o InnoDB guarda os dados, uma vez que os nós da árvore não armazenam o apontador para a localização física da entrada mas por outro lado armazena os dados da entrada e chave primaria da entrada aponta para estes dados, com isto o processo de procura é mais eficiente do que se não tive a referencia a chave primaria FullText Index Este tipo índice só está disponível no InnoDB a partir da versão do MySQL e só podem ser criados em colunas do tipo CHAR, VARCHAR e TEXT. Este tipo de índice ajuda a aumentar a eficiência das perguntas sobre colunas do tipo texto, perguntas tais como por Exemplo: se o texto contem uma determinada palavra. Sintaxe: CREATE TABLE name (col1, col2,..., FULLTEXT (col1, col2 ) ) 10

12 CREATE INDEX name ON table (column) USING FULLTEXT 4.3 Hashing Apesar do InnoDB não possuir a estrutura de dados para hash index, mas suporta em memória índices deste tipo de forma dinâmica o Adaptive hash index Adapatvid Index O Adaptive hash index é uma implementação de hash index em memória. O InnoDB possui um mecanismo que monitoriza os índices sobre as tabelas e verifica se este pode beneficiar de um índice disperso, então cria-o automaticamente. Este tipo de índice pode ser construído sobre um prefixo do comprimento da chave de pesquisa definida para o índice B-Tree. O InnoDB oferece a possibilidade de desactivar este mecanismo através da opção skip innodb_adaptive_hash_index ao iniciar o servidor Rehashing O MySQL possui um mecanismo de rehash automático que por omissão esta activado e pode ser desactivado com a opção --disable-auto-rehash 5. Processamento e optimização de perguntas Neste capitulo vão abordar os temas de processamento e optimização de perguntas em MySQL. Começamos por falar na linguagem que está por trás de tudo o que se faz em relação à base de dados que é álgebra relacional. É essencial falarmos dela porque esta representa uma pergunta de uma forma standard que nos permite optimizar de uma forma mais rápida (ficando a pergunta mais rápida de executar). Na figura seguinte podemos ver como funciona esse processo de optimização. 11

13 Em termos de optimizador (query optimizer na figura) o objectivo é encontrar a expressão que minimiza o tempo de execução para tal temos de procurar expressões algébricas equivalentes à pergunta feita e estimar o tempo de execução de cada uma Operações básicas As operações básicas que vamos abordar neste subcapítulo são a seleção, a junção e a ordenação Junção Em MySQL as junções entre tabelas são feitas utilizando o algoritmo nested-loop ou variantes do mesmo. O MySQL utiliza um buffer para fazer junções (funciona como uma cache). Esse buffer só é utilizado quando a junção é do tipo ALL ou existem índices. O buffer é alocado quando é necessário fazer um full join entre duas tabelas e libertado logo a seguir à pergunta estar concluída. Em versões mais recentes existe também o algoritmo Batched Key Access (BKA) que está disponível e que usa tanto o utiliza a junção da tabela como o a junção do buffer. 12

14 Este algoritmo suporta inner join, outer join, semi-join, e inclui nested outer joins (também são todos suportados pelo BNL). O maior beneficio deste algoritmo é que melhora a performance da junção devido a uma maior efeciência na exploração da tabela. Segundo a Oracle está algoritmo pode aprimorar a throughput das consultas selecionadas em até 280 vezes Nested-Loop Join Algorithm Este é o mais simples e básico que funciona independentemente da linguagem. O algoritmo funciona da seguinte maneira começa por ler as linhas da primeira tabela em um loop, uma de cada vez, passando cada linha para um loop da tabela seguinte na junção. Este processo é repetido até todas as tabelas estejam unidas Block Nested-Loop Join Algorithm Devido à sua complexidade, fica mais simples de entender o pseudocódigo da sua descrição. A junção que se vai exemplificar é da tabela r junção com a tabela s. for each bloco Br of r for each bloco Bs of s for each tuplo tr in Br for each tuplo ts in Bs se o par (tr,ts) satisfaz a condição θ então adicionar tr ts ao resultado end end end end Na maioria das vezes este é o algoritmo utilizado pelo MySQL. 13

15 Ordenação Existem dois tipos básicos de algoritmos para ordenar e retornar resultados. Temos o metodo original que apenas utiliza as colunas que aparecem na clausula ORDER BY e o metodo modificado que utiliza todas as colunas da pergunta. Ficando a cargo do optimizador escolher que algoritmo deve ser utilizado. O método original lê todas as linhas de acordo com a chave, linhas que não corresponderem com o que se encontra na clausula WHERE são ignoradas e passasse à próxima. Em seguida para cada linha guardamos um par de valores (chave, apontador para a linha) no buffer. O tamanho do buffer encontrasse numa variável do sistema (sort_buffer_size). Caso o buffer fique cheio, é executado um quicksort e guarda-se o resultado num ficheiro temporário (é guardado um apontador para o bloco já ordenado). Estes passos são repetidos até todas as linhas terem sido lidas. Um dos problemas com esta abordagem é que temos de ler duas vezes, uma quando avaliamos a clausula WHERE e outra quando depois de ordenarmos os valores dos pares. O método modificado incorpora a otimização de tal forma que ele registra não apenas o valor da chave e o apontador mas as colunas necessárias para a pergunta. Isto evita estar a ler duas vezes. Nos três subcapítulos que se seguem apresentamos três métodos de ordenação utilizando índices The Index Merge Intersection Access Algorithm O algoritmo pode ser utilizado quando na cláusula WHERE foi convertido para várias condições extensivas de chaves diferentes combinadas com o operador logico AND e cada condição é uma das seguintes: Se todas as colunas usadas na pergunta utilizam índices e as linhas completas não são recuperadas; Se utiliza índices que não cobrem todas todas as colunas utilizadas na pergunta e as linhas completas só são recuperadas quando o valor das condições para todas as chaves utilizadas é satisfeito; Se uma das condições de junção são condições sobre a chave primaria da tabela e não é utilizada para recuperação da linha, mas é usado para filtrar linhas obtidas utilizando outras condições. 14

16 The Index Merge Sort-Union Access Algorithm O algoritmo pode ser utilizado quando na cláusula WHERE foi convertido para várias condições extensivas de chaves diferentes combinadas com o operador logico OR mas para cada Index Merge union algorithm não é aplicável The Index Merge Union Access Algorithm O critério para aplicar este algoritmo é parecido ao método Index Merge intersection algorithm. O algoritmo pode ser utilizado quando na cláusula WHERE foi convertido para várias condições extensivas de chaves diferentes combinadas com o operador logico OR e cada condição é uma das seguintes: Tem como condição a chave primaria de uma das tabelas; Metodo Index Merge intersection algorithm é aplicável Mecanismos para expressões complexas Existem três tipos de expressões complexas que são a materialização, o pipelining e paralelização. Mas o MySQL só suporta a materialização Materialização A materialização é controlada por uma flag que diz se estamos a utilizar ou não materialização. Neste caso vamos abordar a optimização de subquerys utilizando materialização. A sua utilização é uma estrategia que permite uma maior eficiência no processamento de subquerys. A materialização utiliza tabelas temporárias que evita a rescrita das mesmas subquerys e faz com que seja possível executar a subquery uma única vez e também aumenta a velocidade de execução da pergunta. A tabela temporária só é criada uma única vez para cada subquery que mais tarde pode ser utilizada novamente caso esta seja executada outra vez (sendo que desta vez basta consultar a tabela temporária). A tabela tem um índice (que é único) que permite fazer consultas rápidas e com custo baixo. Sendo que como o índice é único não existem duplicados. Em geral estas tabelas são guardadas em memoria mas se ficarem demasiados grandes podem passar para disco. Este mecanismo pode ser aplicado em qualquer lado da pergunta ( havendo alguns requisitos que não serão aqui apresentados por serem demasiado complexos). 15

17 A verificação da utilização da materialização pode ser feita através da visualização dos planos de execução Planos de execução Um plano de execução serve para otimizar perguntas, onde o otimizador faz as mesmas escolhas cada vez que executa a mesma pergunta de modo a garantir a consistência. Para vermos os planos de execução de uma pergunta em MySQL podemos utilizar a palavra EXPLAIN (ou DESCRIBE). A palavra DESCRIBE é mais utilizada na visualização da estrutura de uma determinada tabela. Embora o parser do MySQL os trate da mesma maneira. Em versões antigas do MySQL só era possível fazer planos de execução para expressões que tivessem a palavra SELECT. Hoje em dia é possivel fazer planos de execução relativos a SELECT, DELETE, INSERT, REPLACE, e UPDATE. No plano de execução podemos ver a ordem pela qual o MySQL executa a pergunta em si. Existem mais dois tipos de EXPLAIN um que é utilizado para tabelas que se encontram particionadas ( EXPLAIN PARTITIONS) e outro quando o normal não nos dá toda a informação que queremos obter (EXPLAIN EXTENDED). Com a ajuda desta palavra chave podemos ver onde devemos colocar índices nas tabelas para aumentar velocidade de execução de perguntas relacionadas com as mesmas Estimativas Um dos grandes problemas das estimativas é quando se abre as tabelas pela primeira vez porque se tem de processar todas as estimativas e isso exige muito I/O. No InnoDB as estimativas não são guardadas permanentemente nas tabelas, mas é feito de cada vez que abrirmos pela primeira vez uma tabela, ou quando um evento ocorre (exemplo: ANALYZE TABLE) ou até dum certo intervalo de tempo (isto leva a um grande impacto no servidor e nas perguntas feitas). Os valores que mais interessão numa estimativa são o valor da cardinalidade e o número total de linhas da tabela ou entradas de índices. Existe uma característica no MySQL que se chama estimativas persistentes que guardam o índice das estimativas para as tabelas guardadas no disco, fornecendo um melhor plano de estimativa para as perguntas. A operação que manipula estimativas é o ANALYZE TABLE que mostra uma estimativa da cardinalidade, várias execuções consecutivas deste comando podem gerar diferentes estimativas. É muito utilizado para otimizar junções e índices. 16

18 Isso leva a que o optimizador por vezes escolha diferentes planos de execução com base nessas estimativas dependendo do índice que se escolhe. No InnoDB as estatísticas não são guardadas em disco mas sim em memória. Quanto mais exploramos as estatísticas melhores resultados podemos obter. Se pretendermos um plano de perguntas mais estavel e mais rapido é possível utilizar uma tabela de sistema para guardar as estimativas. Sendo que ficam desactivadas o calculo das estimativas, para tal fica a cargo do utilizador actualizar as mesmas de tempos em tempos (com o comando ANALYZE TABLE). 6. Gestão de transacções e controlo de concorrência 6.1 transacções O InnoDB tem suporte para transacções com propriedades ACID (Atomicidade, Coerência, Isolamento e Durabilidade), suporta as operações de commit, rollback e crash-recovery. O modelo de transacções usado pelo InnoDB tem como objectivo combinar o melhor das multi-versionig databases com o tradicional protocolo Two-phase locking. Por omissão o nível de granularidade nos lockings é row level e as operações de read são não-bloqueantes. Os utilizadores podem realizar de lock a cada entrada da tabela ou a um conjunto de entradas aleatórias, sem causar quaisquer problemas de exaustão de memória Nested transactions O innodb não possui suporte para nested transactions Tratamento das transacções No caso do InnoDB, toda a actividade de um utilizador ocorre dentro duma transacção. Caso o modo autocommit estiver activo, cada instrução SQL é tratada como uma transacção. Assim, o MySQL faz commit após cada instrução, sempre que, esta não termine com um erro. Se ocorrer um erro, automaticamente é feito um rollback às operações que originaram o erro. Nas sessões que têm a opção de autocommit activa, é possível realizar transacções com instruções múltiplas, iniciando-as de forma explícita através do comando START TRANSACTION ou BEGIN, e terminando-as com COMMIT ou ROLLBACK. Quando estamos a lidar com sessões com a opção de autocommit desactivada, a sessão tem sempre uma transacção em aberto e usando os comandos COMMIT ou ROLLBACK, a transacção corrente termina, e inicia uma nova. 17

19 Sintaxe para lidar com as transacções é a seguinte: [WITH CONSISTENT SNAPSHOT] - Dá início a uma leitura consistente. Produz o mesmo efeito que um START TRANSACTION seguido de um SELECT de qualquer tabela InnoDB. Esta opção não causa a alteração do nível de isolamento transaccional corrente e, portanto, garante que a cópia (snapshot) é consistente apenas se o nível e isolamento actual for um que permita leituras consistentes (REPEATABLE READ ou SERIALIZABLE). [AND CHAIN] Esta cláusula faz com que uma nova transacção (em espera) inicie logo de imediato ao término da transacção corrente. O nível de isolamento da transacção que se inicia, será igual ao da corrente. [RELEASE] Esta cláusula faz com que o servidor se desconecte da actual sessão do cliente assim que termine transacção 6.3 Isolamento Para lidar com o paradigma de isolamento, o InnoDB utiliza protocolos baseados em locks Tipos de Locks Por omissão, no InnoDB o nível de granularidade é row-level, para o qual há dois modos de lock: Partilhado (S) permite a uma transacção ler um tuplo; Exclusivo (X) permite a uma transacção actualizar ou remover um tuplo Tratamento aos pedidos de lock O InnoDB suporta ainda a possibilidade de termos várias granularidades a actuar, que permite a coexistência de locks, ou sobre um registo, ou sobre uma tabela inteira. Na prática, isto é conseguido usando mais dois modos de locking os chamados intention locks: 18

20 Intention shared (IS): se uma transacção pretender fazer shared Locks a tuplos da tabela. Intention exclusive (IX): se uma transacção pretender fazer exclusive locks a tuplos da tabela. Sintaxe: SELECT LOCK IN SHARE MODE (IS lock). SELECT FOR UPDATE ( IX lock). Estes locks aplicados a tabelas são tratados da seguinte forma: Antes de uma transacção poder adquirir um shared lock sobre tuplo de uma tabela, deve primeiro adquirir um IS lock na tabela. Antes de uma transacção poder adquirir um exclusive lock num tuplo de uma tabela, deve primeiro adquirir um IX lock na tabela. O principal objectivo destes tipo de locks (IS e IX) é apenas mostrar que tem um tuplo bloqueado, ou então vai bloquear tuplo numa tabela. A seguinte tabela mostra a compatibilidade entre os vários tipos de locks : Um lock é concedido a uma transacção se for compatível comos locks existentes. Caso haja algum conflito com algum lock já existente, a transacção tem que esperar até que os (s) lock (s) que estão a provocar o conflito sejam libertados. Se houver um conflito entre a solicitação de um lock com um lock existente e este não pode ser concedido, uma vez que isso causaria um deadlock, ocorre um erro Detecção e Recuperação O InnoDB automaticamente detecta situações de deadlock, e quando tal acontece, faz rollback à (s) transacção (ões) que deram origem ao deadlock, faz isso para minimizar o número de rollbacks necessários. Por outro lado, há situações em que não é possível detectar deadlocks: 19

21 Quando é feito um table lock, usando a instrução LOCK TABLES; Ou quando são feitos locks, por outra storage engine, que não o InnoDB. Nestes casos, o problema pode ser resolvido pelo utilizador através da indicação do parâmetro innodb_lock_wait_timeout, que define o tempo máximo que uma transacção pode ficar a espera de um lock antes de causar rollback na transacção que detém o lock. Por sua vez, há outros casos em que os locks são mantidos e, isso acontece se houver apenas uma instrução SQL, que tem como resultado um erro e, consequentemente um rollback. Tal é possível, porque o InnoDB armazena os row locks num formato que, seja impossível determinar por qual instrução o bloqueio foi gerado. 6.4 Níveis de granularidade O InnoDB suporta essencialmente dois níveis de granularidade através de protocolos de lock, o Row-Level lock e o Table-Level lock. Por omissão usa o row-level locking Row-level Locking Este nível de granularidade subdivide-se em três modos: Record lock o lock é feito sobre os registos de índice, mesmo que na tabela não estejam definidos. Quando estes não estão definidos, o InnoDB cria um clustered index oculto e usa-o para a operação de lock; Gap lock é um lock que funciona como um mecanismo de reserva, isto porque, bloqueia espaços livres entre registos de índice, ou bloqueia espaços livres no início ou depois do último registo de índice. Next-key locking Combina os dois modos anteriores. Quando é feita uma pesquisa, faz locks partilhados ou exclusivos nos registos de índice que encontra. No entanto, como este modo também afecta os espaços livres entre registos de índice, os registos que antecedem o registo de índice, são afectados também. Isto origina que, quando uma sessão tem o lock (S ou X) sobre um registo reg, uma outra sessão é incapaz de fazer inserções dum novo registo índice no espaço livre imediatamente anterior a reg. Em certas circunstâncias, as leituras consistentes (não bloqueantes) não são convenientes, sendo necessárias leituras bloqueantes. No InnoDB existem dois tipos de leituras bloqueantes: SELECT... LOCK IN SHARE MODE define um share mode lock nos registos que são lidos. Este modo permite que outras sessões tenham acesso aos registos sem os modificar. Cada leitura vê a informação mais recente e cria um shared mode lock nos registos lidos. Assim, previne-se que outras sessões actualizem ou eliminem esses 20

22 registos lidos. Além disso, se a informação mais recente pertencer a uma transacção ainda incompleta (uncommited) doutra sessão, têm-se que esperar que ela termine. SELECT... FOR UPDATE permite bloquear outras sessões de realizarem operações SELECT... LOCK IN SHARE MODE ou de ler em certos níveis de isolamento. As leituras consistentes ignoram quaisquer locks feitos sobre registos que estão presentes numa vista de leitura. Quando a transacção termina com commit ou rollback estes locks são descartados Table-level Locking O InnoDB suporta também locks à tabela toda, em vez dum conjunto específico como no row-level. Quando é usada a instrução LOCK TABLES, é usado este tipo de bloqueio. Sintaxe: LOCK TABLES tbl_name [[AS] alias] lock_type [ tbl_name [[AS] alias] lock_type]... lock_type: READ [LOCAL] [LOW_PRIORITY] WRITE UNLOCK TABLES 6.5 Níveis de Isolamento O InnoDB possui 4 níveis de isolamento: READ UNCOMMITTED - as operações de selecção actuam duma forma não bloqueante, mas é possível visualizar uma versão mais recente dos dados. Assim, usando este nível de isolamento, as leituras não são de todo consistentes. READ COMMITTED Cada leitura consistente (não bloqueante), dentro da mesma transacção, actualiza e lê a sua própria cópia mais recente. No caso das leituras bloqueantes (quando é usada granularidade em SHARE MODE), o InnoDB apenas bloqueia os registos de índice, não os espaços livres existentes entre eles. Assim, é possível fazer inserções de registos no espaço livre a seguir aos registos que se encontram bloqueados. Nas operações de UPDATE e DELETE, o bloqueio depende de, se a instrução usa um unique index na condição de pesquisa: Se a condição WHERE for uma igualdade então bloqueia apenas o registo que é encontrado na pesquisa. 21

23 Se a condição WHERE for uma comparação então bloqueia os registos de índice com gap lock ou next-key locking, para os registos que estão abrangidos pelo intervalo de pesquisa. REPEATABLE READ Nível de isolamento por defeito no InnoDB. Nas leituras consistentes, a principal diferença com o READ COMMITED é que, todas as leituras consistentes dentro da mesma transacção lêem a mesma cópia que é estabelecida pela primeira leitura. Isto levanta uma situação em que, se forem efectuadas várias operações de SELECT dentro da mesma transacção, essas operações são consistentes em relação umas às outras. No caso das leituras bloqueantes, o comportamento é idêntico ao nível de isolamento descrito anteriormente. SERIALIZABLE Este nível é idêntico ao REPEATABLE READ. No caso da opção autocommit estar desactivada, o InnoDB implicitamente converte todas as operações de SELECT para SELECT...LOCK IN SHARE MODE. Caso esteja activa, cada operação de selecção é ela própria uma transacção Sintaxe do isolamento Alterar o nível de isolamento por omissão: SET [GLOBAL SESSION] TRANSACTION ISOLATION LEVEL { READ UNCOMMITTED READ COMMITTED REPEATABLE READ SERIALIZABLE } GLOBAL permite definir o nível de isolamento actual para todas as sessões que advenham da sessão actual. As sessões existentes não são afectadas. SESSION define o nível de isolamento actual para todas as operações realizadas dentro da sessão actual. No caso de não ser usada nenhuma das anteriores, define o nível de isolamento para a próxima (não iniciada) transacção realizada dentro da sessão actual. Definir o nível de isolamento no início da execução do servidor: 22

24 [mysqld] transaction-isolation = [ READ-UNCOMMITED READ-COMMITED REPEATABLE-READ SERIALIZABLE ] Consultar o nível de isolamento 6.6 Consistência No InnoDB os problemas de inconsistência são chamados de Phantom Problem. Este tipo de problema acontece dentro duma transacção, quando uma mesma consulta produz resultados diferentes. Exemplo disso é quando uma instrução SELECT é executada duas vezes, mas retorna um tuplo na segunda chamada que não foi mostrada na primeira, a este problema chamado de phantom row. Para prever a ocorrência deste tipo de problemas o InnoDB usa o algoritmo next-key locking. Esta forma de bloqueio, faz com que os registos de índice, que obedeçam aos critérios de pesquisa sejam bloqueados e, também outros registos que estejam num intervalo de índices ou antes ou depois dos registos de índices. É desta forma que, o InnoDB previne a ocorrência de registos ghost no sistema e também para implementar restrições de unicidade. 6.7 Atomicidade e Durabilidade O InnoDB é uma muti-versioned storage engine então, mantém informação sobre estados anteriores dos registos no tablespace, mais especificamente, numa zona conhecida como rollback segment. Internamente, o InnoDB adiciona três campos a cada registo, que é armazenado na base de dados: DB_TRX_ID - Um registo de 6 bytes, que indica a transacção que mais recentemente inseriu ou actualizou o tuplo. No caso da remoção, é tratado como um UPDATE, recorrendo a um bit para identificar tal operação. DB_ROLL_PTR Um registo de 7 bytes conhecido como roll pointer. Este registo serve como apontador para um registo de log escrito no segmento de rollback. Quando o 23

25 tuplo é actualizado, este undo log contem a informação necessária para repor o conteúdo do tuplo antes de ser actualizado. DB_ROW_ID Um registo de 6 bytes, que contem o row ID que incrementa automaticamente assim que um tuplo é inserido. Caso sejam usados clustered index, o índice contém como valor os row ID, senão a coluna DB_ROW_ID nem sequer aparece em qualquer índice. O InnoDB usa este segmento de rollback para repor a base de dados num estado anterior, aquando duma transacção ou para lidar com consistência nas transacções. O mecanismo de rollback usado é o log-based recovery Rollback segment Os logs de rollback estão divididos em duas partes: Insert Undo Log necessários apenas num rollback duma transacção e são descartados assim que é feito commit; Update Undo Log usados para a consistência de transacções. Estes também podem descartados, mas só após existir a garantia que não há nenhuma transacção para a qual foi tirado um snapshot, que possa conter informação necessária para repor o estado mais recente da base de dados. É preciso ter em conta que se senão forem feitos commit regularmente, isso leva a que estes logs ocupem muito espaço no tablespace, facto que compromete a boa eficiência da base de dados. 6.8 Sintaxe de Savepoints SAVEPOINT identifier [ROLLBACK [WORK] TO [SAVEPOINT] identifier RELEASE SAVEPOINT identifier] SAVEPOINT identifier Define um ponto de segurança com o nome identifier. Caso o nome já exista, o savepoint mais antigo é substituído por este novo. ROLLBACK [WORK] TO [SAVEPOINT] identifier permite fazer um rollback para o ponto indicado por identifier, sem que termine a transacção actual. As alterações feitas pela transacção após o savepoint são marcadas como não-concluidas, mas os locks são mantidos. RELEASE SAVEPOINT identifier permite eliminar um dado savepoint anteriormente criado do conjunto actual de savepoint dessa transacção. Ao proceder à eliminação, nenhum commit ou rollback é feito. 24

26 Todos os savepoints de uma transacção são apagados quando esta fazer commit. 7 Suporte para Bases de Dados Distribuídas O nosso trabalho é sobre o engine InnoDB, este em si não tem qualquer suporte para bases de dados distribuídas mas sendo suportado pelo MySQL de forma a lidar com os diferentes tipos de store engine. 8. Outras características do sistema estudado Web Semântica Neste subcapítulo vamos abordar o tema Web Semântica com foco na representação de dados RDF num Sistema Gerenciador de Banco de Dados Relacional (RDBM -> Relational database management) utilizando Jena SBD. Para tal precisamos de ter instalados os seguintes pacotes: - MySQL - MySQLWorkBench - MySQL Connector/J E ainda fazer o download da SDB do site Apache Jena. Em seguida deve ter que definir as variáveis de ambiente no caso de ser Linux são as seguintes: export SDBROOT=/path/to/SDB export PATH=$SDBROOT/bin:$PATH export SDB_USER=root export SDB_PASSWORD=root export SDB_JDBC=/path/to/mysql-connector-java /mysql-connector-java bin.jar Agora já pode utilizar a SDB framework em Java Segurança e Multi-utilizador Em termos de segurança o MySQL utiliza para conexões, queries e para quaisquer operações feitas pelo utilizador umas Listas de controle de acessos ( ACLs -> Access Control Lists) que é uma lista que tem os utilizadores que tem acesso a certos serviços expecificos. 25

27 Suporta também entre as conexões entre clientes e servidores um Protocolo de Camada de Sockets Segura (SSL -> Secure Sockets Layer) que é um protocolo criptográfico que confere segurança na comunicação. No que toca a vários utilizadores tem Row-level locking que consiste numa técnica que bloqueia uma linha para escrita para prevenir outros utilizadores de acederem a informação que está a ser actualizada logo que aumenta a concorrência. Isto é utilizado ao nível das tabelas para suportar simultâneas escritas por vários utilizadores (na Engine InnoDB). A utilização de vários utilizadores é considerada muitas vezes como de não totalmente segura mas isso de facto não é verdade porque vários clientes podem fazer update e obter o valor (ou valores) relativo ao seu cliente sem alterar o valor dos outros clientes. Todo o software MySQL tem multi-threaded, é tambem bastante rápido e robusto. 9. Comparação com o Oracle 11g O MySQL (Engine INNOBD) tem vantagens e desvantagens em relação ao Oracle. As quais vamos abordar neste capítulo. Uma das grandes vantagens do MySQL em relação ao Oracle é o facto de ser open source, por outro lado não possui suporte para redes distribuídas algo que é possível no Oracle Armazenamento e file structure O Oracle tem o seu próprio gerenciamento de buffer, com políticas complexas que são as seguintes: - O Oracle não conta com o sistema de arquivos do sistema operacional subjacente - Uma base de dados em Oracle consiste em tablespaces: - Uma tablespace de sistema contem um classificador de metadados - Uma tablespace de utilizador - O espaço numa tablespace é dividido em segmentos: - Segmentos de dados - Segmentos de índices - Segmentos temporarios (para ordenações) 26

28 - Segmentos de rollback ( para transações) - Os segmentos são divididos em extensões, cada extensão é um conjunto de blocos de dados contíguos. - Um bloco de dados não necessita de ser do mesmo tamanho de um bloco do sistema operativo, mas é sempre um múltiplo Indexação e Hashing Existe apenas uma estrutura de dados para guardar índices no InnoDB que é B-Tree enquanto o Oracle tem duas B-Tree e Bitmap logo neste caso o Oracle tem essa vantagem sobre o InnoBD viste que para algumas situações é muito melhor criar índices de Bitmap. No InnoDB existem três tipos de indices clustered index, sencondary index e FullText Index em contra-ponto no Oracle existem 5 que são o Index-organized tables, o Reverse key indexes, o Descending indexes e o B-tree cluster (para além de bitmap join indexes) Processamento e optimização de perguntas A nível de junções o MySQL apenas Nested-loop join, Block nested-loop join e Indexed nested-loop join enquanto o Oracle tem para além desses Merge-join e Hash-join. Logo o Oracle é muto mais eficiente no que toca a junções porque muitas vezes a utilização de variantes de nested-loop join (caso do InnoDB) é ineficiente em relação aos outros algoritmos implementados pelo Oracle Gestão de transacções e controlo de concorrência Os dois tem suporte para transações com propriedades ACID. O InnoBD tem quatro niveis de isolamento (READ UNCOMMITTED, READ COMMITTED, REPEATABLE READ, SERIALIZABLE) enquanto o oracle tem apenas 2 niveis de isolamento (READ COMMITTED, SERIALIZABLE), logo quem fica a ganhar é o InnoDB. 27