Quando o jovem especialista em programação Spencer Kimball ingressou no Google em 2004, a emergente empresa de buscas – como todas as outras no Vale do Silício – fragmentou seus bancos de dados para superar limitações de armazenamento e latências de desempenho. Mas foi, na melhor das hipóteses, uma solução provisória.
“Eles fragmentaram e esse fragmento foi feio”, disse Kimball.
Depois de Kimball ter passado cerca de uma década no Google, ele, junto com os então colegas do Google Ben Darnell e Peter Mattis, co-fundou o Cockroach Labs, com a ideia de construir um sistema de banco de dados que pudesse escalar para as proporções do Google, ao mesmo tempo em que atendesse aos requisitos de segurança e requisitos de flexibilidade para a empresa.
E então eles criaram o CockroachDB, o primeiro banco de dados SQL distribuído comercialmente que também poderia suportar transações com total conformidade com ACID. Assim como o bug incômodo que lhe deu o nome, o CockroachDB foi projetado para ser o mais resiliente possível.
Não se deixe enganar pelos trajes elegantes com que Kimball se veste para aparições públicas. Ele tem credenciais geek importantes: Kimball realmente criou o popular GNU Image Manipulation Program (GIMP) de código aberto enquanto estava na faculdade. E então, quando conversamos com ele na última conferência anual de usuários da empresa, Roastfest 2023, tivemos uma excelente visão geral de como os bancos de dados distribuídos evoluíram na última década e como surgiu o CockroachDB.
A transcrição foi editada para maior clareza e brevidade.
Você poderia nos contar a história da origem do Cockroach Labs?
O ímpeto para o Cockroach nasceu em minha carreira no Google. O Google tinha um conjunto muito comum de requisitos para os casos de uso de aplicativos que são comuns hoje e muito incomuns naquela época. O Google estava construindo data centers em todo o mundo, e eles fizeram isso com hardware de commodity real. Todo mundo tinha um servidor Sun Microsystems para rodar o Oracle, era assim que funcionava na era pontocom.
O Google, devido à sua imensa escala, começou a construir índices. Era muito diferente: de qualquer maneira, você não poderia colocá-lo em um banco de dados Oracle. Mas quando eles começaram a ir além da simples pesquisa na web e começaram a criar produtos com base nisso – o AdWords foi o primeiro – (os engenheiros) perceberam os bancos de dados necessários. Eles não só precisavam de bancos de dados tradicionais, mas também deles em grande escala.
Portanto, o Google era uma empresa extremamente tecnológica e isso levou a uma série de inovações.
Uma experiência no AdWords foi iniciada no MySQL porque eles queriam um banco de dados relacional de transações. Então entrei direto nesse projeto. Na verdade, eu mesmo criei um ponto.com e usávamos Java muito. E quando cheguei ao Google, a primeira coisa em que fui colocado foi a infraestrutura Java.
Muito do que trabalhei naquela fase inicial foi construir aplicativos Java que funcionassem como as operações C++ do Google em produção. Eu escrevi o mecanismo de servlet do Google, que substituiu o Tomcat, para que eles pudessem executar Java da mesma forma que executavam binários C++. Foi assim que conheci Ben.
Portanto, o gargalo da pesquisa eram os bancos de dados…
O Google fez isso como todo mundo no vale: eles fragmentaram e esse fragmento foi feio.
Em última análise, como qualquer solução escalável – e isso é verdade para o Cockroach tanto quanto era verdade para o processo manual de tentativa de particionar o MySQL – você tem um sistema escalável em teoria, mas quando você realmente obtém esses níveis de escala, você encontra problemas você não estava esperando.
Digamos que você tenha oito fragmentos do MySQL e vários servidores de aplicativos front-end Java AdWords, e eles têm todas essas conexões começando a sobrecarregar todos os bancos de dados. Então você tem que descobrir o que fazer lá.
Você tem centenas de milhares de usuários e todos estão fazendo login. Fragmentamos com base no ID do usuário. Então, se você tiver o ID, poderá saber exatamente com facilidade, vá para o fragmento sete.
Mas se você quiser ver um índice secundário, como, por exemplo, um nome de usuário ou um endereço de e-mail, em vez de um ID de usuário, você não sabe onde ele está. Então o que eles fizeram foi consultar todos os fragmentos de uma vez, em paralelo. Este foi um grande fan-out. Cada banco de dados recebia literalmente milhões de solicitações e estava sobrecarregando os servidores de banco de dados.
Não vou entrar em detalhes técnicos, mas foi um grande projeto só para resolver esse problema. E fomos para 32 fragmentos. Eventualmente, eles tinham 1.000. E isso estava tornando cada um dos servidores MySQL cada vez maiores.
Essa experiência do AdWords persistiu por cerca de 10 anos. Essa arquitetura, no entanto, foi proibida (no Google): era um antipadrão: “Você nunca pode fazer fragmentação do MySQL. ‘Isso preparou o terreno para o Google encontrar outras maneiras de construir bancos de dados.
Tudo o que eles construíram poderia ter um bilhão de usuários. As pessoas não precisavam fazer login no Google com frequência, mas tinham cookies, certo?
Assim, até que um cookie fosse apagado, você poderia saber que um determinado usuário tinha determinados interesses, fazia determinados tipos de consultas, tinha um histórico de pesquisas, por exemplo. Então talvez esse cookie tenha existido por uma semana ou um mês ou algo parecido. E na verdade permitiria melhorar os resultados da pesquisa para um usuário específico.
Mas isso requer armazenamento por cookie. Agora você tem um bilhão de nomes para os quais está tentando criar alguma história. Portanto, mesmo que você queira fragmentar o MySQL, não é razoável.
Então eles começaram a construir o Bigtable.
Vou te contar uma história interessante. O NoSQL existiu por mais de uma década sem transações. E as pessoas acharam que estava tudo bem. Quando o Google lançou o Bigtable, ele não tinha transações, mas tinha escalabilidade elástica. Era um ótimo sistema para determinados casos de uso quando você realmente não precisava de transações. A equipe de infraestrutura que o construiu contava com algumas das pessoas mais inteligentes do Google.
Mas quando a equipe do AdWords analisou o Bigtable, disse: ‘Você está brincando? Temos 500 mesas. Temos transações para tudo. Há dinheiro em jogo. Não podemos usar o Bigtable.’
Então a equipe de infraestrutura adicionou alguns tipos de transações ao Bigtable, e eles chamam isso de Megastore.
Ao mesmo tempo, eles perceberam que os data centers que estavam construindo estavam sempre inoperantes. Bigtable estava lutando com isso. Então a Megastore realmente usou o Paxos para replicação de consenso, e isso foi uma grande inovação.
Os 10 anos que estive no Google, e vendo todas aquelas diferentes evoluções de produtos de banco de dados muito escaláveis, informaram minha perspectiva, como você pode imaginar.
Então, quando Peter, Ben e eu deixamos o Google, começamos esta empresa. Mesmo sendo uma empresa pequena, porque éramos engenheiros de infraestrutura e também engenheiros de aplicação. queríamos uma infraestrutura no nível do Google. Por que construir algo que regrediu 10 anos?
Vimos toda essa melhoria. Queríamos ter as mesmas capacidades. Queríamos escalar esse sistema sem todo esse trabalho extra para fazer isso manualmente.
Hoje, o CockroachDB parece ser comercializado principalmente para arquitetos de sistemas, e não para desenvolvedores. Por que isso acontece?
Nós lutamos com essa questão porque há muito mais desenvolvedores no mundo. E se um desenvolvedor quiser usar o Cockroach, ele vai usar, certo? Eles começarão com isso e poderão evoluir para algo valioso e bem-sucedido.
No entanto, acontece que os desenvolvedores se preocupam apenas com a familiaridade e a facilidade de uso da experiência do desenvolvedor. Eles não se preocupam tanto com os problemas que o CockroachDB resolve. E nos esforçamos muito para fazer com que o Cockroach se parecesse com o Postgres, um padrão familiar.
Mas o CockroachDB não é um banco de dados monolítico. Não parece um quando você realmente se dedica a isso. Você pode ter que se preocupar com coisas diferentes. E se você realmente deseja que ele seja escalonável entre regiões, você tem essa latência, então precisa ter cuidado ao construir seu aplicativo.
Há uma complexidade aí. Não existe quando você tem apenas um relacionamento simples entre um aplicativo e seu banco de dados. A beleza do Cockroach são todos esses recursos avançados de sobrevivência e escalabilidade massiva e coisas assim. O desenvolvedor não está tentando resolver esses problemas. A complexidade extra é apenas um custo. Mas para um arquiteto, esse é o seu trabalho para resolver esses problemas.
Então você pode ver o dilema aí.
Spencer Kimball
Então, o que percebemos é que o Cockroach é realmente interessante e incrivelmente ambicioso para arquitetos-chefes e CTOs em startups. Eles querem usar o Barata assim como eu. Quando eu estava no Google, Cockroach teria sido um golpe certeiro. São aqueles casos de uso em que o banco de dados absolutamente não pode cair – esses são os clientes que realmente precisam do Cockroach.
Na verdade, ficamos muito mais focados como empresa. No início, você deseja que alguém que usará seu sistema o ajude a entendê-lo e desenvolvê-lo. Mas como chegamos ao ponto em que até mesmo as grandes empresas estão usando o Cockroach, o que realmente nos ajuda a focar é com quem tentamos conversar, exclusivamente no mercado de ponta.
E isso ajuda. Se você tentar falar com o nível superior e o nível inferior ao mesmo tempo, você realmente não está transmitindo uma boa mensagem para nenhum deles, porque o nível superior não consegue ouvir seus problemas. E se você estiver falando com o segmento inferior, o segmento superior não ouvirá sobre nenhum de seus problemas.
E isso tem implicações profundas para o nosso roteiro? Tipo, trata-se de bancos de dados gratuitos? Ou os recursos que importam para uma empresa são segurança absurda, resiliência à prova de balas ou recursos alucinantes de execução ativa entre fornecedores de nuvem?
Por que a portabilidade entre nuvens é importante?
Uma coisa é ser capaz de se mover entre as nuvens, outra coisa é ser capaz de sobreviver ativamente a uma falha na nuvem ou desligá-la. Tipo, esse é um recurso fenomenal do CockroachDB. E se pudermos falar sobre isso e fazer disso uma mensagem, obviamente, isso atrairá os arquitetos-chefes e, até mesmo, em alguns casos, as pessoas responsáveis pela estratégia de negócios dessas grandes empresas.
Na verdade, estamos encarando nosso mandato como algo mais do que apenas oferecer um banco de dados. Os riscos de concentração de fornecedores que essas empresas costumavam enfrentar com a Oracle eram muito graves. Agora, se todos os seus produtos estiverem com um fornecedor de nuvem, esse fornecedor de nuvem pode se tornar uma fonte de aprisionamento tão grande que pode realmente afetar sua capacidade de negociação.
Assim, por vários motivos, as grandes empresas estão começando a ter uma presença cada vez maior em multicloud. Acredito que há uma oportunidade para essas empresas assumirem mais controle sobre seu destino por parte de seus fornecedores de nuvem.
Estamos oferecendo algum grau de portabilidade e flexibilidade na nuvem. Você consegue andar de skate acima da nuvem pública? Você está construindo seus aplicativos ou sua empresa de uma maneira que usa os fornecedores de nuvem da maneira que eles deveriam ser usados – como provedores e não necessariamente como um fornecedor tão crítico que você fica preso em sua órbita?
O que você vê como tendências emergentes no espaço de banco de dados?
Certamente suporte para IA. E acho que é um bom momento para trabalhar em infraestrutura em geral. A IA será um acelerador. Todos irão reimaginar seus casos de uso existentes e muitas coisas novas serão construídas. E acho que isso será verdade em todos os negócios – certamente naqueles que já estão inclinados para o Barata. Estas são empresas que são curiosas em tecnologia.
Não importa o que você esteja construindo, você sempre precisará desse sistema de registro, um banco de dados operacional para todos os casos de uso do mundo. Há apenas dois anos, quando fiz entrevistas, todos me perguntaram se o Cockroach faria um blockchain criptografado. Não, esse não é o nosso plano. Mas cada empresa de criptografia ainda precisa ser um sistema de registro extremamente escalonável.
A IA irá, segundo algumas estimativas, acrescentar triliões de dólares à economia global na próxima década. E isso claramente envolverá a gravação de muitos dados adicionais.
A editora-chefe do TNS, Heather Joslyn, contribuiu para esta postagem.
YOUTUBE.COM/THENEWSTACK
A tecnologia avança rápido, não perca um episódio. Inscreva-se em nosso canal no YouTube para transmitir todos os nossos podcasts, entrevistas, demonstrações e muito mais.
SE INSCREVER
