Tudo que você sabe sobre MongoDB está errado!
Avalie esse Artigo
Entrei no MongoDB há menos de um ano e aprenderam muito desde então. Até começar a trabalhar para minhas reportagens na empresa, eu nunca tinha usadoo MongoDB, embora tenha visto algumas conversas sobre ele e tenha sido impactado pela sua simplicidade de uso.
Mas, como muitas outras pessoas, eu também ouvi as histórias assustadoras. "Não faz relacionamentos!" as pessoas diriam. "Tudo bem se você quiser armazenar documentos, mas e se você quiser fazer a agregação mais tarde? Você ficará preso no banco de dados errado! E de qualquer maneira! Transações! Não tem transações!"
Foi só quando Go as fontes dessas informações que comecei a perceber duas coisas: Primeiro, a maioria dessas postagens é de uma década atrás, portanto, elas se referiam a um produto com três anos de idade, em vez da versão madura e testada em batalha que temos hoje. Segundo, quase tudo o que eles dizem não é mais verdade e, em alguns casos, nunca foi verdade.
Então, decidi dar uma palestra (e agora escrever esta postagem no blog) sobre a desinformação que está disponível on-line e combater cada mito, um por um.
Há um vídeodo Youtube com alguns cachorros (cães? Isso é que são cachorros). Você provavelmente já viu - um deles é aquele tipo de seguidor cego de nova tecnologia que comprou totalmente o MongoDB, sem realmente entender o que eles compraram. O outro cão é mais Racional e fica chateado com a recusa do primeiro cão em descer à Terra.
Recebi um link para este vídeo de um amigo meu no meu primeiro dia no MongoDB, caso não o tenha visto. (Eu tinha visto isso.) Confira a data na parte inferior! Este vídeo está circulando há mais de uma década. Foi muito engraçado na época, mas hoje em dia? Quase tudo o que está lá dentro está desatualizado.
Não estamos chateados. Na verdade, muitas pessoas no MongoDB têm o personagem em uma camiseta ou em um adesivo em seu laptop. Ele é meio que um mascote não oficial no MongoDB. Só não assista ao vídeo procurando fatos. E pare de nos enviar links para o vídeo - todos nós já vimos!
Antes de abordar algumas coisas que o MongoDB não é, vamos apenas resumir o que o MongoDB realmente é.
MongoDB é um banco de dados de documentos distribuído. Os clusters (nós os chamamos de conjuntos de réplicas) são em sua maioria autogerenciados - depois que você informar a cada uma das máquinas quais outros servidores estão no cluster, eles lidarão com isso se um dos nós ficar inativo ou se houver problemas com o rede. Se uma das máquinas for desligada ou falhar, as outras assumirão o controle. Você precisa de um mínimo de 3 nós em um cluster para atingir o quorum. Cada servidor no cluster contém uma cópia completa de todos os dados no banco de dados.
Os clusters servem para redundância, não para escalabilidade. Em geral, todos os clientes são conectados a apenas um servidor - o primário eleito, que é responsável por executar queries e atualizações e transmitir alterações de dados para as máquinas secundárias, que estão lá em caso de falha do servidor.
Há algumas coisas interessantes que você pode fazer conectando-se diretamente aos secundários, como executar consultas analíticas, porque as máquinas estão sob menor carga de leitura. Mas, em geral, forçar uma conexão com um secundário significa que você pode estar trabalhando com dados ligeiramente obsoletos, portanto, não deve se conectar a um nó secundário a menos que esteja preparado para fazer algumas concessões.
Então, cobri "distribuído". O que significa "banco de dados de documentos?"
O que torna o MongoDB diferente dos relational database tradicionais é que, em vez de ser capaz de armazenar átomos de dados em linhas simples, armazenadas em tabelas no banco de dados, o MongoDB permite armazenar dados estruturados hierárquicos em um documento - que é (principalmente) análogo a um JSON. Os documentos são armazenados em uma collection, que na verdade é apenas um balde de documentos. Cada documento pode ter uma estrutura ou esquemadiferentede todos os outros documentos da collection. Você também pode (e deve!) indexar documentos em collections, com base no tipo de consultas que você executará e nos dados que está armazenando. E se você quiser validação para garantir que todos os documentos em uma collection sigam uma estrutura definida, você pode aplicar um JSON schema à collection como um validador.
1 { 2 '_id': ObjectId('573a1390f29313caabcd4135'), 3 'title': 'Blacksmith Scene', 4 'fullplot': 'A stationary camera looks at a large anvil with a 5 blacksmith behind it and one on either side.', 6 'cast': ['Charles Kayser', 'John Ott'], 7 'countries': ['USA'], 8 'directors': ['William K.L. Dickson'], 9 'genres': ['Short'], 10 'imdb': {'id': 5, 'rating': 6.2, 'votes': 1189}, 11 'released': datetime.datetime(1893, 5, 9, 0, 0), 12 'runtime': 1, 13 'year': 1893 14 }
O documento acima é um exemplo, mostrando um filme de 1893! Este documento foi recuperado usando o driverPyMongo.
Observe que alguns dos valores são arrays, como "countries" e "cast". Alguns dos valores são objetos (nós os chamamos de subdocumentos). Isso demonstra a natureza hierárquica dos documentos MongoDB - eles não são planos como uma linha de tabela em um banco de dados relacional.
Observe também que ele contém um tipo de data/hora nativo do Python para o valor "released" e um tipoObjectIdespecial para o primeiro valor. Talvez esses não sejam realmente documentos JSON? Retornarei a isso mais tarde...
Se você instalar o MongoDB no Debian Stretch, com
apt get mongodb, ele instalará a versão 3.2. Infelizmente, esta versão tem cinco anos! Desde então, houve cinco lançamentos anuais principais, contendo uma série de novos recursos, bem como melhorias de segurança, desempenho e escalabilidade.A versão atual do MongoDB é v4.4 (no final de 2020). Se quiser instalá-lo, você deve instalar o MongoDB Community Server, mas primeiro certifique-se de ler sobre o MongoDB Atlas, nosso produto de banco de dados como serviço hospedado!
É quase certo que você já deve ter escutado que o MongoDB é um banco de dados JSON, especialmente se leu a página inicial do MongoDB.com recentemente!
No entanto, como sugeri antes, o MongoDB não é um banco de dados JSON. Ele suporta tipos de dados extras, como ObjectIds, objetos de data nativos, tipos mais numéricos, primitivos geográficos e um tipo binário eficiente, entre outros!
Isso ocorre porque o MongoDB é um banco de dados BSON.
Essa pode parecer uma distinção trivial, mas é importante. Além de ser mais eficiente para armazenar, transferir e percorrer do que usar um formato baseado em texto para dados estruturados, além de oferecer suporte a mais tipos de dados do que o JSON, ele também está em toda parte no MongoDB.
- O MongoDB armazena documentos BSON.
- As consultas para procurar documentos são documentos BSON.
- Os resultados são fornecidos como documentos BSON.
- O BSON é usado até mesmo para o protocolo de fio usado pelo MongoDB!
Se você está costumava trabalhar com JSON ao fazer desenvolvimento web, é um atalho útil pensar no MongoDB como um banco de dados JSON. É por isso que às vezes o descrevemos dessa forma! Mas depois de trabalhar com o MongoDB por um tempo, você aprenderá as vantagens que o BSON tem a oferecer.
Ao ler descrições de terceiros sobre o MongoDB, você pode se deparar com publicações de blog que o descrevem como um banco de dados BASE. BASE é um acrônimo para "Basic Availability; Soft-state; Eventual consistency."
Mas isso não é verdade, e nunca foi! O MongoDB nunca foi "finalmente consistente". As leituras e gravações no primário têm a garantia de serem fortemente consistentes, e as atualizações de um único documento são sempre atômicas. O estado suave aparentemente descreve a necessidade de atualizar continuamente os dados ou eles expirarão, o que também não é o caso.
E, por fim, o MongoDB entrará em um estado somente leitura (reduzindo a disponibilidade) se tantos nós estiverem indisponíveis que não seja possível obter um quorum. Isso foi projetado. Ele garante que a consistência seja mantida quando todo o resto dá errado.
MongoDB é um banco de dados ACID. Suporta atomicidade, consistência, isolamento e durabilidade.
As atualizações de várias partes de documentos individuais sempre foram atômicas; mas desde v4.0, o MongoDB oferece suporte atransações em vários documentos e collections. Desde v4.2, isso é suportado até mesmo em shards em um cluster fragmentado.
Apesar de suportar transações, elas devem ser usadas com cuidado. Elas têm um custo de desempenho e, como o MongoDB oferece suporte a documentos ricos e hierárquicos, se o seu esquema for projetado corretamente, você não precisará atualizar com frequência vários documentos.
Outro Mito desatualizado sobre o MongoDB é que você não pode ter relacionamentos entre coleções ou documentos. Você pode fazer junções com queries que chamamos de aggregation pipelines. Eles são superpotentes, permitindo consultar e transformar seus dados de várias coleções usando um modelo de query intuitivo que consiste em uma série de estágios de pipeline aplicados aos dados que se movem pelo pipeline.
O MongoDB oferece suporte a pesquisas (unições) desde v2.2.
O documento de exemplo abaixo mostra como, após uma query que une uma coleção depedidos e uma coleção deinventário, um documento de pedido retornado contém os documentos de inventário relacionados, incorporados em uma array.
Minha opinião é que ser capaz de incorporar documentos relacionados nos documentos primários que estão sendo retornados é mais intuitivo do que duplicar linhas para cada relacionamento encontrado em uma junção relacional.
Você pode ouvir as pessoas falarem sobre fragmentação como um recurso interessante do MongoDB. E é - é definitivamente uma funcionalidade legal e central do MongoDB.
Fragmentação é quando você divide seus dados e coloca cada parte em um conjunto de réplicas ou cluster diferente. É uma técnica para lidar com enormes conjuntos de dados. O MongoDB oferece suporte automático para garantir que dados e solicitações sejam enviados para os conjuntos de réplicas corretos e mesclar resultados de vários fragmentos.
Mas há um problema fundamental com o sharding.
Mencionei anteriormente neste post que o número mínimo de nós em um conjunto de réplicas é três, para permitir o quorum. Assim que você precisar de sharding, terá pelo menos dois conjuntos de réplicas, o que significa um mínimo de seis servidores. Além disso, você precisa executar várias instâncias de um servidor chamado mongos. O mongos é um proxy para o cluster fragmentado que lida com o roteamento de solicitações e respostas. Para obter alta disponibilidade, você precisa de pelo menos duas instâncias do mongos.
Então, isso significa que um cluster fragmentado mínimo é de oito servidores e aumenta pelo menos três servidores, com cada fragmento adicionado.
Os clusters fragmentados também dificultam o gerenciamento de seus dados e adicionam algumas limitações aos tipos de consultas que você pode realizar. A fragmentação é útil se você precisar, mas geralmente é mais barato e fácil simplesmente atualizar seu hardware!
O dimensionamento de dados tem a ver principalmente com RAM, então, se puder, adquira mais RAM. Se a CPU for seu gargalo, atualize sua CPU ou compre um disco maior, se esse for o seu problema.
Os recursos de fragmentação do MongoDB ainda estarão disponíveis quando você escalar além da quantidade de RAM que pode ser colocada em um único computador. Você também pode fazer coisas legais com shards, como geo-pinning, onde você pode armazenar dados do usuário geograficamente mais próximo da localização do usuário, para reduzir a latência.
Se estiver tentando escalonar por meio de sharding, deve pelo menos considerar se os upgrades de hardware seriam uma alternativa mais eficiente, primeiro.
E antes de considerar isso, você deve dar uma olhada no MongoDB Atlas, o produto de banco de dados como serviço hospedado do MongoDB. (Sim, eu já mencionei isso! ) Além de hospedar seu banco de dados para você, na nuvem (ou nuvens) de sua escolha, o MongoDB Atlas também aumentará e reduzirá seu banco de dados conforme necessário, mantendo você disponível, enquanto mantém os custos baixos. Ele lidará com backups e redundância e também inclui recursos extras, como Atlas Charts, pesquisa de texto, funções sem servidore muito mais.
Um Mito persistente sobre o MongoDB é que ele é fundamentalmente inseguro. Meu sentimento pessoal é que este é um dos mitos mais injustos sobre o MongoDB, mas não se pode negar que existem muitas instâncias inseguras do MongoDB disponíveis na Internet e houve várias violações de dados de alto perfil envolvendo o MongoDB.
Isso se deve historicamente à forma como o MongoDB foi distribuído. Algumas distribuições Linux costumavam enviar o MongoDB com a autenticação desativada e com a rede ativada.
Então, se você não tivesse um firewall, ou se você abrisse a porta MongoDB no firewall para que ele pudesse ser acessado pelo seu servidor da web... seus dados seriam furtados. Hoje em dia, é provável que um bot encontre seus dados, criptografe-os em seu banco de dados e, em seguida, adicione um documento informando para onde enviar o Bitcoin para obter a chave para descriptografá-lo novamente.
Eu diria que se você colocar um servidor de banco de dados desprotegido na Internet, a culpa é sua - mas definitivamente isso já aconteceu muitas vezes e havia maneiras de tornar mais difícil bagunçar tudo.
Corrigimos os padrões no MongoDB 3.6. O MongoDB não se conectará à rede a menos que a autenticação esteja ativada ou você fornece uma bandeira específica ao servidor para substituir esse comportamento. Então, você ainda pode estar inseguro, mas agora tem que pelo menos ler o manual primeiro!
Fora isso, oMongoDB usa padrões do setor para segurança, como TLS para criptografar os dados em trânsito, e SCRAM-SHA-256 para autenticar usuários com segurança.
O MongoDB também possui criptografia em nível de campo (FLE) do lado do cliente , que permite armazenar dados no MongoDB para que sejam criptografados tanto em trânsito quanto em repouso. Isso significa que se terceiros obtivessem acesso ao seu servidor de banco de dados, eles não conseguiriam ler os dados criptografados sem também obter acesso ao cliente.
Este mito é um tropo clássico do Hacker News. Uma pessoa publica um exemplo de como criou algo com sucesso com o MongoDB e há um comentário imediato: "Conheço um sujeito que uma vez perdeu todos os seus dados no MongoDB. Ele simplesmente o jogou fora. Evitar."
Se você pedir a esses usuários que entrem em contato e registrem um tíquete descrevendo o incidente, eles nunca aparecerão!
O MongoDB é usado em uma variedade de setores que se importam profundamente em manter seus dados. Eles variam de bancos como Banco de Dados do Banco de Dados, Banco de Dados e HSBC a grandes marcas de editoração, como a Forbe s. Nunca houve um registro de perda de dados em grande escala. Se você tiver uma história em primeira mão para contar sobre a perda de dados,registre um ticket. Vamos levar isso a série, seja você um cliente corporativo pagante ou um usuário de código aberto.
Se você leu até este ponto, já pode ver que esse é um Mito!
O MongoDB é um banco de dados de uso geral para armazenar documentos, que pode ser atualizado de forma segura e atômica, com junções a outros documentos e uma linguagem de query rica, poderosa e intuitiva para localizar e agregar esses documentos na forma que você precisa. Quando seus dados ficam grandes demais para uma única máquina, ele oferece suporte à fragmentação pronta para uso e oferece suporte a recursos avançados, como criptografia no nível do campo do lado do cliente para proteger dados confidenciais, e change streams, para permitir que seus aplicativos respondam imediatamente às alterações aos seus dados, usando qualquer linguagem, framework e conjunto de bibliotecas que você prefira desenvolver.
Se você quiser se proteger dos mitos no futuro, sua melhor aposta é...
MongoDB é um banco de dados fácil de começar, mas a criação de aplicativos de produção exige que você domine as complexidades da interação com um banco de dados distribuído. MongoDB Atlas simplifica muitos desses desafios, mas você aproveitará ao máximo o MongoDB se dedicar tempo ao aprendizado de coisas como a estrutura de agregação, read concernse write concerns. Nada difícil é fácil, mas o difícil é mais fácil com o MongoDB. Você não vai se tornar um especialista da noite para o dia. A boa notí
No Blog do programador do MongoDB, detalhamos alguns padrões do MongoDB para projeto e desenvolvimento de esquemas, e minha popular colegaLaureen Scheefer está produzindo uma série de publicações descrevendo os antivadões do MongoDB para ajudá-lo a reconhecer quando não estiver fazendo as coisas da maneira ideal.
Portanto, o MongoDB é grande e poderoso, e há muito a aprender. Espero que este artigo tenha ajudado a explicar o que é o MongoDB, o que ele não é e como você pode aprender a usá-lo de forma eficaz.
Avalie esse Artigo