SQL e NoSQL podem coexistir?

Bancos de dados relacionais e SQL foram inventados na década de 1970, mas ainda dominam o mundo dos dados hoje. Por quê? Cálculo relacional, dados consistentes, representação lógica de dados são todas as razões que um defensor de banco de dados relacional pode creditar ao seu sucesso. No entanto, o sucesso dos bancos de dados relacionais pode ser resumido a duas considerações práticas: impulso e poder da linguagem de consulta SQL.

A chamada tecnologia “NoSQL” parece ir contra esses pontos fortes. Mas na realidade, NoSQL está ganhando impulso próprio, e fornecer a familiaridade e o poder do SQL é como isso está sendo feito.

O poder do SQL

Vamos rever o poder do SQL supondo que ele não exista: não existe uma linguagem declarativa para trabalhar com dados. Em vez disso, temos que trabalhar imperativamente. Em vez de especificar o que dados que queremos, temos que especificar Como as para obtê-la.

Com essa estratégia, cada etapa de uma consulta de banco de dados recebe instruções detalhadas: correspondência, agrupamento, projeção e classificação. Alguns processados ​​pelo cliente e outros pelo servidor. Comparando essa estratégia com uma consulta SQL declarativa, como projetar, como classificar e todo o processamento especificado é deixado para o banco de dados. O que nos resta é uma linguagem mais fácil de ler e escrever que nos fornece os dados que queremos. E é uma linguagem padrão que alguém que trabalha com dados pode pegar e usar com qualquer outro banco de dados relacional. Não é de admirar que o relacional e o SQL dominem.

Os limites do relacionamento

Então, por que o NoSQL existe? Gartner descobriram que o mercado de DBMS não relacional foi o segmento que mais cresceu em 2020, expandindo 34,5% (mais que o dobro do crescimento do relacional). Os bancos de dados relacionais não foram projetados para lidar com a escala da web. Você quer um servidor relacional para lidar com mais trabalho? Você precisa escala verticalmente isto. O que significa apenas que você precisa de um servidor maior e mais rápido.

O que acontece quando isso se torna impossível ou extremamente caro? Se você é Amazon ou Google, precisa sair do modelo relacional. Você tem que escala horizontal, o que significa que você precisa unir vários servidores em uma rede. Isso introduz um mundo totalmente novo de desafios para resolver. A Amazon e o Google tinham os recursos para enfrentar esses problemas, fazer a pesquisa e divulgar os documentos técnicos, levando a toda uma nova geração de bancos de dados de código aberto e fornecedores focados em banco de dados, em um movimento apelidado de “NoSQL”.

Devo usar NoSQL ou não?

À medida que o NoSQL decolou, o mesmo aconteceu com os microsserviços (uma abordagem distribuída para dimensionamento horizontal de aplicativos). Cada microsserviço poderia usar seu próprio banco de dados e, em muitos casos, isso significava que um sistema completo poderia estar usando uma colcha de retalhos de vários bancos de dados.

Parece uma boa abordagem, mas há desafios. Cada microsserviço tem seu próprio domínio de dados, que é um bom design encapsulado. Mas agora os dados estão espalhados, não apenas entre diferentes bancos de dados, mas em diferentes tecnologias. Nesse novo cenário, sua equipe precisa manter, atualizar, comprar, licenciar, corrigir (log4jalguém?), e aprender diferentes tecnologias de banco de dados, mas eles também precisam comprar, licenciar, construir, manter, corrigir (log4j de novo?), e aprender pipelines e integrações de dados entre essas tecnologias. Isso é conhecido como “expansão de banco de dados”.

Soluções: modelo único, nuvem e multimodelo

Três abordagens podem ajudar a reduzir a expansão do banco de dados:

• Padronize em um único banco de dados
• Bloqueie-se em um provedor de nuvem
• Use uma abordagem multimodelo

Padronize em um único banco de dados

Essa abordagem significa ditar à sua organização: “use este banco de dados para tudo”. O impulso do banco de dados relacional o torna uma escolha in style: pode não ser a melhor escolha para pesquisa, cache ou gráfico, mas “ninguém nunca foi demitido por comprar a IBM”. como dizia o ditado.

Prós: Enorme conjunto de talentos, geralmente pode “fazer funcionar” com pace ou dinheiro suficiente

Contras: Caro, menos ágil

Para organizações que trabalham em um domínio padronizado que não muda com frequência e não precisa lidar com grande escala, essa abordagem cara deve ser considerada.

Bloqueie-se em um provedor de nuvem

Provedores de nuvem populares (Azure, AWS, GCP) reuniram bancos de dados de código aberto, APIs e suas próprias tecnologias de banco de dados proprietárias “como um serviço”. Eles podem oferecer uma ampla variedade de bancos de dados para acompanhar microsserviços. Como eles controlam a nuvem, eles podem oferecer as integrações, patches e manutenção entre todos eles. Ainda é uma expansão do banco de dados, mas dá menos trabalho.

Prós: One-stop store, um buffet de opções de banco de dados

Contras: Pode ficar muito caro, o aprisionamento do fornecedor, a compatibilidade de código aberto fica para trás, ainda se espalhando

Essa abordagem é in style, mas tem riscos. Se seus aplicativos são criados exclusivamente na AWS, por exemplo, o que acontece quando o preço aumenta ou um recurso é removido? Seus custos de troca podem ser enormes (não apenas em dólares, mas custos de oportunidade).

Use uma abordagem multimodelo

Como um banco de dados NoSQL pode competir com os ecossistemas titânicos do Azure, AWS e GCP e ainda ajudar a evitar a expansão do banco de dados? A resposta é bancos de dados “multimodelo”. Esses são bancos de dados construídos em uma única tecnologia de armazenamento de dados, mas oferecem várias maneiras de ler, gravar e acessar os mesmos dados.

Prós: One-stop store, um buffet de opções de interação de dados, pode ser usado em várias nuvens

Contras: Relativamente novo

Espere um minuto, você disse SQL?

Sim, SQL. Está em bancos de dados NoSQL agora. Bancos de dados não relacionais estão se voltando para a linguagem de banco de dados mais bem-sucedida e conhecida para colocá-lo em funcionamento em dados não relacionais (como JSON). É conhecido como SQL++ e é um padrão emergente que está sendo defendido pelo Couchbase, Amazon (PartiQL) e Microsoft (CosmosDB SQL).

Estamos vendo uma fusão do melhor do relacional e do melhor do NoSQL começar a surgir. Rápido e flexível como NoSQL, acquainted como relacional, uma abordagem multimodelo à prova de futuro, juntando-se para tornar a história do seu banco de dados mais acessível.

Matthew Groves é desenvolvedor e entusiasta de banco de dados na Base de sofá.