Recentemente, descobri que a Red Hat está removendo o suporte ao MongoDB do Satellite (dizem eles devido a alterações de licença). Isso me fez pensar que, nos últimos anos, vi vários artigos sobre o quão terrível é o MongoDB e que ninguém deveria usá-lo. Mas durante esse período, o MongoDB se tornou um produto muito mais maduro. O que aconteceu? Todo o ódio é realmente devido a erros no início da comercialização de um novo DBMS? Ou as pessoas simplesmente usam o MongoDB em um lugar errado?

Se, de repente, você sentir que estou protegendo o MongoDB, leia o aviso no final do artigo.

Nova tendência

Trabalho na indústria de software há tempo mais do que suficiente para falar decentemente, mas, mesmo assim, apenas uma pequena parte das tendências que atingiram nossa indústria foram responsáveis por mim. Eu testemunhei o crescimento de 4GL, AOP, Agile, SOA, Web 2.0, AJAX, blockchain ... a lista é interminável. Todos os anos, novas tendências aparecem. Alguns desaparecem rapidamente, enquanto outros mudam fundamentalmente a maneira como o software é desenvolvido.

Em torno de cada nova tendência, cria-se uma certa empolgação geral: as pessoas pulam no barco ou vêem o ruído gerado por outras pessoas - e seguem a multidão. Esse processo é codificado pelo Gartner em um ciclo de hype . Embora controverso, este gráfico descreve aproximadamente o que acontece com as tecnologias antes que elas se tornem utilizáveis.

Mas, de tempos em tempos, uma nova inovação aparece (ou acontece uma segunda vinda, como neste caso), impulsionada por apenas uma implementação específica. No caso do NoSQL, o hype foi fortemente impulsionado pelo advento e rápido aumento do MongoDB. O MongoDB não lançou essa tendência: de fato, grandes empresas de Internet começaram a ter problemas no processamento de grandes quantidades de dados, o que levou ao retorno de bancos de dados não relacionais. O movimento geral começou com projetos como o Bigtable do Google e Cassandra do Facebook, mas foi o MongoDB que se tornou a implementação mais famosa e acessível do banco de dados NoSQL, à qual a maioria dos desenvolvedores teve acesso.

Nota: você pode pensar que estou misturando bancos de dados de documentos com bancos de dados de colunas, armazenamentos de chave / valor ou qualquer um dos muitos outros tipos de armazenamentos de dados que se enquadram na definição geral de NoSQL. E você está certo. Mas naquele tempo reinou o caos. Todos estavam obcecados com o NoSQL, todos precisavam absolutamente dele, embora muitos não percebessem as diferenças nas diferentes tecnologias. Para muitos, o MongoDB tornou-se sinônimo de NoSQL.

E os desenvolvedores a atacaram. Foi uma ideia bastante tentadora ter um banco de dados sem um esquema que fosse escalado magicamente para resolver qualquer problema. Por volta de 2014, parecia que em todos os lugares em que um banco de dados relacional era usado há um ano, como MySQL, Postgres ou SQL Server, os bancos de dados MongoDB começaram a ser implantados. Para a pergunta por que, você pode obter uma resposta do banal "esta é a escala da web" para o mais ponderado "meus dados são muito mal estruturados e se encaixam bem no banco de dados sem um esquema".

É importante lembrar que o MongoDB e os bancos de dados de documentos geralmente resolvem vários problemas com os bancos de dados relacionais tradicionais:

Esquema estrito : com um banco de dados relacional, se você gerou dados dinamicamente, você é forçado a criar um monte de colunas de dados "diferentes" aleatórias, enviar blobs de dados para lá ou usar a configuração EAV ... tudo isso tem desvantagens significativas.
A dificuldade do dimensionamento : se houver tantos dados que eles não cabem em um único servidor, o MongoDB propôs mecanismos para dimensioná-los em várias máquinas.
Modificações sofisticadas do circuito : sem migrações! Em um banco de dados relacional, alterar a estrutura do banco de dados pode ser um grande problema (especialmente quando há muitos dados). O MongoDB conseguiu simplificar bastante o processo. E tornou tudo tão fácil que você pode simplesmente atualizar o circuito em movimento e seguir em frente muito rapidamente.
Desempenho de gravação : o desempenho do MongoDB foi bom, principalmente com o ajuste adequado. Mesmo a configuração do MongoDB pronta para uso, pela qual era frequentemente criticada, mostrava algumas métricas de desempenho impressionantes.

Todos os riscos estão em você.

Os benefícios potenciais do MongoDB eram enormes, especialmente para certas classes de problemas. Se você ler a lista acima sem entender o contexto e não ter experiência, poderá ter a impressão de que o MongoDB é realmente um DBMS revolucionário. O único problema foi que as vantagens acima foram acompanhadas de várias reservas, algumas das quais listadas abaixo.

Para ser justo, ninguém na 10gen / MongoDB Inc. ele não dirá que o seguinte não é verdade; é apenas um compromisso.

Perda de transações : as transações são uma característica importante de muitos bancos de dados relacionais (não todos, mas a maioria). Transacional significa que você pode executar várias operações atomicamente e garantir que os dados permaneçam consistentes. Obviamente, com um banco de dados NoSQL, a transacionalidade pode estar no mesmo documento ou você pode usar confirmações de duas fases para obter semântica transacional. Mas você mesmo precisa implementar essa funcionalidade ... o que pode ser uma tarefa complexa e demorada. Frequentemente, você não está ciente do problema até ver que os dados no banco de dados caem em estados inaceitáveis, porque é impossível garantir a atomicidade das operações. Nota: muitos me disseram que as transações apareceram no MongoDB 4.0 no ano passado, mas com várias limitações. A conclusão do artigo permanece a mesma: avalie como a tecnologia atende às suas necessidades.
Perda de integridade relacional (chaves estrangeiras) : se houver um relacionamento em seus dados, você deverá aplicá-lo no aplicativo. Ter um banco de dados em conformidade com esses relacionamentos removerá uma parte significativa do trabalho do aplicativo e, portanto, dos programadores.
Falta de capacidade de aplicar a estrutura de dados : esquemas rígidos às vezes se tornam um grande problema, mas também é um mecanismo poderoso para uma boa estruturação de dados, se usado corretamente. Os bancos de dados de documentos, como o MongoDB, oferecem incrível flexibilidade de esquema, mas essa flexibilidade remove a responsabilidade de manter os dados limpos. Se você não cuidar deles, no final, você precisará escrever muito código no aplicativo para dar conta dos dados que não estão armazenados no formato que você espera. Como nossa empresa costuma dizer Simple Thread ... algum dia o aplicativo será reescrito e os dados permanecerão para sempre. Nota: O MongoDB suporta validação de esquema: é útil, mas não fornece as mesmas garantias que em um banco de dados relacional. Antes de tudo, adicionar ou modificar uma verificação de esquema não afeta os dados existentes na coleção. Você mesmo deve se certificar de atualizar os dados de acordo com o novo esquema. Decida por si mesmo se isso é suficiente para suas necessidades.
Linguagem de consulta nativa / perda do ecossistema de ferramentas : o advento do SQL tornou-se uma revolução absoluta e nada mudou desde então. É uma linguagem incrivelmente poderosa, mas também bastante complexa. A necessidade de projetar consultas ao banco de dados em uma nova linguagem que consiste em fragmentos JSON é considerada um grande passo atrás por pessoas com experiência em SQL. Há todo um universo de ferramentas que interagem com os bancos de dados SQL: do IDE às ferramentas de relatório. Ir a um banco de dados que não suporta SQL significa que você não pode usar a maioria dessas ferramentas ou precisa converter os dados em SQL para usá-los, e isso pode ser mais difícil do que você pensa.

Muitos desenvolvedores que se voltaram para o MongoDB realmente não entendiam as vantagens e desviam-se, definindo-o como o principal repositório de dados. Depois disso, muitas vezes era incrivelmente difícil voltar.

O que poderia ter sido feito de maneira diferente?

Nem todo mundo pulou a cabeça primeiro e bateu no fundo. Mas muitos projetos instalaram a base do MongoDB onde ela simplesmente não se encaixava - e eles terão que conviver com ela por muitos mais anos. Se essas organizações passassem algum tempo e considerassem metodicamente a escolha das tecnologias, muitas teriam feito uma escolha diferente.

Como escolher a tecnologia certa? Houve várias tentativas de criar uma estrutura sistemática para avaliar tecnologias, como “Estrutura para introduzir tecnologias em organizações de software” e “Estrutura para avaliar tecnologias de software” , mas me parece que essa é uma complexidade desnecessária.

Muitas tecnologias podem ser razoavelmente avaliadas fazendo apenas duas perguntas básicas. O problema é encontrar pessoas que possam responder com responsabilidade, gastando tempo procurando respostas e sem preconceitos.

Se você não encontrar nenhum problema, não precisará de uma nova ferramenta. O ponto.

Pergunta 1: Quais problemas estou tentando resolver?

Se você não encontrar nenhum problema, não precisará de uma nova ferramenta. O ponto. Não é necessário procurar uma solução e, em seguida, apresentar um problema. Se você não encontrou um problema que uma nova tecnologia não resolva muito melhor do que a tecnologia existente, não há nada a discutir. Se você está pensando em usar essa tecnologia porque viu como outras pessoas a usam, considere os problemas que estão enfrentando e pergunte se você tem esses problemas. É fácil aceitar a tecnologia porque outros a usam, a dificuldade está em entender se você está enfrentando os mesmos problemas.

Pergunta 2: O que estou perdendo?

Essa é certamente uma pergunta mais difícil, porque você precisa cavar e entender bem tanto a tecnologia antiga quanto a nova. Às vezes, você não consegue entender verdadeiramente um novo até criar algo com ele ou ter um funcionário com essa experiência.

Se você não tem um nem o outro, faz sentido pensar no investimento mínimo possível para determinar o valor dessa ferramenta. E se você fizer um investimento, quão difícil será reverter a decisão?

As pessoas sempre estragam tudo

Tentando responder a essas perguntas da maneira mais imparcial possível, lembre-se de uma coisa: você precisa lutar com a natureza humana. Há uma série de preconceitos cognitivos que devem ser superados para avaliar a tecnologia de maneira eficaz. Aqui estão apenas alguns:

O efeito de ingressar na maioria - todos sabem disso, mas ainda é difícil lutar com isso. Apenas verifique se a tecnologia realmente atende às suas reais necessidades.
O efeito da novidade - muitos desenvolvedores tendem a subestimar as tecnologias com as quais trabalham há muito tempo e a superestimar as vantagens da nova tecnologia. Não apenas programadores, todos estão sujeitos a esse viés cognitivo.
O efeito das características positivas - tendemos a ver o que é e perder de vista o que está faltando. Isso pode levar ao caos em combinação com o efeito novidade, porque você não apenas superestima a nova tecnologia, mas também ignora suas deficiências .

Uma avaliação objetiva não é fácil, mas a compreensão de vieses cognitivos básicos ajudará a tomar decisões mais racionais.

Sumário

Quando uma certa inovação aparece, duas perguntas devem ser respondidas com muito cuidado:

Essa ferramenta resolve um problema real?
Entendemos bem os compromissos?

Se você não puder responder com confiança a essas duas perguntas, dê alguns passos para trás e pense.

Então o MongoDB era geralmente a escolha certa? Claro que sim; como na maioria das tecnologias de engenharia, isso depende de muitos fatores. Entre os que responderam a essas duas perguntas, muitos se beneficiaram do MongoDB e continuam a se beneficiar dele. Quem não fez isso, espero que tenham recebido uma lição valiosa e não muito dolorosa sobre o movimento ao longo do ciclo da campanha publicitária.

Isenção de responsabilidade

Quero esclarecer que não tenho amor nem ódio pelo MongoDB. Só que não tivemos problemas para os quais o MongoDB é mais adequado. Eu sei que 10gen / MongoDB Inc. No início, ela agiu com muita ousadia, definindo valores padrão inseguros e promovendo o MongoDB em todos os lugares (especialmente em hackathons) como uma solução universal para trabalhar com qualquer dado. Provavelmente foi uma decisão ruim. Mas confirma a abordagem descrita aqui: esses problemas podem ser detectados muito rapidamente, mesmo com uma avaliação superficial da tecnologia.

O MongoDB foi a escolha certa?