Paginations 2.0: Por que escolher o MongoDB
Avalie esse Artigo
Tenho escrito e projetado aplicativos multiusuários de grande escala com back-ends de banco de dados desde 1995, como arquiteto-chefe de sistemas de gerenciamento de inteligência, mineração de texto e plataformas de análise, e como consultor trabalhando em bancos de varejo e de investimento, jogos móveis, projetos de IoT para carros conectados e gerenciamento de documentos em escala nacional. É justo dizer que vi como muitos aplicativos são montados.
Agora, também é razoável supor que, como trabalho para o MongoDB, tenho algum viés, mas o MongoDB não é meu primeiro banco de dados, ou mesmo meu primeiro banco de dados de documentos, e então tenho uma perspectiva bastante ampla. Gostaria de compartilhar com vocês três recursos do MongoDB que o tornariam minha primeira escolha para quase todos os aplicativos de banco de dados grandes e multiusuário.
O document model é um aspecto fundamental do MongoDB. Todos os bancos de dados armazenam registros - informações sobre coisas que têm atributos nomeados e valores para esses atributos. Alguns atributos podem ter vários valores. Em um banco de dados tabular, dividimos o registro em várias linhas com um único valor escalar para cada atributo e temos uma maneira de relacionar essas linhas para acessar o registro.
A diferença em um banco de dados de documentos é que, quando temos vários valores para um atributo, podemos mantê-los como parte de um único registro, armazenando o acesso e manipulando-os juntos. Também podemos agrupar atributos para comparar e nos referir a eles como um grupo. Por exemplo, todas as partes de um endereço podem ser acessadas como um único campo de endereço ou individualmente.
Por que isso é importante? Bem, ser capaz de armazenar um registro inteiro co-localizado no disco e na memória tem algumas vantagens enormes.
Por ter esses objetos atômicos maiores com os quais trabalhar, há alguns benefícios frequentemente citados, como facilitar o trabalho dos desenvolvedores de OO e reduzir as despesas gerais de computação para acessar o registro inteiro, mas isso deixa passar um terceiro benefício ainda mais importante.
Com o esquema correto, os documentos reduzem cada operação de gravação do banco de dados a alterações atômicas únicas de um fragmento de dados. Isso tem dois benefícios enormes e relacionados.
Ao exigir apenas que um dado seja examinado quanto ao seu estado atual e alterado para um novo estado de cada vez, o período de tempo em que o estado do banco de dados não é resolvido é reduzido a quase nada. Efetivamente, não há interação entre várias gravações no banco de dados e nenhuma precisa esperar que outra seja concluída, pelo menos não além de uma única alteração em um único documento.
Se tivermos que usar transações tradicionais, seja em um RDBMS ou MongoDB, para realizar uma alteração, todos os registros envolvidos permanecerão efetivamente bloqueados até que a transação seja concluída. Isso amplia muito a janela para contenção e atraso. Usando o document model, você pode remover toda a contenção em seu banco de dados e obter uma taxa de transferência "transacional" muito maior em um sistema multiusuário.
A segunda parte disso é que, quando cada gravação no banco de dados pode ser tratada como uma operação independente, é fácil escalar horizontalmente o banco de dados para suportar grandes cargas de trabalho, pois o estado de um documento em um servidor não afeta sua capacidade de alterar um documento em outro. Toda operação pode ser paralelizada.
No entanto, fazer isso exige que você projete seu esquema corretamente. Os bancos de dados de documentos estão longe de ser esquematizados (um termo que o MongoDB não usa há muitos anos). Na verdade, isso torna o design do esquema ainda mais importante do que em um RDBMS.
A segunda razão pela qual eu escolheria usar o MongoDB é que a alta disponibilidade está no centro do banco de dados. O MongoDB foi projetado para que um servidor possa ser colocado offline instantaneamente, a qualquer momento, e não haja perda de serviço ou dados. Isso é absolutamente fundamental para a forma como o MongoDB é projetado. Ele não depende de hardware especializado, software de terceiros ou complementos. Ele permite a substituição de servidores, sistemas operacionais e até mesmo versões de banco de dados de forma invisível para o usuário final e, mesmo principalmente, para o desenvolvedor. Isso vale também para o Atlas, onde o MongoDB pode fornecer um serviço de banco de dados multinuvem em qualquer escala que seja resiliente à perda de um fornecedor de nuvem inteiro, seja Azure, Google ou Amazon. Esse nível de tempo de atividade não tem precedentes.
Portanto, se eu planejo desenvolver um aplicativo grande e multiusuário, só quero saber se o banco de dados estará sempre lá, sem tempo de inatividade, sem perda de dados, fim da história.
A terceira razão pela qual eu escolheria o MongoDB é possivelmente a mais surpreendente. Nem todos os bancos de dados de documentos são iguais e permitem que você realize todos os benefícios de um modelo de documento versus relacional, alguns são simplesmente armazenamentos JSON ou armazenamentos de chave/valor em que o valor é alguma forma de documento.
O MongoDB tem os operadores de atualização poderosos e especializados, capazes de fazer mais do que simplesmente substituir um documento ou um valor no banco de dados. Com o MongoDB, você pode, como parte de uma única operação atômica, verificar o estado dos valores no documento, calcular o novo valor para qualquer campo com base nele e em quaisquer outros campos, classificar e truncar arrays ao adicionar a eles e, se você exigir automaticamente, crie um novo documento em vez de modificar um existente.
É esse recurso de atualização " smart " que torna o MongoDB capaz de ser o principal banco de dados transacional " " em grandes sistemas multiusuários, em vez de um simples armazenamento de dados em formato de documento.
Esses três recursos, no centro de uma plataforma de dados de ponta a ponta, são o que realmente faz do MongoDB minha primeira escolha pessoal quando quero criar um sistema para oferecer suporte a muitos usuários com uma experiência de usuário rápida, 24 horas por dia, 365 dias por ano.