Recentemente descobri que (dizem devido a mudanças de licença). Isso me fez pensar porque nos últimos anos tenho visto muitos artigos sobre como o MongoDB é terrível e como 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 na comercialização inicial de um novo SGBD? Ou as pessoas estão apenas usando o MongoDB nos lugares errados?
Se você acha que estou defendendo o MongoDB, leia no final do artigo.
Nova tendência
Trabalho na indústria de software há mais anos do que posso dizer, mas ainda só fui exposto a uma pequena parte das tendências que atingiram nossa indústria. Testemunhei a ascensão do 4GL, AOP, Agile, SOA, Web 2.0, AJAX, Blockchain... a lista é interminável. Todos os anos surgem novas tendências. Alguns desaparecem rapidamente, enquanto outros mudam fundamentalmente a forma como o software é desenvolvido.
Cada nova tendência cria um entusiasmo geral: as pessoas ou embarcam ou veem o ruído gerado pelos outros e seguem a multidão. Este processo é codificado pelo Gartner em . Embora controversa, esta linha do tempo descreve aproximadamente o que acontece com as tecnologias antes que elas se tornem úteis.
Mas de vez em quando surge uma nova inovação (ou tem uma segunda vinda, como neste caso) impulsionada por apenas uma implementação específica. No caso do NoSQL, o hype foi fortemente impulsionado pelo surgimento e ascensão meteórica do MongoDB. O MongoDB não iniciou essa tendência: na verdade, grandes empresas de Internet começaram a ter problemas para processar grandes quantidades de dados, o que levou ao retorno dos bancos de dados não relacionais. O movimento geral começou com projetos como o Bigtable do Google e o Cassandra do Facebook, mas foi o MongoDB que se tornou a implementação de banco de dados NoSQL mais conhecida e acessível à qual a maioria dos desenvolvedores tinha acesso.
Observação: você pode pensar que estou confundindo bancos de dados de documentos com bancos de dados colunares, armazenamentos de chave/valor ou qualquer um dos vários outros tipos de armazenamentos de dados que se enquadram na definição geral do NoSQL. E você está certo. Mas naquela época reinava o caos. Todo mundo está obcecado com NoSQL, tornou-se todo mundo абсолютно necessário, embora muitos não percebessem as diferenças nas diferentes tecnologias. Para muitos, o MongoDB se tornou sinônimo de NoSQL.
E os desenvolvedores atacaram isso. A ideia de um banco de dados sem esquema, que pode ser dimensionado magicamente para resolver qualquer problema, era bastante tentadora. Por volta de 2014, parecia que todos os lugares que há um ano usavam um banco de dados relacional como MySQL, Postgres ou SQL Server começaram a implantar bancos de dados MongoDB. Quando questionado sobre o motivo, você pode obter uma resposta desde o banal “esta é a escala da web” até a mais cuidadosa “meus dados são estruturados de maneira muito livre e se encaixam bem em um banco de dados sem esquema”.
É importante lembrar que o MongoDB e os bancos de dados de documentos em geral resolvem vários problemas com os bancos de dados relacionais tradicionais:
- Esquema estrito: com um banco de dados relacional, se você tiver dados gerados dinamicamente, será forçado a criar um monte de colunas aleatórias de dados "diversos", inserir blobs de dados lá ou usar a configuração ...tudo isso tem desvantagens significativas.
- Escala de dificuldade: se houver tantos dados que não cabem em um servidor, o MongoDB oferece mecanismos para permitir a escalabilidade em várias máquinas.
- Modificações complexas de 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 conforme avança e seguir em frente muito rapidamente.
- Desempenho de gravação: O desempenho do MongoDB foi bom, especialmente quando configurado corretamente. Até mesmo a configuração pronta para uso do MongoDB, pela qual foi frequentemente criticado, mostrou alguns números de desempenho impressionantes.
Todos os riscos estão em você
Os benefícios potenciais do MongoDB foram enormes, especialmente para determinadas classes de problemas. Se você ler a lista acima sem entender o contexto e sem experiência, poderá ter a impressão de que o MongoDB é realmente um SGBD revolucionário. O único problema era que os benefícios listados acima traziam uma série de ressalvas, algumas das quais estão listadas abaixo.
Para ser justo, ninguém na 10gen/MongoDB Inc. não direi que o seguinte não é verdade, são apenas compromissos.
- Transações perdidas: as transações são um recurso central 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. É claro que, com um banco de dados NoSQL, a transacionalidade pode estar em um único documento ou você pode usar confirmações de duas fases para obter a semântica transacional. Mas você mesmo terá que implementar essa funcionalidade... o que pode ser uma tarefa difícil e demorada. Muitas vezes você não percebe que há um problema até ver os dados no banco de dados acabarem em estados inválidos porque a atomicidade das operações não pode ser garantida. Nota: Muitas pessoas me disseram que o MongoDB 4.0 introduziu transações no ano passado, mas com algumas 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 estrangeiras): Se seus dados tiverem relacionamentos, você terá que aplicá-los no aplicativo. Ter um banco de dados que respeite esses relacionamentos tirará muito trabalho do aplicativo e, portanto, de seus programadores.
- Falta de capacidade de aplicar estrutura de dados: esquemas rígidos às vezes podem ser um grande problema, mas também são um mecanismo poderoso para uma boa estruturação de dados, se usados com sabedoria. Bancos de dados de documentos como o MongoDB oferecem flexibilidade de esquema incrível, mas essa flexibilidade elimina a responsabilidade de manter os dados limpos. Se você não cuidar deles, acabará escrevendo muito código em seu aplicativo para contabilizar dados que não estão armazenados na forma esperada. Como costumamos dizer em nossa empresa Simple Thread... um dia o aplicativo será reescrito, mas os dados viverão para sempre. Nota: MongoDB suporta verificação de esquema: é útil, mas não fornece as mesmas garantias que em um banco de dados relacional. Em primeiro lugar, adicionar ou alterar uma verificação de esquema não afeta os dados existentes na coleção. Cabe a você garantir a atualização dos 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 foi uma revolução absoluta e nada mudou desde então. É uma linguagem incrivelmente poderosa, mas também bastante complexa. A necessidade de construir consultas de banco de dados em uma nova linguagem composta por fragmentos JSON é considerada um grande retrocesso por pessoas que têm experiência em trabalhar com SQL. Existe todo um universo de ferramentas que interagem com bancos de dados SQL, desde IDEs até ferramentas de relatórios. Mudar para um banco de dados que não oferece suporte a SQL significa que você não poderá usar a maioria dessas ferramentas ou terá que traduzir os dados em SQL para usá-las, o que pode ser mais difícil do que você pensa.
Muitos desenvolvedores que recorreram ao MongoDB não entenderam realmente as vantagens e desvantagens e muitas vezes mergulharam de cabeça na instalação dele como seu principal armazenamento de dados. Depois disso, muitas vezes era incrivelmente difícil voltar.
O que poderia ter sido feito de forma diferente?
Nem todo mundo pulou de cabeça e bateu no fundo. Mas muitos projetos instalaram o MongoDB em lugares onde ele simplesmente não cabia - e terão que conviver com ele por muitos anos. Se essas organizações tivessem dedicado algum tempo e refletido metodicamente sobre suas escolhas tecnológicas, muitas teriam feito escolhas diferentes.
Como escolher a tecnologia certa? Houve várias tentativas de criar uma estrutura sistemática para avaliação de tecnologia, como и , mas me parece que isso é uma complexidade desnecessária.
Muitas tecnologias podem ser avaliadas de forma inteligente fazendo apenas duas perguntas básicas. O problema é encontrar pessoas que possam respondê-las com responsabilidade, dedicando tempo para encontrar as respostas e sem preconceitos.
Se você não estiver enfrentando nenhum problema, não precisará de uma nova ferramenta. Ponto.
Pergunta 1: Que problemas estou tentando resolver?
Se você não estiver enfrentando nenhum problema, não precisará de uma nova ferramenta. Ponto. Não há necessidade de procurar uma solução e depois inventar um problema. A menos que você tenha encontrado um problema que a nova tecnologia resolva significativamente melhor do que a tecnologia existente, não há nada para discutir aqui. Se você está pensando em usar essa tecnologia porque viu outras pessoas usá-la, pense nos problemas que eles enfrentam e pergunte se você os tem. É fácil aceitar uma tecnologia porque outros a estão utilizando, o desafio é entender se você enfrenta os mesmos problemas.
Pergunta 2: O que estou perdendo?
Esta é definitivamente uma questão mais difícil porque você terá que se aprofundar e ter um bom entendimento da tecnologia antiga e da nova. Às vezes você não consegue realmente entender um novo até que tenha construído algo com ele ou tenha alguém com essa experiência.
Se não tiver nenhum dos dois, faz sentido pensar no investimento mínimo possível para determinar o valor deste instrumento. E depois de fazer o investimento, quão difícil será reverter a decisão?
As pessoas sempre estragam tudo
Ao tentar responder a estas perguntas da forma mais imparcial possível, lembre-se de uma coisa: você terá que lutar contra a natureza humana. Existem vários preconceitos cognitivos que devem ser superados para avaliar eficazmente a tecnologia. Aqui estão apenas alguns:
- - todo mundo sabe sobre ele, mas ainda é difícil lutar contra ele. Apenas certifique-se de que a tecnologia realmente corresponda às suas necessidades reais.
- — Muitos desenvolvedores tendem a subestimar as tecnologias com as quais trabalham há muito tempo e superestimar os benefícios das novas tecnologias. Não são apenas os programadores, todos são suscetíveis a esse viés cognitivo.
- - Tendemos a ver o que está lá e perder de vista o que está faltando. Isto pode levar ao caos quando combinado com o efeito de novidade, pois você não apenas supervaloriza inerentemente a nova tecnologia, mas também ignora suas deficiências..
A avaliação objetiva não é fácil, mas compreender os preconceitos cognitivos subjacentes o ajudará a tomar decisões mais racionais.
Resumo
Sempre que surge uma inovação, duas questões devem ser respondidas com muito cuidado:
- Esta ferramenta resolve um problema real?
- Compreendemos bem as compensações?
Se você não consegue responder com segurança a essas duas perguntas, dê alguns passos para trás e pense.
Então o MongoDB foi mesmo a escolha certa? Claro que sim; Tal como acontece com a maioria das tecnologias de engenharia, isto depende de muitos fatores. Entre aqueles que responderam a estas duas perguntas, muitos beneficiaram-se do MongoDB e continuam a fazê-lo. Para aqueles que não o fizeram, espero que tenham aprendido uma lição valiosa e não muito dolorosa sobre como passar pelo ciclo do hype.
Isenção de responsabilidade
Quero esclarecer que não tenho uma relação de amor nem de ódio com o MongoDB. Simplesmente não tivemos o tipo de problema que o MongoDB é mais adequado para resolver. Eu sei que 10gen/MongoDB Inc. foi muito ousado no início, definindo padrões 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 má decisão. Mas confirma a abordagem aqui descrita: estes problemas podem ser detectados muito rapidamente, mesmo com uma avaliação superficial da tecnologia.
Fonte: habr.com