Recentemente, descobri que (dizem que devido a mudanças na licença). Isso me fez pensar que, nos últimos anos, vi um monte de artigos dizendo o quão terrível é o MongoDB e que ninguém nunca deveria usá-lo. Mas, ao longo desse tempo, o MongoDB se tornou um produto muito mais maduro. O que aconteceu? Toda essa aversão é realmente explicada por erros no início do marketing desse novo SGBD? Ou as pessoas simplesmente aplicam o MongoDB em contextos errados?
Se você acha que estou defendendo o MongoDB, por favor, leia o no final do artigo.
Uma nova tendência
Trabalho na indústria de software há mais anos do que é apropriado mencionar, mas, ainda assim, vivenciei apenas uma pequena parte das tendências que impactaram nosso setor. Fui testemunha do crescimento de 4GL, AOP, Agile, SOA, Web 2.0, AJAX, blockchain… a lista é interminável. A cada ano surgem novas tendências. Algumas desaparecem rapidamente, enquanto outras mudam fundamentalmente a forma como desenvolvemos software.
Em torno de cada nova tendência, gera-se uma certa agitação coletiva: as pessoas ou pulam no barco ou veem o barulho gerado por outros – e seguem a multidão. Esse processo foi codificado pela empresa Gartner no . Embora controverso, esse gráfico descreve aproximadamente o que acontece com as tecnologias antes de se tornarem úteis.
Mas de tempos em tempos surge (ou ocorre um segundo advento, como neste caso) uma nova inovação, impulsionada apenas por uma implementação específica. No caso do NoSQL, o hype foi fortemente influenciado pelo surgimento e rápido crescimento do MongoDB. Não foi o MongoDB que deu início a essa tendência: na verdade, grandes empresas de internet começaram a enfrentar problemas ao lidar com grandes volumes de dados, o que levou ao ressurgimento dos bancos de dados não relacionais. O movimento geral começou com projetos como Bigtable do Google e Cassandra do Facebook, mas foi o MongoDB que se tornou a implementação de banco de dados NoSQL mais conhecida e acessível à maioria dos desenvolvedores.
Nota: você pode pensar que estou misturando bancos de dados documentais com bancos de dados colunares, armazenamentos de chave/valor ou qualquer um dos inúmeros outros tipos de armazenamentos de dados que se encaixam na definição geral de NoSQL. E você está certo. Mas naquela época havia um caos. Todos estavam obcecados por NoSQL, todos se tornaram absolutamente é necessário, embora muitos não tenham notado diferenças nas várias tecnologias. Para muitos, o MongoDB se tornou um sinônimo de NoSQL.
E os desenvolvedores se precipitaram sobre ele. A ideia de um banco de dados sem esquema, que escala magicamente para resolver qualquer problema, era bastante atraente. Por volta de 2014, parecia que em todos os lugares onde um ano atrás um banco de dados relacional, como MySQL, Postgres ou SQL Server, era usado, estavam agora implementando bancos de dados MongoDB. À pergunta do porquê, você poderia receber respostas que variavam de "é a escala da web" até "meus dados são muito mal estruturados e se encaixam bem em um banco de dados sem esquema."
É importante lembrar que o MongoDB e os bancos de dados de documentos, de modo geral, resolvem uma série de problemas com bancos de dados relacionais tradicionais:
- Esquema rígido: com um banco de dados relacional, se você tiver dados gerados dinamicamente, é forçado a criar um monte de colunas de dados "diferentes", enfiar blobs de dados ou usar uma configuração … tudo isso tem desvantagens significativas.
- Dificuldade de escalabilidade: se os dados são tão grandes que não cabem em um servidor, o MongoDB ofereceu mecanismos que permitem escalá-los em várias máquinas.
- Modificações complexas no esquema: sem migrações! Em um banco de dados relacional, alterar a estrutura do banco de dados pode se tornar um grande problema (especialmente quando os dados são muito numerosos). O MongoDB conseguiu simplificar muito o processo. E tornou-o tão fácil que você pode simplesmente atualizar o esquema em tempo real e avançar rapidamente.
- Desempenho de escrita: o desempenho do MongoDB era bom, especialmente com configuração adequada. Mesmo a configuração padrão do MongoDB, pela qual muitas vezes foi criticada, demonstrou alguns indicadores de desempenho impressionantes.
Todos os riscos estão com você
Os potenciais benefícios do MongoDB eram enormes, especialmente para certas classes de problemas. Se você ler a lista acima sem entender o contexto e sem experiência, pode dar a impressão de que o MongoDB é realmente um SGBD revolucionário. O único problema é que os benefícios mencionados acima são acompanhados por uma série de ressalvas, algumas das quais estão listadas abaixo.
Para ser justo, ninguém na 10gen/MongoDB Inc. dirá que o que se segue é mentira; são apenas compromissos.
- Perda de transações: transações são um recurso principal de muitos bancos de dados relacionais (não todos, mas a maioria). A atomicidade significa que você pode realizar várias operações de maneira atômica e garantir que os dados permaneçam consistentes. Claro, em um banco de dados NoSQL, a atomicidade pode ocorrer dentro de um único documento ou você pode usar commits de duas fases para obter semântica transacional. Mas você terá que implementar essa funcionalidade por conta própria... o que pode ser uma tarefa complexa e trabalhosa. Muitas vezes, você não percebe os problemas até ver que os dados no banco estão em estados inválidos, pois não é possível garantir a atomicidade das operações. Nota: muitos me informaram que as transações foram introduzidas no MongoDB 4.0 no ano passado, mas com uma série de limitações. A conclusão do artigo permanece a mesma: avalie até que ponto a tecnologia atende às suas necessidades.
- Perda de integridade relacional (chaves externas): se seus dados possuem relacionamentos, você terá que aplicá-los no aplicativo. Ter um banco de dados que respeite esses relacionamentos reduz significativamente o trabalho no aplicativo e, portanto, dos seus programadores.
- Falta de capacidade de aplicar estrutura de dados: esquemas rígidos às vezes se tornam um grande problema, mas também são um poderoso mecanismo de boa estruturação de dados, se usados corretamente. Bancos de dados documentais, como o MongoDB, proporcionam uma flexibilidade incrível no esquema, mas essa flexibilidade elimina a responsabilidade de manter os dados em ordem. Se você não cuidar deles, acabará tendo que escrever muito código no aplicativo para lidar com dados que estão armazenados em uma forma diferente da que você espera. Como frequentemente dizemos em nossa empresa, a Simple Thread... o aplicativo será reescrito um dia, mas os dados viverão para sempre. Nota: O MongoDB suporta a verificação de esquema: isso é útil, mas não fornece as mesmas garantias que um banco de dados relacional. Antes de mais nada, adicionar ou alterar a verificação de esquema não afeta os dados existentes na coleção. Você mesmo deve garantir que está atualizando os dados de acordo com o novo esquema. Decida por si mesmo se isso é suficiente para as suas necessidades.
- Linguagem de consulta própria / perda do ecossistema de ferramentas: o surgimento do SQL foi uma revolução absoluta, e desde então nada mudou. É uma linguagem incrivelmente poderosa, mas também bastante complexa. A necessidade de construir consultas para o banco de dados em uma nova linguagem composta de fragmentos JSON é vista como um grande retrocesso por pessoas com experiência em SQL. Existe um universo inteiro de ferramentas que interagem com bancos de dados SQL: de IDEs a ferramentas de relatórios. A transição para 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 para SQL para usá-los, o que pode ser mais difícil do que você pensa.
Muitos desenvolvedores que migraram para o MongoDB não compreendiam muito bem os compromissos e muitas vezes se lançavam de cabeça, instalando-o como o principal repositório de dados. Depois disso, muitas vezes era incrivelmente difícil voltar atrás.
O que poderia ter sido feito de forma diferente?
Nem todos mergulharam de cabeça e se chocaram com o fundo. Mas muitos projetos instalaram o MongoDB em lugares onde simplesmente não se adequava — e terão que viver com isso por muitos anos. Se essas organizações tivessem dedicado algum tempo e pensado sistematicamente sobre 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 e , mas parece-me que isso é um excesso de complexidade.
Muitas tecnologias podem ser avaliadas de forma razoável fazendo apenas duas perguntas principais. O problema está em encontrar pessoas que possam responder a elas de forma responsável, gastando tempo em busca de respostas e sem preconceitos.
Se você não enfrenta nenhum problema, não precisa de uma nova ferramenta. Ponto.
Pergunta 1: Que problemas estou tentando resolver?
Se você não está enfrentando nenhum problema, não precisa de uma nova ferramenta. Ponto. Não há necessidade de procurar uma solução e, em seguida, inventar um problema. Se você não encontrou um problema que a nova tecnologia resolve significativamente melhor do que a sua tecnologia existente, então não há o que discutir. Se você está considerando usar essa tecnologia porque viu outras pessoas fazendo isso, pense sobre quais problemas elas estão enfrentando e pergunte-se se você tem esses problemas. É fácil adotar uma tecnologia porque outros a usam; a dificuldade está em entender se você enfrenta os mesmos problemas.
Pergunta 2: Do que estou abrindo mão?
Esta é, sem dúvida, uma pergunta mais difícil, pois você precisará investigar e entender bem tanto a tecnologia antiga quanto a nova. Às vezes, você não pode realmente entender a nova até que construa algo com ela ou tenha um colaborador que tenha essa experiência.
Se você não tem nem uma coisa nem outra, faz sentido pensar em investimentos mínimos para determinar o valor desta ferramenta. E se você fizer investimentos, quão difícil será desfazer a decisão?
As pessoas sempre estragam tudo.
Ao tentar responder a essas perguntas da forma mais imparcial possível, lembre-se de uma coisa: você terá que lutar contra a natureza humana. Existem vários vieses cognitivos que precisam ser superados para avaliar a tecnologia de forma eficaz. Aqui estão apenas alguns:
- — todos sabem sobre ele, mas é difícil de combater. Certifique-se de que a tecnologia realmente atende às suas necessidades reais.
- — muitos desenvolvedores tendem a subestimar as tecnologias com as quais trabalharam por um longo tempo e superestimar os benefícios da nova tecnologia. Não são apenas programadores; todos estão sujeitos a esse viés cognitivo.
- — tendemos a ver o que existe e ignoramos o que está ausente. Isso pode levar ao caos em combinação com o efeito de novidade, pois não apenas superestima a nova tecnologia, mas também ignora suas desvantagens..
A avaliação objetiva não é fácil, mas entender as principais distorções cognitivas ajudará a tomar decisões mais racionais.
Resumo
Quando uma nova inovação surge, é necessário responder com cautela a duas perguntas:
- Esse instrumento resolve um problema real?
- Entendemos bem os compromissos?
Se você não consegue responder a essas duas perguntas com confiança, dê alguns passos para trás e reflita.
Então, a MongoDB foi realmente a escolha certa? Com certeza, sim; como na maioria das tecnologias de engenharia, isso depende de muitos fatores. Muitos que responderam a essas duas perguntas se beneficiaram da MongoDB e continuam a fazê-lo. Aqueles que não o fizeram, espero que tenham aprendido uma lição valiosa e não muito dolorosa sobre o ciclo da inovação.
Isenção de responsabilidade
Quero esclarecer que eu não tenho nem amor nem ódio pela MongoDB. Simplesmente não tivemos problemas para os quais a MongoDB fosse a solução ideal. Eu sei que a 10gen/MongoDB Inc. inicialmente agiu de forma bastante ousada, estabelecendo configurações inseguras como padrão e promovendo a MongoDB em todos os lugares (especialmente em hackathons) como uma solução universal para trabalhar com qualquer tipo de dado. Provavelmente, essa foi uma má decisão. Mas isso confirma a abordagem descrita aqui: esses problemas poderiam ser detectados rapidamente, mesmo com uma avaliação superficial da tecnologia.
Fonte: habr.com
