A história pouco conhecida do SQLite

xguru · 2021-07-05T10:21:01+09:00

Resumo de um podcast de entrevista com o desenvolvedor do SQLite, Richard Hipp (38 min, com transcrição) Seu trabalho principal era como desenvolvedor de software para destróieres da Marinha dos EUA → O Informix usado dentro da embarcação falhava com frequência, o servidor caía e a conexão era interrompida → Como era um navio de guerra, mesmo sofrendo danos em combate não podia aparecer um pop-up de “não foi possível conectar ao DB”; precisava continuar funcionando de forma robusta Também não precisava de transações, mas os dados tinham de ser carregados na RAM em qualquer situação → Procurou um engine de banco de dados SQL que rodasse sem servidor, não encontrou e decidiu criar um SQLite V1 (2000) Escreveu um engine de bytecode que tratava instruções SQL como programas, compilando e executando queries Na prática, não foi usado no projeto real (o cliente queria usar Informix) Enquanto usava para desenvolvimento, publicou na internet e as pessoas começaram a usar Começou a ver comentários como “rodei um banco SQL em um Palm Pilot”, o que chamou atenção. Isso o incentivou a continuar trabalhando no projeto Motorola Entre 2001 e 2002, a Motorola ligou dizendo que colocaria o SQLite em seu novo sistema operacional para telefones Disseram que pagariam se ele implementasse os recursos necessários Foi quando ele descobriu pela primeira vez que dava para ganhar dinheiro com open source Cerca de US$ 80.000; hoje não parece tanto, mas para ele foi um valor surpreendente Tocou o projeto com outras três pessoas com quem trabalhava, e esse foi o começo America Online Phones O contato seguinte veio da AOL Era a época em que CDs eram enviados pelo correio, e dentro desse CD era necessário ter um database Ou seja, queriam colocar o SQLite no CD e precisavam de novos recursos Symbian OS e Nokia Foi a Londres no Dia de Ação de Graças para uma reunião (já que no Reino Unido não existe Ação de Graças) Queriam um banco para o Symbian OS, e o SQLite competiu com outros bancos (2 open source e 7 comerciais) Os outros 9 bancos tiveram chance de fazer tuning, mas no fim o SQLite venceu Bus Factor [1] e o consórcio Bus factor é uma métrica que indica quantas pessoas precisariam ser atropeladas por um ônibus para que o desenvolvimento parasse Embora ele trabalhasse em tempo integral com outras pessoas, o pessoal do Symbian disse que era preciso aumentar o bus factor A ideia era iniciar o consórcio do SQLite para financiar o projeto e fazer mais gente participar no longo prazo Ele teve a ideia maluca de dar direito a voto a todos os membros do consórcio Mitchell Baker, da Mozilla Foundation, ouviu isso de algum lugar e ligou para ele → “Richard, você está fazendo tudo errado. Vou te mostrar como criar um consórcio” → Ela começou a definir as regras → “Os desenvolvedores precisam manter o controle. A decisão final é deles. Entrar não pode significar ganhar direito a voto automaticamente.” → “As empresas que usam isso ganham a honra de contribuir com dinheiro, mas a decisão final precisa ser sua.” → Ela foi muito firme e organizou tudo. Ela é advogada Quando Richard perguntou “como fazer as pessoas entrarem? Qual é o incentivo?”, → “Não se preocupe. Elas vão entrar. E, de fato, se fizer assim, a Mozilla será membro fundadora.” Com o apoio de Mozilla, Symbian e Adobe, o consórcio começou com essas três empresas → No início, quando a Symbian disse que precisava de um consórcio, ele não fazia ideia do que fazer. Não sabe como Mitchell Baker ficou sabendo e ligou, mas toda essa jornada foi extraordinária Entra o Android: o começo do Android Como todos os smartphones usavam SQLite, Richard conseguiu observar o desenvolvimento inicial dos smartphones por todos os ângulos Em 2005, participou de uma reunião com o Android. Na época, ainda não existiam nem Android nem iPhone no mercado Fez debug do SQLite conectado a um telefone parecido com um BlackBerry, com telinha em cima e teclado QWERTY completo Foi incrível depurar com GDB em um telefone conectado a uma rede telefônica real Naquele momento, ninguém da Motorola, Symbian ou Nokia fazia algo assim, e foi aí que ele percebeu que o Android se tornaria enorme Guy, This Is Important: pessoal, isso é realmente importante Naquela época, os outros fabricantes tinham ciclos muito longos de atualização de hardware e software, de cerca de 30 dias, mas o Android instalava um novo OS várias vezes por dia em aparelhos conectados à rede real O protótipo de telefone Android recebido sob NDA tinha uma carcaça que parecia impressa em 3D, mas já era portátil o suficiente → Os das outras empresas eram grandes protótipos em breadboard e nem estavam conectados à rede, então nem podiam ser usados como telefone Ele queria dizer ao pessoal da Motorola e da Symbian “isso é importante, vocês precisam resolver isso”, mas não podia falar (por causa do NDA), e isso fez toda a diferença Testing and Aviation Standards: testes e padrões da aviação Adam (entrevistador): “Hoje o banco de dados do Richard está muito ativo. É uma consultoria de software de 1 a 4 pessoas, talentosa e competente, que dá suporte ao banco que está em todos os telefones Android. Os desenvolvedores do banco são extremamente dedicados e odeiam problemas com dados” Nós ingenuamente dizíamos a todos que o SQLite não tinha bugs, mas o Android provou de forma clara que estávamos errados Ele achava que era possível fazer software sem bugs, mas é impressionante quantos bugs podem aparecer quando o software é instalado em milhões de dispositivos Nessa época, também estavam trabalhando com a Rockwell Collins, uma empresa de aviônicos, e eles apresentaram o conceito do DO-178B [2] → DO-178B trata de padrões de qualidade para produtos aeronáuticos críticos para a segurança e, diferentemente de outros padrões de qualidade, é “legível” → Custa algumas centenas de dólares, mas por ser fino ele recomenda muito a leitura Eles de fato passaram a seguir o processo do DO-178B, incluindo 100% de cobertura de testes MCDC MCDC (Modified Condition / Decision Coverage) [3] significa que os testes precisam passar por cada ramificação individual pelo menos uma vez Levar o SQLite a 100% de MCDC levou um ano, trabalhando 60 horas por semana. Foi extremamente difícil. Eram 12 horas por dia, e muito cansativo Chegar a 90~95% de cobertura é fácil; o 5% restante é realmente difícil. Mas depois de um ano fazendo isso e finalmente alcançar 100%, os bug reports vindos do Android pararam Foi aí que começou a funcionar, e fez uma grande diferença. Depois disso, ficaram 8~9 anos sem bugs Dezenas de bilhões de testes O primeiro foi escrito em TCL (Tool Command Language), e era um teste comum de desenvolvedor Até hoje eles mantêm esse primeiro teste em TCL, e ele é público. Não chega a 100%, mas testa em detalhe todos os recursos do SQLite A cobertura MCDC de 100% é chamada de TH3 e não é pública (proprietary) Tentaram ganhar dinheiro vendendo isso para empresas de aviação, mas não venderam nem uma cópia, então nesse sentido não funcionou.. Mas isso ajudou muito a manter o produto extremamente robusto e a acelerar a inclusão de novos recursos e correções de bugs É difícil contar o número de testes, mas são 100 mil testes individuais parametrizados, que resultam em dezenas de bilhões de execuções Existe um checklist, e antes de cada release os testes rodam por pelo menos 3 dias Eles deliberadamente testam em vários sistemas operacionais → Hoje quase todos os dispositivos são little-endian, mas antigamente havia muitos big-endian. Por isso, faziam testes big-endian em um PowerPC iBook → Testam em plataformas de 32 bits, ARM e Intel, plataformas de 64 bits, Windows, Linux, Mac, OpenBSD e todo sistema operacional e plataforma que conseguirem → Há vários test suites diferentes: o TCL original, o TH3 e também fuzzers rodando continuamente Também existe o teste SQL Logic → Um volume enorme de instruções SQL criado por Shane Harrelson há 10 anos → Testaram em todo banco de dados em que puderam pôr as mãos, e todos os engines falhavam em responder e davam segmentation fault, inclusive o SQLite. Só o Postgres não → Só o Postgres sempre produzia resultado e eles não conseguiam achar falhas. Os desenvolvedores do Postgres disseram que eles não estavam se esforçando o suficiente.. Talvez fosse possível provocar um erro no Postgres, mas eles ficaram muito impressionados → Até a versão comercial do Oracle travava, e o DB2 também travava → O ponto importante é que o SQLite foi ajustado para dar a mesma resposta para todas essas queries Building From First Principles Quando começou a escrever o projeto, tentou encontrar alguma referência sobre como construir um engine SQL DB, mas não encontrou nada. Então precisou fazer por conta própria, numa missão completamente independente Muita teoria estava sendo produzida no MIT, em Harvard e em Berkeley, mas se você não frequentasse essas universidades, nem saberia que essa teoria existia, muito menos como encontrá-la O modelo Volcano usado pelo Postgres e o modelo de bytecode usado pelo SQLite mostram que, no fim, todos convergimos para as mesmas ideias Vistos de cima, eles começam de pontos muito diferentes, mas convergem para a mesma região na busca de como tornar isso mais rápido Ele vê isso como uma espécie de validação teórica: duas linhas independentes de desenvolvimento chegando à mesma resposta Por exemplo, ele não sabia nada sobre covering index, mas participou de uma conferência de PHP na Alemanha onde David Axmark, do MySQL, também palestrou → Nessa palestra, ele explicou como o MySQL implementou covering index → Quando o índice de um banco tem várias colunas, se a query usa apenas as colunas iniciais do índice e a resposta está nas demais colunas dele, o banco pode usar só o índice, sem consultar a tabela original, o que acelera a operação → Então, no voo de volta para casa, como o avião estava vazio, ele abriu o laptop e implementou covering index no SQLite sobre o Atlântico B-Trees and The Art of Computer Programming Muita coisa precisou ser feita do zero. Ninguém jamais lhe ensinou B-Tree. Ele só tinha ouvido falar Quando tentou desenvolver sua própria B-Tree, tinha o TAOCP do Don Knuth na estante, procurou a parte sobre B-Trees e lá encontrou a explicação do algoritmo O curioso é que o livro explica em detalhe os algoritmos de busca e inserção de B-Tree, mas não fornece o algoritmo de remoção. Isso aparece como exercício no fim do capítulo, então ele precisou resolver o problema antes de implementar sua própria B-Tree. “Obrigado, Don, muito obrigado.” As pessoas de hoje deveriam pelo menos ler ou folhear o TAOCP Freedom to Build It Yourself: a liberdade de construir você mesmo O SQLite não depende de nada além do que o próprio Richard construiu (tirando o compilador C e a libc). Ele também criou seu próprio sistema de controle de versão e seu bug tracker. Isso lhe dá liberdade Liberdade (Freedom) significa cuidar de si mesmo Pessoas que fazem mochilão e carregam tudo de que precisam nas costas dizem ser livres porque conseguem cuidar de si próprias Se você constrói tudo por conta própria, há liberdade nisso porque não fica preso a ninguém Se o SQLite 2 tivesse escolhido o Berkeley DB como engine de storage, por exemplo → Naquela época o Berkeley DB era open source, mas depois foi vendido para a Oracle e passou a um modelo proprietário de dual source, de forma que você não conseguiria o código-fonte mais recente sem pagar licenciamento Hoje o parser generator do SQLite não usa Yak nem Bison, e sim algo escrito por ele chamado Lemon; por isso, quando precisa de um novo recurso de linguagem, ele pode modificar sem ficar preso a essas ferramentas No início dos anos 2000, todos os projetos usavam CVS, então ele também usou, mas em meados dos anos 2000 começaram a surgir as ideias de controle de versão distribuído Construindo o Fossil Depois de analisar Git e Mercurial e organizar os requisitos, decidiu desenvolver seu próprio sistema de controle de versão Agora o Fossil funciona bem e virou um projeto próprio Linus Torvalds criou o Git para dar suporte ao desenvolvimento do Linux Kernel, então, se você trabalha com o Linux Kernel, o Git é o sistema de versionamento perfeito O Fossil é o sistema de versionamento ideal para trabalhar no SQLite. Como ele mesmo o fez, atende exatamente aos seus requisitos Ao desenvolver por conta própria, ele controla o próprio destino, tem mais liberdade e não depende de terceiros Ser autossuficiente Como se chama uma pessoa que sai da cidade, cultiva a própria comida e vive assim? Survivalist? Ou prepper? “Como você deve ter visto até enquanto falávamos, meu Gmail está meio estranho. Os e-mails ficam voltando. Então estou pensando em montar meu próprio servidor de e-mail. Até enquanto estávamos marcando esta reunião eu estava fazendo anotações sobre isso. Não deve ser mais difícil do que escrever um engine de banco de dados, mas eu não quero ficar preso ao Gmail. Não quero que eles controlem meu destino. Não quero que controlem o histórico de todas as minhas conversas. Quero controlar isso eu mesmo e, por isso, embora seja doloroso e dê muito trabalho, vou procurar uma solução que eu possa controlar diretamente. Posso alugar uma máquina virtual na nuvem e rodar isso sem depender de terceiros.” Se alguém aparecer dizendo que vai resolver seu problema, você deve saber que essa pessoa vai tirar sua liberdade. “Se quiser ser livre, faça você mesmo” Conselho para outras pessoas “Eu comecei com a ideia maluca de criar um engine de banco de dados que lesse e escrevesse diretamente em disco, sem precisar de servidor” Se você perguntar aos especialistas, eles dirão: “isso é impossível. Nunca vai funcionar. É uma ideia idiota.” Felizmente, ele não conhecia esses especialistas, então simplesmente fez, e tudo isso aconteceu Não dê ouvidos demais aos especialistas; faça o que faz sentido. Resolva o seu problema -- [1] Bus Factor: indicador do risco de uma equipe entrar em crise se um integrante for “atropelado por um ônibus”. É uma métrica que expressa o risco gerado quando informações e funções não são compartilhadas entre os membros da equipe. Quanto maior esse índice, mais o conhecimento é compartilhado e menos o trabalho fica concentrado em uma pessoa específica. [2] DO-178B: Considerações de software na certificação de sistemas e equipamentos embarcados em aeronaves (Software Considerations in Airborne Systems and Equipment Certification) Adotado pela FAA como método de demonstração de conformidade para certificação de software aeronáutico [3] MCDC: Modified Condition / Decision Coverage Método de projetar casos de teste para que, quando existirem várias condições, cada condição individual afete independentemente o resultado da expressão total, sem ser influenciada pelas demais

(corecursive.com)

47 pontos por xguru 2021-07-05 | 16 comentários | Compartilhar no WhatsApp

Resumo de um podcast de entrevista com o desenvolvedor do SQLite, Richard Hipp (38 min, com transcrição)
Seu trabalho principal era como desenvolvedor de software para destróieres da Marinha dos EUA
→ O Informix usado dentro da embarcação falhava com frequência, o servidor caía e a conexão era interrompida
→ Como era um navio de guerra, mesmo sofrendo danos em combate não podia aparecer um pop-up de “não foi possível conectar ao DB”; precisava continuar funcionando de forma robusta
Também não precisava de transações, mas os dados tinham de ser carregados na RAM em qualquer situação
→ Procurou um engine de banco de dados SQL que rodasse sem servidor, não encontrou e decidiu criar um

SQLite V1 (2000)

Escreveu um engine de bytecode que tratava instruções SQL como programas, compilando e executando queries
Na prática, não foi usado no projeto real (o cliente queria usar Informix)
Enquanto usava para desenvolvimento, publicou na internet e as pessoas começaram a usar
Começou a ver comentários como “rodei um banco SQL em um Palm Pilot”, o que chamou atenção. Isso o incentivou a continuar trabalhando no projeto

Motorola

Entre 2001 e 2002, a Motorola ligou dizendo que colocaria o SQLite em seu novo sistema operacional para telefones
Disseram que pagariam se ele implementasse os recursos necessários
Foi quando ele descobriu pela primeira vez que dava para ganhar dinheiro com open source
Cerca de US$ 80.000; hoje não parece tanto, mas para ele foi um valor surpreendente
Tocou o projeto com outras três pessoas com quem trabalhava, e esse foi o começo

America Online Phones

O contato seguinte veio da AOL
Era a época em que CDs eram enviados pelo correio, e dentro desse CD era necessário ter um database
Ou seja, queriam colocar o SQLite no CD e precisavam de novos recursos

Symbian OS e Nokia

Foi a Londres no Dia de Ação de Graças para uma reunião (já que no Reino Unido não existe Ação de Graças)
Queriam um banco para o Symbian OS, e o SQLite competiu com outros bancos (2 open source e 7 comerciais)
Os outros 9 bancos tiveram chance de fazer tuning, mas no fim o SQLite venceu

Bus Factor [1] e o consórcio

Bus factor é uma métrica que indica quantas pessoas precisariam ser atropeladas por um ônibus para que o desenvolvimento parasse
Embora ele trabalhasse em tempo integral com outras pessoas, o pessoal do Symbian disse que era preciso aumentar o bus factor
A ideia era iniciar o consórcio do SQLite para financiar o projeto e fazer mais gente participar no longo prazo
Ele teve a ideia maluca de dar direito a voto a todos os membros do consórcio
Mitchell Baker, da Mozilla Foundation, ouviu isso de algum lugar e ligou para ele
→ “Richard, você está fazendo tudo errado. Vou te mostrar como criar um consórcio”
→ Ela começou a definir as regras
→ “Os desenvolvedores precisam manter o controle. A decisão final é deles. Entrar não pode significar ganhar direito a voto automaticamente.”
→ “As empresas que usam isso ganham a honra de contribuir com dinheiro, mas a decisão final precisa ser sua.”
→ Ela foi muito firme e organizou tudo. Ela é advogada
Quando Richard perguntou “como fazer as pessoas entrarem? Qual é o incentivo?”,
→ “Não se preocupe. Elas vão entrar. E, de fato, se fizer assim, a Mozilla será membro fundadora.”
Com o apoio de Mozilla, Symbian e Adobe, o consórcio começou com essas três empresas
→ No início, quando a Symbian disse que precisava de um consórcio, ele não fazia ideia do que fazer. Não sabe como Mitchell Baker ficou sabendo e ligou, mas toda essa jornada foi extraordinária

Entra o Android: o começo do Android

Como todos os smartphones usavam SQLite, Richard conseguiu observar o desenvolvimento inicial dos smartphones por todos os ângulos
Em 2005, participou de uma reunião com o Android. Na época, ainda não existiam nem Android nem iPhone no mercado
Fez debug do SQLite conectado a um telefone parecido com um BlackBerry, com telinha em cima e teclado QWERTY completo
Foi incrível depurar com GDB em um telefone conectado a uma rede telefônica real
Naquele momento, ninguém da Motorola, Symbian ou Nokia fazia algo assim, e foi aí que ele percebeu que o Android se tornaria enorme

Guy, This Is Important: pessoal, isso é realmente importante

Naquela época, os outros fabricantes tinham ciclos muito longos de atualização de hardware e software, de cerca de 30 dias, mas o Android instalava um novo OS várias vezes por dia em aparelhos conectados à rede real
O protótipo de telefone Android recebido sob NDA tinha uma carcaça que parecia impressa em 3D, mas já era portátil o suficiente
→ Os das outras empresas eram grandes protótipos em breadboard e nem estavam conectados à rede, então nem podiam ser usados como telefone
Ele queria dizer ao pessoal da Motorola e da Symbian “isso é importante, vocês precisam resolver isso”, mas não podia falar (por causa do NDA), e isso fez toda a diferença

Testing and Aviation Standards: testes e padrões da aviação

Adam (entrevistador): “Hoje o banco de dados do Richard está muito ativo. É uma consultoria de software de 1 a 4 pessoas, talentosa e competente, que dá suporte ao banco que está em todos os telefones Android. Os desenvolvedores do banco são extremamente dedicados e odeiam problemas com dados”
Nós ingenuamente dizíamos a todos que o SQLite não tinha bugs, mas o Android provou de forma clara que estávamos errados
Ele achava que era possível fazer software sem bugs, mas é impressionante quantos bugs podem aparecer quando o software é instalado em milhões de dispositivos
Nessa época, também estavam trabalhando com a Rockwell Collins, uma empresa de aviônicos, e eles apresentaram o conceito do DO-178B [2]
→ DO-178B trata de padrões de qualidade para produtos aeronáuticos críticos para a segurança e, diferentemente de outros padrões de qualidade, é “legível”
→ Custa algumas centenas de dólares, mas por ser fino ele recomenda muito a leitura
Eles de fato passaram a seguir o processo do DO-178B, incluindo 100% de cobertura de testes MCDC
MCDC (Modified Condition / Decision Coverage) [3] significa que os testes precisam passar por cada ramificação individual pelo menos uma vez
Levar o SQLite a 100% de MCDC levou um ano, trabalhando 60 horas por semana. Foi extremamente difícil. Eram 12 horas por dia, e muito cansativo
Chegar a 90~95% de cobertura é fácil; o 5% restante é realmente difícil. Mas depois de um ano fazendo isso e finalmente alcançar 100%, os bug reports vindos do Android pararam
Foi aí que começou a funcionar, e fez uma grande diferença. Depois disso, ficaram 8~9 anos sem bugs

Dezenas de bilhões de testes

O primeiro foi escrito em TCL (Tool Command Language), e era um teste comum de desenvolvedor
Até hoje eles mantêm esse primeiro teste em TCL, e ele é público. Não chega a 100%, mas testa em detalhe todos os recursos do SQLite
A cobertura MCDC de 100% é chamada de TH3 e não é pública (proprietary)
Tentaram ganhar dinheiro vendendo isso para empresas de aviação, mas não venderam nem uma cópia, então nesse sentido não funcionou..
Mas isso ajudou muito a manter o produto extremamente robusto e a acelerar a inclusão de novos recursos e correções de bugs
É difícil contar o número de testes, mas são 100 mil testes individuais parametrizados, que resultam em dezenas de bilhões de execuções
Existe um checklist, e antes de cada release os testes rodam por pelo menos 3 dias
Eles deliberadamente testam em vários sistemas operacionais
→ Hoje quase todos os dispositivos são little-endian, mas antigamente havia muitos big-endian. Por isso, faziam testes big-endian em um PowerPC iBook
→ Testam em plataformas de 32 bits, ARM e Intel, plataformas de 64 bits, Windows, Linux, Mac, OpenBSD e todo sistema operacional e plataforma que conseguirem
→ Há vários test suites diferentes: o TCL original, o TH3 e também fuzzers rodando continuamente
Também existe o teste SQL Logic
→ Um volume enorme de instruções SQL criado por Shane Harrelson há 10 anos
→ Testaram em todo banco de dados em que puderam pôr as mãos, e todos os engines falhavam em responder e davam segmentation fault, inclusive o SQLite. Só o Postgres não
→ Só o Postgres sempre produzia resultado e eles não conseguiam achar falhas. Os desenvolvedores do Postgres disseram que eles não estavam se esforçando o suficiente.. Talvez fosse possível provocar um erro no Postgres, mas eles ficaram muito impressionados
→ Até a versão comercial do Oracle travava, e o DB2 também travava
→ O ponto importante é que o SQLite foi ajustado para dar a mesma resposta para todas essas queries

Building From First Principles

Quando começou a escrever o projeto, tentou encontrar alguma referência sobre como construir um engine SQL DB, mas não encontrou nada. Então precisou fazer por conta própria, numa missão completamente independente
Muita teoria estava sendo produzida no MIT, em Harvard e em Berkeley, mas se você não frequentasse essas universidades, nem saberia que essa teoria existia, muito menos como encontrá-la
O modelo Volcano usado pelo Postgres e o modelo de bytecode usado pelo SQLite mostram que, no fim, todos convergimos para as mesmas ideias
Vistos de cima, eles começam de pontos muito diferentes, mas convergem para a mesma região na busca de como tornar isso mais rápido
Ele vê isso como uma espécie de validação teórica: duas linhas independentes de desenvolvimento chegando à mesma resposta
Por exemplo, ele não sabia nada sobre covering index, mas participou de uma conferência de PHP na Alemanha onde David Axmark, do MySQL, também palestrou
→ Nessa palestra, ele explicou como o MySQL implementou covering index
→ Quando o índice de um banco tem várias colunas, se a query usa apenas as colunas iniciais do índice e a resposta está nas demais colunas dele, o banco pode usar só o índice, sem consultar a tabela original, o que acelera a operação
→ Então, no voo de volta para casa, como o avião estava vazio, ele abriu o laptop e implementou covering index no SQLite sobre o Atlântico

B-Trees and The Art of Computer Programming

Muita coisa precisou ser feita do zero. Ninguém jamais lhe ensinou B-Tree. Ele só tinha ouvido falar
Quando tentou desenvolver sua própria B-Tree, tinha o TAOCP do Don Knuth na estante, procurou a parte sobre B-Trees e lá encontrou a explicação do algoritmo
O curioso é que o livro explica em detalhe os algoritmos de busca e inserção de B-Tree, mas não fornece o algoritmo de remoção. Isso aparece como exercício no fim do capítulo, então ele precisou resolver o problema antes de implementar sua própria B-Tree. “Obrigado, Don, muito obrigado.”
As pessoas de hoje deveriam pelo menos ler ou folhear o TAOCP

Freedom to Build It Yourself: a liberdade de construir você mesmo

O SQLite não depende de nada além do que o próprio Richard construiu (tirando o compilador C e a libc). Ele também criou seu próprio sistema de controle de versão e seu bug tracker. Isso lhe dá liberdade
Liberdade (Freedom) significa cuidar de si mesmo
Pessoas que fazem mochilão e carregam tudo de que precisam nas costas dizem ser livres porque conseguem cuidar de si próprias
Se você constrói tudo por conta própria, há liberdade nisso porque não fica preso a ninguém
Se o SQLite 2 tivesse escolhido o Berkeley DB como engine de storage, por exemplo
→ Naquela época o Berkeley DB era open source, mas depois foi vendido para a Oracle e passou a um modelo proprietário de dual source, de forma que você não conseguiria o código-fonte mais recente sem pagar licenciamento
Hoje o parser generator do SQLite não usa Yak nem Bison, e sim algo escrito por ele chamado Lemon; por isso, quando precisa de um novo recurso de linguagem, ele pode modificar sem ficar preso a essas ferramentas
No início dos anos 2000, todos os projetos usavam CVS, então ele também usou, mas em meados dos anos 2000 começaram a surgir as ideias de controle de versão distribuído

Construindo o Fossil

Depois de analisar Git e Mercurial e organizar os requisitos, decidiu desenvolver seu próprio sistema de controle de versão
Agora o Fossil funciona bem e virou um projeto próprio
Linus Torvalds criou o Git para dar suporte ao desenvolvimento do Linux Kernel, então, se você trabalha com o Linux Kernel, o Git é o sistema de versionamento perfeito
O Fossil é o sistema de versionamento ideal para trabalhar no SQLite. Como ele mesmo o fez, atende exatamente aos seus requisitos
Ao desenvolver por conta própria, ele controla o próprio destino, tem mais liberdade e não depende de terceiros

Ser autossuficiente

Como se chama uma pessoa que sai da cidade, cultiva a própria comida e vive assim? Survivalist? Ou prepper?
“Como você deve ter visto até enquanto falávamos, meu Gmail está meio estranho. Os e-mails ficam voltando. Então estou pensando em montar meu próprio servidor de e-mail. Até enquanto estávamos marcando esta reunião eu estava fazendo anotações sobre isso. Não deve ser mais difícil do que escrever um engine de banco de dados, mas eu não quero ficar preso ao Gmail. Não quero que eles controlem meu destino. Não quero que controlem o histórico de todas as minhas conversas. Quero controlar isso eu mesmo e, por isso, embora seja doloroso e dê muito trabalho, vou procurar uma solução que eu possa controlar diretamente. Posso alugar uma máquina virtual na nuvem e rodar isso sem depender de terceiros.”
Se alguém aparecer dizendo que vai resolver seu problema, você deve saber que essa pessoa vai tirar sua liberdade. “Se quiser ser livre, faça você mesmo”

Conselho para outras pessoas

“Eu comecei com a ideia maluca de criar um engine de banco de dados que lesse e escrevesse diretamente em disco, sem precisar de servidor”
Se você perguntar aos especialistas, eles dirão: “isso é impossível. Nunca vai funcionar. É uma ideia idiota.”
Felizmente, ele não conhecia esses especialistas, então simplesmente fez, e tudo isso aconteceu
Não dê ouvidos demais aos especialistas; faça o que faz sentido. Resolva o seu problema

[1] Bus Factor: indicador do risco de uma equipe entrar em crise se um integrante for “atropelado por um ônibus”.

É uma métrica que expressa o risco gerado quando informações e funções não são compartilhadas entre os membros da equipe.
Quanto maior esse índice, mais o conhecimento é compartilhado e menos o trabalho fica concentrado em uma pessoa específica.

[2] DO-178B: Considerações de software na certificação de sistemas e equipamentos embarcados em aeronaves (Software Considerations in Airborne Systems and Equipment Certification)

Adotado pela FAA como método de demonstração de conformidade para certificação de software aeronáutico

[3] MCDC: Modified Condition / Decision Coverage

Método de projetar casos de teste para que, quando existirem várias condições, cada condição individual afete independentemente o resultado da expressão total, sem ser influenciada pelas demais

16 comentários

enowy 2025-08-07

Nem sabia que existia um texto tão bom assim. Ainda bem que podemos lê-lo em tradução.

mkeasy 2021-07-08

É um texto que dá vontade de reler várias vezes. Obrigado.

Se você quer ser livre, precisa fazer você mesmo.

Faça um trabalho que faça sentido.

Resolva o seu problema.

edunga1 2021-07-05

É um texto realmente interessante!

"90~95% de cobertura de testes é fácil, mas os 5% restantes são realmente difíceis. Mas, depois de fazer isso por um ano e finalmente chegar a 100%, os relatórios de bugs no Android deixaram de chegar"

Isso é possível mesmo.

panarch 2021-07-05

Li com bastante interesse. Obrigado!

jsryu 2021-07-05

Li muito bem. Obrigado.

falconer 2021-07-05

Li com atenção.

gmlwo530 2021-07-05

Foi uma leitura divertida!

kwangyeol 2021-07-05

Li com prazer. Obrigado.

baeba 2021-07-05

Gostei muito da leitura.

Acho que resumir e organizar deve ser ainda mais difícil.

shaichoi 2021-07-05

Li com bastante interesse. Isso me faz pensar em muitas coisas. Obrigado :)

fureweb 2021-07-05

Li com muito interesse. Obrigado!

kalihman 2021-07-05

Li com atenção.

jongpak 2021-07-05

Li sem ver o tempo passar, haha

Fico até com vergonha por ter subestimado como se fosse um banco de dados embarcado simples^^;

sixmen 2021-07-05

Eu usei achando que era só um DBMS simples para desenvolvimento local, mas não é nada simples!!

nicewook 2021-07-05

Li com muito prazer.

xguru 2021-07-05

Atualmente, há mais de 1 trilhão de instâncias do SQLite em operação no mundo.

Todos os mais de 4 bilhões de smartphones (Android, iOS)
Mac/Windows
Navegadores FF/Chrome/Safari
PHP/Python
Skype/iTunes/Dropbox/Turbotax
A maioria dos set-top boxes e TVs
O sistema multimídia da maioria dos carros

https://www.sqlite.org/mostdeployed.html