Essa semana foi MUITO mais teórica do que eu achei que seria. Em algum momento, me peguei com sentimento de falta de produtividade por não ter escrito nem uma única linha de código na semana toda. Mas, comecei a me perguntar se realmente havia sido tão improdutivo assim.

Realmente, não codei nada do AuroraDB, mas avancei bastante na parte teórica no que diz respeito a discos magnéticos. Minha principal fonte foi o livro Database System Concepts, mais especificamente a 6° edição. Ele trata sobre o alto nivel do banco de dados, como SQL, mas do 10° capitulo em diante ele aborda o baixo nivel também e foi a partir desse capitulo que foquei o estudo ao longo dessa semana. Isso significa que vou ignorar a parte sobre alto nivel? Não, mas darei mais atenção para essa parte quando a implementação dos Parsers chegar.

Disco Magnético

Agora, o momento mais teórico dos avanços da semana. O que eu estudei no que se trata do armazenamento em disco?

Funcionamento do I/O(Entrada e saída)
Medidas de Desempenho

Funcionamento do I/O

Alguma vez você já se perguntou como seu computador salva os dados no seu HD? Pois bem, irei explicar resumidamente o que aprendi ao longo dessa semana no que tange esse assunto.

Fisicamente falando, discos são relativamente simples. Ele possui diversos pratos, com formato circular e plano. Os dois lados do disco são feitos de um material magnético e a informação fica gravada em sua superfície, sendo feitos normalmente de vidro ou metal rígido

Quando o disco está em uso, um motor o gira a uma velocidade constante(60, 90, 120 ou até 250 rotações por segundo). Acima da superfície do disco, mas sem encostar na mesma, há a cabeça de leitura/gravação, fixada a um braço e entender isso é importante, pois é algo essencial para entendermos o motivo para que operações de I/O em disco sejam um gargalo para as operações. O disco é dividido em trilhas e essas trilhas são divididas em setores, que é a menor unidade de informação que pode ser lida ou escrita.

Fazendo uma analogia, imagine uma vitrola moderna. Os pratos do HD são como os discos de vinil, girando a uma velocidade altíssima. A cabeça de leitura/gravação é como a agulha da vitrola, suspensa por um braço mecânico. E aqui está o ponto crucial: para ler uma música (um dado), a agulha precisa primeiro se mover até a trilha certa no disco e depois esperar o ponto exato da música passar por baixo dela. São esses dois movimentos físicos — a 'viagem do braço' e a 'espera pelo giro' — que criam o gargalo de performance que nós, como desenvolvedores de sistemas, precisamos entender e minimizar.

As operações de I/O ocorrem da seguinte forma:

Escrita: A cabeça de escrita passa bem próximo ao disco(Lembre-se, JAMAIS encostando no prato) e manipula os polos. Ela leva em conta sempre o bit imediatamente anterior para fazer a seguinte operação: Para gravar “1”, o polo é invertido(Se o bit anterior está “Norte”, ela muda esse para “Sul” e vice-versa). Para gravar “0”, o polo é mantido igual ao polo do bit anterior. Parece ser muito aleatório e arbitrária essa decisão, mas vai fazer sentido ao entendermos como funciona a leitura.
Leitura: Em suma, quando há uma mudança brusca de polaridade, é gerado um pulso elétrico forte na cabeça de leitura e dessa forma, se torna possível interpretar o bit 1(afinal, a polaridade sempre vai estar invertida). E, quando não há essa inversão de polaridade, não é gerado o pulso elétrico e, por isso, se torna possível interpretar o bit 0. PS → Para o primeiro bit, é feito a leitura com base em uma série de bits de marcação que precede ele.

Medidas de Desempenho

Tempo de Acesso: É o tempo entre uma requisição de I/O ser emitida e o começo da transferência de dados de fato começar(Ou seja, a soma entre o seek time e a latencia rotacional). Para isso, o braço precisa se mover fisicamente até a trilha correta e então esperar que o devido setor chegue até a cabeça através da rotação do prato. O tempo necessário para o movimento do braço se chama tempo de busca(seek time) e, logicamente, ela aumenta de forma proporcional com a distância que o braço deve se mover. De acordo com o livro(PS → de 2009), tempo de busca tipicos variam entre 2 e 30 milissegundos. Para nós, pode parecer algo extremamente rápido, mas para um computador isso se traduz em uma ETERNIDADE. Para vias de comparação, uma CPU de 3.5Ghz pode executar cerca de de 3,2 milhões de operações em 1 milissegundo.

Tempo de busca médio: É a média entre os tempos de busca. Algo interessante aqui é que, se desconsiderarmos o tempo para o braço começar a se mover, o tempo para o braço parar de se mover e que todas as trilhas possuem exatamente o mesmo número de setores, esse tempo se torna 1/3 do pior tempo possível. Agora, se formos considerar essas variáveis, o tempo médio se torna ½ do pior tempo possível.

Tempo de latência rotacional: É o tempo que leva para o disco girar e colocar o devido setor imediatamente abaixo da cabeça. As velocidades de rotação em discos ficam entre 5400 rotações por minuto(90 rotações por segundo) até 15000 rotações por minuto(250 rotações por segundo), ou, equivalentemente, de 4 milissegundos até 11,1 milissegundos por rotação. Em média, é necessária meia rotação para que o setor correto chegue a cabeça, portanto, o tempo médio é metade do pior caso possível.

Omitirei as demais medidas de desempenho, pois, somente essas já são o suficiente para entendermos que operações em disco serem o gargalo de funcionamento. Entender isso é importante, pois, ao desenvolver um banco de dados nós queremos performance. Imagine se, ao tentar recuperar 500 registros de uma tabela, esse processo fosse feito incessantemente e diversas vezes no disco? Quanto tempo não iria demorar? E pior ainda, imagine que esses registros estejam fisicamente distantes uns dos outros no disco? Dado as informações passadas aqui, dá para perceber que seria uma eternidade correto?

Próximos Passos

O que vocês podem esperar na próxima semana?

Continuar o estudo sobre técnicas de otimização ao acesso de blocos do disco. Já iniciei a leitura e anotações sobre os conceitos base, mas ainda falta ler sobre as técnicas em si.

Nem só de teoria vive um projeto. Pretendo implementar o começo de um PageManager, aplicando o conceito de RAII para fazer essa classe, cujo objetivo será: Criar, abrir e gerenciar o arquivo fisico do banco de dados
Começar a refletir sobre design, como por exemplo o layout fisico das páginas(um conceito que apresentarei semana que vem).

Contato

Gostou do conteúdo ou tem alguma dúvida sobre o processo? Você pode me encontrar no meu LinkedIn

Ou, caso prefira, deixe seu comentário abaixo que eu responderei assim que possível!

Por que um SELECT Pode Levar Uma Eternidade? Uma Análise do Hardware