Criando serviços de dados amigáveis ao desenvolvedor com o Apache Cassandra

Todos os aplicativos dependem de dados, mas os desenvolvedores de aplicativos não gostam de pensar em bancos de dados. Aprender os componentes internos e a linguagem de consulta de um banco de dados específico adiciona carga cognitiva e requer troca de contexto que diminui a produtividade. Ainda assim, aplicativos bem-sucedidos devem ser responsivos, resilientes e escaláveis — todas as características que serão determinadas pela escolha do banco de dados.

Como, então, um desenvolvedor de aplicativos deve equilibrar essas considerações?

E se pudéssemos mudar o equilíbrio, fornecendo um serviço de dados em idiomas amigáveis ao desenvolvedor, em vez de esperar que os desenvolvedores aprendam idiomas específicos do banco de dados?

No projeto Stargate, o gateway de dados de API de código aberto projetado para funcionar com Apache Cassandra , estamos entusiasmados em começar a falar publicamente sobre nossa próxima API JSON que atende aos desenvolvedores orientados a JSON em seus termos. Isso não é apenas uma ótima notícia para desenvolvedores orientados a JSON, mas a técnica que seguimos constitui um novo padrão de design para alavancar APIs de dados e modelagem avançada de dados para produzir serviços de dados.

Neste artigo, discutirei como fornecer idiomas amigáveis ao desenvolvedor usando Cassandra junto com Stargate e como estamos trabalhando para fazer exatamente isso para JSON .

Modelos de dados: interoperabilidade vs. idioma

No início, Cassandra às vezes era descrita como “uma máquina para fazer índices”. Isso foi uma prova da resiliência e flexibilidade inerentes de Cassandra, uma argila da qual estruturas mais robustas poderiam ser moldadas. Cassandra hoje é uma argila mais rica e com maiores possibilidades.

Não é apenas um ótimo banco de dados, mas também uma ótima máquina para criar bancos de dados. Aqui no projeto Stargate, estamos usando a API JSON para provar isso como o primeiro exemplo de um novo paradigma no desenvolvimento de banco de dados.

Não é incomum que um banco de dados seja construído a partir de outro. Até o MongoDB é construído sobre o WiredTiger , se você se aprofundar o suficiente. A AWS é conhecida por seu uso extensivo de MySQL nos bastidores, incluindo o uso do mecanismo de armazenamento MySQL para DynamoDB . Portanto, a ideia de usar o Cassandra, com sua escalabilidade e desempenho inerentes, como bloco de construção para outros sistemas de dados faz sentido.

No entanto, os desenvolvedores de aplicativos realmente não interagem com bancos de dados. Mesmo que sua organização gerencie sua própria infraestrutura de banco de dados e construa aplicativos nessa infraestrutura, a primeira etapa geralmente é definir e implementar os modelos de dados que seus aplicativos exigem.

Esses modelos de dados fazem a mediação entre o aplicativo e o banco de dados. De certa forma, a modelagem de dados limita um banco de dados; ele pega argila não formada e, portanto, de uso geral, e a molda em algo construído especificamente para um idioma de aplicação específico. Sacrificamos a interoperabilidade por algo idiomático.

É uma boa ideia trocar por algo idiomático e desistir de algo interoperável? Se você quiser superar as médias, a resposta é um enfático “sim”. Não pensamos muito assim ao escolher bancos de dados, mas há muito tempo pensamos assim ao escolher linguagens de programação.

Essa ideia foi bem expressa por Paul Graham décadas atrás, quando ele explicou como a Viaweb venceu a primeira corrida pontocom para criar a primeira plataforma de comércio eletrônico baseada na web amplamente bem-sucedida.

A Viaweb não era necessariamente a plataforma de comércio eletrônico mais rápida ou escalável. Nas palavras de Graham, foi “razoavelmente eficiente”. Em vez disso, Graham argumenta que, para linguagens de programação, em uma escala de legível por máquina a legível por humanos, as linguagens mais legíveis por humanos (e, portanto, de nível superior) são mais poderosas porque melhoram a produtividade do desenvolvedor. E na época da Viaweb, Graham achava que a linguagem mais poderosa era Lisp . O cerne do argumento de Graham é este:

“Nossa hipótese era que, se escrevêssemos nosso software em Lisp, seríamos capazes de executar recursos mais rapidamente do que nossos concorrentes e também fazer coisas em nosso software que eles não poderiam fazer. E como Lisp era de alto nível, não precisaríamos de uma grande equipe de desenvolvimento, então nossos custos seriam menores. Se assim fosse, poderíamos oferecer um produto melhor por menos dinheiro e ainda ter lucro. Acabaríamos conseguindo todos os usuários, nossos concorrentes não conseguiriam nenhum e acabariam fechando as portas.”

Desbloqueando a produtividade do desenvolvedor

Graham escreveu essas palavras há 20 anos, e a produtividade do desenvolvedor continua sendo a estrela do norte que orienta grande parte da inovação em tecnologia. Onde Graham fala sobre o poder das linguagens de alto nível, expressamos o mesmo conceito de fornecer aos desenvolvedores ferramentas que são mais idiomáticas para sua experiência de desenvolvimento de software.

Graham elogia Lisp (com razão) e, desde a época das pontocom, vimos uma proliferação de novas linguagens de alto nível: Ruby e Rust, para citar algumas. Também vimos o nascimento e a proliferação de linguagens e estruturas para desenvolvedores de dispositivos móveis, como Swift, Flutter e Dart.

Então, por que linguagens como C e C++ ainda são importantes? A velha piada sobre C contém uma verdade importante: “Combinar o poder da linguagem assembly com a facilidade de uso da linguagem assembly”. Se você deseja escrever um compilador, precisa se aproximar do idioma da linguagem de máquina e se afastar do idioma da linguagem natural.

Em outras palavras, entre outras virtudes, C e C++ são máquinas para construir novas linguagens. O que é fácil de ignorar nos elogios de Graham ao Lisp é que o Lisp também tem algumas dessas características de “máquina para construir linguagens”.

Lisp foi a primeira linguagem amplamente usada a introduzir o conceito de macros, e muitas vezes é o conceito de macros que atrapalha aqueles que são novos no Lisp. Depois de entender as macros, você entende que Lisp é mais uma metalinguagem do que uma linguagem e que as macros podem ser usadas para construir uma linguagem específica para um domínio de problema específico.

Projetar e criar um conjunto inicial de macros é um trabalho árduo e intelectualmente desafiador. Mas assim que Graham e a equipe da Viaweb fizeram isso, na verdade eles tinham uma linguagem de programação de comércio eletrônico para trabalhar, e isso liberou a produtividade do desenvolvedor que os permitiu superar a concorrência.

Vinte anos depois, tudo isso parece bastante claro no contexto das linguagens de programação. Então, o que aconteceu no mundo do banco de dados? A resposta curta é que os bancos de dados evoluíram mais lentamente.

A revolução da API de dados

Se os dados tabulares são a linguagem assembly do mundo dos bancos de dados, o SQL é o C/C++ das linguagens de consulta. Desenvolvemos estruturas de dados tabulares e o conceito de normalização de dados em uma época em que a computação e o armazenamento eram caros e para casos de uso bem definidos com alterações de esquema relativamente pouco frequentes. Nesse contexto, para operar com eficiência em qualquer tipo de escala, os bancos de dados precisavam imitar de perto a maneira como os computadores armazenavam e acessavam as informações.

O mundo de hoje é o oposto, fazendo com que o tempo anterior pareça arcaico em comparação: os custos de computação e armazenamento são altamente comoditizados, mas em um mundo de dados em tempo real combinados com aprendizado de máquina e inteligência artificial, os casos de uso são abertos e as alterações de esquema são freqüente.

A revolução mais recente na tecnologia de banco de dados foi a revolução NoSQL, uma resposta direta ao cânone de dados tabulares e normalizados estabelecidos pelos sumos sacerdotes do mundo dos bancos de dados relacionais. Quando dizemos “revolução NoSQL”, nos referimos ao período de 2004, quando o Google lançou seu white paper MapReduce , até 2007, quando a Amazon publicou seu white paper Dynamo .

O que emergiu desse período foi uma família de bancos de dados que alcançou velocidade, escalabilidade e resiliência sem precedentes ao descartar dois princípios relacionais acarinhados: bancos de dados NoSQL favoreceram dados desnormalizados em vez de normalização de dados e favoreceram consistência eventual em vez de consistência transacional. Cassandra, lançado pela primeira vez em 2008, surgiu dessa revolução.

As APIs de dados serão a próxima grande revolução na tecnologia de banco de dados, uma revolução que está apenas começando. As mudanças no mundo dos bancos de dados tendem a ficar para trás das mudanças nas linguagens de programação e no desenvolvimento de aplicativos. Portanto, embora as APIs RESTful já existam há algum tempo e tenham ajudado a introduzir a arquitetura para aplicativos distribuídos orientados a serviços, estamos apenas começando a ver as APIs de dados se manifestarem como uma parte fundamental da infraestrutura de aplicativos.

Para entender o significado dessa revolução e como, 20 anos após a proclamação de Paul Graham, o mundo do banco de dados está finalmente entregando a produtividade do desenvolvedor, vamos ver a história do próprio Stargate. Começa retornando ao tema interoperável versus idiomático.

Stargate: uma experiência idiomática de desenvolvedor de alta fidelidade

Quando decidimos que o ecossistema Cassandra precisava de um gateway de dados, criamos o conjunto original de APIs Stargate com um senso de urgência. Isso significava uma arquitetura monolítica; monólitos são mais rápidos de construir, mas nem sempre melhores. Lançamos com uma API Cassandra Query Language (CQL), uma API REST e uma API RESTful Document. Adicionamos rapidamente o GraphQL como uma API adicional. Até o momento, Stargate tem sido interoperável; tudo do Stargate é armazenado usando um modelo de dados CQL nativo, portanto, em princípio, você pode consultar qualquer tabela de qualquer API.

Aprendemos que, na prática, ninguém realmente faz isso. Os desenvolvedores seguem seu idioma específico. Ao favorecer a interoperabilidade, introduzimos ismos de Cassandra na experiência do desenvolvedor, impedindo assim a produtividade do desenvolvedor. Como a versão original do Stargate exigia que os desenvolvedores entendessem as estruturas de dados tabulares de colunas largas do Cassandra, para entender os keyspaces e partições, ancoramos muito perto do idioma da máquina e muito longe do idioma humano.

A armadilha da interoperabilidade é favorecer o propósito geral em detrimento do pensamento de design embutido no propósito. Passamos a pensar em termos de construção de propósito, que troca alguma capacidade geral por um modo de expressão mais específico, aproximando-nos do idioma humano e afastando-nos do idioma da máquina. E então começamos a pensar: poderíamos oferecer uma experiência de desenvolvedor idiomática de alta fidelidade, mantendo as virtudes das bases NoSQL do Cassandra (escala, disponibilidade e desempenho)?

A chave está na modelagem de dados. Para transformar Cassandra no “Lisp dos bancos de dados”, precisávamos de um modelo de dados que pudesse servir a um propósito análogo às macros Lisp, junto com uma API Stargate que permitisse aos desenvolvedores interagir idiomáticamente com esse modelo de dados. Começamos com JSON, o maior denominador comum de estruturas de dados entre os desenvolvedores de aplicativos e, assim, começamos a construir a API JSON para Stargate. Então tivemos que descobrir a melhor forma de modelar JSON em Cassandra.

O Stargate já possui uma API de documento, mas na API de documento original do Stargate, usamos um modelo de dados que chamamos de “fragmentação ” para renderizar um documento JSON como uma tabela Cassandra. Este modelo mapeia um documento para várias linhas em uma única tabela Cassandra e preserva a interoperabilidade. Se você usar CQL para consultar a tabela resultante, receberá resultados significativos.

Este modelo de dados de fragmentação original tem desvantagens. Ele não preserva metadados sobre um documento. Por exemplo, para qualquer documento contendo arrays, uma vez que o documento é escrito, não sabemos nada sobre o tamanho do array sem inspecionar completamente o documento. Mais significativamente, partimos das expectativas de Cassandra sobre a indexação. Cassandra indexa em linhas, mas agora espalhamos nosso documento em várias linhas, impossibilitando um índice nativo de documentos Cassandra.

Para tornar o Cassandra um mecanismo de armazenamento adequado para JSON, precisaríamos de um novo modelo de dados, algo superior à trituração. Chamamos isso de “super trituração”. Você pode aprender mais sobre superdestruição na palestra de Cassandra Summit de Aaron Morton em dezembro, mas aqui está um pouco de provocação: Aproveitamos a natureza de coluna larga de Cassandra para armazenar um documento por linha, sabendo que uma linha de Cassandra pode lidar até mesmo com arquivos muito grandes documentos.

Também temos um conjunto de colunas nessa linha que são explicitamente para armazenar características de metadados padrão de um documento JSON. Agora temos algo mais facilmente indexável, bem como um meio de preservar e recuperar metadados.

Contribuindo de volta para Cassandra

Sim, para que tudo isso funcione em escala, precisaremos de algumas alterações básicas no Cassandra. O Accord, que a Apple está contribuindo para o Cassandra 5, nos ajudará a lidar com alterações de dados de maneira mais transacional. Storage-attached indexing (SAI) e Global Sort, com os quais a DataStax está contribuindo para o Cassandra 5 , nos ajudarão a lidar com consultas variadas em documentos JSON de maneira mais eficiente.

O Cassandra não é um software estático; é um projeto de código aberto vibrante e em evolução. Portanto, também estamos dando continuidade a uma longa tradição do Cassandra de usar requisitos que surgem do lado do cliente para promover mudanças no lado do banco de dados. As necessidades dos usuários motivaram as propostas de Accord, SAI e Global Sort. Isso não apenas tornará a API JSON do Stargate melhor, mas também tornará o Cassandra melhor. Este é um ótimo lembrete de que engenheiros de dados e desenvolvedores de aplicativos não são duas comunidades diferentes, mas coortes complementares da comunidade estendida do Cassandra.

E JSON é apenas o primeiro passo. Essencialmente, teremos construído um banco de dados de documentos com o qual você interage por meio de uma API JSON de Cassandra, Stargate e um modelo de dados Cassandra razoavelmente eficiente. Super trituração é a nossa macro. Essa abordagem transforma Cassandra em uma máquina para fazer bancos de dados.

Essa abordagem poderia ser seguida por outro banco de dados além do Cassandra? Não é fácil, e aqui está o porquê. Existe uma espécie de banco de dados análogo à segunda lei da termodinâmica que funciona a favor de Cassandra. Começamos com algo rápido, escalável e resiliente, mas não muito idiomático para os desenvolvedores. Dentro das restrições de eficiência razoável, trocamos parte dessa velocidade, escala e resiliência por uma interface mais idiomática para apresentar aos desenvolvedores. O que não se pode fazer facilmente é ir na direção inversa. Começar com algo altamente idiomático e tentar descobrir como torná-lo rápido, escalável e resiliente é uma tarefa assustadora que pode nem ser possível.

Esse princípio termodinâmico é o motivo pelo qual as APIs de dados são a nova revolução do banco de dados e o motivo pelo qual o Cassandra é o banco de dados que impulsionará essa revolução.

Também publicado aqui.