O problema

• Sem índice, todas. É a varredura sequencial do M5
• Com índice, três ou quatro
• Essa diferença é o motivo de o módulo M3 existir

Por que não uma tabela hash?

• Hash responde igualdade em tempo constante, e é ótimo nisso
• Mas não responde WHERE id BETWEEN 10 AND 90
• Também não entrega os dados em ordem
• Árvore mantém ordem, e por isso é a estrutura padrão de índice

A estrutura

• Nós internos guardam apenas chaves e ponteiros, para guiar a descida
• Folhas guardam as chaves e os RIDs, e são encadeadas entre si
• Todas as folhas ficam na mesma profundidade, sempre
• Cada nó ocupa exatamente uma página

A conta que justifica tudo

página de 4096 bytes, chave de 8, ponteiro de 8
→ cerca de 250 filhos por nó

altura 1:        250 linhas
altura 2:     62.500 linhas
altura 3: 15.625.000 linhas

Quinze milhões de linhas, três leituras de página. É por isso que a árvore é rasa e larga, e não profunda.

Inserção e divisão

• Desça até a folha correta, e insira em ordem
• Se a folha tem espaço, acabou
• Se não tem, divida: metade das chaves fica, metade vai para uma folha nova
• A chave do meio sobe para o pai. Se o pai encher, ele também divide
• Se a raiz dividir, a árvore ganha um nível

O que não vamos implementar

• É a parte mais difícil da estrutura, e a que mais gera casos de borda
• O critério de pronto do semestre só faz INSERT e SELECT
• Nos testes de aceitação não há DELETE

Exercício de hoje

• 1. Desenhe a árvore depois de cada divisão de nó, e não apenas o resultado final
• 2. Qual a altura ao fim, e quantas páginas uma busca por 25 precisa ler?
• 3. Qual chave ficou na raiz, e por que foi ela e não outra?
• 4. Com cerca de 250 filhos por nó, quantas linhas cabem em uma árvore de altura 4?

O item 1 é o que importa: quem desenha as divisões uma vez erra menos no código do M3, que é o módulo mais caro do semestre.