Please enable JavaScript.
Coggle requires JavaScript to display documents.
MongoDB - Coggle Diagram
MongoDB
Conceitos Comuns
Orientado a documentos, semelhantes a JSON.
Utiliza sharding para particionar os dados horizontalmente em vários servidores (possui agora shard keys mutáveis, facilitando a redistribuição dos dados)
-
Utiliza protocolo líder-seguidor, permitindo réplicas para workloads com leituras intensivas
Oferece consistência rígida, assegurando que todos os membro de um conjunto de réplicas tenham os mesmos dados
Garante atomicidade e isolamento em operações de escrita concorrentes ao nível de documento (que pode conter vários registros ex funcionário e seus dependentes). Agora se uma transação mexer em dois documentos, ela não é atômica entre eles (recomendado não utilizar muito transações)
Ao contrário dos key-value que tem consultas muito simples (altera valor, remove valor, etc), tem além disso uma linguagem de consulta rica que permite recuperar e manipular os dados com facilidade
Modelagem de dados flexível, permitindo alterações no esquema sem afetar o sistema como um todo
Suporta ampla gama de opções de indexação, incluindo índices secundários, pesquisa de texto e indexação geoespacial
Possui framework de agregação (sumarização, maior, menor, etc) para análise de dados e geração de relatórios
Arquitetura
Collection, que é um grupo de documentos, equivalente a uma tabela de um relacional
Capped Collection tem um tamanho máximo definido e os documentos são mantidos na ordem de inserção. Logo ao chegar no limite, os documentos mais antigos são sobrescritos. Ideal para logs
Document que são os registros, linhas da tabela e contêm pares de chave-valor
Database conteiner para coleções, que contém todos os dados para um aplicativo específico
Shards, para particionamento horizontal. Cada shard possui servidores primários e secundários (que podem estar até em data centers diferentes, sendo os mais próximos para transacional e os mais distantes para relatórios, por exemplo)
Réplica Set, grupo de servidores que mantém cópias idênticas dos mesmos dados
-
-
Pode ter uma instância como um arbiter para ajudar o cluster a definir o consenso se um nó está up ou não
-
Mirrored Reads ajudam no processo após um failover do replica set. Enquanto o secundário que assumiu como primário atualiza seu cache, pode ter problemas de desempenho. Daí esses mirrored reas pré aquecem o cache dos nós secundários elegíveis
Query router, que recebem as solicitações dos clientes, determinam a localização dos dados necessários e direciona para o shard apropriado
Configuration Server armazenam os metadados e definições de configuração para um cluster MogoDB. Responsáveis por manter o mapeamento de shards para Replica Sets
Índices
-
Stage: como foi feito. COLLSCAN = full table scan, IXSCAN = varredura por índice
-
Para índices compostos é importante fazer consultas na mesma sequência dos atributos que fazem parte do índice
Índice esparso: quando temos um índice composto por atributo (ex. telefone) que não tem o valor preenchido em todas as collections. Daí ele só indexa as collections que tem esse valor preenchido (ao ínves de colocar NULL).
Wildcard Indexes (índices coringa) indexa os documentos, mesmo que ainda eu não saiba exatamente quais atributos a collection tenha. Pode indexar todos os atributos ou mesmo alguns Ex. db.minhaColecao.createIndex({"$**": 1}) ou db.minhaColecao.createIndex({"detalhes.$**": 1}). É possível colocar um filtro no atributo, exemplo, "indexe todos os documentos com status ativo" ou indexe todos menos os atributos x (com 0) - útil para dados sensíveis que nem seriam pesquisados mesmo
Text indexes tentativa de concorrer com o ElasticSearch. Serve para consultas em texto com strin $text. Ele cria tokens dentro do texto. O Mongo retorna pesquisa de texto com uma pontuação de relevância sobre o quão bem o documento corresponde a consulta. Você também consegue setar o idioma
Sharding
Particionamento vertical é a divisão dos atributos e horizontal é por linhas, mantendo todos os atributos (mais comuns)
No MongoDB pegamos "pedaços" de cada collection e distribuimos entre os servidores. O Mongo tenta balancear para que cada shard tenha a mesma quantidade de dados. Mesmo se você não particionar uma collection, ela fica dentro de um shard (Ficam em um shard primário)
-
Shard keys atributo para distribuir os documentos da Collection entre os shards (pode ser um ou mais)
Devem ser boas escolhas para representar bem o espalhamento dos dados. Ex: uma má escolha seria utilizar como shard key o id de lojas, sendo que 90% das vendas são da matriz ("hot key"). Boas escolhas são atributos aleaórios (ex. nome + telefone)
Mesmo se a collection tiver algum desses atributos como nulo, não tem problema, mas atenção que ele vai direcionar todos nulos para o mesmo lugar.
Atenção: você precisa ter obrigatoriamente um índice com os atributos da shard key, mesmo que tenha outros
Dois tipos: Hashed shards, baseado em hash ou Ranged shards em que são distribuídos 0-100, 101-200, etc
Chunks intervalo contíguo de valores de shard keys dentro de um shard. Tem um interalo superior e inferiro com base na shard key. Subdivisão de um shard, onde de fato as informações estão armazenadas
Zones podemos criar zonas de acordo com uma ou mais as shard keys. Um shard pode estar associado a qualquer número de zones. Ex.: zona baseada em geografia
Balancer quando uma quantidade de dados para uma sharded collection em um determinado shard atinge os limites de migração especificados, o balancer tenta migrar automaticamente entre shards para atingir uma quantidade uniforme de dados por shard, respeitando as zones
Storage
Storage engine mecanismos responsáveis por gerenciar como os dados são armazenados, recuperados e mantidos no sistema de arquivos. Ex.: WiredTiger
Wired Tiger suporta compressão de dados e índices, controle de concorrência a nível de documento (melhorando desempenho em operações simultâneas) e journaling (armazena os dados em log entre um checkpoint e outro). Normalmente a melhor escolha
In memory mantém todos os dados na memória, ideal para aplicações que requerem baixa latência (mas pode perder dados)
MMAPv1 antigo, ainda com concorrência a nível de collection
-
Write Concern (como tratar o caso de escritas que não foram confirmadas em banco de dados distribuídos). Define regras que dirão quando podemos confirmar que um dado foi salvo (ex. só depois que for escrito na principal e em 1 secundária)
Retriable Reads/Write parametriza o número de retentativas de escrita/leitura em caso de falhas de rede
-
Modelagem dos Dados
Esquema flexível, onde não são impostas uma estrutura rígida prévia.
A estrutura de Collections permite o mapeamento direto do que está no banco com a entidade aplicação, sem junções
A principal decisão é em torno da estrutura dos documentos e de como o aplicativo representa relacionamento entre os dados: referências ou documentos aninhados. O caso aqui é diferente dos relacionais: enquanto SQL você pensa nos relacionamentos e depois na consulta, NoSQL você pensa nas consultas e depois nos relacionamentos
Relacionamentos
1:1 com documentos aninhados (consome recursos para trazer todos os dados, quando você precisa apenas de 1)
1:N com documentos aninhados, o que faz com que busquemos todos os dados de uma só vez (bom para cenário que sempre busco os dados de pai e filho)
1:N com referências (consome recursos para várias buscas para pegar as referências). Bom se preciso só de 1 informação
Referências um documento filho possui um ID para um documento pai (mas posso deletar um pai sem deletar o filho). Documentos aninhados para evitar as junções ex.: armazenar funcionários e dependentes em uma mesma collection
Agregation Framework
-
-
MAP, REDUCE desacopla para reduzir dados para serem processados por algum atributo. Depois utiliza o reduce para executar alguma operação em cada grupo
Materialized Views
-
Você pode tanto criar uma nova view (nova collection) com $out quanto incluir um atributo novo a uma collection existente $merge