SQLITE INTERNAMENTE

SQLITE INTERNAMENTE

Antes de iniciarmos a análise interna do SQLite é importante ressaltar que que não é necessário o estudo do funcionamento interno do banco de dados para trabalhar com o mesmo. Desta forma, o entendimento dos conceitos aqui descritos não se faz, teoricamente necessários. Fato é que está aula é resultante de um estudo pessoal qu eu Cláudio realizei, logo, decidi produzir este material, haja vista que informações e conhecimento nunca é demais!

O banco de dados SQLite, além de armazenar informações, gerenciar os relacionamentos, armazenar procedimentos, gerenciar os índices e etc, ainda possui um interpretador de código SQL que, tem por objetivo, gerar código para a máquina virtual interna do SQLite. Desta forma, ao manipularmos informações, nossas queries são convertidas para uma linguagem própria e posteriormente, interpretada pela máquina virtual do banco de dados.

Ainda que o executável do SQLite possua um tamanho ínfimo e, para o seu funcionamento não existe a necessidade de manter uma instância em execução, a quantidade de processos que ocorrem desde recebimento de uma Query até o retorno de um conjunto de registro é impressionante!

Um banco de dados SQLite administra tudo utilizando um único arquivo. Logo, para enviar toda a base de dados para outro dispositivo, precisamos só e somente só, mover um único arquivo e assim, todo que for referente a determinada base de dados também será movido. O SQLite até gera um arquivo de paginação, porém, este arquivo contém informações temporárias e não é necessário que façamos backup ou então, move-lo junto com o arquivo que contém as informações.

Algumas vezes, não é possível reconhecer se o arquivo é uma base de dados, até porque, o SQLite não obriga a utilização de uma extensão própria. Logo, é comum a utilização das extensões *.db ou então, *.sqlite, *.sqlite3 e etc.

A seguir, estudaremos em detalhes alguns processo que ocorrem internamente e antes de qualquer Query ser executada.

O QUE É A INTERFACE?

Podemos dizer que é a API que utilizamos para integrar o nosso programa em Python, com a biblioteca do SQLite em C.

O SQLite possui uma interface de acesso público para bibliotecas que terceiros consigam acessar de forma simples e segura. Por padrão, todas as funções e métodos da interface de integração iniciam como o nome sqlite3. Assim, consegue-se distinguir facilmente qual a versão do banco de dados e da biblioteca de acesso. Tokenizer

O QUE É O TOKENIZER?

Converte a nossa query em simbolos de forma a facilitar os processor de interpretação da query enviada.

Ao enviar uma string com códigos SQL para as bibliotecas SQLite, a interface de acesso recebe a string e na sequência passa a mesma para o Tokenizer.

O trabalho do tokenizador será quebrar a string de código SQL em tokens (simbolo) para que então, estes sejam enviados para ao parser (analisador).

O interessante aq'o tokenizer é quem chama o analisador, ao contrario do que normalmente temos com outras linguagens.

O trabalho realizado pelo Tokenizer é chamado de análise léxica, que em resumo, é converter um código para símbolos, ou seja, simbolo léxicos (Lexical tokens). A análise léxica geralmente está entre as primeiras análises feitas pelos compiladores e interpretadores e o objetivo é começar a preparar o código para a sua conversão em código de máquina ou então, em um código que possa ser executado mais rapidamente. Assim, os erros de digitação ou então, a utilização de outras simbologias ou o uso errado de alguma instrução será detectado pelo analisador léxico.

PARSING (ANALISADOR)

O analisado irá receber um conjunto de tokens e então irá a atribuir a estes um significado, conforme a função que o token devera desempenhar. O parser do SQLite é gerado utilizando um sofisticado motor de parsing de nome Lemon.

Parsing ou análise sintática pode-se resumida no processo de transformar e organizar os tokens numa estrutura hierárquica para que assim, seja mais fácil executa-los em ordem. Então, podemos dizer que os tokens gerados na análise léxica, agora serão organizados numa estrutura semelhante a uma arvore.

CODE GENERATOR

Depois que o parser montar os comandos SQL em totens, a estrutura resultante da análise léxica e da análise sintática é enviado para o Code Generator. Este, ira produzir o código de máquina, ou então, o código que o motor do SQLite entende e sabe quais procedimentos devem ser executados. Enquanto o SQL utiliza o paradigma declarativo, podemos dizer que o código gerado pelo Code Generator é a interpretação do SQL e que produz um código imperativo. Assim, enquanto o paradigma declarativo tem como objetivo informar a máquina o que se quer fazer, o paradigma imperativo, diz como deve ser feito. Assim, nós temos que o motor do SQLite recebe código declarativo e converte-o em código imperativo.

MÁQUINA VIRTUAL

O Code Generator irá produzir uma espécie de programinha ou então, uma espécie de script. Então, esse código gerado, é um algoritmo especializado produzido atráves de instruções SQL. Então, após o processo de conversão e de geração do algoritmo a ser executado, este será enviado à Maquina virtual e então as operações serão executadas nos respectivos arquivos.

A Máquina Virtual do SQLite é uma implementação de um mecanismo computacional abstrato, projetado especificamente para manipular os arquivos que compõem o nosso banco de dados. Ou seja, o SQLite possui uma estrutura de dados especifica para guardar as informações. Então, para manipular essa informações, criou-se uma linguagem de programação especifica como também, sua respectiva maquina virtual que sabe como executa-la. Assim, ao enviarmos um código SQL para o motor do SQLite, este convertera o nosso código para uma linguagem especializada na manipulação de informações e graças a isso, hoje somos poupados de ter que aprender uma linguagem complicada e altamente especializada só para manipular grande quantidades de informações.

Se nós formos analisar o que cada query realmente faz e também, todos os algoritmos que ela faz uso, veremos como o SQL é simples antes tudo que uma simples expressão do mesmo pode ocasionar.

B-TREE

Bem como o mesmo é responsável por criar a estrutura que será utilizada na organização do conjunto de registro pertencentes a uma tabela.

O SQLite armazena as informações informações através de uma implementação B-Tree (Arvore B). Assim, cada tabela é uma estrutura B-tree, como também, cada índice das nossas tabelas será uma outra arvore B-tree. O SQLite mantém uma arvore B-Tree para cada lista, porém, todas as estruturas são salvas juntas, isto é, estão contidas num único arquivo.

PÁGINA CACHE (ARQUIVO DE PAGINAÇÃO)

Um módulo B-tree lê as estruturas armazenadas no disco em pequenos pedaços sempre de mesmo tamanho. Por padrão, o tamanho de cada bloco é de 1024 bytes, porém, há situações onde pode ser utilizado um bloco com 512 bytes ou então 65.536 bytes.

O page cache é o responsável por garantir todo o gerenciamento e controle na manipulação das estruturas em uma base. Isso porque, o mesmo é o responsável pela leitura, escrita e através dele alguns desses pedaços são armazenados.

O Page Cache também tem papel importante no processo de rollback, bloquear um registro ou então uma tabela como também, como também, através dele ocorrem o Commit atômico.

O gerenciador da estrutura B-tree pede ao Page Cache uma determinada informação do banco, como também notifica quando deseja fazer uma alteração ou o que precisa ser alterado.

A maior parte das ações que complexas e perigosas realizadas dentro do banco faz em alguma parte do processo a utilização do Cache de Página.

LIMITES DO SQLITE

A seguir, temos alguns números que definem as capacidades hipotéticas que cada base de dados pode possuir. A maioria das "limitações" do SQLite são artificiais, isto é, como tudo precisa ter um limite, foi definido um número improvável, porém, que não é impossível.

LINKS EXTERNOS

Site Oficial do SQLite