O problema Poliglota: resolvendo o paradoxo do banco de dados ‘certo’

(Leszek Glasner/)

a persistência Poliglota, introduzida pela primeira vez em 2011, agora é quase Direito Canônico. Então, o que eu tenho a dizer pode parecer blasfêmia.

a maioria das organizações hoje adotou o conceito de persistência Poliglota — implantando uma variedade de diferentes tecnologias de armazenamento de dados com base na variedade de maneiras que consultam, analisam e implantam seus dados. E o crescimento e a difusão dos armazenamentos de dados key/value, graph, time series e JSON forneceram aos desenvolvedores opções abundantes para escolher a ferramenta de dados certa para o trabalho certo.

mas as exigências sobre nós como desenvolvedores evoluíram rapidamente e eu acredito que a persistência Poliglota vai lutar rapidamente para manter o ritmo. Ou, talvez, essa já seja a realidade que você está enfrentando hoje. Por quê? Porque a tarefa que temos é assustadora e as equipes de desenvolvimento já estão esticadas.

diversidade de banco de dados

precisamos ser especialistas em um amplo espectro de tecnologias de banco de dados, cada uma com suas próprias linguagens de consulta. Precisamos que nossos aplicativos forneçam resultados eficientes em um número crescente de casos de uso. E nós somos convidados a construir e gerenciar centenas crescendo para milhares de aplicações baseadas em dados diversos que exigem uma variedade de modelos de dados e implantações. Você pode imaginar dominar e manter mais uma tecnologia ou linguagem de consulta? Que tal mais cinco? Mais dez?

o Software está comendo o mundo, nossos esforços de desenvolvimento só vão crescer, o tempo e os custos para integrar vários datastores são insustentáveis e os desenvolvedores precisam desesperadamente se concentrar em um conjunto finito de tecnologias de banco de dados.

mais importante, os casos de uso estão crescendo em sofisticação e o que pediremos de nossos dados exigirá o uso de vários modelos de dados, talvez até instantaneamente. Construir soluções alternativas no código do aplicativo para calcular consultas não é Sustentável ou escalável. Acredito que é hora de as organizações buscarem abordagens híbridas que lhes permitam simplificar seu portfólio de tecnologia e ter a flexibilidade de escolher o modelo de dados certo para o trabalho certo.

explorando modelos de dados

descobri que é útil entender quais modelos de dados funcionam bem para diferentes usos e como eles podem ser combinados.

bancos de dados de documentos JSON

JSON é muito versátil para dados não estruturados e estruturados. A natureza recursiva do JSON permite a incorporação de subdocumentos e listas de comprimento variável. Além disso, você pode até armazenar as linhas de uma tabela como documentos JSON, e os armazenamentos de dados modernos são tão bons em compactar dados que essencialmente não há sobrecarga de memória em comparação com bancos de dados relacionais. Para dados estruturados, a validação do esquema pode ser implementada conforme necessário usando uma API HTTP extensível.

Graph Databases

Graph databases são bons modelos de dados para relações. Em muitos casos do mundo real, um gráfico é um modelo de dados muito natural. Ele captura relações e pode conter informações de rótulo com cada borda e com cada vértice. Documentos JSON são um ajuste natural para armazenar esse tipo de dados de vértice e borda.

um banco de dados gráfico é particularmente bom para consultas “gráficas”. O crucial aqui é que a linguagem de consulta deve implementar rotinas como “caminho mais curto” e “travessia do gráfico”, a capacidade fundamental para isso é Acessar a lista de todas as arestas de saída ou entrada de um vértice rapidamente.

bancos de dados Multi-Modelo

um banco de dados multi-modelo combina os recursos dos bancos de dados de documentos, chaves/valores e gráficos. Ele permite que você escolha diferentes modelos de dados com menos sobrecarga operacional. Ter vários modelos de dados disponíveis em um único mecanismo de banco de dados alivia alguns dos desafios da utilização de diferentes modelos de dados, ao mesmo tempo, porque isso significa menos sobrecarga operacional e menos de sincronização de dados, e, portanto, permite um enorme salto na modelagem de dados de flexibilidade.

de repente, você tem a opção de manter os dados relacionados juntos no mesmo armazenamento de dados, mesmo que precise de modelos de dados diferentes. Ser capaz de misturar os diferentes modelos de dados em uma única consulta aumenta as opções de design de aplicativos e otimizações de desempenho. E se você optar por dividir a camada de persistência em várias instâncias de banco de dados diferentes (mesmo que elas usem o mesmo modelo de dados), ainda terá o benefício de apenas implantar uma única tecnologia. Além disso, um bloqueio de modelo de dados é impedido.

a solução Poliglota

a persistência Poliglota foi aceita porque nos permitiu evitar comprometer uma tecnologia de banco de dados monolítica. Entendemos que a persistência Poliglota teve um custo de complexidade, um custo de desempenho e um custo de consistência e Disponibilidade à medida que os clusters cresciam cada vez maior. Mas a maioria, se não todos, de nós sentiu que os benefícios da flexibilidade do modelo de dados superaram em muito esses custos porque um banco de dados monolítico nunca existiria e nunca existirá para atender a todos ou mesmo à maioria dos requisitos e casos de uso.

hoje, é claro que precisamos dos benefícios da persistência Poliglota sem o custo. Precisamos ter a flexibilidade de criar aplicativos de alto desempenho que escalem horizontalmente e utilizem uma variedade de modelos de dados. Precisamos de linguagens de consulta que nos permitam consultar nativamente e em diferentes modelos de dados. Precisamos de bancos de dados para nos dar liberdade e flexibilidade para usar diferentes modelos de dados de maneiras únicas à medida que nossos projetos inevitavelmente evoluem.

para muitas organizações avançadas, já é comum usar um banco de dados de gráfico pequeno em uma parte de um projeto, uma implantação de chave/valor grande para outra ou uma combinação de modelos de gráfico, chave/valor e documento (JSON) para outra.

versatilidade de dados

considere um conjunto de dados complexo como o de uma frota de aeronaves composta por várias aeronaves, cada uma composta por vários milhões de peças, que formam subcomponentes, depois componentes maiores e menores, todos os quais se enquadram em uma hierarquia de “itens.”

para uma manutenção ideal da frota, a organização deve armazenar uma variedade de dados em diferentes níveis da hierarquia, por exemplo. nomes de peças ou componentes, números de série, Informações do fabricante, intervalos de manutenção, datas de manutenção, informações sobre subcontratados, links para manuais e documentação, pessoas de contato, informações de contrato de garantia e serviço, etc. Esse tipo de Hierarquia de dados é um ajuste natural claro para um banco de dados gráfico porque captura relações entre diferentes pontos de dados, incluindo informações em cada aresta e vértice. Mas um banco de dados gráfico é ideal para responder com eficiência às principais consultas da equipe de manutenção da frota?

um banco de dados gráfico funciona bem para a pergunta: “Quais são todas as partes de um determinado componente?”E pode ser capaz de ajudar a responder à pergunta:” dada a parte quebrada a, qual é o menor componente da aeronave que contém a peça e para o qual existe um procedimento de manutenção?”Mas um banco de dados gráfico seria um pouco inútil com uma pergunta comum, como” quais partes desta aeronave precisam de manutenção na próxima semana?”porque a estrutura do gráfico não se encaixa na consulta.

no entanto, se esses dados do gráfico pudessem ser armazenados como documentos JSON, associando dados arbitrários a vértices e arestas, essa pergunta poderia ser facilmente respondida por meio de uma consulta de Documento.

o ponto é que para obter todas as consultas nesse sistema feito rápido, você precisa de um banco de dados que pode armazenar informações como uma variedade de modelos de Dados, Muitas vezes chamado de banco de dados multi-modelo. Não seria bom se esse banco de dados gráfico pudesse implementar índices secundários em seus dados de vértice?

mas então se tornaria essencialmente um banco de dados multi-modelo. É um bom primeiro passo. O cenário ideal é usar um gráfico, documento e um modelo de dados de chave/valor, todos ao mesmo tempo, para primeiro encontrar peças com manutenção devida, executar o cálculo de caminho mais curto acima para cada uma delas e, em seguida, executar uma operação de junção com a coleção de contatos para adicionar informações de contato concretas. Acessar um modelo de dados diferente deve estar apenas alterando uma consulta, não seu banco de dados. É aí que precisamos ir, e em breve.

este exemplo de manutenção de frota não é único ou mesmo especial. Ao falar com desenvolvedores, descobri que é simplesmente um bom análogo para o número crescente e a diversidade de casos de uso que os desenvolvedores estão vendo. Do meu ponto de vista, o aprendizado fundamental da persistência Poliglota é a necessidade de usar o modelo de dados certo para o trabalho certo. E com inovações em tecnologia de banco de dados, podemos ter mais de um no mesmo mecanismo de banco de dados. Caso contrário, precisamos reconhecer que a persistência Poliglota é seu próprio compromisso que nos limita e, eventualmente, nos deixará atrás de nossos concorrentes.

sobre o autor: Max Neunhoeffer é desenvolvedor sênior e arquiteto da ArangoDB. Em sua carreira acadêmica, trabalhou por 16 anos no desenvolvimento e implementação de novos algoritmos em álgebra computacional. Vários anos atrás, ele mudou seu foco para Bancos de dados NoSQL. No ArangoDB, ele é responsável por” todas as coisas distribuídas”, incluindo implantação no Kubernetes, mas também resiliência, failover e escalabilidade. Seus interesses particulares incluem transações distribuídas, sistemas distribuídos de autocura e ajuste de desempenho. Se seus dias tivessem 48 horas, ele jogaria golfe, velejaria, tocaria piano e inventaria uma nova linguagem de programação.

Tags: ArangoDB, graph, json, key-value, banco de dados multi-modelo, poliglota, persistência poliglota, relacional

Deixe uma resposta

O seu endereço de email não será publicado.